Hi I trying to instal chef opscode-manage via:
chef-server-ctl install opscode-manage
But it hangs ( or takes too much time )
Any ideas?
My env:
$ cat /etc/issue
Red Hat Enterprise Linux Server release 6.7 (Santiago)
Kernel \r on an \m
chef-server-core-12.2.0-1.el6.x86_64.rpm
Does it hang when running as root or sudo?
both ways:
Interesting
, funny things after running this command, I notice via ps uax | grep
chef-client that a proper chef-client gets run and try to install
opscode-manage , but it HANGS FOREVER, I mean I get no output from
chef-server-ctl install opscode-manage command
BUT, if U
type CTRL+C and make chef-server-ctl install opscode-manage stop and I
start to see output from chef-client telling me that it installs
opscode-manage stuff.
And finally have Chef Client finished in output.
I
guess the same weird things with other chef-server-ctl install command (
which runs chef-client underhood ), hitting CTLR + C make them "alive"
but this is really strange …
And yeah, the same thing with:
sudo opscode-manage-ctl reconfigure
both ways:
sudo chef-server-ctl install opscode-managechef-server-ctl install opscode-manage # under rootInteresting , funny things after running this command, I notice via ps uax | grep chef-client that a proper chef-client gets run and try to install opscode-manage , but it HANGS FOREVER, I mean I get no output from chef-server-ctl install opscode-manage command
BUT, if I type CTRL+C and make chef-server-ctl install opscode-manage
stopped then start to see output from chef-client telling me that it installing opscode-manage stuff. And finally have “Chef Client finished” in output.
I guess the same weird things with other chef-server-ctl install command ( any which runs chef-client under the hood ), hitting CTLR + C make them “alive” but this is really strange …
sudo chef-server-ctl reconfigure the same trouble … I need to hit CTRL+C to make it finished …
A few questions:
Do you only see this with Manage, or with other add ons as well (I think the answer is you see it with all of them, but could you explicit list them)?
When you hit ctrl-c, does it seem to have completed fine, it was just hanging at the end of the process?
Does Manage appear to have installed correctly and be operating correctly?
What version of Manage are you installing/is being installed? What is the package name?
Is this only when doing a chef-server-ctl install, or do you see it when running other chef-server-ctl commands to?
If Manage has been successfully installed on the box, do chef-manage-ctl commands work?
What is the size of the machine, in terms of CPU, RAM, etc?
These questions will help determine if this is something specific to your setup or an odd bug that we somehow missed.
And yes, it is running a chef run to setup the server and add ons. Specifically it’s a chef-zero (chef client --local-mode) run being done by the chef client that is bundled the the server and add ons specifically for setting them up. It’s Chef all the way down.
One other question to add: Are you running SE Linux?
I encountered this with :
chef-server-ctl install opscode-manage
chef-server-ctl opscode-manage-ctl reconfigure
chef-server-ctl reconfigure
As I told hitting CTRL+C make it appeared output from chef-client and finally I see it finished and then obviously I have a a proper component installed ( f.e. opscode manager ). And yes chef-manage-ctl works fine
Sure it is chef-client running with chef-zero
-bash-4.1$ free -m
total used free shared buffers cached
Mem: 7868 6332 1536 80 317 3264
-/+ buffers/cache: 2750 5117
Swap: 2047 0 2047
-bash-4.1$ cat /proc/cpuinfo | grep processor
processor : 0
processor : 1
processor : 2
processor : 3
processor : 4
processor : 5
processor : 6
processor : 7
And disk:
Size Used Avail Use% Mounted on
20G 5.6G 14G 30% /
976M 1.3M 924M 1% /admhome
488M 75M 389M 17% /boot
2.0G 7.7M 1.8G 1% /tmp
9.8G 1.5G 7.9G 16% /var
20G 2.7M 19G 1% /apps
Probably not ?
-bash-4.1$ sudo sestatus
SELinux status: disabled
-bash-4.1$ sudo cat /etc/sysconfig/selinux
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - SELinux is fully disabled.
SELINUX=disabled
# SELINUXTYPE= type of policy in use. Possible values are:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
SELINUXTYPE=targeted
To follow up and close out this thread, it looks like this might be a bug related to having the Chef 11 client on the system with the Chef 12 server installed and that perhaps a clash is happening somewhere. The best place to follow this for updates will be the GitHub issue.