Bug#789796: systemd[1]: Looping too fast. Throttling execution a little.

[A Mennucc1]

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20150625/86ddd92f/attachment-0002.sig>