> > 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 |