systemd: please stop trying to take over the world :)

[Denys Vlasenko]

On Fri, 2011-06-10 at 15:36 +0200, Michal Schmidt wrote:
> > Why does systemd link against libpam?
> > systemd does logins now, not /bin/login or gdm or ...?
> 
> to implement PAMName= (man systemd.exec)

I don't see any users of this feature on my F15.
I searched with Google and come up empty too.

But anyway, assuming it's a useful feature, why it has to be done by
systemd?

I looked at implementation.
systemd-26/src/execute.c::setup_pam():

        /* We set up PAM in the parent process, then fork. The child
         * will then stay around until killed via PR_GET_PDEATHSIG or
         * systemd via the cgroup logic. It will then remove the PAM
         * session again. The parent process will exec() the actual
         * daemon. We do things this way to ensure that the main PID
         * of the daemon is the one we initially fork()ed. */

I don't see any attempt to free at least something in the child.
So, systemd forks a process with eleven megabyte of malloced stuff
to act just as a babysitter - wait for parent to die, call pam_end,
exit?
For how long will it hang around in the system - possibly days?

Yes, COW, so not all of these eleven megabytes will be around...
...at first, until parent execs, or modifies sufficiently many pages
so that most of them are copied.

But memory consumption is not really the gist of my argument, it's:
why systemd tries to be all things for all people?

Why it has to care about PAM? I think most tools which need it do it
themselves, and we can write a small, really small helper for those
which don't.


> > libwrap? systemd is a network application now too?
> 
> to implement TCPWrapName= (man systemd.exec)

Again, why it has to be done *by systemd*?




On Fri, 2011-06-10 at 10:09 -0400, Steve Clark wrote:
> > Yes, whatever happened to the *NIX philosophy of simple non-complex
> programs that did their job well. It has seemed to serve well since
> the 70's.

Exactly my point.

-- 
vda