Plasma5 user sessions

Thu Feb 1 14:14:52 UTC 2018

Hi Roman,

thanks for your reply.

Am 29.01.2018 um 23:11 schrieb 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.

I guess we are at the very end at the moment. We need to get our release
done and it has to work for the administrators at the end of the day.
I'm not an expert in SysOps either, but I know they will get angry if
stuff is not working. Don't get me wrong but it has to work and it has
to be robust.

On the other hand the particular code in plasma-workspace is not very
dynamic in the sense that it doesn't change frequently. And the patch
isn't very complex either. I attached it, so you can have a look at it.

> 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.

Running a "Xsession" script is the canonical way of starting daemons for
X11 sessions in the user context independent from the desktop
environment. Splitting this into snippets in "/etc/X11/Xsession.d" is
probably debian specific. The "Xsession" script will be executed by the
X11 display manager and is also the point where the desktop environment
is started.

> 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.

I guess this could be done in some way. But I consider this bad design.
System software - also those run in user context - should not rely on
the state of the users home directory.

That is if you could only launch a plasma desktop if you'd installed
some files in your home directory. I know there is other software which
does that. But we will not follow that path.

> 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.

If the home directory has to be synced down from a filer you do not want
to start the desktop environment before.

> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: LHM-0005-Delegate-shutdown.patch
Type: text/x-patch
Size: 2322 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/enterprise/attachments/20180201/23980f45/attachment.bin>