What the heck is a rc.local stop job?

[Tom Horsley]

I just rebooted my fedora 27 partition to get new kernel
running, and I had to hit the reset button because it
stuck here forever:

A stop job is running for /etc/rc.d/rc.local Compatibility

There is no bloody rc.local script that runs on shutdown,
it exists for running stuff at boot. What has systemd
done now and how do I make it stop?

[Doug H.]

On Tue, 2017-11-28 at 09:44 -0500, Tom Horsley wrote:
> I just rebooted my fedora 27 partition to get new kernel
> running, and I had to hit the reset button because it
> stuck here forever:
>
> A stop job is running for /etc/rc.d/rc.local Compatibility
>
> There is no bloody rc.local script that runs on shutdown,
> it exists for running stuff at boot. What has systemd
> done now and how do I make it stop?

Some good info at:

https://github.com/systemd/systemd/issues/5497

So you likely have a result with "running" when doing:

systemctl status rc-local

And they suggest:

The only way to start a daemon in rc.local is by mean of "at -f
<commandfile_that_includes_daemon> now", as atd runs in a separate
cgroup thus rc.local gets no running PIDs in their group

[Tom Horsley]

> Some good info at:
>
> https://github.com/systemd/systemd/issues/5497
>
> So you likely have a result with "running" when doing:
>
> systemctl status rc-local
>
> And they suggest:
>
> The only way to start a daemon in rc.local is by mean of "at -f
> <commandfile_that_includes_daemon> now", as atd runs in a separate
> cgroup thus rc.local gets no running PIDs in their group

Aieee! The only reason I'm starting things in rc.local is because
systemd can't ever start them properly because it has no idea
when the network is actually up. I guess I'll have to move all
my rc.local content to a different script and start that script
with the at -f now gimmick.

Thanks for the pointer!

Hi

On Tue, 28 Nov 2017 12:51:58 -0500 Tom Horsley wrote:
> Aieee! The only reason I'm starting things in rc.local is because
> systemd can't ever start them properly because it has no idea
> when the network is actually up. I guess I'll have to move all
> my rc.local content to a different script and start that script
> with the at -f now gimmick.

Humm. It seems we are back to the thread:

network-online.target appears to be very much broken

:-)

Why not:

* add a A.service "in" the network-online.target
    that waits till the network is up for you

* define a B.service for the things you want to start
    with an: After=network-online.target

?

[Joe Zeff]

On 11/28/2017 06:44 AM, Tom Horsley wrote:
> There is no bloody rc.local script that runs on shutdown,
> it exists for running stuff at boot. What has systemd
> done now and how do I make it stop?

Do you have anything in rc.local?  If so, it may be waiting for that 
script to exit.

[Tom Horsley]

On Tue, 28 Nov 2017 19:26:49 +0100
[e-mail] wrote:
> Why not:

1. Because systemd should work properly and it isn't my
job to fix it.

2. Because using rc.local is 10,000 times easier than
decrypting systemd dependency operations.

3. If rc.local was actually compatible with sysv, I
wouldn't need to make even this change.

[Rex Dieter]

Tom Horsley wrote:
> On Tue, 28 Nov 2017 19:26:49 +0100
> [e-mail] wrote:
> > Why not:
> Because using rc.local is 10,000 times easier than
>
> decrypting systemd dependency operations.

Mind you, rc.local is a systemd service itself, nothing extra special about 
it:
/usr/lib/systemd/system/rc-local.service

-- Rex

[Gordon Messmer]

On 11/28/2017 09:51 AM, Tom Horsley wrote:
> The only reason I'm starting things in rc.local is because
> systemd can't ever start them properly because it has no idea
> when the network is actually up.

Can *anyone* experiencing this problem provide more information about 
it?  I tried to reproduce this problem, but wasn't able to.

I did some testing by creating a shell script, /usr/local/bin/ip-log, 
containing:

#!/bin/sh
     /usr/sbin/ip addr show | logger

I ran "systemctl edit NetworkManager-wait-online" and added two lines to 
the override file:

[Service]
     ExecStart=/usr/local/bin/ip-log

... and rebooted.  Boot logs record that most services start 14-16 
seconds past the minute and that NetworkManager starts setting up.  It 
takes six seconds to connect to WiFi and get an address from DHCP.  At 
22 seconds past the minute, the output of "ip addr show" is logged, and 
then privoxy starts.

The privoxy unit requires network-online, and systemd (and 
NetworkManager) waits for the network to be "actually up" on an 
unmodified system where I did this test.  It would be useful to everyone 
if anyone can provide more information.