But if for some reason, I need to start the app from an SSH session
(putty), the application sometimes dies after I log out. Sometimes
right away, sometimes after some time has passed. Nothing about
interesting is written to the log file. Normally the app makes log
entries when it shuts down cleanly. The process is just gone. This did
not happen prior to implementing log4j. Previously, the app wrote to a
pre-configured file and to System.out. Closing an SSH session had no
ill effects.


This is not really a logging question per-se, but I feel for you. Unix process can die after the user shell that created them exits. To be honest there doesn't appear to be a hard and fast rule as to this behaviour, but I'm quite confident it has nothing to do with log4j. the 'nohup' unix command was originally designed for this purpose, but there's an even better way.

Since you are launching a process that you want to stick around regardless of the connectivity of the shell process that launches it you should consider using the 'screen' application built into most *nix's.

host> screen -S "Some Logical Name"
host> /home/me/launchApp.sh
...
.
..

You can exit that terminal session at any time and it'll be safe from a hang up. Even better, you can relogin and do:

host> screen -ls
There is a screen on:
        23608.Some Logical Name (Attached)
1 Socket in /tmp/uscreens/S-psmith.

you can then reconnect by:

host> screen -r 23608

or via other options (by name etc).

'screen' is fantastic when you're dealing with remote servers that you have problematic connections to (say, if they're on the other side of the world, which for me in Australia, is basically everything! :) ). You can launch critical scripts knowing that a tcp disconnect will not cause any harm and you can come back to it later, even from a completely different computer.

The authors of 'screen' are definitely on my 'List of People To Buy Beers For".

Paul


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to