On Sun, 17.03.13 00:10, Cedric BAIL ([email protected]) 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. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
