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
( 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.
]]>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.
]]>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.
]]>$ 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).
]]>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.
]]>[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)
]]>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?