Bug 487979

Are you using NetworkManager?

I don't see how it is relevant, but no, we don't use NetworkManager, preferring the more traditional "network" script.

If NetworkManager is enabled, NM usually starts as 27, which will cause ypbind to start at 28.

In any case, if ypbind is getting a different level than what's specified, it's because it's being adjusted for its dependencies.

NetworkManager was installed but not being used. Uninstalling it and turning ypbind off and on in chkconfig returned to the correct place (which would be after NetworkManager anyway if chkconfig hadn't interfered because of the alphanumeric sorting).
Presumably my immediate problem could be fixed by putting a dependency in autofs on ypbind, but there seems to me to be a danger of adding this new functionality to chkconfig unless every package supports it and all dependencies are known because it will break things in unexpected ways and what works for one machine might not work on others. This change also seems to be undocumented as I can't see any reference to it in the chkconfig manual page.
So I think there needs to be better documentation and more publicity that this change has been made (did you consider an increment in the major package version of chkconfig to match this change) or else there will be a lot of broken functionality puzzling users.

It's not a new change - that code for handling LSB-style dependencies has been in there for a couple of years now.

It does however seem to be newly active. I didn't notice it in Fedora 10, and chkconfig definitely doesn't renumber ypbind in the same circumstances for Fedora 9. So there should be some announcement that this feature is active, and some documentation I can point out to the maintainer of the autofs package to tell him or her what to fix.

Well, it becomes 'newly active' when the script writer adds LSB dependencies to their script.

As stated in the 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.

I'm not sure how to make it more prominent than that.

That doesn't explain what the section is or what it is supposed to look like and what other fields are supposed to mean, particularly for those who don't know what "LSB-delimited" means . For example what does Provides: do, does the $ prefix in a Provides entry mean anything, and what other fields matter from the point of view of chkconfig? You really need to already know what the above quote means to understand it.

There should be an explained example in the RUNLEVEL FILES section at the end, which is where someone would expect to find details about what should be in their init.d files, and this should say which fields of the LSB are implemented in chkconfig.

(In reply to comment #8)
> That doesn't explain what the section is or what it is supposed to look like
> and what other fields are supposed to mean, particularly for those who don't
> know what "LSB-delimited" means . For example what does Provides: do, does the
> $ prefix in a Provides entry mean anything, and what other fields matter from
> the point of view of chkconfig? You really need to already know what the above
> quote means to understand it.

Sure, but if you don't understand the LSB spec, you wouldn't add the section to your init file, and you won't run into this issue. I think it's out of scope for the chkconfig man page.

But you do run into this issue because other people have put that section into their init scripts and chkconfig mismanages the order of packages if you don't. So in practise what you are going to do is copy someone else's script and find something that works because chkconfig doesn't adequately explain what it is doing or where to find more information about the right way to do it.

Two fixes added in git:
- chkconfig.8 updated to mention LSB scripts in more places
- chkconfig updates so it won't refactor start priorities when the providing service isn't actually enabled (and similar for stop services). This should avoid NM changing your init script priorities when it's installed but not enabled.

Arguably, "chkconfig --add" shouldn't reset the priorities of services that are already enabled (if you want that there's always the "resetpriorities" argument).  That way, the priorities wouldn't break when you update a package.