Reputation: 18585
There is an app (written in C++) running in the background for days in Linux, and if I send some signal to this app (using kill -MYSIG
), asking the app to perform some defined operations, this might make my system not respond as it would normaly. By not responding normally, I mean after I send this signal to the app, the system shell (bash
) cannot respond to any Linux commands (ls,ps,top
...), just like when the system is down. If I wait a couple of minutes, the system comes back again.
I wonder what it is that causes the system to go down, or not to respond normally? Is it that the app uses too much CPU or memory? Then how does the system comes back?
Upvotes: 2
Views: 145
Reputation: 2931
Linux scheduler has a state in which the process doesn't respond to signal(TASK_UNINTERRUPTIBLE
state),the signals sent to such a process stays queued untill process leaves the uninteruptible state, I guess thats the reason why u are not able kill/send signal to your app.If this is the case use ps -A
and see if the state of ur app is D. If so then your app/process is in TASK_UNINTERRUPTIBLE.
Probable The system doesn't respond because of the lack of available RAM. use top
to see how much RAM/resources are consumed by your app, see %CPU
and %MEM
column. You can also Use system monitor tools (ex:Gkrell) to see system wide resource usage.You can lower your apps priority to reduce its resource consumption.
If your app has read/write/select socket calls you should use strace/coredump to see where is it that your app is spending most of its time.this usually happens If select is in a tight loop or your app performed a blocking system call like read/write on socket
Upvotes: 1
Reputation: 109
You could try giving your app a lower priority, unless it is already the lowest priority and still causes problems.
Upvotes: 0