2

I am new to posting here and am unfamiliar with the protocols. I saw a reference here 16.10 rc.local does not exist and tried using that command

The command was

sudo systemctl enable rc-local.service

That command, for me, in 16.10 MATE provides the following (can't work out the formatting here, regrets:

$ sudo systemctl enable rc-local.service
[sudo] password for chris: 
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.

Reboot has no effect.

Zanna
  • 70,465
wizardfromoz
  • 21

1 Answers1

1

One solution

A quick workaround (I don't know if that's the canonical way):

In a terminal do:

sudo touch /etc/rc.local
sudo chmod +x /etc/rc.local
sudo printf '#!/bin/bash\nexit 0' > /etc/rc.local
sudo reboot

After that the rc.local will be called upon system startup. Insert what you want.

Background

If you do in a terminal:

sudo systemctl edit --full rc-local

You can see that the head comment contains lines such as:

# This unit gets pulled automatically into multi-user.target by
# systemd-rc-local-generator if /etc/rc.local is executable.

This indicates, that in this system, if there is a file called /etc/rc.local which is executable, then it will be pulled into multi-user.target automatically. So you just create the according file (sudo touch...) an make it executable (sudo chmod +x ...).

Jan
  • 1,193
  • 11
  • 11