How to run /etc/rc.d/rc.local as the last Linux bootup task?

[aki-k]

systemd version the issue has been seen with

239-68.el8_7.4

Used distribution

Rocky Linux 8.7

Linux kernel version used

6.2.10-100.fc36.x86_64 (host kernel, LXC container)

CPU architectures issue was seen on

x86_64

Component

other

Expected behaviour you didn't see

On Rocky Linux 8.7, the file /etc/rc.d/rc.local contains the following lines:

# In contrast to previous versions due to parallel execution during boot
# this script will NOT be run after all other services.

How to run /etc/rc.d/rc.local as the last Linux bootup task? On Rocky Linux 8.7 it fails to do the task that it
has always served. If it can't be made to run as the last task in Linux bootup, please remove rc-local.service
from systemd to avoid confusion.

Unexpected behaviour you saw

# cat /etc/rc.d/rc.local

Steps to reproduce the problem

# cat /etc/rc.d/rc.local

# rpm -qf /etc/rc.d/rc.local
systemd-239-68.el8_7.4.x86_64

Additional program output to the terminal or log subsystem illustrating the issue

No response

[poettering]

There's no such concept of "last" in systemd, because it makes no sense, it cannot be fulfilled in an event based system, or when more than one such service exists. Add explicit ordering deps instead.

Also rc.local is obsolete. Just write a proper service.

FInally, this is a bug tracker, not a support forum, as the form should have made abundantly clear...

[aki-k]

Why does systemd still carry it if it doesn't do what it used to do pre-systemd? (I mean rc-local.service)

[dtardon]

Why does systemd still carry it if it doesn't do what it used to do pre-systemd? (I mean rc-local.service)

Because rc.local scripts typically aren't that picky regarding their run position and work just fine. We even add After=network-online.target in RHEL to cover scripts that need network. And I'm pretty sure that the people who still insist on using it would shout at us very loudly if rc-local.service were removed...

[poettering]

Why does systemd still carry it if it doesn't do what it used to do pre-systemd? (I mean rc-local.service)

It does something quite similar.

But yeah, we should consider killing it now.

[aki-k]

@poettering Lennart, would you accept this kind of change to rc-local.service to keep it in systemd? This way rc.local is ran after crond in both multi-user.target and graphical.target, so at quite late stage before reaching the target:

[Unit]
After=crond.service

[Install]
WantedBy=default.target

# chmod 700 /etc/rc.d/rc.local
# systemctl enable rc-local.service

(I also removed /usr/lib/systemd/system-generators/systemd-rc-local-generator and created a symlink in its place to /dev/null.)

[poettering]

@poettering Lennart, would you accept this kind of change to rc-local.service to keep it in systemd.

No, I would not. See mailing list thread:

https://lists.freedesktop.org/archives/systemd-devel/2023-April/049038.html

[aki-k]

How about this config? I'm just trying to help keep rc.local alive in systemd. As Mr. Tardon wrote,
there are people that want to use it.

/etc/systemd/system/rc-local.service.d/override.conf:

[Unit]
After=systemd-user-sessions.service

[Install]
WantedBy=default.target

mkdir /root/systemd
mv /usr/lib/systemd/system-generators/systemd-rc-local-generator /root/systemd/
ln -s /dev/null /usr/lib/systemd/system-generators/systemd-rc-local-generator

chmod 700 /etc/rc.d/rc.local
systemctl enable rc-local.service

[poettering]

How about this config? I'm just trying to help keep rc.local alive in systemd. As Mr. Tardon wrote,
there are people that want to use it.

Why though? This should die, not kept alive "just because".

(Why do you mask the generator? That's entirely redundant. The generator will pull in the thing if the script exists, you really don't need to mask it, or move it away or anything like this. It's entirely redundant.)

[aki-k]

Why do you mask the generator? That's entirely redundant.

I don't know all the logic in systemd for it, but I noticed it puts rc-local.service into /run/systemd for multi-user.target.wants.