Devstack installation failed with error message «XXX: no process found»
I’m trying to install Devstack on VMware cloud. After starting to run ./stack.sh, installation is failed with following error message.
+lib/cinder:create_volume_types:531 openstack --os-region-name=RegionOne volume type create --property volume_backend_name=lvmdriver-1 lvmdriver-1 Internal Server Error (HTTP 500) +lib/cinder:create_volume_types:1 exit_trap +./stack.sh:exit_trap:489 local r=1 ++./stack.sh:exit_trap:490 jobs -p +./stack.sh:exit_trap:490 jobs= +./stack.sh:exit_trap:493 [[ -n '' ]] +./stack.sh:exit_trap:499 '[' -f /tmp/tmp.Y95KBJPvp8 ']' +./stack.sh:exit_trap:500 rm /tmp/tmp.Y95KBJPvp8 +./stack.sh:exit_trap:504 kill_spinner +./stack.sh:kill_spinner:399 '[' '!' -z '' ']' +./stack.sh:exit_trap:506 [[ 1 -ne 0 ]] +./stack.sh:exit_trap:507 echo 'Error on exit' Error on exit +./stack.sh:exit_trap:509 type -p generate-subunit +./stack.sh:exit_trap:510 generate-subunit 1588897469 720 fail +./stack.sh:exit_trap:512 [[ -z /opt/stack/logs ]] +./stack.sh:exit_trap:515 /usr/bin/python3.6 /opt/devstack/tools/worlddump.py -d /opt/stack/logs World dumping. see /opt/stack/logs/worlddump-2020-05-08-003630.txt for details nova-compute: no process found neutron-dhcp-agent: no process found neutron-l3-agent: no process found neutron-metadata-agent: no process found neutron-openvswitch-agent: no process found +./stack.sh:exit_trap:524 exit 1 It looks like HTTP 500 error is the primary issue. But ping to HOST_IP works very well so I can’t figure out the cause.
[[local|localrc]] # Credentials ADMIN_PASSWORD=devstack MYSQL_PASSWORD=devstack RABBIT_PASSWORD=devstack SERVICE_PASSWORD=devstack SERVICE_TOKEN=token # Network Address HOST_IP=(. ) nova-compute Guru Meditation Report =================================== 19171 killall -e -USR2 nova-compute ----------------------------- *** Failed to run 'killall -e -USR2 nova-compute': Command 'killall -e -USR2 nova-compute' returned non-zero exit status 1. guru meditation report in nova-compute log neutron-dhcp-agent Guru Meditation Report ========================================= 7758 killall -e -USR2 neutron-dhcp-agent ----------------------------------- *** Failed to run 'killall -e -USR2 neutron-dhcp-agent': Command 'killall -e -USR2 neutron-dhcp-agent' returned non-zero exit status 1. guru meditation report in neutron-dhcp-agent log neutron-l3-agent Guru Meditation Report ======================================= 8482 killall -e -USR2 neutron-l3-agent --------------------------------- *** Failed to run 'killall -e -USR2 neutron-l3-agent': Command 'killall -e -USR2 neutron-l3-agent' returned non-zero exit status 1. guru meditation report in neutron-l3-agent log neutron-linuxbridge-agent Guru Meditation Report ================================================ Skipping as neutron-linuxbridge-agent does not appear to be running neutron-metadata-agent Guru Meditation Report ============================================= 9103 9719 9720 killall -e -USR2 neutron-metadata-agent --------------------------------------- *** Failed to run 'killall -e -USR2 neutron-metadata-agent': Command 'killall -e -USR2 neutron-metadata-agent' returned non-zero exit status 1. guru meditation report in neutron-metadata-agent log neutron-openvswitch-agent Guru Meditation Report ================================================ 7127 killall -e -USR2 neutron-openvswitch-agent ------------------------------------------ *** Failed to run 'killall -e -USR2 neutron-openvswitch-agent': Command 'killall -e -USR2 neutron-openvswitch-agent' returned non-zero exit status 1. guru meditation report in neutron-openvswitch-agent log cinder-volume Guru Meditation Report ==================================== 21971 killall -e -USR2 cinder-volume ------------------------------ guru meditation report in cinder-volume log killall gives me `no process found ` but ps
Could somebody explain to me the difference between kill and killall ? Why doesn’t killall see what ps shows?
# ps aux |grep db2 root 1123 0.0 0.8 841300 33956 pts/1 Sl 11:48 0:00 db2wdog db2inst1 1125 0.0 3.5 2879496 143616 pts/1 Sl 11:48 0:02 db2sysc root 1126 0.0 0.6 579156 27840 pts/1 S 11:48 0:00 db2ckpwd root 1127 0.0 0.6 579156 27828 pts/1 S 11:48 0:00 db2ckpwd root 1128 0.0 0.6 579156 27828 pts/1 S 11:48 0:00 db2ckpwd # killall db2ckpwd db2ckpwd: no process found # kill -9 1126 # kill -9 1127 # kill -9 1128 System is SuSe 11.3 (64 bit); kernel 2.6.34-12; procps version 3.2.8; killall from PSmisc 22.7; kill from GNU coreutils 7.1
5 Answers 5
There are actually a few subtly different versions of the command name that are used by ps , killall , etc.
The two main variants are: 1) the long command name, which is what you get when you run ps u ; and 2) the short command name, which is what you get when you run ps without any flags.
Probably the biggest difference happens if your program is a shell script or anything that requires an interpreter, e.g. Python, Java, etc.
Here’s a really trivial script that demonstrates the difference. I called it mycat :
After running it, here’s the two different types of ps .
$ ps -p 5290 PID TTY . CMD 5290 pts/6 . mycat $ ps u 5290 USER PID . COMMAND mikel 5290 . /bin/sh /home/mikel/bin/mycat Note how the second version starts with /bin/sh ?
Now, as far as I can tell, killall actually reads /proc//stat , and grabs the second word in between the parens as the command name, so that’s really what you need to be specifying when you run killall . Logically, that should be the same as what ps without the u flag says, but it would be a good idea to check.
- what does cat /proc//stat say the command name is?
- what does ps -e | grep db2 say the command name is?
- do ps -e | grep db2 and ps au | grep db2 show the same command name?
If you’re using other ps flags too, then you might find it simpler to use ps -o comm to see the short name and ps -o cmd to see the long name.
You also might find pkill a better alternative. In particular, pkill -f tries to match using the full command name, i.e. the command name as printed by ps u or ps -o cmd .
killall chromium-browser: no process found
I had been able to do killall chromium-browser to stop all chromium browser sessions, but not anymore:
$ killall chromium-browser chromium-browser: no process found $ apt-cache policy chromium-browser chromium-browser: Installed: 58.0.3029.110-0ubuntu0.17.04.1354 Candidate: 58.0.3029.110-0ubuntu0.17.04.1354 Is there still some tricks to kill chromium browser sessions this way? More details: I searched and found pkill chromium , but that’s not what I want, because when using killall chromium-browser , all my chromium browser sessions are stopped and memory released
2 Answers 2
Focus on achieving your goal, not on fixing the specific tool. If you’re trying to kill Chromium’s tab processes but not the main process, start by comparing their command lines, e.g. using ps -efww or pgrep -alf chromium .
You’ll see that all «child» processes have a parameter like —type=zygote or —type=renderer . Since this directly describes the process’ purpose, it will be more reliable than relying on minor differences in the executable name (which has nothing to do it as all Chromium subprocesses are named the same; the fact that «chromium-browser» used to work was just an artifact of Ubuntu’s packaging).
Since this is part of the command line, you’ll have to use pkill -f to match it:
pkill -f -- "--type=renderer" pkill -f -- "chromium --type=renderer" Thanks a lot! Yes, achieving the goal! That’s most important. FYI, I tried command #2 first but it didn’t work, but #1 works. Then I realize that #2 should be pkill -f — «chromium-browser —type=renderer» under Ubuntu.
You can often times achieve exactly what was requested here by using the — Task Manager in Chrome/Chromium. This gives you an easy way to see which tabs are behaving badly and killing them individually with the End process button.
That’s nice, but sometimes you just need to take charge of things from the Linux command-line.
Being able to kill browser processes seems to be a fundamental requirement of maintaining a stable Linux system. Unfortunately, the methods that work for this seem to be continually evolving. It’s a battle of wills, I guess.
I haven’t figured out what’s wrong with killall , which I previously used for this.
pkill is funny. Despite being produced by tab completion, pkill chromium-browser has no effect (just quietly returns an error status). But leave off the trailing r and you’re in business. pkill chromium-browse . I’m not sure it does exactly what you want, but at least it does something. I also found that running the command more than once makes a difference.
One clue is that ps -e also displays the shortened version of the name: chromium-browse
. And as noted by the OP in a comment to another answer, this command seems to work well (at the moment) for killing all tabs without killing windows.
pkill -f -- "chromium-browser --type=renderer" killall gives me `no process found ` but ps
There are actually a few subtly different versions of the command name that are used by ps , killall , etc.
The two main variants are: 1) the long command name, which is what you get when you run ps u ; and 2) the short command name, which is what you get when you run ps without any flags.
Probably the biggest difference happens if your program is a shell script or anything that requires an interpreter, e.g. Python, Java, etc.
Here’s a really trivial script that demonstrates the difference. I called it mycat :
After running it, here’s the two different types of ps .
$ ps -p 5290 PID TTY . CMD 5290 pts/6 . mycat $ ps u 5290 USER PID . COMMAND mikel 5290 . /bin/sh /home/mikel/bin/mycat Note how the second version starts with /bin/sh ?
Now, as far as I can tell, killall actually reads /proc//stat , and grabs the second word in between the parens as the command name, so that’s really what you need to be specifying when you run killall . Logically, that should be the same as what ps without the u flag says, but it would be a good idea to check.
- what does cat /proc//stat say the command name is?
- what does ps -e | grep db2 say the command name is?
- do ps -e | grep db2 and ps au | grep db2 show the same command name?
If you’re using other ps flags too, then you might find it simpler to use ps -o comm to see the short name and ps -o cmd to see the long name.
You also might find pkill a better alternative. In particular, pkill -f tries to match using the full command name, i.e. the command name as printed by ps u or ps -o cmd .
Solution 2
killall tries to match on a process name (but is not really that good at the matching part).
And since ps | grep and ps | grep | kill does a much better job, someone simplified this and created pgrep and pkill . Read that commands like ps grep and ps kill , since that command first ps then grep and if wanted kills.
Solution 3
I had a similar problem but /proc//stat contained the expected string. By using strace I could see that killall also accessed /proc//cmdline .
I continued to investigate using gdb to find that in my case it failed on a check of my command to the full command including all args found in /proc//cmdline . It seemed like that path of the code triggered due to the filename being longer than 15 chars (which is a hardcoded value in the source of killall). I didn’t fully investigate if I could somehow getting it to work with killall.
But as mentioned in other comments here pkill is a better alternative that does not have the same issues.