KamoCRM

Root could not read a member's idle time, so nothing ever slept

FixKlusterServices
Expediere
23 septembrie 2026 la 19:23 UTC
Autor
Kamo
Comite
06f8b1c

The first computer reported its idle time as 13.9, then 29.2, then 14.4 seconds over three minutes while nobody was touching it. That is not a person — it is a sawtooth capped by the thirty-second poll interval, and it is what poll() does when no display will answer: unreadable counts as ACTIVE and last_active is pushed to now on every pass. The agent runs as root and the X display belongs to the member, which is not something X is relaxed about. xprintidle was invoked with DISPLAY and no XAUTHORITY, so the display refused it, it exited non-zero, and the return value was None. Every poll. Forever. So the idle timeout could never fire on any computer. Hibernation readiness was the bug in front of it; this one was behind it, and would have kept every machine awake even once readiness came true. The cookie is read off the Xorg process that serves the display, via `-auth` on its command line. xorgxrdp passes that RELATIVE to the session's home, so a bare path is resolved through the process's own /proc/<pid>/cwd rather than guessed from the username — the process already knows, and a home directory that is not under /home would have made a guess wrong. Unreadable is no longer silent, and that matters more than the fix: it pins a computer awake, so it now says which display refused, what xprintidle printed, and which XAUTHORITY was tried — once per display and reason, not once per poll. stderr was going to DEVNULL, which is why three separate sessions of work never saw it. Five tests, including the relative-path resolution and the log-once behaviour.

Toate modificările

Ca ceea ce vezi de transport maritim?

Toate acestea ajung în spațiul de lucru pe cont propriu. Începeți cu planul gratuit și citiți această pagină din nou într-o lună.

Pornește gratuit pentru totdeaunaVezi prețurile