On Mon, Jan 15, 2018 at 9:37 PM, Max Harmathy <max.harma...@web.de> wrote:
> Am 15.01.2018 um 20:07 schrieb Kai Uwe Broulik: > > Hi, > > Thanks for your replay > > We found out, that running a process with a systemd inhibitor as root e.g > > > # systemd-inhibit --what=shutdown --mode=block sleep 365d > > Try mode "delay", this will temporarily delay the action until you release > your inhibition. Typically used for certain cleanup tasks, like disconnecting > the network, before sending the computer to sleep but according to > documentation this works also for "shutdown" command. Check out the Logind > inhibition documentation [1]. > > Sadly the mode "delay" is no option: since there is a globally set timeout > for any delay, which is per default set to 5 sec and can be changed in > /etc/systemd/logind.conf by setting InhibitDelayMaxSec. Setting this to a > very high value would probably mean a high risk of breaking other uses > cases (set to sleep?). > > Another Problem is, that in order to prevent the system from being > shutdown the inhibitor has to be set by root (or at least by a different > user than the dbus command is sent). In my opinion this is a implementation > flaw in systemd and contradicts some uses cases listed at the beginning of > https://www.freedesktop.org/wiki/Software/systemd/inhibit > > At this point it would be extremely complicated to use inhibitors to > achieve our goal. The only way would be a system daemon which sets a block > inhibitor for shutdown and watches all user sessions and releases the > inhibitor only if there is no user session running. This would however > render the shutdown button in plasma useless. > > As for the warning when shutting down with multiple users, I that might be an > SDDM limitation/bug/missing feature. > > Probably this is how KDM worked with utmp or ConsoleKit before. Correct me > if I am wrong, but in the old days the user session would always reuse the > x-server from the display manager. So naturally when the user session ends > the display manager would naturally regain control. > > But now the kdisplaymanager code send messages to logind via dbus, which > then just killes the session. Any code after the comment in "startkde": > > #Anything after here is logout/shutdown > is definitely not executed on shutdown. > > Right, that's definitely changed. In the old days, KDE would ask the DisplayManager to terminate us, now we have these daemons that manage sessions that we talk to directly. --- As for us checking for other sessions and prompting the user, we probably should do that. We have the code available. ---- For running scripts on shutdown Anything in $XDG_DATA_DIRS/plasma-workspace/shutdown and executable will be run blocking in alphabetical order and run until completed before we actually execute the shutdown/logout. (make sure you have 1dc7f11692a4096b9815ae24f7be9cec10f8f7a5 in plasma-workspace) You should be able to sync there. ---- You can't cancel logout from within that. If you need to, there is one (quirky) option. When a user shuts down, ksmserver goes round every GUI client asking what to do. For example if you have a text editor with unsaved changed for example it till give you a prompt. It will pause, whilst it's prompting the user and will cancel shutdown/logout if the user presses cancel. You could implement a (hidden) app that does the same. David
