Petter Reinholdtsen <[EMAIL PROTECTED]> writes:
> [Goswin von Brederlow]
>> we use fuse-unionfs for /etc and /usr on a pool of systems. When
>> rebooting killall5 will kill all processes execpt init and itself
>> causing the fuse filesystems to be killed without umount. In our
>> case the next access to /etc or /usr will block because there will
>> be no process left to service the request.
>
> Why does it not work to use the omitpid feature of sendsigs? It was
> written for cases like this.
For one thing because there is no such thing as an "omitpid feature"
in killall5. Only pidof has it.
>From sysvinit 2.86.ds1-56 src/killall5.c:
/* Right, so we are "killall". */
if (argc > 1) {
if (argc != 2) usage();
if (argv[1][0] == '-') (argv[1])++;
if ((sig = atoi(argv[1])) <= 0 || sig > 31) usage();
}
The other is that fuse filesystems can fork and thereby add new
pids. Depending on the threading modell in use even threading will
create pids. And you can't add the pids of children to the omitpid
file without race conditions.
>> The attached patch adds a test for fuse filesystem and leaves them
>> alone. This allows any of the many fuse filesystems to be used for
>> system directories.
>
> It seem like a bad idea to add file system specific code in killall5,
> and I would prefer this to be done using the omitpid feature instead.
By the way, how do you expcet that to work with fuse filesystems that
are not root? They can not create a omitpid file.
>> It also changes the cwd to /proc and changes readproc() to use
>> relative paths. This avoids access() calls to / that would deadlock
>> if / is a fuse filesystem.
>
> This sound like a good idea. Can you make a clean patch to use
> relative paths?
Will do.
> Btw, the stat() patch in #476695 will be included in the next upload.
Thanks.
> Happy hacking,
> --
> Petter Reinholdtsen
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
