Hi,
I'm noticing some strangeness with chkconfig on CentOS 6.0 and was looking for a bit of advice.
It appears that chkconfig is re sequencing or re ordering the start priority of various services when turning on a service using chkconfig. Example is the network service. Under normal circumstances network is set to start at S10. However when I add something like snmpd and invoke chkconfig snmpd on it will change network to S81. Which fouls up some of my other services that look for config files on NFS shares.
Testing this issue with the snmpd service I removed $network from Required-Start which did nothing.
The only solution I've found is to remove the entire BEGIN INIT INFO to END INIT INFO section. Once that is removed it no longer changes the network startup priority when enabling the snmpd service.
Seems to me that you'd want network started before snmpd. So why chkconfig wants to re arrange it to start after snmpd which defaults to S50 is beyond me.
So why would it do that? Did I miss some documentation or something? :-)
Thanks in advance for any assistance!
--Jerry
--On Friday, July 22, 2011 11:10:29 AM -0700 Jerry Moore tech10@mcn.org wrote:
It appears that chkconfig is re sequencing or re ordering the start priority of various services when turning on a service using chkconfig.
[...]
The only solution I've found is to remove the entire BEGIN INIT INFO to END INIT INFO section. Once that is removed it no longer changes the network startup priority when enabling the snmpd service.
SuSE (and perhaps some other distributions) have for a few years been using that BEGIN/END INIT INFO block instead of the 'chkconfig' line to determine ordering, and will do exactly as you described.
Without having looked into the CentOS 6 case, I would guess that the mechanism used in RHEL has changed to match. This could very well be related to the LSB project, although that's just a guess, too.
Devin
On Jul 22, 2011, at 12:00 PM, Devin Reade wrote:
SuSE (and perhaps some other distributions) have for a few years been using that BEGIN/END INIT INFO block instead of the 'chkconfig' line to determine ordering, and will do exactly as you described.
Without having looked into the CentOS 6 case, I would guess that the mechanism used in RHEL has changed to match. This could very well be related to the LSB project, although that's just a guess, too.
Devin
Hi Devin,
Is it possible to sticky a service then to always start at the value chkconfig lists? Moving various services around like that isn't very helpful when I specifically need services to start is an exact order.
Or if I do remove the BEGIN/END INIT INFO block from the init scripts will that cause issues?? What's the solution in the SuSE world when someone wants a service to not get reordered??
Thanks!
--Jerry
--On Friday, July 22, 2011 12:12:28 PM -0700 Jerry Moore tech10@mcn.org wrote:
Is it possible to sticky a service then to always start at the value chkconfig lists? Moving various services around like that isn't very helpful when I specifically need services to start is an exact order.
Or if I do remove the BEGIN/END INIT INFO block from the init scripts will that cause issues?? What's the solution in the SuSE world when someone wants a service to not get reordered??
I'm afraid I don't have the answers to those ones. Although I occasionally have need to deal with SuSE, the Linux distributions I use most of the time are RHEL/CentOS. The most I can do is point you at google, although knowing the SuSE relationship might help you there.
My suspicion is that assuming that RHEL has indeed changed the mechanism we're in the "growing pains" transition period where various rc scripts may need to be tweaked (especially custom ones).
Devin
On Fri, 2011-07-22 at 13:00 -0600, Devin Reade wrote:
--On Friday, July 22, 2011 11:10:29 AM -0700 Jerry Moore tech10@mcn.org wrote:
It appears that chkconfig is re sequencing or re ordering the start priority of various services when turning on a service using chkconfig.
[...]
The only solution I've found is to remove the entire BEGIN INIT INFO to END INIT INFO section. Once that is removed it no longer changes the network startup priority when enabling the snmpd service.
SuSE (and perhaps some other distributions) have for a few years been using that BEGIN/END INIT INFO block instead of the 'chkconfig' line to determine ordering, and will do exactly as you described.
Without having looked into the CentOS 6 case, I would guess that the mechanism used in RHEL has changed to match. This could very well be related to the LSB project, although that's just a guess, too.
System V init has been replaced by "upstart"
Upstream Deployment Guide: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_...
Fedora Wiki: http://fedoraproject.org/wiki/Features/Upstart
Run levels are depreciated: http://en.wikipedia.org/wiki/Runlevel http://en.wikipedia.org/wiki/Upstart
This change has been in the works for a few years: http://lists.centos.org/pipermail/centos/2009-September/082817.html
Some articles from Google search [RHEL centos upstart] http://www.linux.com/archive/articles/57213 http://searchenterpriselinux.techtarget.com/tip/RHEL-6-ditches-System-V-init...
On Jul 22, 2011, at 12:17 PM, Cal Webster wrote:
System V init has been replaced by "upstart"
Upstream Deployment Guide: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_...
Fedora Wiki: http://fedoraproject.org/wiki/Features/Upstart
Run levels are depreciated: http://en.wikipedia.org/wiki/Runlevel http://en.wikipedia.org/wiki/Upstart
This change has been in the works for a few years: http://lists.centos.org/pipermail/centos/2009-September/082817.html
Some articles from Google search [RHEL centos upstart] http://www.linux.com/archive/articles/57213 http://searchenterpriselinux.techtarget.com/tip/RHEL-6-ditches-System-V-init...
Hey Cal,
I knew I was missing something!
Thanks for the assist guys!
--Jerry
On Fri, 2011-07-22 at 12:47 -0700, Jerry Moore wrote:
On Jul 22, 2011, at 12:17 PM, Cal Webster wrote:
System V init has been replaced by "upstart"
Upstream Deployment Guide: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_...
Fedora Wiki: http://fedoraproject.org/wiki/Features/Upstart
Run levels are depreciated: http://en.wikipedia.org/wiki/Runlevel http://en.wikipedia.org/wiki/Upstart
This change has been in the works for a few years: http://lists.centos.org/pipermail/centos/2009-September/082817.html
Some articles from Google search [RHEL centos upstart] http://www.linux.com/archive/articles/57213 http://searchenterpriselinux.techtarget.com/tip/RHEL-6-ditches-System-V-init...
Hey Cal,
I knew I was missing something!
Thanks for the assist guys!
Hold onto your hat Jerry...
Upstart has already been replace by systemd in Fedora 15 and most other major distros are planning to use it too. RHEL 7 will most likely switch to systemd if it stays in Fedora. If it does everything planned you may even see it in a 6.x point release. This after only about a year in distribution.
An overview on Wikipedia: http://en.wikipedia.org/wiki/Systemd
A year-old article summarizing blog posts by authors of upstart and systemd http://www.h-online.com/open/news/item/Systemd-presented-as-SysV-Init-and-Up...
A year-old (30 Apr 2010) Lennart Poettering (systemd author) blog post announcing systemd with detail about systemd: http://0pointer.de/blog/projects/systemd.html
A recent (28 Apr 2011) blog post by Lennart Poettering attempting to answer the question "Why systemd?". Includes a side-by-side comparison of features between sysvinit, upstart, and systemd. http://0pointer.de/blog/projects/why.html
A year-old (30 Apr 2010) blog post by Scott Remnant (upstart author) with candid remarks about systemd. http://netsplit.com/2010/04/30/on-systemd/
./Cal
--On Friday, July 22, 2011 11:10:29 AM -0700 Jerry Moore tech10@mcn.org wrote:
It appears that chkconfig is re sequencing or re ordering the start priority of various services when turning on a service using chkconfig. Example is the network service. Under normal circumstances network is set to start at S10. However when I add something like snmpd and invoke chkconfig snmpd on it will change network to S81. Which fouls up some of my other services that look for config files on NFS shares.
Testing this issue with the snmpd service I removed $network from Required-Start which did nothing.
Again just guessing (my one test CentOS 6 system doesn't currently have snmpd installed) have a look at not only the snmpd script but also the ones that should have been started between network and snmpd. It sounds like some dependencies are missing.
In particular, do your "other services" depend on $network, either directly or transitively?
You might also want to experiment with 'chkconfig XXXXXX reset'.
Devin
On Jul 22, 2011, at 12:10 PM, Devin Reade wrote:
Again just guessing (my one test CentOS 6 system doesn't currently have snmpd installed) have a look at not only the snmpd script but also the ones that should have been started between network and snmpd. It sounds like some dependencies are missing.
In particular, do your "other services" depend on $network, either directly or transitively?
You might also want to experiment with 'chkconfig XXXXXX reset'.
Devin
Hey Devin,
I'm feeling a little silly now and I swear I checked for this but you hit the nail on the head. Turns out I had pushed a service that was dependent on network further down the list so whenever I enabled snmpd in chkconfig it would re order network below the other dependent service.
Thanks again for the help!
--Jerry
-
Cal Webster -
Devin Reade -
Jerry Moore