5 ms·
Before bringing in the big guns, I'd recommend just whipping out strace -p 1 -s 1000 -tt -T (or something like that). Chances are it'll show something that'll g
by pas 7y ago
Before bringing in the big guns, I'd recommend just whipping out strace -p 1 -s 1000 -tt -T (or something like that). Chances are it'll show something that'll get you closer to solving whatever issue you have.
SystemTap and other kernel instrumentation stuff are of course invaluable sometimes, but I just find strace easier, even if it requires looking at and divining meaning from a lot of mystical output lines. :)
That said, the amount of processes, DBus messages, and system calls that happen on even on an idle system these days is crazy. (On Windows it's even worse, something is doing I/O all the time. Diagnostic that, ETW this [event tracing for windows], you can't stop most of them.) There is just too much broadcasting going on. And it's especially maddening on platforms that provide subscription for events. (Don't broadcast the same signal over and over. Let new clients get the current state and wait.)
- jandrese 7y agoStrace is of no help in discovering why your bootup is stalled out because one of the processes didn't receive a message it was expecting. Who was supposed to emit the message? Who knows? Why wasn't it sent? Sucks to be you. Unlike the old init days you can't just look at the previous lines in the script to figure out what went wrong, you have to understand the entire system before you can start debugging it.
- pas 7y agoHave you encountered that? Since systemd I have more confidence in issuing reboots, but of course if it goes sideways it seems harder to debug, exactly because I have not much experience with that part. I enabled various debug levels for it (it can spew out an ungodly amount of data, but exactly what you mentioned is missing, the "what are we waiting for" info) - I had a problem with shutdown taking too long.