Getting a grip on systemd, just in case.

PReP · 2012-07-27 16:36:04

I still do not see a need for systemd, personally and for my usecase
- but i have decided to atleast get to know it a bit, just in case of need in the future.
Thus, i took the chance while i also tried the new archiso in a VM in virtualbox.

After a smooth pacstrap/arch install scripts fresh installation,
i followed the systemd wiki-article, and did this, one step at the time;

$ pacman -S systemd # getting systemd itself, and any deps

* fixed myself a hostname, vconsole.conf, locale.conf, and timezone file in /etc

$ pacman -R initscripts # removing initscripts, getting a rc.conf.pacsave just in case was good.
$ pacman -R sysvinit

$ pacman -S systemd-sysvcompat # replacing init and boot with systemd

$ pacman -S systemd-arch-units # getting Arch-compatible versions of native systemd service/unit-files

$ reboot

After the boot, i saw the systemd boot-message breeze by.
By my usecase and situation, i recon i saved about 1-2 secs of boot time (which are trivial for me personally)
but it worked just as well as initscripts has thus far.

- the first thing i noticed was that i had no network. i pondered a bit, figured i had to use some systemd-unit for it,
i later found a mention of dhcpcd@.service, and how to enable it with systemctl further down the wiki,
and i got it working well.

A few thoughts;

1. Couldn't we just aswell use SystemD "the arch way", just having those loose settings still in an rc.conf, or hack up a new one?,
Just the way we have had rc.conf centralizing the old sysvinit-way. i still like that.

Something like:

  #/etc/arch.conf

  hostname=xxxx

  vconsole_keymap=xxxx
  vconsole_font=xxxx
  vconsole_font_map=xxxx
  
  locale_lang=xxxx
  locale_lc_collate=xxxx

  timezone=xxxx

atleast that saves time in my book, if having a good way to make systemd be redirected to look there.
or perhaps something like (semi-pseudo-code): setting hostname: echo $hostname > /etc/hostname, getting it's variables from an arch-centric config-file, and then parsing it when needed.

2. I did not like this symlink-play in traditional sysvinit, and i quite don't find it all too neat in systemd, i wish they could instead have a config-file where to enable services to run,
or have a "Enabled=yes/no" key in each unit file, which systemctl enable just sets when used instead, the same effect but without symlinking.

3. Is there a way to keep the systemd boot messages on screen when hitting the tty-login?, i always feel calmer inside when i have had a quick glance on the boot-output

My thoughts are still that systemd is not needed at all for a simple and maintained system, but i will keep following it and see where it gets.

/PReP

Last edited by PReP (2012-07-27 16:43:13)

satanselbow · 2012-07-27 19:08:24

PReP wrote:

My thoughts are still that systemd is not needed at all for a simple and maintained system, but i will keep following it and see where it gets.
/PReP

Mostly personal blog post material - but I must disagree entirely with your conclusion. systemd itself is in keeping with KISS principles and is an inevitable evolutionary step forward. There does seems to be a lot of challenging arches KISS approach at the moment and attempts to equate it (KISS) with burying your head in the sand; which is far from the truth and way off the mark.

I recently had reason to clean install arch and converted to systemd at that time - by reading the arch news on the homepage and following the wiki there should not be any major headaches

.

kaszak696 · 2012-07-27 19:49:37

The symlink-play in systemd isn't as bad as it was in some sysvinit setups, since it's supposed to be handled automatically by systemctl and not touched by the user.
I found the systemd configs more 'sane' than the rc.conf with all these unrelated settings mashed up into one file.

Last edited by kaszak696 (2012-07-27 19:50:07)

PReP · 2012-07-28 01:55:32

satanselbow wrote:

PReP wrote:
My thoughts are still that systemd is not needed at all for a simple and maintained system, but i will keep following it and see where it gets.
/PReP
Mostly personal blog post material - but I must disagree entirely with your conclusion. systemd itself is in keeping with KISS principles and is an inevitable evolutionary step forward. There does seems to be a lot of challenging arches KISS approach at the moment and attempts to equate it (KISS) with burying your head in the sand; which is far from the truth and way off the mark.
I recently had reason to clean install arch and converted to systemd at that time - by reading the arch news on the homepage and following the wiki there should not be any major headaches

.

I fell that you might have missed the actual parts that were, not, blogpost-related - or you might have cherry-picked just the conclusion of mine (which were personal)

I had no particular troubles with getting systemd up and running, it works quite well for what it does
- but for me, it mostly just meant that it was somewhat smooth to get the things that was already working for me - working again

PReP · 2012-07-28 01:59:40

kaszak696 wrote:

The symlink-play in systemd isn't as bad as it was in some sysvinit setups, since it's supposed to be handled automatically by systemctl and not touched by the user.
I found the systemd configs more 'sane' than the rc.conf with all these unrelated settings mashed up into one file.

As i wrote, the systemctl way is nice, but it could still achieve the same without symlinking, systemctl could be made to work any number of ways of config, as i wrote some loose ideas about.
But yeah, it was not as 'ill' as with "pure" sysvinit.

I do not find a central file for various sane settings to be messy or mashed up if orderly and tidy - all it does is save time when setting things up, and lessens the commands needed to execute
(i.e like vim "this" one time, instead of 5-20 (if this is an increasing trend/revert of and old trusted arch-gimmick )

kaszak696 · 2012-07-28 08:05:47

You can still have rc.conf working with systemd if you want, there is a package for that. More info: https://wiki.archlinux.org/index.php/Sy … ntegration
It pulls in the old initscripts and sysvinit as dependencies though.
In the FAQ section of the systemd wiki article is an answer for your third point, how to disable console clearing.

Last edited by kaszak696 (2012-07-28 08:21:24)

satanselbow · 2012-07-28 08:25:12

PReP wrote:

I fell that you might have missed the actual parts that were, not, blogpost-related - or you might have cherry-picked just the conclusion of mine (which were personal)

Nope don't think I missed that at all. The only questions in your post are more personal, wishful, retro-fit feature requests rather than actual requests for support - therefore blog fluff... and a tad too whimsical for the wiki...

PReP · 2012-07-28 10:09:13

satanselbow wrote:

PReP wrote:
I fell that you might have missed the actual parts that were, not, blogpost-related - or you might have cherry-picked just the conclusion of mine (which were personal)

Nope don't think I missed that at all. The only questions in your post are more personal, wishful, retro-fit feature requests rather than actual requests for support - therefore blog fluff... and a tad too whimsical for the wiki...

As demonstrated by the reply above, that is simply not the case.
either it is an odd definition of "wishful and whimsical" on your part (or atleast differenting from mine),
or you need some practice in the mature art of confessing when one have erred.

I mean this as feedback, and to get pointers and ideas and discussion (hence posting in a forum) relating to arch, where systemd is slowly growing in place into - no matter what i feel personally.
I do not rant on it.

Either way, i think my post rubs you the wrong way no matter what, so let's just leave it at that
- no hard feelings

kaszak696 wrote:

You can still have rc.conf working with systemd if you want, there is a package for that. More info: https://wiki.archlinux.org/index.php/Sy … ntegration
It pulls in the old initscripts and sysvinit as dependencies though.
In the FAQ section of the systemd wiki article is an answer for your third point, how to disable console clearing.

Thanks for the pointing out of the FAQ, i missed that

Last edited by PReP (2012-07-28 10:12:42)

kang · 2012-07-28 11:47:38

To KISS my reply:

- pacman -Ql systemd; pacman -Ql initscripts
- http://fedoraproject.org/wiki/How_to_de … d_problems
- dbus dependency
- horrible logging mechanism
- questionable high level understanding of some technologies (hint: if you think a while you'll figure out the issue with seccomp filters being set in systemd, applies for some other options)

I believe the main fundamental issue is in the design: it tries to *hide* too much complexity. Initscripts have some complexity in the single main script, but not much. Most of it you can troubleshoot in /etc/rc.d/script-name extremely easily. That's also why you get the aforementioned symlink mess.

Anyhow, my puny little POV.

Last edited by kang (2012-07-28 11:49:05)

kaszak696 · 2012-07-28 12:30:36

kang wrote:

pacman -Ql systemd; pacman -Ql initscripts

Comparing these 2 poackages makes no sense, since they do not provide the same functionality. Compare systemd to initscripts+sysvinit+syslog instead. But still, i think systemd might be slightly bigger than these 3 combined.

goran'agar · 2012-07-28 13:47:52

kaszak696 wrote:

kang wrote:
pacman -Ql systemd; pacman -Ql initscripts
Comparing these 2 poackages makes no sense, since they do not provide the same functionality. Compare systemd to initscripts+sysvinit+syslog instead. But still, i think systemd might be slightly bigger than these 3 combined.

You forgot that systemd also supersedes cron and, in perspective, consolekit.

bohoomil · 2012-07-28 15:25:24

Yesterday I decided to transfer my current Arch KDE system permanently to systemd. After several hours of reading Wikis (including the Fedora one) and tweaking the required services, I decided to remove Arch native init files and reboot the system. And nothing happened... Well, nothing unexpected happened. The boot output is clean OK top to bottom, the functionality I had previously is still there, up and running, service management seems in no way more intimidating than the one I was used to (there are a few handy tips in our mighty Wiki to ease initial confusion). What's more, when you take a step back things appear quite logical and reasonable, once you stop trying to make them be what they aren't...

All in all, the bottom line is: Arch still sucks as the only user input it requires (apart from excellent devs' work it always provides free of charge) is still the ability to read and understand what is actually going on under the system's hood.

kaszak696 · 2012-07-28 15:35:27

Good to know, but logrotate still depends on a cron package installed. Can it be somehow used with systemd instead?

scjet · 2012-07-28 15:37:11

Thanks for the above systemd tips:
Actually, compared to the new "AIS's"-(but lets not go there again), switching completely over to "systemd" was freshly-enjoyable in Arch (for a change), very well documented, and with a positive reduction in boot speeds, and initial mem usage, thanks to their parallel, read-ahead approach, as compared to the older, yet more SIMPLER, BSD-style startups, as mentioned here too, somewhere.
But then again, I have a very simple system setup -nuthin' too exotic yet, otherwise, this new Arch user "hidden-transparency" model, of certain things, would have drove me nutz, just like redhat used to. -but that don't take much either, does it ?!

Soooo, I say +1 to this "systemd" switch, SO FAR.
..., voting, or non-voting acceptances' aside.

Last edited by scjet (2012-07-28 16:09:02)

swanson · 2012-07-28 17:43:01

I went for systemd to learn. I've learnt that it is very suitable for servers and server admins. And it gives fast boottimes as well. But how often do you reboot a production server? So, overkill for the average desktop user.

tomegun · 2012-07-29 00:54:53

PReP wrote:

1. Couldn't we just aswell use SystemD "the arch way", just having those loose settings still in an rc.conf, or hack up a new one?,
Just the way we have had rc.conf centralizing the old sysvinit-way. i still like that.
Something like:
  #/etc/arch.conf

  hostname=xxxx

  vconsole_keymap=xxxx
  vconsole_font=xxxx
  vconsole_font_map=xxxx
  
  locale_lang=xxxx
  locale_lc_collate=xxxx

  timezone=xxxx

  
atleast that saves time in my book, if having a good way to make systemd be redirected to look there.
or perhaps something like (semi-pseudo-code): setting hostname: echo $hostname > /etc/hostname, getting it's variables from an arch-centric config-file, and then parsing it when needed.

Currently systemd can read rc.conf as a fallback just fine. It can parse HOSTNAME, LOCALE, KEYMAP, CONSOLEFONT, CONSOLEMAP, and with initscripts-systemd also MODULES and DAEMONS.

I still think going forward we don't want this sort of trivial duplication of configuration options, and should encourage everyone to use the native systemd formats.

2. I did not like this symlink-play in traditional sysvinit, and i quite don't find it all too neat in systemd, i wish they could instead have a config-file where to enable services to run,
or have a "Enabled=yes/no" key in each unit file, which systemctl enable just sets when used instead, the same effect but without symlinking.

I guess you could just use DAEMONS in rc.conf and install initscripts-systemd (which will be part of initscripts as of the next release, so things will "just work"). I don't think it is a good idea, but it is possible :-)

tomegun · 2012-07-29 01:05:53

kang wrote:

- dbus dependency

And this is bad because? If you need an IPC mechanism (which systemd does), then it certainly is much better to take on that is in use rather than rolling your own (which is what udev does, but I guess that will switch to dbus in the not too distant future).

- horrible logging mechanism

The journal is awesome. That alone is reason for using systemd. Especially now that it starts to integrate with the kernel.

kang wrote:

- questionable high level understanding of some technologies (hint: if you think a while you'll figure out the issue with seccomp filters being set in systemd, applies for some other options)

I'm no expert on seccomp, but I did notice that the seccomp author commented on the systemd implementation and he didn't seem to have any issues with it...

Roken · 2012-07-29 01:23:01

tomegun wrote:

Currently systemd can read rc.conf as a fallback just fine. It can parse HOSTNAME, LOCALE, KEYMAP, CONSOLEFONT, CONSOLEMAP, and with initscripts-systemd also MODULES and DAEMONS.

My own, admitedly somewhat limited experience of systemd, is that both of rc.conf and rc.local can be retired. rc.conf is fully capable of being replaced by systemd, and rc.local can be, though replacing rc.local does require a little more work.

I know this simply because I'm 3/4 of the way to a complete migration to systemd, and have had to write some of my own .service files to maintain my existing rc.conf/rc.local setup. I won't lie, it hasn't been easy (not helped at all by my reliable kernel build .config file suddenly needing more than it has, but that's life), but I'm close to dumping initscripts now. I actually find that I quite like the systemd way of doing things. Granted, rather than a single (or two) config files we now need multiple files, in those multiple files we have the options to enable/disable without editing configs, and with a little work you can create your own background task to run at boot without worrying about the underlying sub-system.

And in fact, even the multiple .system files, whilst apparently unwieldy at first, are a bonus inasmuch as if one fails for whatever reason, you can concentrate on simply fixing the failed task. not to mention that I no longer have to manually force processes to detach themselves from the tty they were started in.

Personally, I'm starting to be encouraged by systemd. Still some work to go, but far better than even a couple of months ago.

Zancarius · 2012-07-29 01:53:54

Roken wrote:

Personally, I'm starting to be encouraged by systemd. Still some work to go, but far better than even a couple of months ago.

Same here. I just made the switch today, and the wiki has been hugely helpful. Honestly, I didn't find it nearly as difficult as I was expecting...

The systemctl semantics are a little awkward, but I think I can get used to them. The minor annoyance is that not all services have *.service files yet. Fortunately, creating an appropriate systemd.service(5) config isn't terribly difficult.

Oh, and the much faster boot was very encouraging. I was also surprised!

triton60 · 2012-07-29 05:18:04

Zancarius wrote:

Roken wrote:
Personally, I'm starting to be encouraged by systemd. Still some work to go, but far better than even a couple of months ago.
Same here. I just made the switch today, and the wiki has been hugely helpful. Honestly, I didn't find it nearly as difficult as I was expecting...
The systemctl semantics are a little awkward, but I think I can get used to them. The minor annoyance is that not all services have *.service files yet. Fortunately, creating an appropriate systemd.service(5) config isn't terribly difficult.
Oh, and the much faster boot was very encouraging. I was also surprised!

This is my experience with systemd as well, I switched my main desktop and netbook over to a full systemd implementation today.

Apart from having to write a handful of .service files everything went fine and as you say the boot time is faster (50%) for me now without any tweaks.

I actually like systemctl, seems more logical to me.

Thanks for the hard work devs.

Last edited by triton60 (2012-07-29 05:18:55)

Zancarius · 2012-07-29 06:56:54

triton60 wrote:

Apart from having to write a handful of .service files everything went fine and as you say the boot time is faster (50%) for me now without any tweaks.

I haven't quantified the exact difference, but I suspect it has to be at least that much. After running systemd-analyze, the charts claim my boot time is now around 22 seconds. I'm fairly certain I was sitting around 50-60+ prior to systemd. The difference was pretty surprising! (Also, shutdown times are almost instantaneous.)

Incidentally, I have a few more services enabled in systemd (healthd, hddtemp, various NFS mounts) compared to my old rc.d setup!

Also, you're right: systemctl is pretty logically structured. The commands and the output are a little verbose, but I'm almost startled by the fact that the learning curve isn't very steep.

Jristz · 2012-07-29 07:49:02

why you want a fast boot..is a competence who have the faster boot?
why have a unified cron and journal inside systemd...is a plan to kill cron and jornals remplacenments/forks and other related projects like syslog-ng and dcron?
why have soo long start daemon and not fallow the ordinary daemon and inittabs...is for making you brain work in memorice all services and other thinks and know what is what and where is where?

really the systemd is not a bad idea but is so complex or is so ambitious in places that no need for that, I know is the future, but is so ambitious and all know what happen to so ambitious projects trow the history

I only spect one thig fro systemd and for arch (recovber the old one unique centalices rc.conf for systemd

goran'agar · 2012-07-29 07:59:36

kaszak696 wrote:

Good to know, but logrotate still depends on a cron package installed. Can it be somehow used with systemd instead?

Actually logrotate is not needed anymore with systemd, the journal has an internal rotate mechanism .

kaszak696 · 2012-07-29 08:07:01

goran'agar wrote:

kaszak696 wrote:
Good to know, but logrotate still depends on a cron package installed. Can it be somehow used with systemd instead?
Actually logrotate is not needed anymore with systemd, the journal has an internal rotate mechanism .

But what about the rest of the logs? Journal handles them too?

triton60 · 2012-07-29 08:07:20

Zancarius wrote:

triton60 wrote:
Apart from having to write a handful of .service files everything went fine and as you say the boot time is faster (50%) for me now without any tweaks.
I haven't quantified the exact difference, but I suspect it has to be at least that much. After running systemd-analyze, the charts claim my boot time is now around 22 seconds. I'm fairly certain I was sitting around 50-60+ prior to systemd. The difference was pretty surprising! (Also, shutdown times are almost instantaneous.)
Incidentally, I have a few more services enabled in systemd (healthd, hddtemp, various NFS mounts) compared to my old rc.d setup!
Also, you're right: systemctl is pretty logically structured. The commands and the output are a little verbose, but I'm almost startled by the fact that the learning curve isn't very steep.

I was pleasantly surprised by the speed increase but to be honest it wasn't that slow before, I think it was around 30 secs compared with my windows 7 boot which was/is minutes.

However as I only boot a couple of times a day the increase in speed is irrelivant in the grand scheme and I installed it because I wanted to learn about systemd, I am glad I did install it.

I know tom (the developer) seems to be coming in for a lot of flak over the use of rc.conf and systemd which I personally feel are unfounded. For me (I have only been with Arch since April this year) there were a few things that attracted me to Arch.

1. Rolling release.
2. Arch way/Kiss (including the use of rc.conf).
3. The wiki is brilliant.
4. It always has the latest releases.
5. I wanted to delve more into how Linux works and Arch allows me to do this (I don't want to say forces me, but as a user you are expected to use the terminal more) which is what I want.

Since using it as my main OS I can also say the stability of the packages has been better than all the other distros I tried before ending up at Arch.

For me personally if we end up losing rc.conf then I don't see it as a major problem because Arch still has all the other plus points.

Andrew.

Arch Linux

#1 2012-07-27 16:36:04

Getting a grip on systemd, just in case.

#2 2012-07-27 19:08:24

Re: Getting a grip on systemd, just in case.

#3 2012-07-27 19:49:37

Re: Getting a grip on systemd, just in case.

#4 2012-07-28 01:55:32

Re: Getting a grip on systemd, just in case.

#5 2012-07-28 01:59:40

Re: Getting a grip on systemd, just in case.

#6 2012-07-28 08:05:47

Re: Getting a grip on systemd, just in case.

#7 2012-07-28 08:25:12

Re: Getting a grip on systemd, just in case.

#8 2012-07-28 10:09:13

Re: Getting a grip on systemd, just in case.

#9 2012-07-28 11:47:38

Re: Getting a grip on systemd, just in case.

#10 2012-07-28 12:30:36

Re: Getting a grip on systemd, just in case.

#11 2012-07-28 13:47:52

Re: Getting a grip on systemd, just in case.

#12 2012-07-28 15:25:24

Re: Getting a grip on systemd, just in case.

#13 2012-07-28 15:35:27

Re: Getting a grip on systemd, just in case.

#14 2012-07-28 15:37:11

Re: Getting a grip on systemd, just in case.

#15 2012-07-28 17:43:01

Re: Getting a grip on systemd, just in case.

#16 2012-07-29 00:54:53

Re: Getting a grip on systemd, just in case.

#17 2012-07-29 01:05:53

Re: Getting a grip on systemd, just in case.

#18 2012-07-29 01:23:01

Re: Getting a grip on systemd, just in case.

#19 2012-07-29 01:53:54

Re: Getting a grip on systemd, just in case.

#20 2012-07-29 05:18:04

Re: Getting a grip on systemd, just in case.

#21 2012-07-29 06:56:54

Re: Getting a grip on systemd, just in case.

#22 2012-07-29 07:49:02

Re: Getting a grip on systemd, just in case.

#23 2012-07-29 07:59:36

Re: Getting a grip on systemd, just in case.

#24 2012-07-29 08:07:01

Re: Getting a grip on systemd, just in case.

#25 2012-07-29 08:07:20

Re: Getting a grip on systemd, just in case.

Board footer