Caution re systemd

I notice a user having stress with systemd in Tumbleweed, in the mailing List. Here’s his comment/s:

Several hours ago I did a zypper dup on a Tumbleweed system. The next several boots took an eternity each to complete, and made a mess of boot message output until I figured out systemd had been installed. The init command was broken for switching among runlevels, keyboard was producing unexpected behavior, and boot was producing messages about problems with *.services.

The fix was simple enough: ‘zypper rm systemd systemd-sysvinit; zypper al systemd’.

I realize Tumbleweed is rather young and somewhat experimental, but a testbed for systemd development it should not be. That’s Factory’s job, right?

And some users are having wireless probs when they install systemd in Tumbleweed.

And I installed it just out of curiosity, got very odd behaviour. Uninstalled it and my system wouldn’t return to normal so I had to write back a backup image to my root partition. If I didn’t have the backup, I would have been obliged to format and reinstall on root partition.

So now I have locked systemd and systemd-sysvinit as never to be installed (in Yast – software management).

Just something for ppl to think about.

On one of my systems, I haven’t done the latest Tumbleweed updates but all that’s installed is systemd. No problems there.

I’m not in front of my desktop, but it has the all of the updates except for the kernel updates I saw this morning. I’m 99% certain that systemd is the only package installed there as well. Maybe the problem is with systemd-sysvinit.

Thanks. I’ll try it again. I haven’t got a clue why systemd-sysvinit was in my system. In fact I don’t understand systemd much, a newbie in that area. So I’ll do the kernel updates you mentioned than put in systemd then see how it goes. And report back in a day or two (if all goes well).

And I just noticed on the mailing list (from greg k-h) that systemd is not meant to be enabled yet for Tumbleweed. Here’s the comment:

Yes, and systemd should not be enabled by default in Tumbleweed (yet),
so I find the above boot problem very strange as it doesn’t happen here
for me on my test systems, or my main development machine.

So we’re really just experimenting here, having fun with something that’s still regarded as unstable. If you look at the wiki page for systemd (as at todays date), it’s currently regarded as very unstable. So my advice to TW users would be to install systemd only for testing and if you don’t need your installation to be stable for everyday usage.

On my system it’s not enabled by default. I enter the option init=/bin/systemd at the boot prompt when I want to use it.

I just reinstalled systemd. It screwed with my system big time. The “path” seems to be gone or broken. Then I tried to reboot, couldn’t. I tried to go to init 1, couldn’t. I used the GUI menu → reboot, couldn’t. Finally I uninstalled systemd. Logged out then in as root user, unmounted /home and pulled the plug. On reboot I got a good result, minus systemd.

Unless you just want to have the experience because you’re a real geek, I recommend not to install systemd in Tumbleweed for the short future, until it comes out of “factory unstable”.

Do you have the call to systemd in grub’s menu.list?

Unless you have systemd-sysvinit installed you have to call it, otherwise it should still use sysvinit.

No. Like I posted above, I do it manually. The only option I added to menu.lst is ‘nomodeset’. I’m not sure what the differences in our systems are, but I don’t have the problems you described when I use systemd.

Just as a matter of interest, about 4 years back I was on the Upstart list, which is another well known distro’s attempt to revolutionise the old Sys V init. The whole start up scripts inherited from a popular community distro were a real mess.

One thing I found useful was using my own interpreter script “#!/bin/sh” as drop in for the real init(8) which allowed setting up environmentals & using one time flags and such to have some fail safe tinkering. Worked quite well, if anyone gets involved with bug fixing, rather than just satisfying a healthy curiosity in init(8) & how UNIX & Linux systems get started.