[SOLVED] Remove sysv in favour of systemd

nierro · 2012-06-02 15:29:17

Hi!
Yesterday udev became part of systemd-tools and then i decided to try systemd out, to see how does it work.
Well, i must say "i like it!" , yes i really like it. I installed it without initscripts-systemd, to understand better how it works. And today i'm planning to switch completely to systemd.
Reading the wiki, it seems it is only as far as a

pacman -S systemd-sysvcompat

.
Currently, i'm running xfce + slim + everything i used with sysv, without any sort of troubles. I'm only missing a hibernate-cleanup.service to avoid image corruption when hibernating with toi, but for now it is not important.
So i'd be glad if someone of you, who uses systemd alone, could tell me his experience, because i want to avoid any kind of troubles
Thank you very much guys!

Last edited by nierro (2012-06-02 18:04:26)

litemotiv · 2012-06-02 15:55:02

I would advise to keep the old init system installed for a while, just in case you run into problems with systemd. If you boot with init=/bin/systemd there's no harm in keeping the other init dormant on your system.

nierro · 2012-06-02 16:54:16

Yes, i know.
It was only to respect my "one software for each task" philosophy.

litemotiv · 2012-06-02 17:11:50

nierro wrote:

Yes, i know.
It was only to respect my "one software for each task" philosophy.

You're not compromising that philosophy by keeping the Arch init installed.

PaulBx1 · 2012-06-02 17:32:01

I too am interested in this issue.

There is the old arch init, and there is systemd running compatibility, and there is native systemd. I wish there was a document somewhere, a list explaining what files and directories are used with each. At some point I want to clean out the old and then have only to maintain the native systemd setup, without getting the two confused.

Last edited by PaulBx1 (2012-06-02 17:32:20)

nierro · 2012-06-02 17:36:23

Yes, i've not initscripts-systemd as i pointed out, but it's the same...i find it messy to have so many files i don't need anymore...the most important things i want to know are 2: how stable is systemd (i saw it is often upgraded, so may be it can have problems sometimes) and if i'm gonna lost any kind of features (i don't think, on the contrary, i think i'll have more features )

65kid · 2012-06-02 17:56:42

I've been running systemd without initscripts on three machines for months, I don't even a /etc/rc.conf anymore. In general, it works fine and I haven't really run into problems after upgrading. However, you really shouldn't remove initscripts if you are not sure that you are able to debug systemd problems yourself and have a good understanding of how it works. There is still some stuff being added/changed/removed.

nierro · 2012-06-02 18:03:48

Well, that's what i was looking for, thanks!
Uhm probably, now, i can't debug systemd properly; so i'll follow your instructions, and keep sysv until i'm really sure i can live without it!
Thanks!

WorMzy · 2012-06-02 18:16:06

I'm not sure what you're asking here.

I've been using systemd on Arch for over a year now, on several different machines, and the only real problem I've encountered was the self-inflicted one I was fighting with yesterday.

Make sure you follow the wiki, enable the services you need, learn how to use the systemctl command to administrate your system, and you should be fine.

nierro · 2012-06-02 18:30:24

Yes, i followed the wiki entirely, enabled the service i need, and i think i can use systemctl (hope ) .
Well, i'll take another week to feel at ease with it, then may be i'll try!

swanson · 2012-06-02 18:33:41

Yeah, eliminate the daemons you have in rc.conf one by one. For some there are native ones for some the archunits will do for a while, for one or to you can make your own.

nierro · 2012-06-02 18:45:53

As i said, the only daemon i cannot replace now, it's hibernate-cleanup...but i can't make mine I'm not sure about how to do it...

nierro · 2012-06-02 19:11:12

Ok i created the hibernate-cleanup.service! No error prompted when i "systemctl enable" it, so i think it should work! (it was quite simple anyway )
So, more and more solved

nierro · 2012-06-02 19:40:37

Can anyone please explain me why in rc-local.service from initscripts-systemd has "RemainAfterExit=yes" option? I do not need it to remain after it executes the rc.local script!
ps: i did not install initscripts-systemd, i only copied that service from github

PaulBx1 · 2012-06-02 21:28:51

Maybe it's the most forgiving option, given that people put all sorts of things in rc.local?

I'm wondering about that service, is that a compatibility mode thing? So that we won't be running native mode unless we get rid of it? I have a couple things in rc.local. One of them I was able to do with that tmpfiles thing, writing a variable (specifically, changing the scheduler to "noop"). The other thing was calling chkboot as mentioned at the end of this page:
https://wiki.archlinux.org/index.php/Sy … _with_LUKS
I tried to make a little service file to do that but when I do "systemctl status chkboot.service" it reports

chkboot.service - Detect modification of unencrypted /boot
	  Loaded: loaded (/etc/systemd/system/chkboot.service; disabled)
	  Active: failed (Result: exit-code) since Sat, 02 Jun 2012 14:12:35 -0700; 2min 32s ago
	 Process: 1384 ExecStart=/usr/local/bin/chkboot.sh (code=exited, status=203/EXEC)
	  CGroup: name=systemd:/system/chkboot.service

So I am still in the dark about this. Apparently the reporting part of chkboot gets picked up somehow by systemd in /etc/xdg/lxsession/LXDE/autostart, probably another compatibility mode thing.

<later>
I found this script had a <space> in front of the #/bin/bash. Strangely it did not cause a problem when running from the command line, but systemd choked on it. Removed the space and it works. I have notified the author.

It does bring up an issue though. I wish I had the list of error codes and more explanation about what they mean. This one was called "Exec format error" in the journal, but that only makes sense now that I know what the error is! The usual problem with error messages, I guess.

Last edited by PaulBx1 (2012-06-03 04:34:31)

nierro · 2012-06-03 07:42:52

Well, what i think is that calling rc.local from a service is only like calling a script...rc.local is a script just like other mine ones.
I don't think you have to get rid of it, well may be it would be better, and faster, but it is not a real problem to keep it.
I too have in rc.local echo bfq , echo brightness and a pm-powersave call, so, nothing too heavy or strange; i think i'll keep it. What i don't think, again, is why RemainAfterExit=yes?
It is a oneshot type, and we do not need it to "remain after exit" because it doesn't have to perform any action after boot up...

swanson · 2012-06-03 07:51:28

rc.local.service was in my case a hog although I had very small things started from it. Most things in there were not necessary and I think it's really worth considering what you do from there. Like activating bfq could be done from the kernel line, right? A radical rethink of old habits can really pay off. I know, casue I've used rc.local as a last resort, as black hole for misbehaving apps and services for years. No more.

I htink that finding out what application a service or otherwise, really uses and then create a native unit for it can pay off. At least compared to start it from rc.local.

nierro · 2012-06-03 08:25:30

Uhm, no. I can't activate from the kernel line, because in that case bfq must be static module (i use kernel-netbook and not -ck so i can't do that).
Yes, i think i could create a service that starts pm-powersave...but for example, how can i create a unit to echoing brightness?
EDIT: ok, i made it... no more rc-local.service
EDIT2: it seems that the 2 echo services won't work...
this is the one which set brightness (very easy)

[Unit]
Description=Set brightness during startup

[Service]
Type=oneshot
ExecStart=/bin/echo 6500 > /sys/class/backlight/intel_backlight/brightness

[Install]
WantedBy=multi-user.target

Is there any problem? The same comand as ExecStart, pasted in terminal, works...
EDIT3: it seems they're executed during startup :

journalctl | grep echo
Jun 03 10:57:46 arch echo[189]: 6500 > /sys/class/backlight/intel_backlight...ss
Jun 03 10:57:46 arch echo[179]: bfq > /sys/block/sda/queue/scheduler

But they don't work...
systemctl status report their exitcode is SUCCESS

Last edited by nierro (2012-06-03 09:03:39)

nierro · 2012-06-03 10:12:49

Oh damn, i found out systemd doesn't use a shell to start services, so i had to change ExecStart line in

ExecStart=/bin/bash -c 'echo 6500 > /sys/class/backlight/...'

Arch Linux

#1 2012-06-02 15:29:17

[SOLVED] Remove sysv in favour of systemd

#2 2012-06-02 15:55:02

Re: [SOLVED] Remove sysv in favour of systemd

#3 2012-06-02 16:54:16

Re: [SOLVED] Remove sysv in favour of systemd

#4 2012-06-02 17:11:50

Re: [SOLVED] Remove sysv in favour of systemd

#5 2012-06-02 17:32:01

Re: [SOLVED] Remove sysv in favour of systemd

#6 2012-06-02 17:36:23

Re: [SOLVED] Remove sysv in favour of systemd

#7 2012-06-02 17:56:42

Re: [SOLVED] Remove sysv in favour of systemd

#8 2012-06-02 18:03:48

Re: [SOLVED] Remove sysv in favour of systemd

#9 2012-06-02 18:16:06

Re: [SOLVED] Remove sysv in favour of systemd

#10 2012-06-02 18:30:24

Re: [SOLVED] Remove sysv in favour of systemd

#11 2012-06-02 18:33:41

Re: [SOLVED] Remove sysv in favour of systemd

#12 2012-06-02 18:45:53

Re: [SOLVED] Remove sysv in favour of systemd

#13 2012-06-02 19:11:12

Re: [SOLVED] Remove sysv in favour of systemd

#14 2012-06-02 19:40:37

Re: [SOLVED] Remove sysv in favour of systemd

#15 2012-06-02 21:28:51

Re: [SOLVED] Remove sysv in favour of systemd

#16 2012-06-03 07:42:52

Re: [SOLVED] Remove sysv in favour of systemd

#17 2012-06-03 07:51:28

Re: [SOLVED] Remove sysv in favour of systemd

#18 2012-06-03 08:25:30

Re: [SOLVED] Remove sysv in favour of systemd

#19 2012-06-03 10:12:49

Re: [SOLVED] Remove sysv in favour of systemd

Board footer