[systemd-devel] Enlightenment and systemd user session.

[Lennart Poettering]

On Sun, 17.03.13 00:10, Cedric BAIL (cedric.bail at free.fr) wrote:

> Hello,
> 
>    I am currently working on improving Enlightenment integration with
> Systemd. So far, I have done the easiest thing, socket activation in
> our network library with just one flag and notification when the main
> loop is finally started. I am now facing various issue.
> 
>    I have added support for Journal. It is turned on by default when
> the application is started by systemd. I don't think I made anything
> wrong, but it seems that Journal doesn't know about systemd user
> session unit, is that correct ? I am thinking that because I get the
> following :

Hmm, systemctl didn't use to be able to properly match journal entries
for user units, but I thought that had been fixed. Are you using the
most recent systemd?

>    Now, one of my goal is to remove enlightenment_start binary when in
> a systemd user session. That process start enlightenment and monitor
> it. If it crash, it generate a backtrace and restart it. If the user
> request Enlightenment to restart (common use case for all developers),
> it will exit with a specific value and enlightenment_start will
> restart it. Of course if the user exit it normally, it does just quit.
> I can implement all of this in a systemd unit, but it comes at a cost.
> I am loosing all the applications started by Enlightenment ! Any idea
> how we could prevent that ?

Well, that's what systemd does by default: if a service dies, all that
is remaining is killed. You can turn this off via KillMode=process (see
systemd.kill(5) for details).

>    There is two additional process that do have the same issue :
>    - elm_quicklaunch: a daemon doing linking and initialization of
> EFL, then waiting for request to fork and load EFL application (I
> think KDE has something similar).

KDE does the same, I think it's an intensly bad idea. You cannot really
take arbitrary libraries, initialize them, fork the process and expect
they still work. And maybe the enlightenment libraries are up for that,
but I am sure EFL pulls in a few things, and many of them in non-obvious
ways, through NSS and other loadable modules systems.

Also, you create a tonload of page faults with forked processes like
this, since every process essentially is a CoW copy of your original
process, for all its heap and everything, and every single page write
access in any of the clients will immediately cause a pagefault.

Also, this seriously fucks up security security trails and suchlike,
because every process is running from the same binary.

I mean, Enlightenment and KDE are welcome to do that, but I want to make
clear that we will *never* do anything like that in systemd itself...

>    Something that would be nice is if we could instruct systemd about
> those child process somehow. Even better would be, if possible, a
> library to share the cgroup and all that infrastructure that systemd
> use when setting up a process before doing exec. That could have a
> simple API with just one function that could receive a token coming
> from a .desktop or something like that. Just a thought.

We will eventually ship a .desktop file generator that automatically
turns .desktop files into systemd units and runs that.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.