0

This strange behavior occurs when I replace the shared library object of a running process which causes the whole operating system to become inoperable with load avg values close to 40.

I don't lose responsiveness in the console, but I'm unable to kill any process or do any task to recover the OS from the disaster state. The only solution is to reboot the machine or to wait a substantial amount of time until it fully recovers.

My guess is that after replacing the .so, the process segfaults, but since the core dumping function is active, it has to retrieve all the memory state of 64 forked children and write that down to disk. Can this be causing the problem?

Improve this question
1
  • 1
    It's likely a different signal, such as SIGBUS, and not SIGSEGV, when code is paged out and the file containing it has been modified.
    – Ben Voigt
    Nov 26, 2012 at 15:23

1 Answer 1

Reset to default
0

Don't use constructs like cat file.so > libfile.so to "replace" your file. Use cp, mv or install instead.

Improve this answer
5
  • I did it with cp, and it crashed my server.
    – caruizdiaz
    Nov 26, 2012 at 19:53
  • 1
    You have a very strange running process. Perhaps you should provide more details about it.
    – Michael Hampton
    Nov 26, 2012 at 19:55
  • Don't use cp. Use mv.
    – David Schwartz
    Nov 26, 2012 at 19:59
  • And if you have to use mv, then remember to fix your SELinux context afterward with restorecon.
    – Michael Hampton
    Nov 26, 2012 at 20:00
  • what's the difference between using cp and mv?
    – caruizdiaz
    Nov 27, 2012 at 16:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.