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

[Lucas]

On 06/10/2011 08:42 PM, Denys Vlasenko wrote:
> 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.
>


It looks like it is the right time to think about upstart again. I will definitely check it out on 
rawhide.
Thanks to OP for pointing on some difficulties. More important that it will be not so easy to clean 
that all up latter and we will get eventually unmanageable windows.