Il 24/06/2015 21:41, Marco d'Itri ha scritto: > Can you clarify what you are complaining about exactly? sure.
Yesterday systemd was filling its own logs with the message " systemd[1]: Looping too fast. Throttling execution a little" (as you can see in the attached log sy_po_log.txt.xz ). BTW to create the attachment I used "journalctl > sy_po_log.txt" then deleted some private lines, then compressed and attached it Moreover I add this fact. I use the tool "Mate System Monitor", that graphs the CPU usage. Yesterday the graph was flat but for a recurring spike of activity. IMHO the spike of activity was due to systemd crazy looping, and then noticing it, and then throttling, up t the next crazy loop. This seems some sort of bug, or at least a misbehavior. (In the end I rebooted the notbook, and it all went back to normal — but on production servers this may be quite annoying) This kind of problem was already reported in http://lists.freedesktop.org/archives/systemd-devel/2015-February/028541.html where they say: > THis is happens if for some reason the event loop entered a busy > loop. It's simply a protection against eating up all CPU forever. It's > a symptom of another bug, which is the one to track down. In the above post they suggest to use 'strace -p 1' ; I did that (for 2 seconds) and attached the result to this bug. This other post http://lists.freedesktop.org/archives/systemd-devel/2014-December/025867.html suggests that the problem may occur after heavy swapping. This is exactly what happened here two days ago: I was trying to compile 'git-annex' but ghc exhausted all the memory. Note though but the problem did not start immediately after the swapping; it started when I put the notebook to sleep, and resumed it next morning. My hypothesis is that at a certain point some parts of systemd died because of lack of memory, indeed I could spot this > giu 23 19:41:40 kytty systemd-journal[30249]: Journal started > giu 23 19:41:40 kytty systemd-journald[227]: Received SIGTERM from PID 1 > (systemd). > giu 23 19:41:40 kytty systemd[1]: systemd-journald.service stop-sigterm timed > out. Killing. > giu 23 19:41:40 kytty systemd[1]: systemd-journald.service: main process > exited, code=killed, status=9/KILL > giu 23 19:41:40 kytty systemd[1]: Unit systemd-journald.service entered > failed state. > giu 23 19:41:40 kytty kernel: ghc invoked oom-killer: gfp_mask=0x201da, > order=0, oom_score_adj=0 then after I put the notebook to sleep and resumed it, systemd wanted to use those killed parts, but could not, and hence this triggered the weird behavior. You may probably see if I am right or wrong by looking at the strace. (I lack the competence). A solution of this bug (if my analysis is correct) may be as follows. If a part of systemd dies because of lack of memory, then, when the situation is back to normal, systemd should restart it. Hope this helps, thx a.
signature.asc
Description: OpenPGP digital signature
