[SOLVED] Slackware 13.37

jdgr · 04-10-2012, 06:43 AM

Hi everyone,

When I was using Ubuntu, if I wanted to start a program from the command line, I would just append the "&" at the end of the command and it would spawn the program in a new process, so that I was free to continue using the terminal window or close it even (lets say putty for example, since I do use that).

Now in Slackware, when I do the same thing, it doesn't have the same effect. It starts the program sure, but the terminal is still somewhat tied up. I can continue using it, but any output the command might generate gets directed back to that terminal window, and if I was to close the terminal, the program shuts down.

How can I open programs via the command line, but have them completely in their own processes? At the moment I have to keep a few extra tabbed terminal windows open just so I can start the program and then all the output gets directed to the tabbed terminal where I don't see it.

Thanks.

mrclisdue · 04-10-2012, 07:28 AM

You can output to /dev/null thusly,

Code:

$ firefox & > /dev/null

If you have run the program in the background (by appending '&'), there's no reason why the process should shut down when you close the terminal, so I can't answer why this is happening to you; however, to prevent this, you could add 'nohup' to the beginning of your command, but skip outputting to /dev/null, as the nohup command causes the process to output to nohup.out (eg, nohup firefox & )

cheers,

tronayne · 04-10-2012, 07:41 AM

This is where nohup and redirection come in handy.

Let's say you want to execute prog:

Code:

nohup prog 2>&1 &

This will start prog running, append the standard error to the standard output, and run in background. Any output from prog will be directed into a file, nohup.out (you can monitor what's going on with something like tail -f nohup.out). You can close the terminal window or log off entirely and the program will continue to run.

Note that, when you execute nohup, the process identification number (PID) will be displayed; you might want to write it down so you can conveniently kill the running program if necessary (you might want to, oh, go home or something) -- the program will not die until you kill it, the system is rebooted or there is a fatal error.

See the manual pages for nohup, kill and tail for more information.

Hope this helps some.

TobiSGD · 04-10-2012, 07:45 AM

Quote:

Originally Posted by mrclisdue

If you have run the program in the background (by appending '&'), there's no reason why the process should shut down when you close the terminal

The reason is simple: Any program you launch from within the terminal is a child process of that terminal. If you kill the parent process you are automatically killing the children. Using the & is just telling the program to run in the background, it is some type of job control.
To prevent that the applications are closed you can use either nohup or disown.

FeyFre · 04-10-2012, 09:26 AM

Quote:

If you kill the parent process you are automatically killing the children.

It is false, or at least not entirely truth. If one kills process it kills only this process, and never any children or parent. So behaviour "Child dies because parent dead" is problem of particular child.

mrclisdue · 04-10-2012, 10:22 AM

@TobiSGD

I could be wrong, but I can't think of any occasion where a process I've backgrounded in a terminal is killed when I exit the terminal (other than when forwarding through ssh). Could you possibly provide an example?

cheers,

jdgr · 04-10-2012, 10:39 AM

Thanks for all the responses, and the nohup and > /dev/null options.

But for an example: I use putty for one of my work programs. It is a telnet based POS and parts system. I start it via the command line like [CODE]putty -load Parts\ Handler & [\CODE] because I have a few different versions I connect to. Now when I do this the program loads the proper session in the background, and I can use the terminal again. But if I close that terminal window, and I just did it again to confirm, my putty window (the child of that terminal) disappears.

I've never had this happen in Ubuntu and it seems weird that it would work differently in Slackware. I understand that certain children may die if the parent is killed, but I would think the terminal would be different since practically everything can be started from the command line. And putty isn't the only program that this happens to, it's just one that everyone here probably knows.

TobiSGD · 04-10-2012, 11:11 AM

Quote:

Originally Posted by mrclisdue

@TobiSGD

I could be wrong, but I can't think of any occasion where a process I've backgrounded in a terminal is killed when I exit the terminal (other than when forwarding through ssh). Could you possibly provide an example?

cheers,

Easy. I use Roxterm and zsh on my systems. For my example I created a simple script:

Code:

#!/bin/zsh
while true 
do 
	date >> test.log
done

I open a terminal and execute that script in the background:

Code:

./test.sh &

For testing if the script is running I open a different terminal and launch

Code:

 ps aux | grep test

As expected, this is the output:

Code:

tobi      5309  4.4  0.0  25116  2216 pts/1    SN   17:58   0:00 /bin/zsh ./test.sh
tobi      6893  0.0  0.0   4924  1064 pts/2    S+   17:59   0:00 grep --color=auto test

(I have an alias for grep to include the --color=auto option).
Now I close the terminal in which I have started the script (not even kill (SIGKILL), just close (SIGTERM)) and run the ps command again in the second terminal. Output:

Code:

 tobi      7770  0.0  0.0   4924  1060 pts/2    S+   17:59   0:00 grep --color=auto test

As I expected.
Now I repeat the procedure, but this time with disown:

Code:

tobi@demon ~ :) % ./test.sh &
[1] 9414
tobi@demon ~ :) % disown

Output of ps on the second terminal:

Code:

tobi      9414  4.4  0.0  25116  2216 pts/3    SN   18:07   0:03 /bin/zsh ./test.sh
tobi     17230  0.0  0.0   4640   588 pts/2    R+   18:09   0:00 grep --color=auto test

After closing the first terminal:

Code:

tobi      9414  4.4  0.0  25116  2216 ?        SN   18:07   0:05 /bin/zsh ./test.sh
tobi     21696  0.0  0.0   4924  1064 pts/2    S+   18:09   0:00 grep --color=auto test

I also could have used nohup, like tronayne pointed out.
This should be easy to reproduce for everyone.

mrclisdue · 04-10-2012, 11:41 AM

@TobiSGD

Thank you.

I'm not trying to derail the thread, plus it is related to the OP, but why would a process ie.,$ firefox & *not* be killed when the original terminal is closed, but your script, for example, is? How would either scenario differ from launching the process from the 'run' box (alt-F2)?

cheers,

TobiSGD · 04-10-2012, 11:47 AM

Quote:

Originally Posted by mrclisdue

why would a process ie.,$ firefox & *not* be killed when the original terminal is closed, but your script, for example, is?

I just tried that and on my system Firefox is closed when I close the terminal.

Quote:

How would either scenario differ from launching the process from the 'run' box (alt-F2)?

I don't know, since I don't know how your run-box is programmed to start applications.

mrclisdue · 04-10-2012, 01:07 PM

Ah, then perhaps it's a difference between bash and zsh? I just tried your script and the process keeps running even when the original terminal is closed.

Alas, I tried the same test using zsh, and the processes shut down, as per your example, so it occurs with zsh but not with bash. Interesting, and I wonder why (but I won't be losing sleep over it!)

cheers,

TobiSGD · 04-10-2012, 01:27 PM

Quote:

Originally Posted by mrclisdue

Ah, then perhaps it's a difference between bash and zsh? I just tried your script and the process keeps running even when the original terminal is closed.

Then it would be interesting to know which shell the OP uses.

Mark Pettit · 04-10-2012, 02:02 PM

Quote:

Originally Posted by FeyFre

It is false, or at least not entirely truth. If one kills process it kills only this process, and never any children or parent. So behaviour "Child dies because parent dead" is problem of particular child.

No - if a parent process is killed, a HUP (hang-up) signal is sent to ALL of it's child processes. The question is - what does the child process do. It may decide to ignore the HUP signal, in which case it will continue running. Do note that default is for programs to exit on HUP. Thus a program that does not do that will have to be explicitly programmed that way. It wouldn't surprise me if FireFox is compiled like that - I'm really not sure.

The other way for programs to ignore the death of a parent, is to "divorce" the parents first (my choice of words) - by becoming a daemon process. This is fairly complex, and requires deep Unix voodoo. And can really only be done by the original author (or another hacker if you have the source). Many programs offer a daemon mode from the command line - eg -D or -d or --daemon or -b (background).

jdgr · 04-10-2012, 03:47 PM

I'm just using the default terminal that comes preinstalled with slackware 13.37. Nothing fancy.

So judging by the rest of this thread, I would assume that on Ubuntu, the terminal doesn't send the HUP signal to all child processes but Slackware does handle this properly, thus killing all children unless specifically divorced/disowned? Does that sound about right?

TobiSGD · 04-10-2012, 06:45 PM

Seems to be so, but I neither have an install of Ubuntu nor would I know how to test if the terminal sends the SIGHUP to its child processes (well, I would know if my coding skills would be better).