On 01/05/2015 01:22 AM, Andrei Borzenkov wrote:

You waved off suggestions to wrap it in service file as "noise". It is up to you of course, but having systemd service for your program would immediately answer the first two questions (by showing you *why* program exited); would preserve any program output for later perusal and could capture core dump for further analysis.

yeah ahd then systemd will restart it and you will never know it crashed. Additionally, it aborbed your core so you can red that either. Then it has binary loggings... you can only hope it logs correctly. There is nothing systemd gives you what is worth a damn thing. never the less, he is saying that random prrocesses are dieing. That might make it hard to figure out what to wrap, but perhaps nagaos might be helpful. Ruben -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Mon, Jan 05, 2015 at 03:38:05PM +0100, Aaron Digulla wrote:

Am Montag, 05. Januar 2015 03:57 CET, Fred n Sandy schrieb:

...

On Sunday 04 January 2015, Aaron Digulla wrote:

...

Ok, some rough outline of the remote help process: You supply us with reliable information about your system, program versions, possibly links to where you got unusual tools (like the noip2 executable) and we rise our voices when we spot something.

Remote help isn't telepathy. If you want us to help you, you need to tell us everything you know and everything which might be related. Which isn't easy - usually, when someone reaches out for help, they are frustrated. Not an idea state of mind to think about everything that some unknown person on the other side of the globe might need to know to help you.

With that out of the way, to keep a process alive, there are several ways which are better than cron. If you have a Linux system with the old init system (https://en.wikipedia.org/wiki/Init), you should look at daemonize (http://linux.die.net/man/1/daemonize).

If you have a more modern startup system like systemd (https://en.wikipedia.org/wiki/Systemd), then they have config files where you can say "start this when this happend and restart it when it exist and make sure it stays alive but only restart it 10 times if it terminates after 10 seconds".

Systemd is not modern. It is backward. Never excpet systemd to calify anything. It is a monolithic cludge and it is likely part of his problem. Is not systemd in 12.3 which he is running. In any event, it really smells like a hardware problem.

...

...

If you know old System V init scripts, this explains how to convert the information for systemd: http://0pointer.de/blog/projects/systemd-for-admins-3.htm l

There are only a limited number of options to find out why a process terminates:

1. Redirect stdout&stderr to a file. Might not catch processes which are forcefully terminated (killed) by the kernel, though. 2. Log files 3. Use daemonize or systemd since they log unusual behavior for you. 4. Run the process in a debugger 5. Run the process in strace. Warning: Lots and lots of output.

This is about right. There are system monotiring tools and the kernel debugging can be turned up. Ruben -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org