13

I am using Archlinux and began trying systemd these days.

However, I found that systemd doesn't load my /etc/rc.local script.

As mentioned in the Wiki page, I did have run systemctl enable rc-local.service, but this didn't help.

The content of my /etc/rc.local file is:

echo -n 120 > /sys/devices/platform/i8042/serio1/speed
echo -n 250 > /sys/devices/platform/i8042/serio1/sensitivity
iptables --table nat -A POSTROUTING -s 192.168.0.0/16 -j MASQUERADE

Any suggestions?

6 Answers 6

16

Arch might not have included the service unit file necessary to run rc.local.

Just create a file /etc/systemd/system/rc-local.service with the following contents (copied verbatim from my Fedora systemd system):

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

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

[Service]
Type=forking
ExecStart=/etc/rc.local start
TimeoutSec=0
StandardOutput=tty
RemainAfterExit=yes
SysVStartPriority=99

Then, just run systemctl enable rc-local.service as root to enable it. You can also test it/run it now by running systemctl start rc-local.service.

4
  • These two files already exists: /etc/systemd/system/multi-user.target.wants/rc-local.service and /lib/systemd/system/rc-local.service
    – Felix Yan
    Jun 21, 2011 at 4:09
  • 2
    It's probably disabled then. Try running systemctl enable rc-local.service. If you continue to have trouble, please post the output of systemctl status rc-local.service.
    – Patches
    Jun 21, 2011 at 4:31
  • 6
    You cannot issue "enable" on unit that has no Install section, this example will perhaps not work.
    – lzap
    Aug 30, 2013 at 12:28
  • 1
    On the other hand, the file (hopefully a link) in multi-user.target.wants is exactly what enables it. Apr 5, 2015 at 5:59
29

With systemd 188-2, systemd complains about having no [Install] section and as such being unable to enable the rc.local service. Might have been the case with earlier versions but since Arch devs only recently announced systemd will become the default I am fixing up my system.

To fix that, just add a section for the multiuser target in /etc/systemd/system/rc-local.service:

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

[Service]
Type=forking
ExecStart=/etc/rc.local start
TimeoutSec=0
StandardOutput=tty
RemainAfterExit=yes
SysVStartPriority=99

[Install]
WantedBy=multi-user.target

Create the /etc/rc.local script and make it executable with chmod +x /etc/rc.local

1
  • 2
    This is because rc-local.service was never a service that was enabled via systemctl enable but since 2011 has been a service auto-enabled by a generator. However Arch Linux, as explained at unix.stackexchange.com/a/471871/5132 , does not turn on the backwards compatibility options in systemd that provide the generator in the first place.
    – JdeBP
    Nov 15, 2018 at 14:33
4

Pkgfile (on my system) says:

$ pkgfile --search rc-local.service
community/initscripts-systemd

That package installs other stuff you may not want, but you can disable it. See also: https://wiki.archlinux.org/index.php/Systemd#The_initscripts-systemd_package

2

Don't forget to make rc.local executable - or the compatibility layer will not run it! In the above examples which are listed - you would run chmod a+x in order to make the rc.local file executable. As follows:

$ chmod a+X /etc/systemd/system/rc-local.service 

I would think another possible problem is the location of your rc.local script! If you haven't already added the compatibility to systemd (which should be built in - and seems to be by former mention of it already existing) you may need to double check your files location... On my OS I have rc-local at /etc/rc.d/rc.local so I ran the following:

$ sudo chmod a+x /etc/rc.d/rc.local
$ sudo systemctl restart rc-local.service
$ sudo systemctl status rc-local.service
rc-local.service - /etc/rc.d/rc.local Compatibility
      Loaded: loaded (/lib/systemd/system/rc-local.service; static)
      Active: active (exited) since Fri, 13 Apr 2012 14:42:39 -0600; 3s ago
     Process: 2285 ExecStart=/etc/rc.d/rc.local start (code=exited, status=0/SUCCESS)
      CGroup: name=systemd:/system/rc-local.service
1
  • 5
    It is pointless to make the systemd service file executable, as shown in your first code snippet. Also, on Arch Linux, the file path is /etc/rc.local -- perhaps the contents of the systemd service file are incorrect. Feb 24, 2013 at 21:13
1

Two common gotchas:

  1. Don't forget to make /etc/rc.d/rc.local executable. You can use

    # chmod a+rx /etc/rc.d/rc.local
    

    to make it executable.

  2. Don't forget to put a #!/bin/sh line in the first line of /etc/rc.d/rc.local. Here's how things should look:

    #  head -1 /etc/rc.d/rc.local 
    #!/bin/sh
    # file /etc/rc.d/rc.local 
    /etc/rc.d/rc.local: POSIX shell script, ASCII text executable
    

    If you don't get similar output, edit /etc/rc.d/rc.local to add a line at the very top containing just #!/bin/sh.

1

If you have /etc/rc.local as an executable file, it will be pulled in to the boot process by systemd-rc-local-generator / rc-local.service.

At least /etc/rc.local is the default path it uses, but this is set by the distribution. Because it's mainly for backwards compatibility, and different distributions were using different paths. E.g. on Fedora, the path is /etc/rc.d/rc.local. You can check the path as follows:

$ systemctl cat rc-local.service
# /usr/lib/systemd/system/rc-local.service
# ...

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

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

It seems this is not very well known. There's several posts which show a previous version of the file, which has no such comment.

1
  • 1
    This is not in fact true. As explained at unix.stackexchange.com/a/471871/5132 , Arch does not use the backwards compatibility mechanisms and does not have this generator.
    – JdeBP
    Nov 15, 2018 at 14:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .