Systemd opposed to init?

Vicophine · 2012-10-14 06:22:07

Should upcoming releases of Crunchbang come shipped with Systemd installed by default rather than init? The more I read about systemd, the more I think it is suited for Crunchbang over the existing init scripts. I realize the Systemd program does not necessarily conform to the KISS standard, but it is also supposedly much more efficient. I myself will be testing it out on one machine just to see if it increases performances at all.

What do you guys think? I may learn something here too smile

VastOne · 2012-10-14 07:16:09

Good questions ... Here is a link has that several other links that discuss systemd values and standards.

One link is specific to Debian and the debate is on.

I am definitely interested in where this goes and am researching it more before offering an opinion. I also see that Fedora, openSUSE, Mandriva, Mageia and Arch already has it available.

Thanks for bringing this up!

mynis01 · 2012-10-14 18:45:43

I've moved all of my systems over to systemd. Boot times are noticeably faster, and shutdown is near instant. Learning to use systemctl instead of init and runlevel and some of the older commands is taking a bit of getting used to. Other than that, it's been a pretty seamless transition for me. Most distros seem to be moving over to systemd, so you might as well start learning it now. I'm guessing debian might stick with sysvinit for the default for one more release. But as time goes on, developers and maintainers might stop paying attention to compatibility with sysvinit based systems.

VastOne · 2012-10-14 18:54:50

^ Are any of your systems Debian? Perhaps you could create a guide on how you did this.. smile

mynis01 · 2012-10-14 19:15:29

The desktop and laptop I converted to systemd are running arch. For the most part, all you should really have to do to get the system up and running is install the systemd package from the testing repos and append this to your kernel boot parameters: "init=/bin/systemd". So if you are using grub, you need a line that looks something like this:

linux    /vmlinuz-linux root=UUID=########-####-####-####-############ init=/bin/systemd ro quiet

I have this following week off school so maybe if I can peel myself away from Guild Wars 2 for long enough I'll install Waldorf in a VM and figure out what additional steps (if any) are necessary to get it running in debian.

Unia · 2012-10-14 19:17:26

I'm using systemd too, on Arch. I think it's has just taken step one to being the default: it's installed by default now when you use the new installation CD.

I have never had to deal with any init system in-depth, but from the files I had to edit I think systemd is simpler. The commands are different, but not per se harder. I do also like it also manages hibernate and sleep etc so one can ditch pm-utils and acpid with it.

It's like one centralized place for every start/stop thing you would use on your computer. Might not be KISS or GNU spirit, but I like it.

VastOne · 2012-10-14 19:53:06

mynis01 wrote:

The desktop and laptop I converted to systemd are running arch. For the most part, all you should really have to do to get the system up and running is install the systemd package from the testing repos and append this to your kernel boot parameters: "init=/bin/systemd". So if you are using grub, you need a line that looks something like this:
linux    /vmlinuz-linux root=UUID=########-####-####-####-############ init=/bin/systemd ro quiet
I have this following week off school so maybe if I can peel myself away from Guild Wars 2 for long enough I'll install Waldorf in a VM and figure out what additional steps (if any) are necessary to get it running in debian.

I installed it... Running Debian Sid and also the Liquorix kernel which does have the correct config flags setup.

I did put init=/bin/systemd in the grub line but had to remove it as it would not boot with that there. In researching systemd, it would seem that line is no longer a requirement.

So the question now is whether or not it is actually running.

Edit - I did have to have init=/bin/systemd in the grub line as described on the Debian Systemd Wiki

I too quiet out to see what was going on ... there is a long delay in the boot process but it does boot... Researching now what that is.

So the steps I took were this for Debian

sudo apt-get install systemd

then

sudo geany /etc/default/grub

And made this line

GRUB_CMDLINE_LINUX_DEFAULT="quiet nomodeset nouveau.modeset=0"

this

GRUB_CMDLINE_LINUX_DEFAULT="init=/bin/systemd nomodeset nouveau.modeset=0"

VastOne · 2012-10-14 20:37:43

^ Shutdowns are instantaneous... Incredibly fast.. I still have the issue on startup, a full minute delay after starting up the network.

Still researching what that is.

Unia · 2012-10-14 20:44:03

Run $ systemctl --failed to see if any unit file failed.

Or use $ systemd-analyze blame to see your startup processes and list them from taking alot of time to taking nothing wink

Last edited by Unia (2012-10-14 20:45:29)

VastOne · 2012-10-14 20:49:26

Unia wrote:

Run $ systemctl --failed to see if any unit file failed.
Or use $ systemd-analyze blame to see your startup processes and list them from taking alot of time to taking nothing

Just found these the same time you posted them... Thanks

systemctl --failed
UNIT LOAD   ACTIVE SUB JOB DESCRIPTION

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.
JOB    = Pending job for the unit.

0 units listed. Pass --all to see inactive units, too

systemctl -- all --failed

0 usints listed

systemd-analyze blame

  3006ms hddtemp.service
  2453ms loadcpufreq.service
  2399ms udev.service
  2352ms bootlogs.service
  2346ms keyboard-setup.service
  2321ms nfs-common.service
  2206ms cron.service
  2164ms sys-kernel-debug.mount
  2052ms ntp.service
  1893ms dev-mqueue.mount
  1888ms sys-kernel-security.mount
  1883ms dev-hugepages.mount
  1800ms systemd-remount-api-vfs.service
  1787ms lightdm.service
  1681ms binfmt-support.service
  1383ms systemd-modules-load.service
  1355ms networking.service
  1230ms screen-cleanup.service
  1134ms alsa-utils.service
  1134ms kbd.service
  1052ms live-config.service
   816ms atd.service
   686ms hdparm.service
   683ms proc-sys-fs-binfmt_misc.mount
   646ms systemd-user-sessions.service
   630ms avahi-daemon.service
   614ms rc.local.service
   605ms systemd-logind.service
   514ms sys-fs-fuse-connections.mount
   348ms cpufrequtils.service
   318ms rpcbind.service
   295ms media-sda2.mount
   279ms media-sda5.mount
   243ms rtkit-daemon.service
   214ms console-kit-daemon.service
   209ms media-sda7.mount
   206ms pulseaudio.service
   205ms console-setup.service
   202ms systemd-sysctl.service
   164ms console-kit-log-system-start.service
   153ms media-Boot_Grub_Drive.mount
   144ms udev-trigger.service
   130ms upower.service
   123ms media-sda6.mount
   106ms live.service
    97ms systemd-tmpfiles-setup.service
    82ms motd.service
    65ms remount-rootfs.service
    63ms polkitd.service
    55ms debian-fixup.service
    25ms rsyslog.service

Gonna add logging to grub parameters to chase it down...

Last edited by VastOne (2012-10-14 20:53:33)

sano · 2012-10-14 20:57:30

For another overview to what is delaying your boot you could also try

systemd-analyze plot > systemd.svg

mynis01 · 2012-10-14 21:27:13

That's a whole lot of stuff you have running at startup there. If you add up all those milliseconds in systemd-analyze blame and do the math that's at least a good minute of initializing services. Here's what mine looks like:

190ms media-delphixfs.mount
   186ms wicd.service
   149ms systemd-binfmt.service
   139ms media-delphixfs2.mount
   126ms systemd-modules-load.service
   126ms systemd-udev-trigger.service
    56ms sensors.service
    53ms rc-local.service
    49ms systemd-remount-fs.service
    49ms media-delphiroot.mount
    49ms systemd-logind.service
    45ms console-kit-log-system-start.service
    40ms sys-kernel-debug.mount
    34ms systemd-sysctl.service
    33ms dev-mqueue.mount
    33ms systemd-vconsole-setup.service
    31ms systemd-udevd.service
    30ms dev-hugepages.mount
    26ms console-kit-daemon.service
    23ms alsa.service
    16ms systemd-user-sessions.service
    16ms udisks2.service
    14ms systemd-tmpfiles-setup.service
    10ms proc-sys-fs-binfmt_misc.mount
     7ms upower.service
     6ms tmp.mount
     2ms ntpd.service
     2ms boot-efi.mount
     1ms boot.mount
     0ms sys-fs-fuse-connections.mount

I could even trim that down and get my startup time to be around half a second if I wanted to. I had ntpd taking up a considerable amount of time at startup like you do so I took it out and made a cron job that syncs my clock via ntp about 30 seconds after startup (so as not to interfere with fsck) like this:

@reboot /bin/sleep 30 ; /usr/bin/ntpd -qg

Bootlogs can probably be disabled too, since systemd has its own built in logging system. The keyboard setup could probably be disabled too, I just have xmodmap entries in my ~/.config/openbox/autostart.sh for all my keyboard-remapping needs (the downside of this of course is that the keyboard mods don't apply to the tty).
I would just go through all those services one by one and determine what you could get rid of and what you need right away at startup. A lot of those I see in your list are redundant, unnecessary or could be started after boot time with cron (like hddtemp and cpufreq-utils). I disabled networking.service and all the DNS related stuff (like avahi) and use wicd.service in place of them. Even though I use a static IP and DNS configuration, it seems to work faster.

Last edited by mynis01 (2012-10-14 21:30:25)

VastOne · 2012-10-14 21:32:29

^ That is a major difference in time and services you have compared to mine.

Same system, same setup as with init services, why didn't init take as long to boot?

I have a bit to learn and study on this.

Thanks for the input

mynis01 · 2012-10-14 21:42:27

Keep in mind if you had trimmed down your startup with rcconf or something like that in the past, that configuration won't carry over. When you used apt to install systemd, it probably just created a ton of default .service files that are there for compatibility. Also, I think debian made some tweaks to make it more interoperable with their existing initscripts setup, I've heard a few people on the debian forums saying that they compiled systemd manually and applied just one of the debian patches. You might find this blog informative: http://www.holgerschurig.de/linux/systemd.html

VastOne · 2012-10-14 21:48:04

^ That is perfect... And it makes sense

Thanks for that link, it is well done and documented.

Makes it a lot easier to work with and debug systemd.

I'll keep you posted on my progress.

Vicophine · 2012-10-15 06:18:43

Wow, awesome responses all around guys! I think I will wait till someone creates a good, thorough guide on setting this up before I move my main machine (Running #! of course big_smile ) to Systemd, but hopefully that won't be too long.

Thanks guys! Let's keep up this development! big_smile

VastOne · 2012-10-15 12:18:48

^ The link that mynis01 provided is one of the best How To's I have seen. wink

Erinsfan · 2012-10-15 18:38:23

Can I ask will systemd make the OS unbootable or can you still boot using init should a systemd boot fail?

Thanks

mynis01 · 2012-10-15 18:56:09

Erinsfan wrote:

Can I ask will systemd make the OS unbootable or can you still boot using init should a systemd boot fail?
Thanks

All you should have to do is remove the init=/bin/systemd line from your kernel boot parameters and you should boot right back up using init. On my arch system, the ability to boot using sysvinit was removed (deliberately by myself using the package manager) but I'm pretty sure debian still won't even allow you to remove sysvinit, at least short of using rm -rf. Basically you're telling the system to load services at startup using the /bin/systemd binary instead of the regular sysvinit binary (/sbin/init ? ), so they can coexist on your system.

Last edited by mynis01 (2012-10-15 18:59:15)

Erinsfan · 2012-10-15 19:25:51

Thank you for the clarification.

DapperMe17 · 2013-04-07 07:56:36

Installed systemd in VSIDO.

Simply installed systemd, and it's dependancies via Synaptic.

Per the Debian Wiki....http://wiki.debian.org/systemd

added "init=/lib/systemd/systemd" (Without the quotes)

to the kernel parameter line in grub.cfg.

Works fine as tested with the Liquorix kernel.

Both boot & shutdown are noticably quicker.
wink

Last edited by DapperMe17 (2013-04-07 08:05:15)

wuxmedia · 2013-04-07 08:25:29

must read thread dates.... roll
thought for a minute V1 was getting a bit slow, yikes
even i'm fairly up on systemd tongue

BTW - MATE1.4 didn't like systemd much (at least not for me), MATE 1.6 is supposed to be happier, so i will try it out. won't be posting here though monkey

DapperMe17 · 2013-04-07 08:39:22

...didn't know it had an expiration date. angel

VastOne · 2013-04-07 13:49:11

DapperMe17 wrote:

Installed systemd in VSIDO.
Simply installed systemd, and it's dependancies via Synaptic.
Per the Debian Wiki....http://wiki.debian.org/systemd
added "init=/lib/systemd/systemd" (Without the quotes)
to the kernel parameter line in grub.cfg.
Works fine as tested with the Liquorix kernel.
Both boot & shutdown are noticably quicker.

Thanks for this info DapperMe17. I had tested systemd on a pure Debian install before VSIDO and was not happy at all with the results

I have just tested it again with a new install of VSIDO and now see a 12 second boot time and a 3 second shutdown time and everything running fine

Now to look into incorporating systemd as the default in VSIDO

I appreciate it

dura · 2013-04-07 14:04:45

^That would be a really good addition to Vsido I think. Systemd, for me, is much more intuitive than init, and more efficient. I see systemd as a nice breaking away from pure Debian and an opening up to new possibility.

CrunchBang Linux

SEARCH

#1 2012-10-14 06:22:07

Systemd opposed to init?

#2 2012-10-14 07:16:09

Re: Systemd opposed to init?

#3 2012-10-14 18:45:43

Re: Systemd opposed to init?

#4 2012-10-14 18:54:50

Re: Systemd opposed to init?

#5 2012-10-14 19:15:29

Re: Systemd opposed to init?

#6 2012-10-14 19:17:26

Re: Systemd opposed to init?

#7 2012-10-14 19:53:06

Re: Systemd opposed to init?

#8 2012-10-14 20:37:43

Re: Systemd opposed to init?

#9 2012-10-14 20:44:03

Re: Systemd opposed to init?

#10 2012-10-14 20:49:26

Re: Systemd opposed to init?

#11 2012-10-14 20:57:30

Re: Systemd opposed to init?

#12 2012-10-14 21:27:13

Re: Systemd opposed to init?

#13 2012-10-14 21:32:29

Re: Systemd opposed to init?

#14 2012-10-14 21:42:27

Re: Systemd opposed to init?

#15 2012-10-14 21:48:04

Re: Systemd opposed to init?

#16 2012-10-15 06:18:43

Re: Systemd opposed to init?

#17 2012-10-15 12:18:48

Re: Systemd opposed to init?

#18 2012-10-15 18:38:23

Re: Systemd opposed to init?

#19 2012-10-15 18:56:09

Re: Systemd opposed to init?

#20 2012-10-15 19:25:51

Re: Systemd opposed to init?

#21 2013-04-07 07:56:36

Re: Systemd opposed to init?

#22 2013-04-07 08:25:29

Re: Systemd opposed to init?

#23 2013-04-07 08:39:22

Re: Systemd opposed to init?

#24 2013-04-07 13:49:11

Re: Systemd opposed to init?

#25 2013-04-07 14:04:45

Re: Systemd opposed to init?

Board footer