Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable
[2019-05-01 13:25] Alessandro Vesely > Put it another way, if I drop the (admittedly unrealistic) possibility > to edit rc?.d's by hand, I would have to conclude that that > architecture is a relic devoid of its functionality. Do we maintain > it for aesthetic reasons, like the Colosseum? > I wouldn't know. I like it, probably just because I've been using it > for so long. I appreciate LSB comment convention as a clever > evolution, which helps ordering the links. Preserving that somewhat > baroque directory structure, deprived of its flexibility merits, > however, sounds fictional. Beauty in the eye of beholder. I do not see anything baroque or fictional in /etc/rc[0-6] directory structure. In theory, we could have replaced symlink tree with some other output format. Plain text file, autogenerated shell script, cdb database, whatever. To do so, we would need at least: * change insserv to generate new format * change /etc/init.d/rc and startpar to read this format * have transition plan from symlink tree format It would have at least following downsides: * it will break third-party scripts. They exist. I wrote some. I see following upsides, aside from aesthetic: * we could move output under /var, where it actually belongs. So, I do not think it worth the trouble, sorry. But I think it would be nice to add note /etc/rc[0-9]/README, that content of this directories are not meant to be edited manually. Sad that I can't chmod 444 symlink. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable
On Thu 25/Apr/2019 16:12:42 +0200 Dmitry Bogatov wrote: > [2019-04-22 19:07] Alessandro Vesely > >> The point is building every time from scratch, rigidly enjoining specs, >> like it or lump it, versus an incremental, tolerant, minimal changes >> operation. > > What is the point of "incremental, tolerant, minimal changes operation"? Just to allow a wider set of possibilities. > C compiler always builds .o file from source file always afresh, and it > reduces its complexity, and insserv(8) can be seen as compiler from > content of /etc/init.d/, /etc/insserv/ and /etc/insserv.conf to > /etc/rc[0-6].d .o files are not quite editable. To patch them, one needs so much careful checking that it is not practical to do it. There is no tool to support it. And, you don't recompile every object and library every time. > The only possible reason to attempt reusing existing content of > /etc/rc[0-6].d is perfomance, and it does not apply. I agree performance is not an issue. > I argue, that isserv(8) is compiler, not build tool like make(1), since > it is impossible to separate processing of any individual file from rest > of them: /etc/init.d/, /etc/insserv/ and /etc/insserv.conf together > are single input. It is possible to consider each /etc/rc[0-6].d as > separate output, but it is useless. Your latter paragraph condenses very well the point on which we disagree. Unlike object files, /etc/rc?.d can be edited using ln, mv and rm. It would even be possible to place there a plain script or --why not?-- an executable. No, I never did that and cannot imagine why on earth someone else would do it. But, in case, who am I to deny them the right to do so? Put it another way, if I drop the (admittedly unrealistic) possibility to edit rc?.d's by hand, I would have to conclude that that architecture is a relic devoid of its functionality. Do we maintain it for aesthetic reasons, like the Colosseum? I wouldn't know. I like it, probably just because I've been using it for so long. I appreciate LSB comment convention as a clever evolution, which helps ordering the links. Preserving that somewhat baroque directory structure, deprived of its flexibility merits, however, sounds fictional. Best Ale --
Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable
[2019-04-22 19:07] Alessandro Vesely > > On Mon 22/Apr/2019 11:55:55 +0200 Dmitry Bogatov wrote: > > I agree, better not to break things if we don't need to, but introducing > > complexity to support broken setup? > I thought that script was way less complex than insserv... Hm, seems I was prejudced. Sorry. Probably `insserv` really could be simplified by replacing with high-level language implementation; but it is not for me to decide. Probably you want to propose such change to insserv's upstream. He is subscribed to this list, I believe, but you may wish to report it separately. History knows precendends: TexInfo >= 5.0 was succesfully reimplemented in Perl instead of C. > > Cycled dependencies or otherwise incoherent dependencies is broken > > setup. Fix it. We already discussed how to fix it. Asking to support it > > is like asking to support situation, when dependency of your package is > > removed by `dpkg -r'. > > Let me just note, in passing, that you're assuming any script belongs to > some package. What if a simple-minded user wants to write "Hello world" > on every boot? Normally, $ cat /etc/rc.local #!/bin/sh echo "Hello world" but also you can modify any script in /etc/init.d/, so you will get your "Hello world" text printed at any moment of boot process. Modifications will be preserved between upgrades, and you will even have option to merge your changes and Debian ones. > Similarly, LSB defines installation of scripts, and casually mentions rc > as an example implementation. Given that the implementation can > actually host more than the specification assumes, why artificially > limit it? Not artificially, just keeping scope of program in check. > I'd never complicate things in order to support unspecified martians. > The point is building every time from scratch, rigidly enjoining specs, > like it or lump it, versus an incremental, tolerant, minimal changes > operation. What is the point of "incremental, tolerant, minimal changes operation"? C compiler always builds .o file from source file always afresh, and it reduces its complexity, and insserv(8) can be seen as compiler from content of /etc/init.d/, /etc/insserv/ and /etc/insserv.conf to /etc/rc[0-6].d The only possible reason to attempt reusing existing content of /etc/rc[0-6].d is perfomance, and it does not apply. I argue, that isserv(8) is compiler, not build tool like make(1), since it is impossible to separate processing of any individual file from rest of them: /etc/init.d/, /etc/insserv/ and /etc/insserv.conf together are single input. It is possible to consider each /etc/rc[0-6].d as separate output, but it is useless. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable
On Mon 22/Apr/2019 11:55:55 +0200 Dmitry Bogatov wrote: > [2019-04-18 18:30] Alessandro Vesely >> On Thu 18/Apr/2019 12:43:24 +0200 Ian Jackson wrote: >>> >>> But I think the current behaviour of insserv in this situation is to >>> bomb out completely and refuse to operate, isn't it ? So it already >>> fails to disturb the existing symlinks ? >> >> At least, that's what happens at mine. I had to write a quick script to >> overcome that, http://www.tana.it/sw/fix-init/. > > I agree, better not to break things if we don't need to, but introducing > complexity to support broken setup? I thought that script was way less complex than insserv... > Cycled dependencies or otherwise incoherent dependencies is broken > setup. Fix it. We already discussed how to fix it. Asking to support it > is like asking to support situation, when dependency of your package is > removed by `dpkg -r'. Let me just note, in passing, that you're assuming any script belongs to some package. What if a simple-minded user wants to write "Hello world" on every boot? Similarly, LSB defines installation of scripts, and casually mentions rc as an example implementation. Given that the implementation can actually host more than the specification assumes, why artificially limit it?. >> Rather than a patch, I'd consider an alternative executable. The link above >> displays a man page for the script. I'm not advocating that script, as it >> has >> many defects. However, I like its man page and its options. I don't think > > You can try introducing new package into debian: > insserv-with-support-of-inconsistent-scripts and make it Provides: > insserv. I append that to my to do list. > Data point: I do not care much of speed of boot (as long it is not 90s), (loading ClamAV database may take longer...) > and I do not care at all of support for inconsistent LSB dependencies. I'd never complicate things in order to support unspecified martians. The point is building every time from scratch, rigidly enjoining specs, like it or lump it, versus an incremental, tolerant, minimal changes operation. > PS. About services starting before you can see config. There is > /sbin/rc.policy mechanism. Thanks for the tip. Best Ale --
Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable
[2019-04-18 18:30] Alessandro Vesely > On Thu 18/Apr/2019 12:43:24 +0200 Ian Jackson wrote: > > Dmitry Bogatov writes: > >> > >> As far as I know, "A depends B, B depends A" situation is called > >> RC-critical bug. > > > > If shipped by Debian but it can perhaps arise due to old packages, > > ad-hoc packages, etc. I agree that it's wrong but ISTM that it is > > better not to break things if we don't need to. > > > > But I think the current behaviour of insserv in this situation is to > > bomb out completely and refuse to operate, isn't it ? So it already > > fails to disturb the existing symlinks ? > > At least, that's what happens at mine. I had to write a quick script to > overcome that, http://www.tana.it/sw/fix-init/. I agree, better not to break things if we don't need to, but introducing complexity to support broken setup? Cycled dependencies or otherwise incoherent dependencies is broken setup. Fix it. We already discussed how to fix it. Asking to support it is like asking to support situation, when dependency of your package is removed by `dpkg -r'. > > As for "stable sort": > > > > So IMO if someone wants to send a patch which improves the algorithm > > so that it preserves more of the existing link ordering, when > > right now it doesn't care, we ought to consider it. (We'd want to > > be sure it didn't have any meaningfully different behaviour in > > "normal" configurations.) > > Rather than a patch, I'd consider an alternative executable. The link above > displays a man page for the script. I'm not advocating that script, as it has > many defects. However, I like its man page and its options. I don't think You can try introducing new package into debian: insserv-with-support-of-inconsistent-scripts and make it Provides: insserv. > > Note that the existing scheme parallelises things when the > > dependencies permit, and we should not take a patch which fails to > > parallelise things just because the existing links aren't parallel. > > Here's a point I had never considered. Perhaps, that's because I tend to boot > very sparingly --even on laptops, since suspend works well enough. I accept > parallelism can be a very important point for several people. An instance of > diversity? Data point: I do not care much of speed of boot (as long it is not 90s), and I do not care at all of support for inconsistent LSB dependencies. PS. About services starting before you can see config. There is /sbin/rc.policy mechanism. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable
On Thu 18/Apr/2019 12:43:24 +0200 Ian Jackson wrote: > Dmitry Bogatov writes: >> >> As far as I know, "A depends B, B depends A" situation is called >> RC-critical bug. > > If shipped by Debian but it can perhaps arise due to old packages, > ad-hoc packages, etc. I agree that it's wrong but ISTM that it is > better not to break things if we don't need to. > > But I think the current behaviour of insserv in this situation is to > bomb out completely and refuse to operate, isn't it ? So it already > fails to disturb the existing symlinks ? At least, that's what happens at mine. I had to write a quick script to overcome that, http://www.tana.it/sw/fix-init/. > As for "stable sort": > > So IMO if someone wants to send a patch which improves the algorithm > so that it preserves more of the existing link ordering, when > right now it doesn't care, we ought to consider it. (We'd want to > be sure it didn't have any meaningfully different behaviour in > "normal" configurations.) Rather than a patch, I'd consider an alternative executable. The link above displays a man page for the script. I'm not advocating that script, as it has many defects. However, I like its man page and its options. I don't think sparse patches to insserv can result in similar behavior. > Note that the existing scheme parallelises things when the > dependencies permit, and we should not take a patch which fails to > parallelise things just because the existing links aren't parallel. Here's a point I had never considered. Perhaps, that's because I tend to boot very sparingly --even on laptops, since suspend works well enough. I accept parallelism can be a very important point for several people. An instance of diversity? Best Ale --
Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable
On Thu 18/Apr/2019 12:24:25 +0200 Dmitry Bogatov wrote: > [2019-04-17 18:02] Alessandro Vesely >> >> I recall having seen all links renumbered as 01, 02, 03, ... On the machine >> I'm writing from now --a client where the boot sequence was never tampered >> with-- links are numbered with gaps. I see several 01's, a single 02, then >> 14, >> 16, ... Perhaps unconditional renumbering was changed since I posted that >> bug? > > On my system no gaps: 01, 02, 03, 04, 05, 06 in rc2.d/ When programming in Basic, I was advised to number lines as 10, 20, 30, ..., so as to ease insertions without having to renumber everything. Yes, that was before Dijkstra's invective against goto's, but since you mentioned manually editing text segments... >> To edit LSB headers may make sense for one's own scripts. Arbitrary >> insserv overrides don't seem to be the right thing to do... Or is it >> customary? > > If you have special needs -- it is okay. If ordering is wrong -- report > bug. The whole idea of Debian is to ship things that work. Sounds good. >> Bottom line, I've been trying to recover some of the flexibility we >> had before LSB's. I know that train has left many years ago... > > To be honest, I have rather basic knowledge, how things worked before > LSB. But as you describe it, manual moving symlinks feels like manual > editing output of `gcc'. Actually, it was much easier. It usually boiled down to an /early/ vs /late/ decision, which was easily answered after reading the man page. Nowadays, daemons are started as soon as you install them, without even having a glance at their configuration. Best Ale --
Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable
Dmitry Bogatov writes ("Bug#711853: insserv: Design bug: rcN.d unstable and
not, maintainable"):
> [2019-04-17 18:02] Alessandro Vesely
> > I just meant respecting the existing order, either if possible or if a fix
> > is
> > not at all obvious. Suppose A requires B and B requires A, a circular loop
> > which is somehow resolved by having S10A S20B. Now, you want to insert
> > links
> > for C, which is new. If C requires B, you can insert it at S21C, even if C
> > doesn't require A. That is, assume that the existing configuration works.
>
> As far as I know, "A depends B, B depends A" situation is called
> RC-critical bug.
If shipped by Debian but it can perhaps arise due to old packages,
ad-hoc packages, etc. I agree that it's wrong but ISTM that it is
better not to break things if we don't need to.
But I think the current behaviour of insserv in this situation is to
bomb out completely and refuse to operate, isn't it ? So it already
fails to disturb the existing symlinks ?
As for "stable sort":
So IMO if someone wants to send a patch which improves the algorithm
so that it preserves more of the existing link ordering, when
right now it doesn't care, we ought to consider it. (We'd want to
be sure it didn't have any meaningfully different behaviour in
"normal" configurations.)
Note that the existing scheme parallelises things when the
dependencies permit, and we should not take a patch which fails to
parallelise things just because the existing links aren't parallel.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable
[2019-04-17 18:02] Alessandro Vesely > On Wed 17/Apr/2019 00:44:26 +0200 Dmitry Bogatov wrote: > > Right now insserv implements little more than topological sort. You can > > modify relations between scripts by editing LSB headers. What do you > > mean 'adjusting links without subverting existing order'? Mind to provide > > example? > > > I just meant respecting the existing order, either if possible or if a fix is > not at all obvious. Suppose A requires B and B requires A, a circular loop > which is somehow resolved by having S10A S20B. Now, you want to insert links > for C, which is new. If C requires B, you can insert it at S21C, even if C > doesn't require A. That is, assume that the existing configuration works. As far as I know, "A depends B, B depends A" situation is called RC-critical bug. > I recall having seen all links renumbered as 01, 02, 03, ... On the machine > I'm writing from now --a client where the boot sequence was never tampered > with-- links are numbered with gaps. I see several 01's, a single 02, then > 14, > 16, ... Perhaps unconditional renumbering was changed since I posted that > bug? On my system no gaps: 01, 02, 03, 04, 05, 06 in rc2.d/ > To edit LSB headers may make sense for one's own scripts. Arbitrary > insserv overrides don't seem to be the right thing to do... Or is it > customary? If you have special needs -- it is okay. If ordering is wrong -- report bug. The whole idea of Debian is to ship things that work. > Bottom line, I've been trying to recover some of the flexibility we > had before LSB's. I know that train has left many years ago... To be honest, I have rather basic knowledge, how things worked before LSB. But as you describe it, manual moving symlinks feels like manual editing output of `gcc'. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable
On Wed 17/Apr/2019 00:44:26 +0200 Dmitry Bogatov wrote: > [2019-04-15 09:14] Alessandro Vesely >> >> Nowadays, stable sort algorithms are really widespread. Adjusting links >> without subverting their existing order is not that hard. > > I am not going to implement it, but even as user I fail to understand > your proposal. To configure a stable boot sequence. > Right now insserv implements little more than topological sort. You can > modify relations between scripts by editing LSB headers. What do you > mean 'adjusting links without subverting existing order'? Mind to provide > example? I just meant respecting the existing order, either if possible or if a fix is not at all obvious. Suppose A requires B and B requires A, a circular loop which is somehow resolved by having S10A S20B. Now, you want to insert links for C, which is new. If C requires B, you can insert it at S21C, even if C doesn't require A. That is, assume that the existing configuration works. I recall having seen all links renumbered as 01, 02, 03, ... On the machine I'm writing from now --a client where the boot sequence was never tampered with-- links are numbered with gaps. I see several 01's, a single 02, then 14, 16, ... Perhaps unconditional renumbering was changed since I posted that bug? To edit LSB headers may make sense for one's own scripts. Arbitrary insserv overrides don't seem to be the right thing to do... Or is it customary? Bottom line, I've been trying to recover some of the flexibility we had before LSB's. I know that train has left many years ago... Best Ale --
Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable
[2019-04-15 09:14] Alessandro Vesely > I get this: > insserv: There is a loop between service umountnfs and rsyslog if stopped > insserv: loop involving service rpcbind at depth 3 > insserv: loop involving service umountnfs at depth 2 > insserv: loop involving service gdm3 at depth 1 > insserv: loop involving service sendsigs at depth 2 > insserv: loop involving service networking at depth 7 > insserv: exiting now without changing boot order! > > I run fixinit instead > http://www.tana.it/sw/fix-init/ > >> Now, as to whether this should be considered a bug or a desired effect > >> is open to debate. On the one hand it is understandable people might not > >> want insserv to overwrite their changes. On the other hand, in my case > >> insserv is fixing a mistake in my symlinks, and adjusting them to match > >> their LSB headers. > > Running interactively in some cases may make sense. Instead, insserv is run > every time one installs a package which includes a daemon, automatically. > > Nowadays, stable sort algorithms are really widespread. Adjusting links > without subverting their existing order is not that hard. I am not going to implement it, but even as user I fail to understand your proposal. Right now insserv implements little more than topological sort. You can modify relations between scripts by editing LSB headers. What do you mean 'adjusting links without subvering existing order'? Mind to provide example? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable
On Sun 14/Apr/2019 12:52:44 +0200 Dmitry Bogatov wrote: > > control: tags -1 +wontfix +moreinfo > > [2019-04-11 10:54] Jesse Smith When update-rc.d calls insserv, the rcN.d directories are rebuilt without taking into consideration any adjustment that might have been set up locally. That seems to be done on the assumption that the dependencies coded in the LSB blocks are universally accurate. Now, LSBs are a great improvement over numeric priorities, but to hamper local system tuning, which is not necessarily related to LSBs, IMHO is an insult to the legendary versatility of SysV init. >>> >>> I believe it is not how things work now. Last time I checked, call >>> `insserv foo` does not update any links to `foo' if there is already at >>> least one of them. I get this: insserv: There is a loop between service umountnfs and rsyslog if stopped insserv: loop involving service rpcbind at depth 3 insserv: loop involving service umountnfs at depth 2 insserv: loop involving service gdm3 at depth 1 insserv: loop involving service sendsigs at depth 2 insserv: loop involving service networking at depth 7 insserv: exiting now without changing boot order! I run fixinit instead http://www.tana.it/sw/fix-init/ >> Now, as to whether this should be considered a bug or a desired effect >> is open to debate. On the one hand it is understandable people might not >> want insserv to overwrite their changes. On the other hand, in my case >> insserv is fixing a mistake in my symlinks, and adjusting them to match >> their LSB headers. Running interactively in some cases may make sense. Instead, insserv is run every time one installs a package which includes a daemon, automatically. Nowadays, stable sort algorithms are really widespread. Adjusting links without subverting their existing order is not that hard. >> My thought on this is if someone wants to improve their start-up routine >> it makes more sense for them to edit their script's LSB header and >> re-run insserv rather than editing links by hand. > > Thank you Jesse. Sounds reasonable. +1 > Dear submitter, please consider, whether your issue could be solved by > editing LSB headers and if not, why. Loops or other unforeseen circumstances are always possible. In such cases, it would still be possible to add or fix unrelated parts of the start-up sequence. Perhaps this should be turned wishlist, rather than wontfix. Thank you for the considerable work you're doing on sysv init. Ale --
Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable
control: tags -1 +wontfix +moreinfo [2019-04-11 10:54] Jesse Smith > >> When update-rc.d calls insserv, the rcN.d directories are rebuilt > >> without taking into consideration any adjustment that might have > >> been set up locally. That seems to be done on the assumption that > >> the dependencies coded in the LSB blocks are universally accurate. > >> Now, LSBs are a great improvement over numeric priorities, but to > >> hamper local system tuning, which is not necessarily related to > >> LSBs, IMHO is an insult to the legendary versatility of SysV init. > > > > I believe it is not how things work now. Last time I checked, call > > `insserv foo` does not update any links to `foo' if there is already at > > least one of them. > > > > @Jesse, am I right? > > I just ran a quick test and can confirm that if I have an existing link > to a service, for example /etc/rc5.d/S05bluetooth, then running the > command "insserv bluetooth" will attempt to remove the old symlink and > replace it with one that conforms to the LSB headers. In my case, > removing the original link and creating /etc/rc5.d/S04bluetooth. > > Now, as to whether this should be considered a bug or a desired effect > is open to debate. On the one hand it is understandable people might not > want insserv to overwrite their changes. On the other hand, in my case > insserv is fixing a mistake in my symlinks, and adjusting them to match > their LSB headers. > > My thought on this is if someone wants to improve their start-up routine > it makes more sense for them to edit their script's LSB header and > re-run insserv rather than editing links by hand. Thank you Jesse. Sounds reasonable. Dear submitter, please consider, whether your issue could be solved by editing LSB headers and if not, why. So far, tagging as wontfix and moreinfo, subject to close-on-timeout. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable
>> When update-rc.d calls insserv, the rcN.d directories are rebuilt >> without taking into consideration any adjustment that might have >> been set up locally. That seems to be done on the assumption that >> the dependencies coded in the LSB blocks are universally accurate. >> Now, LSBs are a great improvement over numeric priorities, but to >> hamper local system tuning, which is not necessarily related to >> LSBs, IMHO is an insult to the legendary versatility of SysV init. > > I believe it is not how things work now. Last time I checked, call > `insserv foo` does not update any links to `foo' if there is already at > least one of them. > > @Jesse, am I right? I just ran a quick test and can confirm that if I have an existing link to a service, for example /etc/rc5.d/S05bluetooth, then running the command "insserv bluetooth" will attempt to remove the old symlink and replace it with one that conforms to the LSB headers. In my case, removing the original link and creating /etc/rc5.d/S04bluetooth. Now, as to whether this should be considered a bug or a desired effect is open to debate. On the one hand it is understandable people might not want insserv to overwrite their changes. On the other hand, in my case insserv is fixing a mistake in my symlinks, and adjusting them to match their LSB headers. My thought on this is if someone wants to improve their start-up routine it makes more sense for them to edit their script's LSB header and re-run insserv rather than editing links by hand.
Bug#711853: insserv: Design bug: rcN.d unstable and not maintainable
control: tags -1 +moreinfo [2013-06-10 13:53] Alessandro Vesely > When update-rc.d calls insserv, the rcN.d directories are rebuilt > without taking into consideration any adjustment that might have > been set up locally. That seems to be done on the assumption that > the dependencies coded in the LSB blocks are universally accurate. > Now, LSBs are a great improvement over numeric priorities, but to > hamper local system tuning, which is not necessarily related to > LSBs, IMHO is an insult to the legendary versatility of SysV init. I believe it is not how things work now. Last time I checked, call `insserv foo` does not update any links to `foo' if there is already at least one of them. @Jesse, am I right? Dear submitter, can you please re-evaluate, whether problem still present with insserv=1.18.0-2 and dependency-based boot system? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#711853: insserv: Design bug: rcN.d unstable and not maintainable
Package: insserv
Version: 1.14.0-5
Severity: normal
When update-rc.d calls insserv, the rcN.d directories are rebuilt
without taking into consideration any adjustment that might have
been set up locally. That seems to be done on the assumption that
the dependencies coded in the LSB blocks are universally accurate.
Now, LSBs are a great improvement over numeric priorities, but to
hamper local system tuning, which is not necessarily related to
LSBs, IMHO is an insult to the legendary versatility of SysV init.
On the other hand, when .legacy-bootordering exists, update-rc.d
does not use LSB blocks at all, and mindlessly links at priority
20. I understand that maintainers don't put default priority
orders, which are difficult to maintain: That is exactly the
reason why LSB INIT INFO blocks were devised. So, why not use
them?
A way to use that info and still respect existing priorities is
coded in the attached script. Thanks to it, I was able to get the
cleanest boot since I upgraded to wheezy. Unlike update-rc.d,
fix-init does not take a scrip name to operate on. It assumes all
links older than .legacy-bootordering are to be respected, and
writes any action it deems required to a shell script.
Please have a look at it.
Regards
Ale
-- System Information:
Debian Release: 7.0
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.41ale20 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages insserv depends on:
ii libc6 2.13-38
insserv recommends no packages.
Versions of packages insserv suggests:
pn bootchart2
-- debconf-show failed
#! /usr/bin/perl
# written by Alessandro Vesely in June 2013. This is free software.
=head1 NAME
fix-init - rebuild F links according to LSB headers
=head1 SYNOPSIS
fix-init [-n|--dry-run [I]]
[-r|--renum [I]]
[--root I]
[-v|--verbose [2|3|4]]
fix-init -h|--help [1|2]
=head1 OPTIONS
=over
=item help
An optional value of I<1> displays these options in addition to the synopsis.
Use I<2> for a man-like page.
=item root
Default to F. Use a different directory for testing.
=item dry-run
B writes shell commands on a temporary file, then executes it.
This option prevents that execution. It is implied if I is not
writable. If an output I is specified, it will be used instead of a
temporary one, overwriting its previous content if any.
=item renum
Without this option, B tries to respect the existing order of links.
Otherwise, it renumbers them. The default I is 6, resulting in names
like F, F, F, ... This option is implied if
dependecy based boot sequencing is in effect.
=item verbose
Minimal verbosity (I<-v>) is recommended, otherwise B is almost
silent. At intermediate verbosity, unsatisfied required dependencies (I<-v 2>),
optional ("should") and satisfied ones (I<-v 3>) are displayed, as well as some
skipped files and "strange" facts. Top verbosity (I<-v 4>) dumps some internal
structures, such as the initial and resulting order for each level.
=back
=cut
use strict;
use warnings;
use feature "switch";
use File::Find;
use File::Temp 'tempfile';
use Getopt::Long;
use List::Util qw(max min);
use Data::Dumper;
use Pod::Usage;
use constant {BROKEN_LINK => 1,
PLAIN_FILE => 2, STRANGE_LINK => 3, NEW_LINK => 4};
my ($dryrun, $renum, $help, $root, $verbose);
Getopt::Long::Configure('no_ignore_case');
if (!GetOptions('verbose|v:i' => \$verbose,
'dry-run|n:s' => \$dryrun,
'renum|r:i' => \$renum,
'root=s' => \$root,
'help|h:i'=> \$help))
{
pod2usage();
exit 1;
}
if (defined($help))
{
pod2usage(-verbose => $help);
}
if (defined($verbose))
{
$verbose = 1 unless ($verbose); # -v same as -v 1
}
else {$verbose = 0;}
$root = '/' unless defined($root);
$root .= '/' unless (substr($root, -1) eq '/');
my $initdir = $root . 'etc/init.d';
my $init_link = "../init.d/";
my $fix_flag = $initdir .'/.legacy-bootordering';
my $overridepath = "/usr/share/insserv/overrides";
my $hostoverridepath = "/etc/insserv/overrides";
$Data::Dumper::Terse = 1;
my @levels = map "$_", ('S', 0.. 6);
my %rc_d = map {$_ => $root ."etc/rc$_.d"} @levels;
my $rc_d_length = length($rc_d{0}); # different from length($initdir)
do {
my @invalid = grep ! -d, values %rc_d;
push(@invalid, $initdir) unless -d $initdir;
pod2usage(-msg => 'Invalid dir: '. join(', ', @invalid)) if (@invalid);
};
my $timestamp = (stat($fix_flag))[9];
if (!defined($timestamp))
{
$timestamp = 0;
if (!defined($renum))
{
$renum = 0;
print "Dependecy based boot sequencing detected, --renum implied\n"
if ($verbose);
}
}
my $defaultstep = 6;
$renum = $defaultstep if (defined($renum) && $renum == 0);
# cannot do, because order becomes negative or larger than 99
my $cannot;
# which files to skip in $initdir
