Description of problem: After an upgrade from F8 to F10 links in /etc/rc.d looks like follows: /etc/rc.d/rc6.d/K74rsyslog /etc/rc.d/rc0.d/K74rsyslog /etc/rc.d/rc5.d/S26rsyslog /etc/rc.d/rc1.d/K74rsyslog /etc/rc.d/rc4.d/S26rsyslog /etc/rc.d/rc2.d/S26rsyslog /etc/rc.d/rc3.d/S26rsyslog despite that chkconfig markup in /etc/rc.d/init.d/rsyslog says: # chkconfig: 2345 12 88 The issue is that some other deamons, like setroubleshootd, depend on rsyslog running during their startup and you will see something like: "exception when creating syslog handler: (2, 'No such file or directory')" otherwise. After 'chkconfig --del rsyslog; chkconfig --add rsyslog' links become /etc/rc.d/rc6.d/K88rsyslog /etc/rc.d/rc0.d/K88rsyslog /etc/rc.d/rc5.d/S12rsyslog /etc/rc.d/rc1.d/K88rsyslog /etc/rc.d/rc4.d/S12rsyslog /etc/rc.d/rc2.d/S12rsyslog /etc/rc.d/rc3.d/S12rsyslog like they should be. It would be nice to have such operation done in a package script; possibly conditional on an existence of /etc/rc.d/rc3.d/S12rsyslog Version-Release number of selected component (if applicable): rsyslog-3.21.9-1.fc10
This is strange, I've checked several packages in F8, F10 and they all contain: # chkconfig: 2345 12 88 so I'm wondering where do those symlinks come from. Would it be possible to find out from which rsyslog version you were upgrading? Additionally, the packages in F10 contain unconditional "chkconfig --add rsyslog" which should correct the symlink names.
> ... they all contain: # chkconfig: 2345 12 88 Maybe this is even older "leftover", which was not so essential up to now and it was just lingering, but I noticed the same "26 74" order on at least three upgraded machines. An F9 installation I have around shows links at "12 88". > Would it be possible to find out from which rsyslog version you were upgrading? It was rsyslog-2.0.2-3.fc8 in the case I can tell that for sure. > ... "chkconfig --add rsyslog" which should correct the symlink names. Even when symlinks exist but in wrong positions? Maybe it was happening in a wrong phase of a transaction? Indeed when I run "chkconfig --add rsyslog" manually, after shifting links to wrong places, it does correct these. OTOH I did see those incorrect positions already a number of times. Possibly "chkconfig --del rsyslog" before "chkconfig --add rsyslog" was excessive but it surely corrected the issue.
From chkconfig man page: Note that default entries in LSB-delimited ’INIT INFO’ sections take precedence over the default runlevels in the initscript; if any Required-Start or Required-Stop entries are present, the start and stop priorities of the script will be adjusted to account for these dependencies. So those priorities might actually be correct. The problem is that the priorities of other services that depend on rsyslog don't seem to reflect this change. These bugs might shed some light on this: bug #443430, bug #444410, bug #444859 I've experimented with chkconfig a bit: [/etc/rc.d/rc3.d]# ls *rsyslog *setroubleshoot S12rsyslog S29setroubleshoot [/etc/rc.d/rc3.d]# mv S12rsyslog S30rsyslog [/etc/rc.d/rc3.d]# mv S29setroubleshoot S31setroubleshoot [/etc/rc.d/rc3.d]# chkconfig --add rsyslog [/etc/rc.d/rc3.d]# ls *rsyslog *setroubleshoot S12rsyslog S29setroubleshoot So modifying a service seems to also modify those that depend on it. [/etc/rc.d/rc3.d]# ls *rsyslog *setroubleshoot S12rsyslog S29setroubleshoot [/etc/rc.d/rc3.d]# mv S12rsyslog S30rsyslog [/etc/rc.d/rc3.d]# mv S29setroubleshoot S31setroubleshoot [/etc/rc.d/rc3.d]# chkconfig --add setroubleshoot [/etc/rc.d/rc3.d]# ls *rsyslog *setroubleshoot S29setroubleshoot S30rsyslog Is this correct? It seems like chkconfig ignores the curently set priority of a service on which the modified service depends on.
When changing priorities, it checks that the priority has changed with respect to what's in the file itself, not necessarily the specific link in the subdirectory.
I bumped into what turned out to be really the same problem with a different service (see bug 482782). So I decided even a closer look is necessary. On F10 installation which resulted from an F8 upgrade (and earlier upgrades before that) I run the following script: #!/bin/sh chkconfig --list | awk '/:on/ && /^[^\t ]/{print $1}' | \ while read sr ; do chkconfig $sr off ; chkconfig $sr on done An impact is clear. Here are differences for outputs of 'ls' in /etc/rc.d/rc3.d: --- before 2009-01-29 11:23:47.000000000 -0700 +++ after 2009-01-29 11:34:23.000000000 -0700 @@ -21,21 +21,22 @@ S06cpuspeed S08ip6tables S08iptables +S08mcstrans S10network -S10restorecond +S12restorecond S12rsyslog S13irqbalance -S13mcstrans S13rpcbind S14nfslock S15mdmonitor S18rpcidmapd S19rpcgssd +S22messagebus S25netfs +S26acpid +S26haldaemon S26lm_sensors S26udev-post -S27acpid -S27messagebus S28portreserve S55sshd S56xinetd @@ -50,9 +51,8 @@ S90xfs S91dictd S95atd -S98avahi-daemon +S96avahi-daemon S98cups -S98haldaemon S99anacron S99local S99smartd A shift in a position of haldaemon is likely the most dramatic. Interestingly enough nothing moved for "K" prefixes. A question remains - what should be responsible for such adjustments when a position in a startup sequence changes? Individual packages or maybe anaconda? In the later case that would happen only on distro upgrades. It may run 'cleanlinks' in /etc/rc.d/ too while at it.
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.