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

Reply via email to