[arch-general] udevd related warning after initscripts update

[Tom Gundersen]

On Sun, Oct 23, 2011 at 4:42 PM, Mauro Santos
<registo.mailling at gmail.com> wrote:
> After the latest initscripts update I get a warning (?) from udevd (?)
> when shutting down, it goes like this:
>
> ...
> Deactivating Swap              [Done]
> Sending SIGTERM to processes   [Busy]
> udevd[pid]: 'udisks-part-id /dev/sda2' [pid] terminated by signal 15
> (terminated)
>                               [Done]
> Saving random seed             [Done]
> ...
>
> In my case sda2 is the swap partition, nothing seems to break as swap
> still gets enabled when the machine boots but I was wondering if this is
> expected and if this might cause trouble for some corner case.

This is an udev thing, rather than an initscripts thing as far as I
can tell. However, we might want to add a fix to initscripts for this
in the future (I'm still trying to figure out what is the "correct"
behavior).

This is what happens:

When we run "swapoff --all" at shutdown the kernel sends out a CHANGE
event on the swap device (you can see this by running "udevadm
monitor" in one terminal and "swapoff /devsda2" in another). This then
triggers several udev rules, which in turn run blkid, udisks-part-id,
and probably others.

By the time blkid and friends have started we have reached the killall
part of rc.shutdown, so they are sent a TERM signal (signal 15). They
then terminate as they are requested to do, but whine a bit about it
in the terminal (wouldn't you, if the guy who started you immediately
tells you to shut down?).

The only reason these helpers are run, is so udev can assign the
correct properties to the swap partitions in its database. However, we
really don't care about that as udev is about to be shutdown (and its
database destroyed) in a few milliseconds anyway.

In principle this might cause some more annoying problems where an
event at the perfect time creates a process that escapes the killall
logic and causes an unclean shutdown, so I should really look into
shutting down udev properly (though probably, through pure luck, this
can never happen).

-t

TL;DR: it doesn't matter, just ignore it.