Plasma5 user sessions

[Roman Gilg]

Hi Max,

sorry for my late reply. I was working on some larger project, which
took me away.

I'm no expert on the init sequence and also not on SysOps, but from a
developer perspective diverging from upstream by patching a major
software piece like plasma-workspace in order to solve a particular
setup problem should always only be considered at the very end.

Especially in your case you want to use some undocumented and
obviously not very abstract routine (startkde) to hook into. Does the
documentation imply anywhere that you have the right to expect that
the startkde script is not exited early and you can wrap it? I think
it does not and even if it does, there is the question if this is
really the most canonical approach. I would say the more canonical
approach would be to use the $HOME/.config/plasma-workspace/env
directory or systemd user services.

Regarding the scripts in the env directory being under user control:
Is this really an issue? How many users will delete these files? Can
you not restore them in this case with a small setup script not in
user control? And I don't know if it's bad practice, but the first
thing I thought of was to own the env directory by a higher privileged
user and make the directory non-writeable to your users, so they just
can't delete these files.

Regarding the systemd user services: Is it really necessary that your
startup scripts run in sequence before the workspace loads? If you
think so, maybe it would be better to patch your startup scripts so
they can run in parallel. I can't directly think of a reason why this
should not work for tasks like setting up network shares and so on.

Anyways good luck and I hope the solution you decide upon in the end
works fine for your setup.

Cheers
Roman

On Thu, Jan 18, 2018 at 10:06 AM, Max Harmathy <max.harmathy at web.de> wrote:
> Am 15.01.2018 um 14:32 schrieb Max Harmathy:
>> Greetings from Munich's LiMux developers team.
>>
>> short story:
>>
>> * during user session initialisation notifications get displayed as windows
>> * if one user requests a shutdown (reboot, poweroff) all sessions get killed
>>
>> long story:
>>
>> We are currently in development of our next (final?) release. Our
>> current release is based on Ubuntu 14.04 trust, whereas our next release
>> will be based on Ubuntu 18.04 bionic.
>>
>> Thus we switch from
>> * upstart to systemd
>> * ConsoleKit to logind
>> * KDM to SDDM
>> * Plasma 4.x to Plasma 5.x
>>
>> We have to execute some tasks for every user who logs into a computer.
>> This includes configuring start menu applications, configuring printers,
>> mounting network shares and synchronise the users home directory with a
>> filer (downsync). We also provide slots where administrators can run
>> scripts in the user context.
>>
>> Up until now we hooked into the user session by putting some files into
>> /etc/X11/Xsession.d which is as far as we understand executed by the
>> display-manager when a x11 user session gets initialised.
>>
>> During these configuration steps there are some notifications we want to
>> be displayed after the desktop is ready. Therefore we collect such
>> messages. The a script in /etc/xdg/autostart displays them after the
>> plasma session started as normal desktop notifications. Therefore the
>> script sends them through the DBus session bus via
>> org.freedesktop.Notifications. However on our development release those
>> messages get displayed as windows instead of the usual bubbles. It seems
>> that the notification handling is not ready when the autostarts are running.
>>
>> When the user ends the session we also run code to synchronise the home
>> directory (upsync), umnount network shares etc. This works as expected
>> if the user does a simple logout. However if the user requests a
>> shutdown (reboot, poweroff) then the session and other user sessions are
>> killed and the computer shuts down. The KSMServer
>> (plasma-workspace/ksmserver/server.cpp, void KSMServer::cleanUp()) uses
>> a KDisplayManager (plasma-workspace/libkworkspace/kdisplaymanager.cpp)
>> which sends a "Reboot" or "PowerOff" through the system bus to logind.
>> This results in an immediate shutdown and neither our code nor parts of
>> the startkde script is executed.
>>
>> Comments in kdisplaymanager.cpp state that there should be a policykit
>> dialog preventing a shutdown if other sessions are running, which is not
>> displayed in our case. But also without other sessions running, the
>> logout should finish in a clean way(wait for startkde to terminate).
>>
>> We found out, that running a process with a systemd inhibitor as root e.g
>>> # systemd-inhibit --what=shutdown --mode=block sleep 365d
>> prevents the system from killing the session and a clean logout is
>> conducted. However in this case also the shutdown request is silently
>> ignored.
>>
>> There are some questions we where not able to find answers by ourselves:
>>
>> Is there a definition when xdg-autostart applications are started?
>>
>> Is there a way to make sure that the session is ready to display
>> notifications?
>>
>> It seems that sending dbus messages to logind in kdisplaymanager.cpp is
>> too early. Could this be a general issue? Should this not be the last
>> part of startkde?
>>
>> Could this be a misconfiguration of policykit?
>>
>> Could it be that the behaviour of logind changed recently?
>>
>> It looks like there are currently some weak spots with plasma5 sessions.
>> We hope that we can work together to make the users session handling
>> more robust.
>>
>
> I familiarised myself with session handling with logind [1]. I also
> looked at what GNOME is doing [2].
>
> I have come to the conclusion, that we will most likely patch
> plasma-workspace not to send DBus requests to logind. Instead we will
> record the request of the user (with a flag file) and handle it during
> logout after startkde terminated and our configuration tasks have finished.
>
> Nevertheless I think that the session handling in the KDisaplayManager
> code has a severe issue in conjunction with logind. Therefore I opened a
> ticket on Bugzilla[3].
>
> Max
>
> [1] https://dvdhrm.wordpress.com/2013/08/24/session-management-on-linux/
> [2] https://git.gnome.org/browse/gnome-session/
> [3] https://bugs.kde.org/show_bug.cgi?id=389144