[SOLVED] systemd and rc-local.service

kokoko3k · 2012-08-27 15:08:20

So, today i decided to try a pure systemd system by migrating my old installation.

The first problem i faced comes from rc-local.service.

I followed this:
https://wiki.archlinux.org/index.php/Sy … s#rc.local

and created an identical rc-local.service:

/etc/systemd/system/rc-local.service

[Unit]
Description=/etc/rc.local Compatibility

[Service]
Type=oneshot
ExecStart=/etc/rc.local
TimeoutSec=0
StandardInput=tty
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

...made it executable and enabled the service via

systemctl enable rc-local.service

The problem comes when i issue:

systemctl --system daemon-reload
systemctl start rc-local.service

Here the prompt hangs forever.

..so i reeboted and automagically "Something" of my rc.local has been executed.
What has been left out was a subscript launched in background from my rc.local.

While in the past my working rc.local executed a script:
checkmounts.sh & #<-this loops forever

...and in ps -ef|grep checkmounts i got it listed, now with systemd i haven't it anymore.

...note that to debug issues i echoed several "marks" into a text file, and i'm sure that
rc.local has been executed till the end and systemctl status reports no errors at all.

So the question are:

1) why can't i start rc-local from terminal via sysctl and it works (sort of) if i reboot?
2) why a script executed from rc.local in background doesn't work?

Last edited by kokoko3k (2012-08-27 15:43:35)

ataraxia · 2012-08-27 15:18:57

You don't want Type=oneshot if something a unit starts will run forever. It's hanging waiting for it to finish. Try Type=forking instead (and you won't need RemainAfterExit=yes either in that case).

kokoko3k · 2012-08-27 15:37:48

I already tried that with the same results.
Now i found that removing StandardInput=tty works and solved both of the issues (at least issuing manual startups).
So this:

[Unit]
Description=/etc/rc.local Compatibility

[Service]
Type=oneshot # is forking instead of oneshot needed here?
ExecStart=/etc/rc.local
TimeoutSec=0
#StandardInput=tty
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Works really well for me, exactly like in the past.
Plus, i can see all running child processess via systemctl status rc-local.service

If someone thinks this is wrong for seome reason i'll NOT update the wiki page.

--EDIT

Works well after a reboot too, and changing Type= to fork make just fork, parallelizing the boot (kdm+kde for me)

Last edited by kokoko3k (2012-09-13 13:43:38)

falconindy · 2012-08-27 16:51:35

You would be much better off figuring out ways to replace /etc/rc.local than to perpetuate it. In most cases I've seen, there are already existing constructs to take the place of what people are doing with this file (udev rules, tmpfiles.d, modules-load.d).

patroclo7 · 2012-08-27 21:47:28

I really think that rc.local is a valuable scratchpad for system admins. Many times you need to try something at boot time without the hassle of dealing with udev rules etc.
Obviously it is just a script and can be put in other places if one has philosophical reasons to get rid of any sysvinit trace (I have moved it to /usr/local/sbin).

Last edited by patroclo7 (2012-08-27 21:48:07)

falconindy · 2012-08-27 22:48:56

patroclo7 wrote:

I really think that rc.local is a valuable scratchpad for system admins. Many times you need to try something at boot time without the hassle of dealing with udev rules etc.
Obviously it is just a script and can be put in other places if one has philosophical reasons to get rid of any sysvinit trace (I have moved it to /usr/local/sbin).

That's exactly the argument against using rc.local. It's a place you put hacks that you're too lazy to properly order with bootup.

kokoko3k · 2012-08-28 07:17:01

For me it is the same of "one rc file vs multiple settings file".
If tomorrow i want to migrate my "Hacks" to another machine, i will just move that rc.local and the service, plus i can still disable an hack by putting "#" in front of it (simpler?, off topic...)
Same thing would apply to rc.conf, but as we're moving to systemd, i've to deal with that.

stqn · 2012-09-04 01:25:34

I have the same problem. If removing StandardInput=tty is the only way to be able to launch background processes from rc.local, shouldn’t it be the default? Or is there another way?

kokoko3k · 2012-09-04 06:36:41

As far as i know there is no default, the question should be why the wiki explicitely mension that option.

stqn · 2012-09-04 14:11:33

There is a default if you have initscripts installed:

$ pacman -Qo /usr/lib/systemd/system/rc-local.service 
/usr/lib/systemd/system/rc-local.service is owned by initscripts 2012.08.3-2

PS: since it seemed to have something to do with inputs, I tried this in my rc.local:

( dostuff ) </dev/null &

but it doesn’t change anything, dostuff is still killed (at least that’s what I think happens).

Last edited by stqn (2012-09-04 14:14:55)

patroclo7 · 2012-09-04 14:55:04

falconindy wrote:

That's exactly the argument against using rc.local. It's a place you put hacks that you're too lazy to properly order with bootup.

I am the sysadmin and I am free to be as lazy as I like to be. And I can also have the specific desire not to order properly something with bootup, because ordering it would be overkill and loss of time. Also when I want to "order" it, I need to try it in a simple and easily revertible way beforehand.

Beelzebud · 2012-09-04 21:31:11

patroclo7 wrote:

falconindy wrote:
That's exactly the argument against using rc.local. It's a place you put hacks that you're too lazy to properly order with bootup.
I am the sysadmin and I am free to be as lazy as I like to be. And I can also have the specific desire not to order properly something with bootup, because ordering it would be overkill and loss of time. Also when I want to "order" it, I need to try it in a simple and easily revertible way beforehand.

Well said.

stqn · 2012-09-05 19:09:42

I believe I found another way to keep subscripts running after rc.local has exited, without removing “StandardInput=tty”:

( dostuff ) </dev/null &>/dev/null &
disown

I don’t know if everything is required, but at least it seems to be working.

Edit: Turns out it doesn’t work, or only randomly… I’ll just remove this TTY thing from the service file.

Last edited by stqn (2012-09-06 00:02:22)

progandy · 2012-09-05 19:23:28

stqn wrote:

I believe I found another way to keep subscripts running after rc.local has exited, without removing “StandardInput=tty”:
( dostuff ) </dev/null &>/dev/null &
disown
I don’t know if everything is required, but at least it seems to be working.

In my terminals I use the following function:

detached () {
	# detach stdout, stderr, stdin, run in background and disown handles
	"$@" > /dev/null 2>&1 < /dev/null &
	disown
}
# Example:
detached update_database -dir /var/db/something

Arch Linux

#1 2012-08-27 15:08:20

[SOLVED] systemd and rc-local.service

#2 2012-08-27 15:18:57

Re: [SOLVED] systemd and rc-local.service

#3 2012-08-27 15:37:48

Re: [SOLVED] systemd and rc-local.service

#4 2012-08-27 16:51:35

Re: [SOLVED] systemd and rc-local.service

#5 2012-08-27 21:47:28

Re: [SOLVED] systemd and rc-local.service

#6 2012-08-27 22:48:56

Re: [SOLVED] systemd and rc-local.service

#7 2012-08-28 07:17:01

Re: [SOLVED] systemd and rc-local.service

#8 2012-09-04 01:25:34

Re: [SOLVED] systemd and rc-local.service

#9 2012-09-04 06:36:41

Re: [SOLVED] systemd and rc-local.service

#10 2012-09-04 14:11:33

Re: [SOLVED] systemd and rc-local.service

#11 2012-09-04 14:55:04

Re: [SOLVED] systemd and rc-local.service

#12 2012-09-04 21:31:11

Re: [SOLVED] systemd and rc-local.service

#13 2012-09-05 19:09:42

Re: [SOLVED] systemd and rc-local.service

#14 2012-09-05 19:23:28

Re: [SOLVED] systemd and rc-local.service

Board footer