On Wed, Dec 19, 2007 at 05:38:04PM +0100, Lennart Poettering wrote: > On Wed, 19.12.07 17:06, Patrice Dumas (pertusus@xxxxxxx) wrote: > > > > starting and monitoring processes is just what a session manager is > > > good in. A session manager is not good for authenticating users, and > > > PAM is not great for starting/monitoring/stopping processes. So we > > > > PAM is great for starting (and maybe stopping) session-wide > > processes. > > Not really. > > What we really want is some kind of init-like babysitter as the > session manager. Something that looks after processes, starts them, > stops them, restarts them when they die, handles login/logout, > maintains their startup order, supervises RT cpu load, kills > misbehaving processes, sets resource limits, nice levels, handles core > files, allows control via D-Bus, and so on and so on. Basically what a > good system init process would do for system daemons, but for > user/session daemons and other processes. I try to push Scott > Remnant with his InitKit into that direction. Urg... This seems a bit too much, that time ;-). something that launches scripts in a given order at start and stop would be enough in my opinion. But with a possibility of modularity and per-login possible configuration. > Right now, every single user/session daemon behaves differently. Some > daemonize properly (which is a bad thing), some don't. Some do their > own logging, some don't. Some are started via XSM, some via XDG > autostart, some are run directly by gs. So, what we really want is a > central daemon which treats all those daemons the same, and makes sure > they are started in the right order, and that it is waited that they > fully started up before we get to the next process. While the > dependency trees are certainly much simpler for GNOME sessions than > for system bootup it is basically the same problem, so it would be > great to handle both the same way by the same code. System bootup seems more complex to me, but why not have some manager that can be used for both, indeed (as long as it is not mandatory). > Now, we don't have such a cool session daemon right now. However, > moving things into PAM is definitely the wrong direction. Because in > PAM you can only hook code when the session starts and when the > session ends. A session daemon like that however needs to constantly > monitor all its processes, and thus needs to be running all the time. You mean must be restarted when it died? > Now, of course you can fork this monitoring daemon away from the PAM > session login code and kill it on logout. But if you do that you are > mixing the code that makes up the session with the code that sets up > the session. I can't see why this couln't be possible. > More correct than running PA and any number of other auxiliary daemons > from the PAM hooks would be to call the session manager with special > settings for the console from the login process, instead of /bin/bash > directly. i.e. replace the shell in /etc/passwd by /usr/bin/initkit or > suchlike. However, that's definitely a controversial issue. It would be nice to have many way of doing it. Including as a shell, from X init scripts, from pam, from window manager, and so on and so forth. Still, currently, the only modular place where per login stuff can be launched at the administrator will is PAM. -- Pat -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
