Re: switch-root, init, SIGHUP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

 


[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux