How a process can kill its parent then be attached to its grandparent?

Didier Spaier · 06-11-2014, 08:11 AM

We are in the context of a new slint installer, rc.S2 is running and is the last (interactive) part of rc.S, i.e. "do you want to change your keymap" etc.

Here is an sample output of "ps -AT --forest" inserted at the beginning of rc.S2:

Code:

  PID TTY      STAT   TIME COMMAND
  300 tty1     Ss+    0:00 /bin/sh /etc/rc.d/start_rc.S2
  332 tty1     R+     0:00  \_ /usr/bin/fbterm -n DejaVu Sans Mono -s 30 -- /etc/rc.d/rc.S2
  335 pts/0    Ss+    0:00      \_ /bin/sh /etc/rc.d/rc.S2
  339 pts/0    R+     0:00          \_ ps -aT --forest

Now, given that fbterm's standard error is redirected say to /tmp/err, I want that rc.S2 first check that file for fatal errors [*], that can result in a black screen and a lost user. In that case rc.S2 should kill fbterm (its parent), then be attached to its grand-parent /etc/rc.d/start_rc.S2 (or directly to init).

But of course I want to avoid that rc.S2 killing his father kill itself as that would abort the installation (any similarity with events of the Greek mythology would be a pure coincidence :-)

Of course any user input at this stage is not an option.

I'd be grateful of any clue, feel free to ask any more information and make any suggestion.

The aim is that the installer can detect an FbTerm's irrecoverable error resulting in a black screen, then automatically falling back to a standard Linux terminal.

At the moment if that happens the user can restart the installer appending " fbt=n" to the kernel command line, but I'd prefer to avoid this kind of _not_so_user_friendly workaround as much as possible.

[*] This can happen for instance if fbterm can't find the top left of the screen as the relevant VESA function call fails, in case of some weird video card and/or monitor. Thanks Diantre for testing, by the way.

pan64 · 06-11-2014, 08:25 AM

a process can detach itself from its parent, but cannot attach to anything else (it will be a daemon process). Before detaching it can store the parent process' id, and later can handle if needed...

genss · 06-11-2014, 09:53 AM

in shell i don't think, no

in C a process can reap its children by setting prctl( PR_SET_CHILD_SUBREAPER, ... )
instead of init, that is

how about making a fifo for output then cat-ing to new shell ?

Didier Spaier · 06-11-2014, 10:30 AM

Thanks both for your answers.

I've found a few tools that could change the controlling tty like reptyr, retty, injcode and neercs, but I'm not sure that they be relevant for that specific use case.

I may instead insert another step in inittab's sysinit, between execution of /etc/rc.d rc.S1 (non-interactive beginning of Slackware's rc.S) and rc.S2 (interactive part). In that step I would just make the test and store the result in /tmp so that /etc/rc.d/start_rc.S2 can behave accordingly, i.e. start /etc/rc.d/rc.S2 either in an fbterm or directly (as it does already if fbt if set).

I'm afraid that won't help Slint to get the seal of approval of our BDFL, but I think that's worth trying (and after all the inittab of the genuine Slackware installer already has 5 steps just for the shutdown :-)

PS I can't append the test at the end of rc.S1 as fbterm should run in an interactive tty. By the way that's the reason why I had to split rc.S in two parts to use fbterm during sysinit.

PPS New ideas are still welcome