On Sat, Aug 18, 2018 at 11:56:04PM -0000, Nick Levinson wrote: > Which is the proper component for this problem? > > A user departs from the OS in a way that requires the OS to exit all of the apps. Usually that's by shutdown or reboot, but it might be logoff or some other method. Each app may have to clean itself up and so each app might need time. This could take so long that the user gets frustrated or the computer could freeze because of an app's misbehavior that a forced quit could have prevented, so a time limit may be forced. But if the time is thus too short, data or apps may get damaged. Powering off could damage even more data and apps. People involved with Firefox said that insufficiency of time is a problem. I posted a feature request for Fedora 28 to give the user control over the time allocated to cleanup and assigned this to a component. In answer, I was told that the component was wrong but that which component it is happens to be unknown, so far. > > If you can select a better component, please do: https://bugzilla.redhat.com/show_bug.cgi?id=1611040 Hi, the timeouts for stopping the system are hierarchical. At the top is systemd which knows about a bunch of system services and dependencies between them. Each one has can have a timeout of it's own, but generally most services don't specify it and use the DefaultTimeoutStopSec= setting which is 90 s by default. Each service either stops within the given time, or is killed when the time runs out. So the procedure is that systemd sends the stop signal to all "leaf" services, the ones on which no other service depends on the moment, and when those services stop, it becomes possible to stop other services, and so on, until all services are stopped. Some services managed by the main systemd instance have components of their own. Each user has their own systemd instance, which is a single service in the system manager, but internally has services of its own, and applies the same timeout logic. So when the user's systemd instance gets the stop signal, it'll apply the stop logic to all of it's services, respecting their timeouts, and then finally exit itself. Then there are graphical session managers, which also have internal services. The logic they use to stop services is probably different than systemd. Let's look at the specific case of firefox: $ systemctl status $(pgrep firefox) ● session-4.scope - Session 4 of user zbyszek ... CGroup: /user.slice/user-1000.slice/session-4.scope ├─ 1264 gdm-session-worker [pam/gdm-password] ├─ 1944 gdm-session-worker [pam/gdm-password] ├─ 2222 /usr/bin/gnome-keyring-daemon --daemonize --login ├─ 5952 /usr/lib64/firefox/firefox ... When started in the normal fashion, firefox is running with a bunch of other processes as part of the gnome session. In particular this means that it is not a user service under the user's systemd instance, but is managed by the gnome session. 'systemctl show -p TimeoutStopUSec session-4.scope' tells us that the timeout for the whole session to stop is 90s. How exactly gnome-session handles stopping all those processes is something that I don't know. So the short answer is that everything that you ask for in #1611040 is implemented, at least at the system level, but the specific timeout you are interested in depends on the logic in gnome session. I hope other people can provide more info about that part. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/2PDG5L53PLZQKNQ4LCS6UF23B76FM3IH/
