<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-CA" link="#467886" vlink="#96607D" style="word-wrap:break-word"> <div class="WordSection1"> > > It is not clear to me if the '@' is necessary because the process is<o:p></o:p> > > invoked using the "init" kernel parameter.<o:p></o:p> > <o:p></o:p> > That detail doesn't matter. It's irrelevant how the process gets<o:p></o:p> > started. In particular as I understand you you fork()ed once,<o:p></o:p> > i.e. init= starts PID 1, but this is not PID 1 we are talking about<o:p></o:p> > here...<o:p></o:p> <o:p> </o:p> I did not mean to imply that a process forked from "init=" gets special treatment.<o:p></o:p> <o:p> </o:p> I only mentioned "init=" because I think it implies an ordering wrt the switch-root killing spree.<o:p></o:p> <o:p> </o:p> > > Doesn't that mean it gets executed after the switch-root killing<o:p></o:p> > > spree? (i.e. it gets executed when PID 1 from the initial ramdisk<o:p></o:p> > > re-executes to run the new init).<o:p></o:p> > <o:p></o:p> > do you actually invoke the systemd binary in the initrd already, and<o:p></o:p> > the ask it to switch root, or how does that work?<o:p></o:p> <o:p> </o:p> I am working with a vanilla Fedora 41 image. systemd runs as PID 1 in the initrd.<o:p></o:p> <o:p> </o:p> The process I specify using "init=" is invoked as part of the normal switch-root flow (when systemd from the initrd calls execve() ).<o:p></o:p> <o:p> </o:p> > > I think the SIGHUP must come from the new PID 1.<o:p></o:p> > <o:p></o:p> > sigaction() actually tells you exactly where a signal comes from, if<o:p></o:p> > you let it via the siginfo_t structure optionally delivered to your<o:p></o:p> > signal handler. hence you can relatively easily figure this out. The<o:p></o:p> > si_pid specifies the source pid. And si_code tells you if this was<o:p></o:p> > sent by the kernel or by userspace, i.e. SI_KERNEL, SI_USER and so on.<o:p></o:p> <o:p> </o:p> The strace log I pointed to shows PID 1 sent the signal.<o:p></o:p> <o:p> </o:p> However, there is PID 1 from the initrd and the new PID 1 from the real root file system.<o:p></o:p> <o:p> </o:p> It must be the new PID 1 that sends the SIGHUP.<o:p></o:p> <o:p> </o:p> > > > Note that we'll also possibly reinitialize the tty on switch root,<o:p></o:p> > > > maybe your tool has the tty open and gets a SIGHUP because of that.<o:p></o:p> > ><o:p></o:p> > > Brian M also suggested that might be the cause, but I don't see any<o:p></o:p> > > ttys when I do "ls -l /proc/<pid>/fd".<o:p></o:p> > <o:p></o:p> > it's not so much about that, but about which ctty your process has.<o:p></o:p> <o:p> </o:p> There is no controlling tty listed in the output of "ps".<o:p></o:p> <o:p> </o:p> -James M<o:p></o:p> <div id="mail-editor-reference-message-container"> <div> <div> <div> <o:p> </o:p> </div> </div> </div> </div> </div> </body> </html>