4

I used to run a Perl TCP Socket program 24*7 in my UBUNTU server. Usually I would open the Gnome terminal and go to script path and start the Perl script. The Gnome terminal stays open throughout. It was working fine for 6 months. But for the past three days, It is not working properly. Gnome terminal is closing automatically and so the Socket program. The next day morning I again opened the terminal and ran the socket program, then again the terminal has been closed overnight. I could not find any solution in the web. Need help in resolving the issue

8
  • 3
    "Ubuntu server" does not have a "Gnome terminal" ;-) Eliminate the need for a terminal: start the program in the background? (nohup {command} &) would do that. Or use a different ttty? By the way: Ubuntu probably does not close it out of itself. You probably need to find out why, it could be a crash or a problem with your perl program
    – Rinzwind
    Sep 14, 2015 at 8:49
  • 1
    Have your perl server program write a message "still alive" + timestamp to a log file. Then, the next morning, see if the time of death correlates with something like cron_daily or anything else in /var/log.
    – Jos
    Sep 14, 2015 at 10:32
  • 1
    Good answers for working around this; you might also want to check if TMOUT is set (do echo $TMOUT; if it comes back non-empty, that might be why your terminal is closing overnight)
    – Foon
    Sep 14, 2015 at 17:08
  • Are you really running gnome-terminal on the server, on Ubuntu 12.04? During the last 2 years we fixed plenty of bugs (including crashes) in gnome-terminal (and its underlying vte widget). 12.04 is a quite old system, I recommend you to upgrade to 16.04 soon after it's released (it's still more than half a year from now, I know); or use 15.04/15.10 on your workstation, run gnome-terminal there and ssh to the server. Alternatively, you can run your app inside screen, or in a different terminal emulator.
    – egmont
    Sep 14, 2015 at 17:52
  • What's the app you're running like? Does it produce lots (like really lots, gigabytes) of output? Can it potentially produce binary unprintable stuff? How large is your scrollback buffer? Can you try to decrease that? How much memory and free disk space do you have? Is there maybe a message from the kernel OOM killer in dmesg's output or the system logs?
    – egmont
    Sep 14, 2015 at 17:56

3 Answers 3

6

Run your program in screen. Just install screen, open your terminal and type "screen". From that moment on everything you do will be inside of a persistent 'screen' that doesn't depend on whether the outside shell is closed.

If your terminal is closed, you can open a new one and re-attach the screen.

If I write programs that need to run like this (I will usually start them remotely through ssh) I usually write in a check, so that the program refuses to start unless it's running in screen (check if the environment variable STY exists). That way I can't accidentally run the program outside of screen.

3
  • Oh yes that is another good method :-D
    – Rinzwind
    Sep 14, 2015 at 12:14
  • 2
    To reattach to an existing screen session, use screen -r. (Also, screen -x lets you attach to a session that another terminal is already attached to)
    – user253751
    Sep 14, 2015 at 14:02
  • 1
    sudo apt-get install screen
    – mchid
    Sep 25, 2015 at 17:49
5

It is possible to start the program in background (your script might need some alteration if it is not possible) with ...

nohup {program} > {program.out} 2>&1 & 

The output from program will be redirected to {program.out}. If you change the ">" to ">>" it will append the output instead of writing over the previous time it was used.

That would eliminate the need for a terminal session. Besides that it will also trap error messages you might have missed due to the terminal session being killed/stopped.

1
  • I can successfully run the script with background. But while killing the process the socket doen't get closed. If I apply the command sudo netstat -peanut | grep ':1008' I'm getting the PID. But if I try to kill PID it keeps changing and socket doesn't gets closed. Same doen't happens, while opening and closing with terminals. I might want to create a separate question for this matter, I think.
    – gzix
    Sep 15, 2015 at 5:48
3

Press CTRL + ALT + F2 and sign in with your user-name and password.

Run the command from there and it shouldn't close.

1
  • Though this is the most simple and reliable technique, screen seems pretty cool to use.
    – gzix
    Sep 25, 2015 at 12:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .