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

Re: A few observations about systemd

On Tue, 19 Jul 2011, Bastien ROUCARIES <roucaries.bastien@gmail.com> wrote:
> > The above is from the ps output of one of my i386 servers running
> > Squeeze.  It appears that systemd has allocated an extra 2324K of RAM
> > and has an extra 2712K resident.  Given that it's difficult to buy a
> > phone with less than 256M of RAM nowadays that doesn't seem to be a big
> > problem, and systemd can save memory by removing the need to run other
> > daemons.
> I have some avr32 card with 32Mb that are valuable and do measurement
> over network with blas/lapack. 1Mb is a lot of double. Phone is not
> the only market.

How do dpkg and apt-get run on that?


Back in 2008 I did some tests on Xen DomUs running Debian with varying amounts 
of RAM.  A simple apt-get command to install 14 packages started taking 
exponentially greater amounts of time when less than 32M of RAM were 
available.  A DomU with 28M of RAM wasn't bootable with the default Debian 

Given that things are getting bigger all the time (both kernel and user-space) 
I wonder if Wheezy will boot in a default configuration with 32M of RAM 

It could be that systemd isn't the biggest problem for 32M systems in Wheezy.

> >> Better security will need to keep pid==1 to some really simple stuff,
> >> and delegate funky stuff to another daemon. pid == 1 should be keep
> >> only to reap zombie process no more.
> > 
> > I think you mean to say that there is a theoretical benefit for
> > reliability there.  As all the things that systemd does will be
> > performed by different root owned processes in a typical Linux system
> > there won't be much potential for security benefits in using separate
> > processes.
> pid == 1 is immortal. I should not get unrecoverable signal like
> sigsegv. I could restart other daemon if needed.

Jul 19 01:01:47 unstable64 systemd[1]: Caught <SEGV>, dumped core as pid 889.
Jul 19 01:01:47 unstable64 systemd[1]: Freezing execution

It's not strictly unrecoverable.  If you run "kill -11 1" then you get the 
above in syslog.

But it does result in a system that doesn't work properly.

My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Reply to: