I was wondering how can I find the culprit of a slow shutdown on my debian box? I am actually looking for a diagnosis tool that might dump the process name and amount of time it took to close the process after signal was send.
As for now I am trying to use journalctl to seek some information, but I would like to narrow the suspects down.
We had a problem like this in Solaris 10. There was an issue with using NFS across zones on the same system. It hung in certain circumstances.
The point I am trying to make: it may not be a process but a relationship between processes and their current status.
You are assuming a single process is the problem, which is okay, but you ma want to think "larger", multiple process or a device and some process group.
You are right, it could very much be a co/in-dependent set of processes creating the problem.
I have not installed any packages noticeably. I am sure gdb wouldn't have this issue. However, I do have my own code on the box (multiple demons). The problem started appearing recently when the reboot/shutdown command started taking more than 10 minutes as opposed to 45 second previous reboot time. And now, the delay is almost consistent.
Whether mine or external, I simply need to narrow down the problem.
I think you have to work "backwards".
Change startup to be more minimal, do not start any your own daemons.
If the problem goes away, keep adding them back into the mix one by one. If it is resource contention, like waiting on some kind of lock, it may be hard to track down. Any daemons that work cooperatively with others may deserve first attention.
If the problem still exists, you may have to start looking at your configuration by changing to single user boot, then changing startup/shutdown script to boot and shutdown at each runlevel to eliminate process groups and processes as a problem.
I vote for your hand-rolled daemons as a great place to start. Sorry I cannot be more specific.
With regard to gdb: it will not have the problem, but if the process it controls does have issues, what then? Why are you shutting down with processes running under gdb? Sounds like a bad plan to me.
Shutdown works by sending signals to processes to go through orderly shutdown. If a process cannot or is in a deadlock because a another process locked a mutex then got killed off, SIGTERM will not shut the process down. There are so-called robust mutexes that can help.
The SCO OSR 5.7 system was migrated from older HP DL360 to new DL380 G7. The SMP feature was not activated on older box, it is activated now on this 4 core Xeon.
A s/w we maintain has been copied without any change over to the new box. I noticed that the application profiling does not show any... (4 Replies)
I have Oracle 9i R2 on AIX 5.2. My Database is running in shared server mode (MTS).
Sometimes when I shutdown the database it shutsdown cleanly in 4-5 mints and sometimes it takes good 15-20 minutes and then I get some ora-600 errors and only way to shutdown is by opening another session and... (7 Replies)
I compiled my device driver with the profiling option -p but while linking I am getting undefined reference to _mcount.
Building modules, stage 2.
*** Warning: "_mcount" undefined!
From... (0 Replies)
i am try to write a profiler for a multithreaded applciation. When i creat e a thread for "function f2()" the profiling information for this function does not get captured in the struct profileManager. i;e i get the exit information for "function f2()" in that thread, but the entry... (2 Replies)