[Michael Biebl] > I noticed a rather inconsistent behaviour of insserv. > > 1.) Removing runlevels from Default-Start or Default-Stop, doesn't make > insserv remove the symlinks from those run levels. > One has to run insserv -r $service && insserv $service > This is rather cumbersome, because if you change the header file, you'd > have to run insserv -r manually.
This is the intended behaviour, as the symlinks presense in rcX.d/ directories are considered configuration and should be used instead of the header when present. So the Default-Start or Default-Stop are only used when a script is inserted for the first time. After that, the symlinks override the Default-Start or Default-Stop values. > I said inconsistent, because adding runlevels to Default-Start or > Default-Stop will cause insserv to add new symlinks. This sound like a bug. I am unable to reproduce it. Can you let me know how to reproduce it, so I can add it to the test suite and find a solution for it. > 2.) I think there is a similar inconsistency with Required-Start. > Adding new dependencies will cause insserv to update the start > priority, but there are cases, if I remove a dependency, the service > is not reordered (and started earlier, as early as possible). This is because of the way insserv is implemented (see #458582 for another consequence of it). It only have one dependency graph for both start and stop dependencies, and thus the ordering might not change when changing only one of the start and stop dependencies. The effect is a slightly non-optimal sequencing, but the order is still correct, so I consider this issue at most a minor one. To solve it, insserv need to be rewritten to handle start and stop dependencies separately. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
