From: Tomas Volf <~@wolfsden.cz>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: GNU Shepherd 0.10.3 released
Date: Wed, 10 Jan 2024 17:38:17 +0100 [thread overview]
Message-ID: <ZZ7H-e7Gw6NSxgss@ws> (raw)
In-Reply-To: <878r4yw06f.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 3298 bytes --]
On 2024-01-10 00:34:48 +0100, Ludovic Courtès wrote:
> Tomas Volf <~@wolfsden.cz> skribis:
>
> > On 2024-01-07 15:08:59 +0100, Ludovic Courtès wrote:
>
> [...]
>
> >> ** Do not accidentally wait for Linux kernel thread completion
> >> (<https://issues.guix.gnu.org/67132>)
> >>
> >> In cases a PID file contained a bogus PID or one that’s only valid in a
> >> separate PID namespace, shepherd could end up waiting for the termination of
> >> what’s actually a Linux kernel thread, such as PID 2 (“kthreadd”). This
> >> situation is now recognized and avoided.
> >
> > This is great, I will not have to remember to run `modprobe -r mt7921e' before
> > each shutdown anymore. I hope. Looking forward to getting it in the Guix :)
>
> D’oh, why did you have to do that?
Otherwise the shepherd would be stuck on shutdown waiting for process named
[mt76-tx phy0]
to terminate with messages along the lines of:
shepherd[1]: waiting for process termination (processes left: (1 678))
It is a kernel thread as far as I can tell (based on
https://stackoverflow.com/a/12231039):
$ cd /proc/678
$ cat cmdline
$ readlink exe; echo $?
1
Removing the module mt7921e stops the thread, so shepherd does not wait for it.
> How did Shepherd end up with “wrong” PID?
That I do not know. It is visible in `ps' output, so I assume shepherd picked
it up on its own somehow.
>
> I hope this release fixes it!
As far as I can tell, the 0.10.3 was already added into guix:
$ ps 1 | cat
PID TTY STAT TIME COMMAND
1 ? Sl 0:01 /gnu/store/bhynhk0c6ssq3fqqc59fvhxjzwywsjbb-guile-3.0.9/bin/guile --no-auto-compile /gnu/store/06mz0yjkghi7r6d7lmhvv7gryipljhdd-shepherd-0.10.3/bin/shepherd --config /gnu/store/klkqq2y65k141rlipq4ls0w2rlhds12h-shepherd.conf
So I have to say it sadly did not resolve this issue. I am unsure why though.
I am not familiar with Shepherd's code base, but quick look at the git log
suggested that procedure (@@ (shepherd service) pseudo-process?) is the relevant
one. When I try it from a REPL, it returns #t.
$ guix shell guile shepherd guile-fibers -- guile
GNU Guile 3.0.9
Copyright (C) 1995-2023 Free Software Foundation, Inc.
Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.
Enter `,help' for help.
scheme@(guile-user)> ,use (shepherd service)
scheme@(guile-user)> ((@@ (shepherd service) pseudo-process?) 688)
$1 = #t
So it *should* work? However the issue is caused by non-free WiFi driver on a
corrupted kernel, so I am not sure if it is even problem that needs to be
solved... I would (obviously) like to see it resolved, but I probably cannot
even bug report it, since it requires non-free hardware and software to
reproduce.
Tomas
PS: It is interesting that `guix shell guile shepherd' is not enough, the
guile-fibers have to be explicitly specified as well. Is that expected?
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-01-10 16:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-07 14:08 GNU Shepherd 0.10.3 released Ludovic Courtès
2024-01-07 14:59 ` Tomas Volf
2024-01-09 23:34 ` Ludovic Courtès
2024-01-10 16:38 ` Tomas Volf [this message]
2024-01-10 16:50 ` Tomas Volf
2024-01-11 12:41 ` Ludovic Courtès
2024-01-11 13:12 ` Tomas Volf
2024-01-29 16:31 ` Ludovic Courtès
2024-01-07 15:45 ` Wilko Meyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZZ7H-e7Gw6NSxgss@ws \
--to=~@wolfsden.cz \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.