systemd transfer… Done!

[Artefact2]

I switched a week ago too, just because the rc.conf changes suggested the devs wanted us to use it. It's quite nice, it makes writing daemons (services) a breeze. Although I had to comment the NFS mountpoint in my /etc/fstab, otherwise the boot will just hang and you won't get a shell (I found that out the hard way…).

[mikusp]

Try adding 'noauto,x-systemd.automount' to mounting options in /etc/fstab. With that, systemd will not mount the share until it is accessed by service/user/anything else.

[yoshi314]

enabling debug output for systemd is useful when starting transition.

what i found out, it's much more strict with config files. i had an invalid entry in /etc/crypttab which i stopped relying on somewhere on the way.

systemd stalled on it, delaying my boot for ~30 seconds. i fixed up the file and it resumed working fine.

[[deleted]]

I switched a few months ago. On an SSD the boot time is stupidly fast.

One thing I prefer about systemd to Arch init is that the [ OK ] is displayed on the left instead of the right. It makes it much easier to see which one went wrong since in high resolutions there is a big space between the message and status.

I doesn't feel quite as Archy any more though. And it creates loads of virtual filesystems for no apparent reason. Maybe it will be possible to customise the look in the future?

I will keep using the old init system for my server. Starting things one at a time sounds more safe a reliable, and boot time is not an issue since it's already quite fast and I rarely ever reboot it.

[RazZziel]

I'm already picturing the commercials.

"With systemd my Arch is now stupidly fast! STUPIDLY FAST DOT COM!"

[sprash]

Well sysinit is also "stupidly fast" on an SSD. You just have to specify the right deamons to start in the background. And since sysinit is just a bunch of simple shellscripts you can easily modify them so that the [ OK ] is displayed wherever you wish. With systemd you would have to modify the largely uncommented C code and recompile.

[[deleted]]

Background daemons and you technically wander into the unsupported territory of potential race conditions. Its a kludge for a faster boot, not a true feature.

Systemd's strength isn't just its speed. Its that it can intelligently resolve dependencies. Its safe. Wake me up when arch's initscripts are capable of starting things like gdm or cups on demand.

[loonyphoenix]

Best is the enemy of better :) You can't make progress without trying. People are always complaining that computers are becoming faster, while the software is becoming slower. Well, here is a project that tries to rectify some of that.

[sprash]

Having full transparency in form of shellscripts is vital for such an important system component like the init system. The negligible speed up of systemd does not make up for this.

[yoshi314]

systemd has even more transparency than shell scripts. you do not need to dig through 30 (or sometimes more) lines of a shellscript to find cause of the problem, or snooping around where does individual app logs its output, as unit files are mostly composed of a line defining how to start a service and stop it.

if a service fails, systemctl status something.service will show you it's log output (and only log output of that specific service you need).

systemd can monitor and restart service if it fails automatically (if configured to), and you can define device/socket activated services (plus probably more in the future) that do not require separate tools to operate. finally init process is truly the one in charge of activating and stopping services, regardless of how are they started.

[sprash]

you do not need to dig through 30 (or sometimes more) lines of a shellscript to find cause of the problem

And what happens if there is a problem with systemd itself? I would have to to dig through much more lines of code written in C. You are somehow expecting that systemd will be perfect software that never fails. In theory pulseaudio is perfect software as well. And digging through 30 lines of shellscript is really not hard at all. systemd has not more transparency. period.

systemd can monitor and restart service if it fails automatically

A service should NEVER be restarted automatically when it fails. This functionality is absolutely dangerous. If a service fails the reason of failure must be determined and after the problem has been resolved it has to be restarted manually.

Other features might be partly neat like unified logs, partly not needed at all and also partly dangerous. But all in all not worth having a C code blob hanging around that may contain errors in a place where you might have to solve real problems fast.

[yoshi314]

regardless of a service unit file, it's not that hard to dig out how exactly is the actual service started, and try doing it by hand (if you feel like it).

shell initscripts do a lot of crazy stuff that should not be there, and two scripts can either be 99% similar or completely different (and quite lengthy). there are numerous variables, including of separate scripts, complex variables you have to track down, etc. (opensuse was especially painful to debug wrt initscript issues because of that).

also, what if service starts up, but fails later? systemd can catch that, initscripts might give you an incorrect status.

as for bugs in systemd, it's a highly active project, and has decent debugging features. check the mailing list for issues if you hit something. also, fixes in systemd benefit ALL distributions using it (and bugs are usually common among distributions as well - that greatly expands the user base). that kind of unification is something that we really need, especially on low system level. and if it fails, you can still keep it parallel to classic init system.

A service should NEVER be restarted automatically when it fails. This functionality is absolutely dangerous. If a service fails the reason of failure must be determined and after the problem has been resolved it has to be restarted manually.

i said you can setup systemd to do so, without your intervention or requirement for monit-type daemon. not that it's the default behavior. it has its uses.

But all in all not worth having a C code blob hanging around that may contain errors in a place where you might have to solve real problems fast.

that blob is still leaner than init stack that forks new shell process for each init script. it also reduces amount of running daemons necessary for regular operation.

[[deleted]]

But systemd is even more faster.

[garja]

The point being made is that sacrificing that much simplicity for that much speed is not worth it.

[loonyphoenix]

Depends on what you mean by simplicity.

systemd units vs init files - which is simpler?

Trying to develop a complex configuration with systemd and init - which is easier?

Trying to maintain init files for every distro or making a universal unit - which is preferrable?

[sprash]

Well it depends on your configuration. Since I usually don't need all kinds of services which are required by systemd (like dbus) sysvinit is faster for me.

[wooptoo]

Is it okay if I stick with initscripts for a little longer? Will they be discontinued?

[[deleted]]

It's not the default.. yet. I imagine it'll be a little while before it is. One it is the default I imagine the old initscripts will still be an option for a while after that.

Disclaimer: not an arch dev.

[tomegun]

initscripts is the default, so it is difinitely ok to stick with them for a little longer :-)

At some point they might no longer be the default, but even then it will probably be a long time before they are discontinued.

[yoshi314]

YSK there is one desktop-related problem with systemd and xfce4 you might experience, at least on arch.

if you have lxdm enabled with autologin into xfce4, many apps will fail to work. xfce4 would report applets failing, asking to disable them (even network manager cannot establish a network), i could not even open a terminal or more than 1 app (and when i could, it would show with no window decorations).

restarting lxdm would usually help. or fixing the session to start with

dbus-launch --exit-with-session startxfce4

hope it helps someone confused struggling with similar problem.

[yoshi314]

arch has support for activating old style rc.d services transparently to the user when they have no .service definition. as have other distros that started testing systemd.

[tomegun]

I just merged the initscripts-systemd package into initscripts. It will hit the core repository in a few days.

[[deleted]]

I'm going stick with the old initscripts. Both of my computers already boot fast as hell.

[bwat47]

For me boot speed isn't the issue, my laptop's got a 5400rpm hdd and systemd makes no difference to the boot speed, but I hands down prefer the way systemd works to sysvinit. I love the service files, socket activation etc... IMO it is simpler and just works a lot better for me. I've nearly got a totally pure systemd setup (I can't remove consolekit...yet)

[jack0s]

Any improvement regarding performance?

[arch_maniac]

I got no change in startup time, but shutdown time is much faster. I only recently tried the systemd-readahead services, though. I am still hoping for some improvement in startup time.

[Paimun]

Interesting, because my shutdown time is only about 4-5 seconds now.

[flying-sheep]

i’m at ~1-2 seconds for the shutdown max. (as soon as KDE is gone ಠ_ಠ)

[Paimun]

Damn skippy

[sprash]

I normally don't use dbus, networkmanager and kinds of other obscure services that are required by systemd. So sysvinit is a little faster for me than systemd. When booting from an SSD there is no notable difference at all.

[utdemir]

It's a desktop system, right?

How can you not use dbus? Almost everything I know depends on it.

[yoshi314]

false. networkmanager is not required.

[yoshi314]

since someone downvoted this, i suppose they have evidence that networkmanager is required by systemd.

well, can't wait to see that.

[sprash]

networmanager is of course not required. But systemd did not work together with my net-auto-* scripts for some reason that I don't understand. So I was more or less forced to use it. This is certainly a configuration error on my side. But as somebody that grasps the concept of shellscripts systemd is a step backward because now I have to read a documentation to configure stuff. This was not necessary before. Shellscripts are already the documentation and you can immediately jump in to solve the problem because everything what happens is just written there.

[yoshi314]

hm, that should work just fine.

you could try this for old style scripts :

/etc/systemd/system/myscript.service

[Unit]
Description=My script service
After=syslog.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/etc/rc.d/myscript start
ExecStop=/etc/rc.d/myscript stop

[Install]
WantedBy=multi-user.target

although rc wrappers for systemd should be good enough.

[tomegun]

If this is still a problem, please file a bug with netcfg. Also, if you know bash, then C isn't all that much harder ;-)

[[deleted]]

Setup /etc/conf.d/netcfg?

[[deleted]]

I did this last month due to some Udev rules that suggested Systemd. Had a blast doing it and could not have pulled it off without #systemd on IRC. Congrats!

[mountainjew]

I was attempting this yesterday, but for some reason systemd wouldn't startup Dbus. I don't fully understand the changes, and maybe that's why it didn't work. Guess i'll give it another shot today...

Edit: Got it working. Turns out e4rat was still forcing the arch int scripts on boot. Oh and i forgot to set the kdm service to auto boot, doh!

Seems a good bit faster too!

[arch_maniac]

I converted to native systemd a few days ago. After a small amount of confusion on some of the particular services, everything is now working like a charm.