On Wed, Dec 19, 2007 at 05:38:04PM +0100, Lennart Poettering wrote:
On Wed, 19.12.07 17:06, Patrice Dumas (pertusus(a)free.fr) 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
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
Right now, every single user/session daemon behaves differently.
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.
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
I can't see why this couln't be possible.
More correct than running PA and any number of other auxiliary
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
Still, currently, the only modular place where per login stuff can be
launched at the administrator will is PAM.