2

While this part of the script works fine:

geany &
pid=$!
...
kill -KILL $pid

This, instead, does not.

lxterminal &
pid=$!
...
kill -KILL $pid

Looks like a bash process remains in the background, but it is not identified by $pid. How can I get the PID of the terminal window, such that the process can be killed afterwards?

Note: I also tried to kill it by its name, but the --title option provokes some kind of conflict with PROMPT_COMMAND.

  • 4
    If lxterminal does a second fork, you can't easily get the pid of the resulting grandchild. – 9000 Dec 29 '16 at 1:10
  • @9000 I'm afraid it is so... – nightcod3r Dec 29 '16 at 1:50
1

Of course lxterminal forks off a child process. Think about it. That child process is the interactive shell that is attached to the emulated terminal by lxterminal (or whatever alternative program one has supplied with the -e option). It in turn makes further grandchild processes, depending from what one has actually done in that shell.

Killing lxterminal closes the master side of the pseudo-terminal that it uses, which looks like a terminal hangup as far as the slave side is concerned. The slave side is what the interactive shell sees as its controlling terminal. So the shell should be seeing a normal terminal hangup, generating a SIGHUP to the session leader if the terminal's -hupcl setting is on. That session leader is that shell process.

The session leader is responsible for job control within the session, and for passing the hangup signal along to all of its jobs. Obviously, if you have disowned something run by that shell, or nohupped it, the session leader does not pass along the hangup signal and that something will continue to run even though lxterminal has been terminated and the master side of the pseudo-terminal has been closed. That's what disown and nohup do.

You need to sort out why whatever it is you are running in that interactive session is not dying when the pseudo-terminal is hung up. You haven't told us anything about what that is, and we aren't telepathic. So there's little to suggest beyond generalities about what session leader shells are designed to do.

  • Nothing is running in the new session, the new terminal starts and awaits for a command in the prompt line. That's the thing. When a program is run (say -e "sleep 2"), then it executes the command and the terminal vanishes. (BTW, thanks for such a detailed explanation of how things work.) – nightcod3r Dec 29 '16 at 10:21
0

As @9000 has placed in a comment, lxterminal may be forking again. It is harder to get the process ID of the new fork, which is why $! isn't working.

0

This might work. But I've not tested it.

lxterminal &
pid=$!
kill -KILL "$(ps -ho ppid,pid | grep ^$pid | cut -d' ' -f2)"
  • ps -ho ppid,pid gets PPID (parent PID) and PID of the currently run processes.
  • Then grep ^$pid filters out what's not forked by $pid, so by the lxterminal in the background.
  • Finally, cut selects the PID of the grandchild.
  • It raised this error: bash: kill: '': not a pid or valid job spec. pid has the value 16209, but it is not in the process list, not even before the kill command. – nightcod3r Dec 29 '16 at 10:10
  • @nightcod3r If you replace the third line with just this: ps -ho ppid,pid | grep ^$pid, does it show anything? – Tomasz Dec 29 '16 at 10:22
  • I'm afraid it does not. Nothing shows, nothing happens, the shell remains opened. I mean: no error message this time. – nightcod3r Dec 29 '16 at 10:24
  • It's like the process does not exist any longer. – nightcod3r Dec 29 '16 at 10:30
  • What's the output of ps after lxterminal &? In the first terminal, that is. – Tomasz Dec 29 '16 at 10:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.