sc_serv process Killed silently

[mitchellclark]

This is a mystery:
Am running Shoutcast 1.9.2 (linux glibc6). Vanilla sc_serv.conf. Everything worked perfectly well for weeks. One week ago the server died unexpectedly.

When I run the server from the prompt, (./sc_serv sc_serv.conf), it starts fine, runs through the conf file, begins listening for incoming streams and incoming users on port 8000. I can successfully connect my audio stream from my local machine to the server, and users can successfully tune into the stream once the connection has been made.

After 40 - 50 seconds, I receive a Killed message and am dropped back to the prompt. Nothing of much debug value is logged to the log file or the screen (no segfaults, no errors, just "Killed"). I've run the server under nohup as was suggested, have made sure the logging directory is writable, and have checked to see if any other process is sweeping through port 8000, killing connections. Still no luck.

Here is the strace output from the last few seconds of the server's life:
###
.000112 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
1.001880 time([1078162860]) = 1078162860
0.000115 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
0.997925 time([1078162861]) = 1078162861
0.000106 select(0, NULL, NULL, NULL, {1, 0}) = ? ERESTARTNOHAND (To be restarted)
0.015481 +++ killed by SIGKILL +++
###
The (Timeout)'s happen as expected for the first 40 seconds or so, and the process dies with the ERESTARTNOHAND signal. Does anyone have any information about why that signal would be sent, and how I can prevent it? Thanks!

[Jay]

nohup won't stop a sigkill. Something on your system is obviously sending this, try sending the process to the background to ensure that it's not your shell client.

./sc_serv > /dev/null &

should do the trick.

[mitchellclark]

[2]- Killed ./sc_serv >/dev/null

Hell; was excited. Sounded like a sensible solution, but something's sweeping the process even still. I exited the session, and came back a few minutes later to a Killed process. Thanks for the suggestion, though.

[peppert]

check the process limits (ulimit, limit, unlimit, etc. dependent on your shell)