On 2/4/21 16:07, Chris Murphy wrote:
On Thu, Feb 4, 2021 at 6:16 AM pmkellly@xxxxxxxxxxxx
<pmkellly@xxxxxxxxxxxx> wrote:
I have noticed that during a restart, the thermal daemon apparently
doesn't respond to the stop and the system has to kill it after the 2
minute timeout. This makes restarts very slow. Is this a bug or just how
things work now?
It's not stuck on thermald, it's stuck on the user manager service.
It's best evaluated following a reboot, and then looking at the
previous boot with `journalctl -b -1`
Feb 04 10:06:39 systemd[1]: Stopped Thermal Daemon Service.
Feb 04 10:08:37 systemd[1]: user@1000.service: State 'stop-sigterm'
timed out. Killing.
See the 2 minute gap? There are a bunch of user services that didn't
quit when SIGTERM was issued, for reasons we don't know. There is a 2
minute timer at which point systemd issues a SIGKILL to everything
that's part of the user session. Those are:
Feb 04 10:08:37 systemd[1]: user@1000.service: Killing process 1323
(systemd) with signal SIGKILL.
Feb 04 10:08:37 systemd[1]: user@1000.service: Killing process 2176
(dbus-broker-lau) with signal SIGKILL.
Feb 04 10:08:37 systemd[1]: user@1000.service: Killing process 2178
(dbus-broker) with signal SIGKILL.
Feb 04 10:08:37 systemd[1]: user@1000.service: Killing process 1733
(pipewire) with signal SIGKILL.
Feb 04 10:08:37 systemd[1]: user@1000.service: Killing process 1856
(pipewire-media-) with signal SIGKILL.
Feb 04 10:08:37 systemd[1]: user@1000.service: Killing process 1858
(pipewire-media-) with signal SIGKILL.
Feb 04 10:08:37 systemd[1]: user@1000.service: Killing process 1571
(pipewire-pulse) with signal SIGKILL.
Feb 04 10:08:37 systemd[1]: user@1000.service: Main process exited,
code=killed, status=9/KILL
Feb 04 10:08:37 systemd[1]: user@1000.service: Killing process 1856
(pipewire-media-) with signal SIGKILL.
Feb 04 10:08:37 systemd[1]: user@1000.service: Failed with result 'timeout'.
Should bugs be filed? I honestly don't know, because they might
legitimately be waiting on something else. But I'd probably start with
filing a bug against pipewire. It might be hanging on because some
unlisted application refuses to quit. But in that case, either
pipewire or systemd needs to include in the journal the reason why
pipewire is not responding to SIGTERM, so that we can trouble shoot
further.
I suspect that dbus-broker isn't quitting because pipewire isn't
quitting. Should there be a bug for dbus-broker? I don't know. Maybe.
https://bugzilla.redhat.com/show_bug.cgi?id=1925320
Thank you. This and the WS issue #163 were very informative. I never
would have guessed the SIGTERM and SIGKILL operate completely open loop.
I never would have guessed that it would be at all acceptable for a
process to simply ignore SIGTERM.
I would have thought that at least processes where data loss might be
involved would have brief (conversations) with systemd about things like
"need more time", "proccess xxxx is blocking my completion", or at least
a simple ACK or NAK. In cases where data loss my be involved a popup
would presented to the user with a brief explanation and options. Then
just put a hold on the restart or shutdown until the user took action.
Given that the above is highly unlikely to be implemented, perhaps an
easier solution would be to do two things. First shorten the time out
and most importantly modify the Gnome software that receives the click
for shutdown or restart so the code checks for incomplete transactions
for storage and network. If a problem is found inform the user of a
delay and and reason. After the situation is resolved Gnome can sent the
usual signal for shutdown or reboot.
In any case thanks for the insight.
Have a Great Day!
Pat (tablepc)
_______________________________________________
test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
