System | rc.local failed to start

[Remonli]

ADMIN EDIT

Solution:

systemctl disable rc-local
systemctl disable rc.local
cat << _EOF_ > /lib/systemd/system/rc-local.service
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

# This unit gets pulled automatically into multi-user.target by
# systemd-rc-local-generator if /etc/rc.local is executable.
[Unit]
Description=/etc/rc.local Compatibility
ConditionFileIsExecutable=/etc/rc.local
After=network.target

[Service]
Type=forking
ExecStart=/etc/rc.local start
TimeoutSec=0
RemainAfterExit=yes
GuessMainPID=no

_EOF_
systemctl daemon-reload

Required Information

• DietPi version | 6.21.1
• Distro version | 9.8
• Kernel version | Linux DietPi 4.14.79-v7+
• SBC device | RPi 2 Model B (armv7l)
• Power supply used | (EG: 5V 2A RAVpower)
• SDcard used | (EG: SanDisk ultra)

Additional Information (if applicable)

• Fresh new installed dietpi on 32G sdcard

/etc/rc.local was not excuted after systemctl enable rc-local.service and reboot.

systemctl start rc-local.service
Warning: rc-local.service changed on disk. Run 'systemctl daemon-reload' to reload units.

And it will be successfully if run systemctl daemon-reload and then start again systemctl start rc-local.service, however , after reboot , same situation happens.

Pls help check , thanks.

[MichaIng]

@Remonli
Thanks for your report.

Warning: rc-local.service changed on disk.

This means that something has written the /lib/systemd/system/rc-local.service file, which of course should not be done. However even without systemctl daemon-reload, systemctl start rc-local should start the service successfully (in case just the old version) and run /etc/rc.local.
And especially on reboot, the reload step is not required, as all services are freshly loaded anyway 🤔.

Please check:

cat /lib/systemd/system/rc-local.service
cat rc-local.service
journalctl -u rc-local

---

I just wanted to check on my VM and found some important change:

root@VM-Stretch:~# systemctl enable rc-local
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
   .wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
   a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
   D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
   instance name specified.

root@VM-Stretch:~# cat /lib/systemd/system/rc-local.service
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

# This unit gets pulled automatically into multi-user.target by
# systemd-rc-local-generator if /etc/rc.local is executable.
[Unit]
Description=/etc/rc.local Compatibility
ConditionFileIsExecutable=/etc/rc.local
After=network.target

[Service]
Type=forking
ExecStart=/etc/rc.local start
TimeoutSec=0
RemainAfterExit=yes
GuessMainPID=no

root@VM-Stretch:~# l /lib/systemd/system-generators/systemd-rc-local-generator
-rwxr-xr-x 1 root root 10504 Jan 15 10:59 /lib/systemd/system-generators/systemd-rc-local-generator

• So now you cannot enable the service, but just chmod +x /etc/rc.local to have it run on boot automatically.
• So first it is disabled by default, but now even a special generator is implemented for it? I am confused 🤔.

[Remonli]

root@DietPi[22:14:29]:~#systemctl enable rc-local.service

Created symlink /etc/systemd/system/multi-user.target.wants/rc-local.service → /etc/systemd/system/rc-local.service.

root@DietPi[22:14:34]:~#cat /lib/systemd/system/rc-local.service

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

# This unit gets pulled automatically into multi-user.target by
# systemd-rc-local-generator if /etc/rc.local is executable.
[Unit]
Description=/etc/rc.local Compatibility
ConditionFileIsExecutable=/etc/rc.local
After=network.target

[Service]
Type=forking
ExecStart=/etc/rc.local start
TimeoutSec=0
RemainAfterExit=yes
GuessMainPID=no

/etc/rc.local is correct in both content and execute privilege,but it just do not start on reboot, while the same rc.local starts as normal on another debian server.

And you're right, systemctl start rc-local.service can start it eventually without reload. It really confuse
me why rc.local not start on reboot.

[MichaIng]

@Remonli
Indeed very strange.

Created symlink /etc/systemd/system/multi-user.target.wants/rc-local.service → /etc/systemd/system/rc-local.service.

This should only happen, if rc-local.service contains an [Install] section with WantedBy=multi-user.target. This was the case before, but as you can see in your file as well, obviously a new systemd update removed it and made it a static unit by this. Now systemctl enable rc-local should throw the error that you see in my output above.

I can imagine that the enabled symlink and the static unit on reboot cases some inconsistency error, which is perhaps the reason why the script is not called.

What does happen if you do:

systemctl disable rc-local
systemctl daemon-reload
systemctl enable rc-local

• The second commands reloads all systemd units/services, thus afterwards the last command should fail as it did in my case. If it still succeeds, please try to disable it again and reboot to see if /etc/rc.local is called then.

Also try to do a dist upgrade, to resolve possible version mismatches:
apt full-upgrade

• Carefully check the packages this step might want to remove. If there is something inside that you require (MariaDB, a webserver or something), check that it installs updated versions for it. But actually on Raspbian Stretch there should be no issues.

[Remonli]

Sorry for late reply.

root@DietPi[22:51:44]:~#systemctl disable rc-local
Removed /etc/systemd/system/multi-user.target.wants/rc-local.service.
root@DietPi[22:52:20]:~#systemctl daemon-reload
root@DietPi[22:52:31]:~#systemctl enable rc-local
Created symlink /etc/systemd/system/multi-user.target.wants/rc-local.service → /etc/systemd/system/rc-local.service.

And after reboot, still not yet start rc.local correctly.Same as this:

root@DietPi[22:54:53]:~#systemctl start rc.local.service
Warning: rc.local.service changed on disk. Run 'systemctl daemon-reload' to reload units.

[Remonli]

I changed rc-local.service as same as another debian stretch server as below, it works fine now. Looks like some dietpi service goes wrong , so rc-local does not start correctly.

#[Unit]
#Description=rc.local backwards compatibility
#Requires=dietpi-boot.service dietpi-ramdisk.service
#After=dietpi-boot.service dietpi-ramdisk.service dietpi-ramlog.service dietpi-postboot.service

#[Service]
#Type=idle
#RemainAfterExit=yes
#ExecStart=/bin/bash -c '/etc/rc.local'
#StandardOutput=tty

#[Install]
#WantedBy=multi-user.target

[Unit]
Description=/etc/rc.local Compatibility
ConditionFileIsExecutable=/etc/rc.local
After=network.target

[Service]
Type=forking
ExecStart=/etc/rc.local start
TimeoutSec=0
RemainAfterExit=yes
GuessMainPID=no

[MichaIng]

@Remonli
Strange, DietPi does not start this service at all.

Ah wait, your commented old service now looks different to the cat /lib/systemd/system/rc-local.service you printed above.

You use a quite old DietPi image right? In the past we used rc.local for DietPi scripts as well but changed this some time ago. You service content looks like the one we left for compatibility reasons. Yeah and this seems to conflict with the new systemd-rc-local-generator.

Okay so now all this makes sense. We can fix this on all systems:

• Check if rc-local.service is the one we left in place (grep 'dietpi') and in case replace it with the current static unit.

[Remonli]

Actually , I installed with latest 6.20 image and updated to 6.21.1 automaticly.
So , the problem is the old version rc-local.service in /etc/systemd/system was from previous
Dietpi which is deprecated now and not yet deleted ?

[MichaIng]

@Remonli
Strange, looks like the RPi image is based on an old DietPi image. Generally not a big issue, we fix that with v6.22.

But I will update the RPi image soon as well, most properly after v6.22 release. Will check other images as well that I can redo (x86).

[MichaIng]

Fixed for v6.22:

• Patch: ffbbe4f
• Changelog: 9082c2b