[systemd-devel] switch-root, init, SIGHUP
James Muir (jamesmui)
jamesmui at cisco.com
Mon Jan 20 23:25:59 UTC 2025
> > It is not clear to me if the '@' is necessary because the process is
> > invoked using the "init" kernel parameter.
>
> That detail doesn't matter. It's irrelevant how the process gets
> started. In particular as I understand you you fork()ed once,
> i.e. init= starts PID 1, but this is not PID 1 we are talking about
> here...
I did not mean to imply that a process forked from "init=" gets special treatment.
I only mentioned "init=" because I think it implies an ordering wrt the switch-root killing spree.
> > Doesn't that mean it gets executed after the switch-root killing
> > spree? (i.e. it gets executed when PID 1 from the initial ramdisk
> > re-executes to run the new init).
>
> do you actually invoke the systemd binary in the initrd already, and
> the ask it to switch root, or how does that work?
I am working with a vanilla Fedora 41 image. systemd runs as PID 1 in the initrd.
The process I specify using "init=" is invoked as part of the normal switch-root flow (when systemd from the initrd calls execve() ).
> > I think the SIGHUP must come from the new PID 1.
>
> sigaction() actually tells you exactly where a signal comes from, if
> you let it via the siginfo_t structure optionally delivered to your
> signal handler. hence you can relatively easily figure this out. The
> si_pid specifies the source pid. And si_code tells you if this was
> sent by the kernel or by userspace, i.e. SI_KERNEL, SI_USER and so on.
The strace log I pointed to shows PID 1 sent the signal.
However, there is PID 1 from the initrd and the new PID 1 from the real root file system.
It must be the new PID 1 that sends the SIGHUP.
> > > Note that we'll also possibly reinitialize the tty on switch root,
> > > maybe your tool has the tty open and gets a SIGHUP because of that.
> >
> > Brian M also suggested that might be the cause, but I don't see any
> > ttys when I do "ls -l /proc/<pid>/fd".
>
> it's not so much about that, but about which ctty your process has.
There is no controlling tty listed in the output of "ps".
-James M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20250120/2081e81f/attachment-0001.htm>
More information about the systemd-devel
mailing list