2

today I observed something which probably has an easy explanation, but was quite quite unexpected from my side: I'm running CentOS (and RHEL which behaves same). I open a bash in a terminal and start any subprocess like gedit. The window opens, fine. When I do a 'ps', I can see that gedit has the bash as it's parent process which itself has the gnome-terminal as it's parent. When I then stop bash, I would expect that all child processes stop as well. But gedit keeps running and the parent changed to 1 (init)!

I tried to don't stop the shell gracefully, but kill it hard, same result. It tried killing the terminal instead of the shell, still same result. Only when I close the terminal by clicking the X button, then gedit is closed as well.

I didn't expect that behaviour. Starting gedit with nohup, I would not be surprised, but even without nohup ... why does it stay alive?

Maybe someone can shed some light and knows what's going on there. Thanks in advance!

Improve this question
2
  • You're starting it in the background or somehow sending it to the background right? Commented Oct 9, 2013 at 14:39
  • @terdon I start it either with 'gedit' and then send it to background with CTRL-Z and 'bg', or doing the same with 'gedit &', both behaves the same Commented Oct 14, 2013 at 8:46

2 Answers 2

Reset to default
3

Programs like gedit, gvim, google-chrome and many others fork themselves into the background automatically. This allows you to type

gedit /home/msw/ul-answer

map the new window and get your shell prompt back. It's not a bad design choice, and there's usually an option to override it. The commands gedit -w and gvim --nofork will not detach from the controlling terminal and will not give you back your shell prompt.

For a program to background itself, it forks and then the parent exits. This will make your normal instance of gedit a child of init (PPID == 1) almost immediately after you type it.

Other programs like mplayer or calibre don't automatically background themselves either because they aren't typed frequently or because they like to dump debug information to their controlling terminal.

added oddity:

After spending a little time testing this and looking at strace output and such, gedit appears to not be backgrounding itself automatically. What I said about gvim still holds and it is way past time for sleep, so I'll let this stand for now.

Improve this answer
1
  • That's correct, gedit does not fork, that's why I either have to start it with 'gedit &' or send to to background after start. But still, isn't it normal behaviour that a subprocess is stopped after the parent process has terminated? Even after a fork I would've expected that. Commented Oct 14, 2013 at 8:51
3

When you close the terminal window, the kernel sends a SIGHUP signal to bash. Bash then sends a SIGHUP to each job, so it kills gedit with a SIGHUP.

When you exit bash by typing exit or Ctrl+D or by killing it with SIGKILL, the terminal emulator notices that its child process has exited and closes the window. Gedit is not affected.

Improve this answer
2
  • Ok, that explains it a little further. But still I find it a bit weird, that bash forwards SIGHUPs but doesn't send e.g. SIGTERMs to it's child processes when itself exits. But even if bash wouldn't take care for it's children, is that normal kernel behaviour that subprocesses losing their parent get attached to init rather then being stopped? I thought so. Why would I have to use 'nohup' then, if I just have to let bash end "gracefully" and all subprocesses keep running? I'm a little confused ... Commented Oct 14, 2013 at 9:02
  • 1
    @T4X It would be really troublesome if processes were killed because their parent dies! SIGHUP propagation addresses a specific case: the end of the session. nohup stops that SIGHUP propagation. Commented Oct 14, 2013 at 9:05

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.