FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 06-10-2011, 01:36 PM
Michal Schmidt
 
Default systemd: please stop trying to take over the world :)

On 06/10/2011 03:07 PM, Denys Vlasenko wrote:
> I understand your desire to replace everything by systemd.
> I really do. syslogd, klogd, mount, fsck, and a dozen other things
> I forget or don't know.

You're exaggerating.

> Why does systemd link against libpam?
> systemd does logins now, not /bin/login or gdm or ...?

to implement PAMName= (man systemd.exec)

> libattr? Does it mean it requires filesystem which implements
> extended attributes? If not, why does it use libattr then?

systemd uses libcap. libcap depends on libattr.

> libwrap? systemd is a network application now too?

to implement TCPWrapName= (man systemd.exec)

> libaudit? What systemd has in common with audit?

Start and stop of a service is an auditable event.
http://lists.fedoraproject.org/pipermail/devel/2010-August/141543.html

> To be honest, I doubt the wisdom of implementing service manager
> as an init process. There is no inherent reason why it has to be init -
> you can run it as *a child of init*, and keep init very simple.
> Then, if service manager would crash, at least it doesn't
> take system down with it...

systemd does not take the system down when it crashes. It catches the
signal, dumps core and freezes, but does not exit.

Michal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-10-2011, 01:59 PM
Steve Clark
 
Default systemd: please stop trying to take over the world :)

On 06/10/2011 09:36 AM, Michal Schmidt wrote:

On 06/10/2011 03:07 PM, Denys Vlasenko wrote:


I understand your desire to replace everything by systemd.
I really do. syslogd, klogd, mount, fsck, and a dozen other things
I forget or don't know.



You're exaggerating.



Why does systemd link against libpam?
systemd does logins now, not /bin/login or gdm or ...?



to implement PAMName= (man systemd.exec)



libattr? Does it mean it requires filesystem which implements
extended attributes? If not, why does it use libattr then?



systemd uses libcap. libcap depends on libattr.



libwrap? systemd is a network application now too?



to implement TCPWrapName= (man systemd.exec)



libaudit? What systemd has in common with audit?



Start and stop of a service is an auditable event.
http://lists.fedoraproject.org/pipermail/devel/2010-August/141543.html



To be honest, I doubt the wisdom of implementing service manager
as an init process. There is no inherent reason why it has to be init -
you can run it as *a child of init*, and keep init very simple.
Then, if service manager would crash, at least it doesn't
take system down with it...



systemd does not take the system down when it crashes. It catches the
signal, dumps core and freezes, but does not exit.
^^^^^^^


So you just end up with a "froze" system instead of a crashed
system????


Michal






--

Stephen*Clark

NetWolves

Sr.*Software*Engineer*III

Phone:*813-579-3200

Fax:*813-882-0209

Email:*steve.clark@netwolves.com

http://www.netwolves.com




--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-10-2011, 02:09 PM
Steve Clark
 
Default systemd: please stop trying to take over the world :)

On 06/10/2011 09:07 AM, Denys Vlasenko wrote:

Hi Lennart,

systemd is eating a lot more memory than any other init process
I ever played with.

Granted, systemd does a bit more that "typical" init, but I think
using *eleven plus megabytes* of malloced space is a bit much.

systemctl --all shows 258 units total on my machine,
thus systemd uses ~40 *KILO*bytes of state per unit?

I understand your desire to replace everything by systemd.
I really do. syslogd, klogd, mount, fsck, and a dozen other things
I forget or don't know. It's called "featuritis".
Now I hear about plans to incorporate ConsoleKit into it
(hearsay, so maybe it's not true).

Look where it is now:

Top:

Mem total:2035840 anon:431208 map:78924 free:419084
slab:91624 buf:108040 cache:942336 dirty:196 write:0
Swap total:4095996 free:4095996
PID VSZ VSZRW RSS (SHR)*DIRTY (SHR) STACK COMMAND
1818 624m 365m 185m 13472 155m 64 224 /usr/lib/firefox-4/firefox
1816 433m 189m 166m 17248 142m 0 204 evolution
1257 53672 40400 22664 6004 18336 4176 132 /usr/bin/Xorg
1 15384 11856 13664 1340 11752 0 132 /sbin/init
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^ 11.7 megs of malloc space

1839 275m 40224 24208 10572 11020 0 132 /usr/bin/gnome-terminal
1713 202m 45284 20308 9736 9604 576 132 /usr/libexec/xfce4/panel-plugins/xfce4-mixer-plugin
1843 171m 9448 20264 10012 8440 344 204 xchat
1770 152m 55672 19412 10972 6108 0 132 nautilus

It's the *fourth* largest process on my system!


# ldd `which systemd`
linux-gate.so.1 => (0x00a6b000)
libselinux.so.1 => /lib/libselinux.so.1 (0x414f6000)
libdbus-1.so.3 => /lib/libdbus-1.so.3 (0x41bc1000)
libpthread.so.0 => /lib/libpthread.so.0 (0x0019a000)
libudev.so.0 => /lib/libudev.so.0 (0x422c9000)
libwrap.so.0 => /lib/libwrap.so.0 (0x420fa000)
libpam.so.0 => /lib/libpam.so.0 (0x420e6000)
libaudit.so.1 => /lib/libaudit.so.1 (0x420cc000)
libcap.so.2 => /lib/libcap.so.2 (0x4152f000)
librt.so.1 => /lib/librt.so.1 (0x00be8000)
libc.so.6 => /lib/libc.so.6 (0x00295000)
/lib/ld-linux.so.2 (0x00276000)
libdl.so.2 => /lib/libdl.so.2 (0x00af6000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00f68000)
libnsl.so.1 => /lib/libnsl.so.1 (0x0095c000)
libattr.so.1 => /lib/libattr.so.1 (0x420c5000)

Why does systemd link against libpam?
systemd does logins now, not /bin/login or gdm or ...?

libattr? Does it mean it requires filesystem which implements
extended attributes? If not, why does it use libattr then?

libwrap? systemd is a network application now too?

libaudit? What systemd has in common with audit?

libdbus?... this is a lost battle I guess...

I propose to stop for a second and optimize systemd down
instead of trying to add even more bells and whistles to it.
Or else you'll soon end up linking against every /lib/lib*.so*

At the very least, I would like to see its memory consumption
to go down substantially.

It is an *init replacement*, not the replacement for everything.
One of init's goal is to be *simple* and *stable*.
Every new feature you add and library you link against
works against that goal.

To be honest, I doubt the wisdom of implementing service manager
as an init process. There is no inherent reason why it has to be init -
you can run it as *a child of init*, and keep init very simple.
Then, if service manager would crash, at least it doesn't
take system down with it...



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.



--

Stephen*Clark

NetWolves

Sr.*Software*Engineer*III

Phone:*813-579-3200

Fax:*813-882-0209

Email:*steve.clark@netwolves.com

http://www.netwolves.com




--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-10-2011, 02:11 PM
Michal Schmidt
 
Default systemd: please stop trying to take over the world :)

On 06/10/2011 03:59 PM, Steve Clark wrote:
> On 06/10/2011 09:36 AM, Michal Schmidt wrote:
>> systemd does not take the system down when it crashes. It catches the
>> signal, dumps core and freezes, but does not exit.
>> ^^^^^^^
> So you just end up with a "froze" system instead of a crashed system????

No, only systemd freezes itself. Other processes continue running.

Michal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-10-2011, 04:42 PM
Denys Vlasenko
 
Default systemd: please stop trying to take over the world :)

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


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-10-2011, 04:58 PM
Denys Vlasenko
 
Default systemd: please stop trying to take over the world :)

On Fri, 2011-06-10 at 16:11 +0200, Michal Schmidt wrote:
> On 06/10/2011 03:59 PM, Steve Clark wrote:
> > On 06/10/2011 09:36 AM, Michal Schmidt wrote:
> >> systemd does not take the system down when it crashes. It catches the
> >> signal, dumps core and freezes, but does not exit.
> >> ^^^^^^^
> > So you just end up with a "froze" system instead of a crashed system????
>
> No, only systemd freezes itself. Other processes continue running.

systemd-26/src/main.c::crash() is the function which does it.
Assuming it will not recurse by crashing again, of course. It calls
log_error and assert_se, which go into log_dispatch(), which logs to
syslog, may try to write to klog, and whatnot... this doesn't look
too robust to me.

But anyway. Assuming it successfully froze. Does it help?
Yes. How much? Well, it's better than instant oops which happens
when PID 1 exits, but reaping of processes reparented
to init will stop, which, for example, makes the hang from pid
exhaustion just a question of time.

Ultimately, this stems from the decision to make systemd
to run as PID 1 process. Are there technical reasons for this?

--
vda


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-10-2011, 05:00 PM
Lucas
 
Default systemd: please stop trying to take over the world :)

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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-10-2011, 05:02 PM
Colin Walters
 
Default systemd: please stop trying to take over the world :)

On Fri, Jun 10, 2011 at 9:07 AM, Denys Vlasenko <dvlasenk@redhat.com> wrote:
>
> It's the *fourth* largest process on my system!
>
>
> # ldd `which systemd`

1) Looking at what libraries a binary links to a is a terrible way to
optimize memory usage; try massif, say
2) It'd be a lot more productive to be positive and not phrase your
message in such an antagonistic way (in fact, this message would
probably be better on the systemd-devel mailing list)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 09:51 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org