Hi,

in Bug 458224, which implements the "X-Interactive: true" features it
was said:

  At the moment, "interactive" scripts are listed in
  /etc/insserv.conf, and these scripts will get a unique boot sequence
  number to make sure it isn't executed in parallel with other
  scripts.

My /etc/insserv.conf has the following line:

  <interactive>   glibc udev console-screen keymap keyboard-setup console-setup cryptdisks cryptdisks-early checkfs-loop

But:
  % ls /etc/rc0.d/K02*
  /etc/rc0.d/K02cryptdisks-early@  /etc/rc0.d/K02sysklogd@
  /etc/rc0.d/K02spamassassin@      /etc/rc0.d/K02xend@

Shouldn't cryptdisks-early have a unique boot sequence number on
shutdown too?

Also I wonder why sendsigs is not listed there too. If that ever runs
in parallel with any other script then it will kill the other
script.

MfG
	Goswin

[Goswin von Brederlow]

Not because of its interactive fag, as far as I know.  The interactive
flag only affect the boot, not the shutdown, and as far as I know that
is by design.  The shutdown should not be interactive.

That late in the shutdown sequence, I believe all scripts are already
well-ordered, but if you find an example where that could happen, we
should have a look and fix it.  When every script in the archive is
ordered, sendsigs get its own sequence number for both runlevel 0 and
6, so I do not believe it is likely to happen.

This is the ordering for rc0.d at the moment:

K07sendsigs
K08rsyslog
K09umountnfs.sh
K10nfs-common
K10portmap
K11hwclock.sh
K11networking
K12atm
K12ifupdown
K13open-vm-tools
K13shorewall-init
K14umountfs
K15cryptdisks
K16lvm2
K17cryptdisks-early
K18mdadm-raid
K18umountroot
K19live-boot
K20halt

See <URL: http://lintian.debian.org/~pere/ > for the daily updated logs.

Happy hacking,

Petter Reinholdtsen <pere@hungry.com> writes:

Only when the scripts do have the right dependencies. And they not
always do. For example chrony depends only on $local_fs instead of
$remote_fs and could be scheduled in parallel with sendsigs. People do
get the depends wrong and it would be nice to have an extra level of
protection for sendsigs.

The reason why I looked into this is that with ubuntus half conversion
to upstart sendsigs does run in parallel with other scripts and happily
kills them. And I wondered how well Debian is protected from that.

MfG
        Goswin

[Goswin von Brederlow]

Of course.  And buggy packages will give their users problems which
hopefully will be reported and fixed by its maintainer.

I see #590888 is reported (thought its suggestion regarding networking
should probably be changed to $network), so this seem to work.

This is another way to say that the boot system should hide bugs in
packages, and I believe this to be a bad idea.

Right.  Suspect we will have similar problems that need to be
fixed. :)

Happy hacking,

Petter Reinholdtsen <pere@hungry.com> writes:

It should be easy to detect when dependencies would allow scripts to be
run in parallel with a specially flaged script, like sendsigs, and
report a warning/error automatically. If you have a flag for this.

I'm not saying the bug should be hidden. But hoping that someone notices
when it happens will not work. The occurance is random and the effect
might not even be visible to the user. In 99.99% the bad script might
finish before sendigs is run and in 0.01% it blows up.

So far it looks good for the software I have installed. But that is just
a fraction of all software. Some automatic verification that sendsigs is
indeed nevere going to run in parallel with something else would be
nice.

MfG
        Goswin

I am currently running into this exact situation with /etc/init.d/ocfs2:
The script takes care of (un)mounting all ocfs2 volumes.
In my case I have 11 volumes to be unmounted which takes some time,
sendsigs tries to kill "umount -a -t ocfs2" which leads to an open
heartbeat on exactly one volume (the one unmounted in parallel with
"sendsigs" trying to kill umount).

I understand that a system shutdown should not be interactive and that
setting "# X-Interactive: true" isn't the way to go. So probably
introducing "# X-Exclusive: true" could be a viable solution to the
problem of providing a somewhat similar feature to system shutdown?

In case you think that this is an issue with ocfs2-tools (the package
providing /etc/init.d/ocfs2), please tell me what a good/working LSB header
would look like. From what I've read I'd rather think that a script that
needs to run in an exclusive fashion should indicate that (which means that
this bug needs to be reasigned to initscripts which provides
/etc/init.d/sendsigs).

best regards,
        Adi Kriegisch

[Adi Kriegisch]

Is it enough to make sure the script run before sendsigs?  If not, why
do you need to run it alone?

I would suspect changing the header to make sure the script is running
before sendsigs would be enough, but I do not really understand the
problem.

Happy hacking,

Yes, it is enough to run the script either before or after sendsigs.
Actually the ocfs2 script *could* even run in parallel with sendsigs,
provided sendsigs does not kill this script's tasks. ;-)
The problem is that a script (sendsigs) is killing tasks from other init
scripts that happen to run in parallel to it. This has started to happen
since the switch to insserv, obviously.
I consider a script that acts destructive to other scripts without even
giving a hint (aka "need to run exclusively") a problem. IMHO sendsigs
needs to avoid killing stuff from other scripts.
Actually I am quite surprised that ocfs2 is obviously the only script
affected by this...

So in your opinion the right way to deal with the issue is to file a bug
against ocfs2-tools telling them that it is necessary to add a dependency
on sendsigs to avoid getting killed when using more than just some volumes
(I think this started to take too long to umount at around 7 or 8 volumes)?

Thanks for your quick response!

[Adi Kriegisch]

Well, most scripts have fairly correct dependency information, and
when they do, this problem will not occur.

Perhaps it should have a stop dependency on sendsigs, or perhaps it
should depend on $remote_fs, or perhaps it should register a omit file
to avoid being killed by sendsigs.  I do not know, but what you
descripe defintely sound like a bug in the ocfs2-tools package.

Happy hacking,

Hmmm... Judging from a grep on the init scripts on my system almost all of
them depend on "$remote_fs" which will avoid being killed by sendsigs. So,
I think you're right: ocfs2 is (kind of) providing a remote filesystem and
should therefor include a sendsigs dependency.
Registering an omit file for a task run by an init script on system
shutdown ("umount -a -t ocfs2") sounds futile to me, but probably isn't
because ocfs2 is running before sendsigs starts. On the other hand a
dependency seems to be a cleaner way of getting rid of that stuff.
IMHO the ocfs2 script should run after sendsigs and in parallel with the
rest of $remote_fs as it is providing the same features.
I will submit a patch for bug #504748 (initscripts: mountall.sh must not
mount ocfs2, gfs) as [u]mountnfs is not the right place to handle ocfs2
stuff.

Thanks for your help and the insights on insserv!

[Adi Kriegisch]

The omit file would be registered in the start part of the script, and
created during boot, not during shutdown.  The point would be to let
the boot system know that the service is supposed to survive until the
very end of the shutdown.  rsyslog do this, if you need an example.

Happy hacking,

Yes, I know how to do that. But what gets killed isn't a service but just
the umount command issued by ocfs2 script. ocfs2 script just mounts and
unmounts all ocfs2 volumes and displays the mount status of ocfs2
filesystems. Parts of the functionalty just duplicate the mountnfs and
umountnfs code.
That is why I think it is futile to register the pid of 'umount -a -t
ocfs2' within an omit file. And that is why I still (at least partly) think
that there should be some kind of 'X-Exclusive' for system shutdown in
insserv: because sendsigs might kill commands executed by other init
scripts that might run a little longer for some reaon.

Thanks for your answer!

control: tags -1 +moreinfo

[2011-08-17 20:57] Adi Kriegisch <kriegisch@vrvis.at>

I thing we already have everything needed.  Essentially, insserv
impements topological sorting, both on start sequence and stop sequence.

 On start, if "foo" has "Should-Start: bar", it means that "foo" will be
 started /after/ "bar".

 On start, if "foo" has "X-Start-Before: bar", it means that "foo" will
 be started /before/ "bar".

 On stop, if "foo" has "Should-Stop: bar", then "foo" is stopped /before/
 "bar".

 On stop, if "foo" has "X-Stop-After: bar", then "foo" is stoppend
 /after/ "bar"

So, any init script can specify arbitrary relations (before, after,
irrelevant) with any other script. So, to make sure that your script is
never executed parallel to some other, you have to use one of first two
relations and one of last two.

On other hand, we already have X-Interactive, which, strictly speaking,
is not in basis (it can be expressed in terms of Should-Start and
X-Start-Before).

Jess, how much complexity would it be to implement X-Exclusive (or reusing
X-Interactive for stop sequence)?

Jessie,

I know this has been dormant for a long time, for which, apologies.

What are your thoughts here?

Mark

This is probably something we could work into insserv. I like the idea
of a new X-Exclusive directive to isolate shutdown jobs instead of
trying to overload X-Interactive. Right now, in the code, X-Interactive
has a pretty specific meaning and it's geared toward start-up jobs only.