systemd: Yet Another Init Replacement

WorMzy · 2011-05-18 10:45:08

Zom wrote:

That's pretty much wrong. AFAIK, systemd just uses some variables from rc.conf, things like hostname, while the DAEMONs part is completely skipped.

Not according to the wiki: https://wiki.archlinux.org/index.php/Sy … ntegration

DAEMONS (ordering and blacklisting is respected, if a native systemd service file by the same name as a daemon exists, it will take precedence, this logic can be disabled by 'systemctl disable arch-daemons.target')

sidneyk · 2011-05-18 11:22:36

WorMzy wrote:

Zom wrote:
That's pretty much wrong. AFAIK, systemd just uses some variables from rc.conf, things like hostname, while the DAEMONs part is completely skipped.
Not according to the wiki: https://wiki.archlinux.org/index.php/Sy … ntegration
DAEMONS (ordering and blacklisting is respected, if a native systemd service file by the same name as a daemon exists, it will take precedence, this logic can be disabled by 'systemctl disable arch-daemons.target')

Let me clarify. IF you have the systemd-initscripts pkg. installed AND you haven't disabled the arch-daemons.target then:

arch-daemons.target

Parses the DAEMONS array in rc.conf and starts the services. If a native systemd unit exists (by the same name) for a given daemon, this is used, otherwise the script in /etc/rc.d/ is used to control the unit.

As I said, I do NOT have the systemd-intscripts pkg. installed and therefore no arch-daemons.target. Without it, I don't think systemd is doing anything with daemons scripts from /etc/rc.d/. In this situation you would have to manually load the daemon with the new /sbin/rc.d script. As I said, I've tested this and am typing this with a system booted under systemd with the only line enabled in my rc.conf being the line to autoload modules. I have created a /etc/hostname file to set hostname for systemd. I have created or edited the other native systemd config files as per the mentioned wiki to enable those configs natively in systemd. Again, my DAEMONS line is double commented out, so I don't think anything is parsing it. I'll try with an rc.conf with just one active line and let you know what happens. But I can assure you, that on my system, the only thing rc.conf is doing for me now is telling some other part to autoload modules. The wiki says that systemd ignores the inittab file, but I don't know if any of the service files are calling on other sysvinit scripts or not.

UPDATE: Confirmed. My /etc/rc.conf file now has only 1 line it: MOD_AUTOLOAD="yes" and my system boots up just fine with systemd handling everything with *.service files and *.targets and such that I used to be starting up with /etc/rc.conf and /etc/inittab. Now on to try to build a liquorix kernel again. The first attempt bombed out at the very end - a wasted hour or so of waiting.

Last edited by sidneyk (2011-05-18 12:18:19)

Zom · 2011-05-18 11:26:04

litemotiv wrote:

Actually, that's exacty what initscripts-systemd does, see https://wiki.archlinux.org/index.php/Sy … md_package

I meant systemd by itself from a stock install, not with initscripts-systemd, which was what the post i quoted seemed to assume.

E: Missed a page, apparently.

WorMzy wrote:

Zom wrote:
That's pretty much wrong. AFAIK, systemd just uses some variables from rc.conf, things like hostname, while the DAEMONs part is completely skipped.
Not according to the wiki: https://wiki.archlinux.org/index.php/Sy … ntegration
DAEMONS (ordering and blacklisting is respected, if a native systemd service file by the same name as a daemon exists, it will take precedence, this logic can be disabled by 'systemctl disable arch-daemons.target')

Yes, and what package owns arch-daemons.target?

...
initscripts-systemd /lib/systemd/system/arch-daemons.target
...

Last edited by Zom (2011-05-18 11:29:15)

sidneyk · 2011-05-18 12:29:03

Zom wrote:

litemotiv wrote:
Actually, that's exacty what initscripts-systemd does, see https://wiki.archlinux.org/index.php/Sy … md_package
I meant systemd by itself from a stock install, not with initscripts-systemd, which was what the post i quoted seemed to assume.
E: Missed a page, apparently.
WorMzy wrote:
Zom wrote:
That's pretty much wrong. AFAIK, systemd just uses some variables from rc.conf, things like hostname, while the DAEMONs part is completely skipped.
Not according to the wiki: https://wiki.archlinux.org/index.php/Sy … ntegration
DAEMONS (ordering and blacklisting is respected, if a native systemd service file by the same name as a daemon exists, it will take precedence, this logic can be disabled by 'systemctl disable arch-daemons.target')
Yes, and what package owns arch-daemons.target?
...
initscripts-systemd /lib/systemd/system/arch-daemons.target
...

Actually, I didn't see where your original post quoted anyone, but since it was directly after mine and dealing with the same context I assumed you were talking to me. From my original post:
"and then I installed ONLY systemd and systemd-arch-units and enabled the services and targets I needed"

No initscripts-systemd mentioned. So far I've been able to get everything except the auto loading of modules enabled from somewhere other than rc.conf. I think the only thing holding me back are the modules for my usb wireless keyboard and mouse, which apparently don't get loaded if I comment out autoloading of modules in rc.conf. I need to figure out what is needed and add the appropriate *.conf files under /etc/modules-load.d/ which is where native systemd module conf files go.

Zom · 2011-05-18 12:58:31

sidneyk wrote:

Actually, I didn't see where your original post quoted anyone, but since it was directly after mine and dealing with the same context I assumed you were talking to me. From my original post:
"and then I installed ONLY systemd and systemd-arch-units and enabled the services and targets I needed"
No initscripts-systemd mentioned. So far I've been able to get everything except the auto loading of modules enabled from somewhere other than rc.conf. I think the only thing holding me back are the modules for my usb wireless keyboard and mouse, which apparently don't get loaded if I comment out autoloading of modules in rc.conf. I need to figure out what is needed and add the appropriate *.conf files under /etc/modules-load.d/ which is where native systemd module conf files go.

Yeah, sorry, I thought I quoted your post but I must've misremembered.

I also missed your earlier post about not using initscripts-systemd. Strange though, since AFAIK it shouldn't care for the DAEMONs array in rc.conf.

We'll see what falconindy says.

falconindy · 2011-05-18 13:08:59

sidneyk wrote:

So far I've been able to get everything except the auto loading of modules enabled from somewhere other than rc.conf. I think the only thing holding me back are the modules for my usb wireless keyboard and mouse, which apparently don't get loaded if I comment out autoloading of modules in rc.conf. I need to figure out what is needed and add the appropriate *.conf files under /etc/modules-load.d/ which is where native systemd module conf files go.

Commenting out MOD_AUTOLOAD in rc.conf has a whole different effect -- it causes /lib/udev/load-modules.sh to misbehave. This is unrelated to systemd and would illicit the same effect under sysvinit. There's plans to remove load-modules.sh now that module-init-tools offers proper module blacklisting -- you can either wait for that to happen, use udev-vanilla, or leave MOD_AUTOLOAD alone.

sidneyk · 2011-05-18 13:19:25

falconindy wrote:

sidneyk wrote:
So far I've been able to get everything except the auto loading of modules enabled from somewhere other than rc.conf. I think the only thing holding me back are the modules for my usb wireless keyboard and mouse, which apparently don't get loaded if I comment out autoloading of modules in rc.conf. I need to figure out what is needed and add the appropriate *.conf files under /etc/modules-load.d/ which is where native systemd module conf files go.
Commenting out MOD_AUTOLOAD in rc.conf has a whole different effect -- it causes /lib/udev/load-modules.sh to misbehave. This is unrelated to systemd and would illicit the same effect under sysvinit. There's plans to remove load-modules.sh now that module-init-tools offers proper module blacklisting -- you can either wait for that to happen, use udev-vanilla, or leave MOD_AUTOLOAD alone.

That was what I was assuming that it was effecting udev, preventing my modules for keyboard and mouse to load because that was the only thing I could see that was working before that didn't work with module autoloading disabled, but then I couldn't get logged in to check it out further. I have chosen to leave MOD_AUTOLOAD in place for now and am quite happy so far with this system. Thanks for clarifying.

sidneyk · 2011-05-18 13:29:29

Zom wrote:

I also missed your earlier post about not using initscripts-systemd. Strange though, since AFAIK it shouldn't care for the DAEMONs array in rc.conf.
We'll see what falconindy says.

That was kind of my point, systemd isn't doing anything with the DAEMONS array unless you have the initscripts-systemd pkg installed and have enabled the arch-daemons.target which may call other scripts, too, but long and short of it that target directs the DAEMONS array to be parsed and to either grab a native systemd service unit or to use the corresponding rc.d script if none exist. I currently have no DAEMONS array in my rc.conf, but I do have enabled the appropriate service and target units that call everything up just fine.

Last edited by sidneyk (2011-05-18 13:30:21)

Zom · 2011-05-18 14:22:45

sidneyk wrote:

That was kind of my point, systemd isn't doing anything with the DAEMONS array unless you have the initscripts-systemd pkg installed and have enabled the arch-daemons.target which may call other scripts, too, but long and short of it that target directs the DAEMONS array to be parsed and to either grab a native systemd service unit or to use the corresponding rc.d script if none exist. I currently have no DAEMONS array in my rc.conf, but I do have enabled the appropriate service and target units that call everything up just fine.

Oh, okay then I completely misunderstood your post. Sorry!

PReP · 2011-05-18 14:41:38

I am wondering a bit about this might-be-replacement.
I have read some of this thread, and a semi-heated discussion on the mailing list.

What i have not gotten an impression of yet, is why one would need systemd as opposed to the simple, and from all my time on arch, stable init and deamon-style we already have,
what is the reasoning, and what are the critically needed benefits of systemd in reality?

1. Performance?,

Is something i do not buy in to, mostly because the latest year or two (or more) i have not feelt nr-of-seconds-to-boot have any tangible differences.
I see no troublesome delay as it is now, from grub to login, it just breezes trough my daemons start.

I can boot, scratch my back, and the system is booted - so faster booting is not needed as i see it (i am speaking for me)
Neither my current system: i5 2500k @ 3.5 ghz, nor my pentium 4 @ 2.8 ghz, has any particular delay in booting these days.

2.Stability?,

This probably differs for different system, as software and stuff always does - but i have had no issues with stability with booting or init or the easy daemon start and stop system to this date, atleast.

3. Simplicity?,

I find the current init-system very nice to work with, as a user of my own computer, fast and manageable,
from what i have read, i see more work getting systemd going, and it feels to abstract away a bit, put more things between me and my system?

Though perhaps there are different views on this, i don't use dbus, or "ck-launch-session" or such things either,
I find setting my partitions up in /etc/fstab to be quick and painless (though that is probably not the main and sole scope of this new initsystem)

And i mostly just set up as little things and have as little stuff as possible, i just need to access and simply use my arch setup, and that works splendidly.

4. Need?

I think this is what my main question boils down too, for what does one need systemd?

I am neither bashing nor complaining, i am just curious of everyones take on this.

wonder · 2011-05-18 14:46:28

@PReP add in your list obligated. systemd was just proposed as dependency for gnome 3.2

nordmoen · 2011-05-18 15:10:33

PReP wrote:

1. Performance?,

On my laptop with an SSD I have noticed much better(might be a couple of secounds) boot times

PReP wrote:

2.Stability?,

I have noticed some problems, but if Arch adopted systemd it would be better

PReP wrote:

3. Simplicity?,

systemctl enable gdm.service

and nothing more was needed for me to get Gnome up, then just add what you need

PReP · 2011-05-18 17:08:24

nordmoen wrote:

PReP wrote:
1. Performance?,
On my laptop with an SSD I have noticed much better(might be a couple of secounds) boot times
PReP wrote:
2.Stability?,
I have noticed some problems, but if Arch adopted systemd it would be better
PReP wrote:
3. Simplicity?,
systemctl enable gdm.service
and nothing more was needed for me to get Gnome up, then just add what you need

1: Well my point was that even my pentium 4, does not take much time in the init-part of the booting, nor firing up the daemons,
And the difference between that and my new core i5 2500k is very small aswell.

The point is that boot time is very fast already, and that i stopped giving though to it these last year, 1-5 secs here and there
before using the system

2: I didn't say anything about systemd stability, but i said that the current system in arch has not had any stability issues.

3: I find the current system simple and usable to say the least, i don't know about systemd that much, so i cannot say anything there
- just that it feels further from simplicity then stuff does right now.

I run openbox though.

PReP · 2011-05-18 17:09:34

wonder wrote:

@PReP add in your list obligated. systemd was just proposed as dependency for gnome 3.2

Obligated, oh damn.

I don't run gnome myself though, and if they need yet another dependency for gnome, then i guess a _gnome_ dependency it is

-------------------------------

Last edited by PReP (2011-05-18 17:17:35)

sidneyk · 2011-05-18 17:09:42

I agree with the above. I think most of the seeming trouble in the thread comes from misunderstanding and perhaps expecting it to be more complex. Once the understanding kicks in it's a breeze. Systemd is intended to try and get rid of the many slow bash scripts being used to get the system going now. To Arch people it seems they tend to see only rc.conf, which is really only holding variables to pass to the other scripts, and think simple because they're not worrying about what's going on under the hood, so to speak. Some realize faster bootup with systemd, there seems to better response in my Gnome 3 system. Most of the stuff of systemd is under the hood also, but it's compiled C code instead of slow scripts. It is able to start and stop and reload daemons and keeps better track of them, not letting forked processes escape. I'd recommend reading the developer's blog and searching for some of the videos where he presents the breakdown and explains it. I did and it really helped me to see that I was over complicating it in my own mind.

Last edited by sidneyk (2011-05-18 17:53:21)

PReP · 2011-05-18 17:17:44

On another note, and this is not based on me knowing the inner workings of systemd, just as a slight hunch:

I have been working with different windows systems for a long time, both personally and for helping other people.

My take on windows is that they build up this very bulky system, with the services and the registry (which is an horrible crows nest to me)
They make it do everything per default - just in case some person needs this and that. (they even have a service running per default to "track links to ntfs-files over the network so that they don't get obsolete". as an example)

When setting up windows for myself, what i need to do is remove, configure, fix, mend, and take away all these things i actually do not need personally.
Compared to arch when i just, choose and configure the parts i need from the start.

To me, this is the big difference which has made me use Linux, and in the extent, Arch for my daily, 95% use of my computer.

And to me, starting with little, fetching the vital functions, takes much less time than working, cleaning and tidying up from a cluttered enviroment.

Point of this little comparison, some things (perhaps systemd?) feels just like that, trying to work in too much - as a default

litemotiv · 2011-05-18 17:31:44

PReP wrote:

The point is that boot time is very fast already, and that i stopped giving though to it these last year, 1-5 secs here and there
before using the system

That's a philosophical problem, when is 'good' good enough?

And as sidneyk said, you really need to look under the hood of Arch's current init system to see what it really does, and which scripts are invoked to accomplish what you see as a user. In general though, the Simplicity in Arch is not focused on end users per sé, but rather on system elegance.

sidneyk · 2011-05-18 17:35:44

Yesterday I was playing around and experimenting in Virtual Box on my Windows 7 install. I set up Arch x86_64 with the base and base-devel just like when I installed it for real. I then installed systemd and the arch-units pkg before installing xorg or Gnome or anything else beyond whatever got pulled in with systemd and the arch-units and I don't remember it pulling that much, if any extra in. That vm booted in 2 seconds and since it was only starting in an equivalent mode to run level 3, then systemd was only managing what needed to be managed for that scenario, nothing more. It was very robust and easy to forget that it was a vm. Agreed, when you add complexity with graphical environments and sound and desktops and hotplugging of devices, etc, etc. then things start piling up pretty quick. MS Windows is a very good example of that. I think systemd is much more flexible than MS Windows, even in a graphical environment. Yes, systemd supposedly defaults to what would be run level 5 (booting into x) but it is very simple to change that from the start. :

systemctl enable multi-user.target.

I get what you are saying about controlling what's going on and how much of it. That's what I believe sytemd brings to the table, it gives much better control over all the background things that are going on which we didn't have before. There's no more starting multiple instances of things anymore and forking here and there. The processes are tracked better and controlled so they can't escape and become difficult to track down when they misbehave. Again, if you're into that kind of stuff, the technical background and reasoning makes a lot of sense.

Last edited by sidneyk (2011-05-18 17:44:38)

PReP · 2011-05-18 21:03:51

I do understand a bit of what systemd is supposed to do, and i appreciate all the info and response.

1.

I read up a bit more on the authors blog, and one of the first things in the explanation was also: "Unfortunately, the traditional SysV init system was not particularly fast."

This is were i am most confunded, since i don't see where the system is slow today.
To re-iterate a bit then, by making some sort of scenario:

Say it takes me 10-12 seconds to boot up my system today,
In the world of sensibility, what would this, not often occuring, boot give me if it was say 3-8 seconds?
My point is just that the "boot faster faster faster"-part is not real world tangible; perhaps for a system that needs to boot x times every hour or so, i don't know, or someone really impatient.

That is just the speed-part, and just because that is the most i hear of when people seem (even the authour of systemd in parts) to respond as to why we need it.

2

Another quotation:

"Most current systems that try to parallelize boot-up still synchronize the start-up of the various daemons involved: since Avahi needs D-Bus, D-Bus is started first, and only when D-Bus signals that it is ready, Avahi is started too. Similar for other services: livirtd and X11 need HAL (well, I am considering the Fedora 13 services here, ignore that HAL is obsolete)"

I must confess that it might just be me, but i have seen little need for Avahi, I was glad to skip HAL a while back, I didn't fancy udisk since i find having my external drives set in fstab works fine, having a simple alias to "mount / umount this that", which can be executed from a button on the graphical side, or just in the terminal as i usually do.
I have also been wondering about dbus.

To me, most of these things, i only see as dependencies for various programs i use, though i don't now about my own need for them.
I just did a little check on dbus while reading up on things:

~ -> sudo pacman -R dbus

:: avahi: requires dbus
:: qt: requires dbus
:: xfconf: requires dbus

~ -> sudo pacman -R avahi

:: libcups: requires avahi

sudo pacman -R libcups # (well i don't use a printer, but i certainly wouldn't say that is something the world shares with me, i'm not silly )

:: gtk2: requires libcups
:: gtk3: requires libcups

------- Here it was ^ --------

gtk.,

which obviously is needed by a lot of things, and i won't go into one of the classical and tirering "gtk or qt or deps" debate, i'll just say that this feels a bit annoying.
i certainly don't need the gtk programs i use to configure my network, and i do not need to print with them either since i don't have a printer
But still, somehow, these things end up "needed" as dependencies.

3. Conclusions, again, but revised (perhaps )

Other than 'speed', the idea with systemd seems to be starting and stopping of servi.. i mean daemons... on demand?

I just feel that, this is what is already happening,
though i don't have big needs on daemons for starters,
this is my daemons line: DAEMONS=(!hwclock syslog-ng network !netfs crond sshd httpd alsa !dbus)

Some are inactivated but have been kept in case, don't have nfs shares to mount anymore, and dbus i am still trying to figure out personally. (the why, that is, and for me)
And i don't see them running and being a heavy strain or encumbering my system to date neither.

If i need a daemon, i would just do: /etc/rc.d/xxxx start - which frankly don't take up much of my time at all.
Or use the new rc script, though i haven't gotten used to that yet, even if it is less typing and i sort of like it.

I am mostly just afraid of things coming needlessly less simple, though perhaps in the future, or when i have learnt more, systemd would be simpler?

PReP is a friendly sceptic, and thinks a lot, that is all

Glaucous · 2011-05-18 21:18:30

litemotiv and falconindy; I finally fixed the automount problem which we talked about on page 23, 24. The fix was actually very simple (and makes sense). I mounted all my partitions using 'defaults,comment=systemd.automount', however, 'defaults' implies 'auto', which meant that the partition is always mounted at boot, so all I needed to do was to add 'noauto'. Now they're not mounted at boot, and mounted automatically when accessed.

A thought though, how does fsck work with autofs?

Last edited by Glaucous (2011-05-18 21:20:36)

litemotiv · 2011-05-18 21:38:25

Glaucous wrote:

litemotiv and falconindy; I finally fixed the automount problem which we talked about on page 23, 24. The fix was actually very simple (and makes sense). I mounted all my partitions using 'defaults,comment=systemd.automount', however, 'defaults' implies 'auto', which meant that the partition is always mounted at boot, so all I needed to do was to add 'noauto'. Now they're not mounted at boot, and mounted automatically when accessed.

Ah that's good, thanks for the heads-up.

@PRep, you're straying a bit offtopic. systemd is just a new init system, faster and more feature rich, while still trying to be elegant and easily maintainable. My grandmother is still puzzled why we even need pc's in the first place.

ngoonee · 2011-05-18 21:55:22

Also, on the matter of boot times, its great you have 10-12 seconds, but this laptop used to take 1 minutes 50 seconds on Gnome (now 1 minute 15 seconds on Awesome), so that DOES make quite a bit of difference when that's improved. Of course, I just use hibernate, but that's besides the point .

Both speeds are sans systemd, I've gone back to sysvinit for now (more familiar).

hauzer · 2011-05-18 22:43:50

Is systemd still unusable with a separate /usr (/var?) partition?

falconindy · 2011-05-18 22:44:54

Separate /var is fine. It will never support separate /usr.

hauzer · 2011-05-18 23:01:45

I see.

Arch Linux

#601 2011-05-18 10:45:08

Re: systemd: Yet Another Init Replacement

#602 2011-05-18 11:22:36

Re: systemd: Yet Another Init Replacement

#603 2011-05-18 11:26:04

Re: systemd: Yet Another Init Replacement

#604 2011-05-18 12:29:03

Re: systemd: Yet Another Init Replacement

#605 2011-05-18 12:58:31

Re: systemd: Yet Another Init Replacement

#606 2011-05-18 13:08:59

Re: systemd: Yet Another Init Replacement

#607 2011-05-18 13:19:25

Re: systemd: Yet Another Init Replacement

#608 2011-05-18 13:29:29

Re: systemd: Yet Another Init Replacement

#609 2011-05-18 14:22:45

Re: systemd: Yet Another Init Replacement

#610 2011-05-18 14:41:38

Re: systemd: Yet Another Init Replacement

#611 2011-05-18 14:46:28

Re: systemd: Yet Another Init Replacement

#612 2011-05-18 15:10:33

Re: systemd: Yet Another Init Replacement

#613 2011-05-18 17:08:24

Re: systemd: Yet Another Init Replacement

#614 2011-05-18 17:09:34

Re: systemd: Yet Another Init Replacement

#615 2011-05-18 17:09:42

Re: systemd: Yet Another Init Replacement

#616 2011-05-18 17:17:44

Re: systemd: Yet Another Init Replacement

#617 2011-05-18 17:31:44

Re: systemd: Yet Another Init Replacement

#618 2011-05-18 17:35:44

Re: systemd: Yet Another Init Replacement

#619 2011-05-18 21:03:51

Re: systemd: Yet Another Init Replacement

#620 2011-05-18 21:18:30

Re: systemd: Yet Another Init Replacement

#621 2011-05-18 21:38:25

Re: systemd: Yet Another Init Replacement

#622 2011-05-18 21:55:22

Re: systemd: Yet Another Init Replacement

#623 2011-05-18 22:43:50

Re: systemd: Yet Another Init Replacement

#624 2011-05-18 22:44:54

Re: systemd: Yet Another Init Replacement

#625 2011-05-18 23:01:45

Re: systemd: Yet Another Init Replacement

Board footer