[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: how is pulseaudio supposed to work?

On Wed, 19.12.07 17:06, Patrice Dumas (pertusus 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
> 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.

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. 

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.

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.

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.


Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]