Bug#711853: insserv: Design bug: rcN.d unstable and not maintainable

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#711853: insserv: Design bug: rcN.d unstable and not maintainable

Alessandro Vesely
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  <none>

-- debconf-show failed

fix-init (33K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#711853: insserv: Design bug: rcN.d unstable and not maintainable

Dmitry Bogatov-3

control: tags -1 +moreinfo

[2013-06-10 13:53] Alessandro Vesely <[hidden email]>
> 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
                                                                             --

Reply | Threaded
Open this post in threaded view
|

Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

Jesse Smith-2
In reply to this post by 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?


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.

Reply | Threaded
Open this post in threaded view
|

Bug#711853: Bug# 711853: insserv

Tom H-4
In reply to this post by Alessandro Vesely
> 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.

I've always assumed that:

- the rcX.d links are only meant to be changed by running "insserv"
(directly or via update-rc.d)

- the dependencies of "/etc/init.d/foo" should be changed via
"/etc/insserv/overrides/foo"

Reply | Threaded
Open this post in threaded view
|

Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

Dmitry Bogatov-3
In reply to this post by Jesse Smith-2

control: tags -1 +wontfix +moreinfo

[2019-04-11 10:54] Jesse Smith <[hidden email]>

> >> 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
                                                                             --

Reply | Threaded
Open this post in threaded view
|

Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

Alessandro Vesely
On Sun 14/Apr/2019 12:52:44 +0200 Dmitry Bogatov wrote:

>
> control: tags -1 +wontfix +moreinfo
>
> [2019-04-11 10:54] Jesse Smith <[hidden email]>
>>>> 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
--

Reply | Threaded
Open this post in threaded view
|

Bug#711853: Bug# 711853: insserv

Alessandro Vesely
In reply to this post by Tom H-4
On Sat 13/Apr/2019 01:06:01 +0200 Tom H wrote:
>
> I've always assumed that:
>
> - the rcX.d links are only meant to be changed by running "insserv"
> (directly or via update-rc.d)
>
> - the dependencies of "/etc/init.d/foo" should be changed via
> "/etc/insserv/overrides/foo"


That sounds overly procrustean if applied rigorously, don't you think so?

The beauty of init is not only in allowing inspection, but also offhand
changes, however discouraged.

jm2c
Ale

Reply | Threaded
Open this post in threaded view
|

Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

Dmitry Bogatov-3
In reply to this post by Alessandro Vesely

[2019-04-15 09:14] Alessandro Vesely <[hidden email]>

> 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
                                                                             --

Reply | Threaded
Open this post in threaded view
|

Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

Alessandro Vesely
On Wed 17/Apr/2019 00:44:26 +0200 Dmitry Bogatov wrote:
> [2019-04-15 09:14] Alessandro Vesely <[hidden email]>
>>
>> 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
--

Reply | Threaded
Open this post in threaded view
|

Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

Dmitry Bogatov-3

[2019-04-17 18:02] Alessandro Vesely <[hidden email]>

> 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
                                                                             --

Reply | Threaded
Open this post in threaded view
|

Bug#711853: 711853

Tom H-4
In reply to this post by Alessandro Vesely
>> I've always assumed that:
>>
>> - the rcX.d links are only meant to be changed by running "insserv"
>> (directly or via update-rc.d)
>>
>> - the dependencies of "/etc/init.d/foo" should be changed via
>> "/etc/insserv/overrides/foo"
>
> That sounds overly procrustean if applied rigorously, don't you think so?

On a personal laptop, maybe.

In a professional context, with multiple sysadmins and systems,
definitely not. The insserv man page should really say something like
"the /etc/rcX.d directories are owned by insserv and the symlinks that
they contain should not be edited manually."

If creating "/etc/insserv/overrides/foo" is too much, there's always
the option of editing "/etc/init.d/foo" directly, since it's generally
(always?) a dpkg conffile.

Reply | Threaded
Open this post in threaded view
|

Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

Ian Jackson-2
In reply to this post by Dmitry Bogatov-3
Dmitry Bogatov writes ("Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable"):
> [2019-04-17 18:02] Alessandro Vesely <[hidden email]>
> > 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 Jackson <[hidden email]>   These 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.

Reply | Threaded
Open this post in threaded view
|

Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

Alessandro Vesely
In reply to this post by Dmitry Bogatov-3
On Thu 18/Apr/2019 12:24:25 +0200 Dmitry Bogatov wrote:
> [2019-04-17 18:02] Alessandro Vesely <[hidden email]>
>>
>> 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
--

Reply | Threaded
Open this post in threaded view
|

Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

Alessandro Vesely
In reply to this post by Ian Jackson-2
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
--

Reply | Threaded
Open this post in threaded view
|

Bug#711853: 711853

Alessandro Vesely
In reply to this post by Tom H-4
On Thu 18/Apr/2019 12:41:57 +0200 Tom H wrote:

>>> I've always assumed that:
>>>
>>> - the rcX.d links are only meant to be changed by running "insserv"
>>> (directly or via update-rc.d)
>>>
>>> - the dependencies of "/etc/init.d/foo" should be changed via
>>> "/etc/insserv/overrides/foo"
>>
>> That sounds overly procrustean if applied rigorously, don't you think so?
>
> On a personal laptop, maybe.
>
> In a professional context, with multiple sysadmins and systems,
> definitely not. The insserv man page should really say something like
> "the /etc/rcX.d directories are owned by insserv and the symlinks that
> they contain should not be edited manually."


What's the point of having manually editable links, then?  Create a binary file
containing the boot recipe, à la systemd, and you can be almost sure that your
ban against manual interventions is duly respected.


> If creating "/etc/insserv/overrides/foo" is too much, there's always
> the option of editing "/etc/init.d/foo" directly, since it's generally
> (always?) a dpkg conffile.


Probably writing /patches/ to the LSB's would be more appealing.  For example
one could eliminate X from runlevel 2 and ignore the rest of the block.


Best
Ale
--

Reply | Threaded
Open this post in threaded view
|

Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

Dmitry Bogatov-3
In reply to this post by Alessandro Vesely

[2019-04-18 18:30] Alessandro Vesely <[hidden email]>

> 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
                                                                             --

Reply | Threaded
Open this post in threaded view
|

Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

Alessandro Vesely
On Mon 22/Apr/2019 11:55:55 +0200 Dmitry Bogatov wrote:

> [2019-04-18 18:30] Alessandro Vesely <[hidden email]>
>> 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
--

Reply | Threaded
Open this post in threaded view
|

Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

Dmitry Bogatov-3

[2019-04-22 19:07] Alessandro Vesely <[hidden email]>
> > 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
                                                                             --

Reply | Threaded
Open this post in threaded view
|

Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

Alessandro Vesely
On Thu 25/Apr/2019 16:12:42 +0200 Dmitry Bogatov wrote:
> [2019-04-22 19:07] Alessandro Vesely <[hidden email]>
>
>> 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
--

Reply | Threaded
Open this post in threaded view
|

Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

Dmitry Bogatov-3

[2019-05-01 13:25] Alessandro Vesely <[hidden email]>
> 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
                                                                             --