25

Many years ago, we can write our startup-script into /etc/rc.local. After all system services loaded, your script will run.

Now, we use systemd, we don't have rc.local anymore. Systemd starts the service parallel. You can write your own service to act a rc.local` but you can't ensure it will run after all system services loaded.

Is there a way to do it? Or we have to use Before and After in the systemd service file?

  • 5
    Systemd, not Upstart!! – 比尔盖子 Jan 31 '13 at 9:46
  • Specify name and version OS? – STTR Jan 31 '13 at 9:59
  • OS: Arch Linux, Version: N/A – 比尔盖子 Jan 31 '13 at 10:02
  • 1
    @比尔盖子 Why "last", do you not know the dependencies of the script, or do you want it last just to be safe? – Paul Jan 31 '13 at 13:05
26

In systemd it is advised to use Before= and After= to order your services nicely around the other ones.

But since you asked for a way without using Before and After, you can use:

Type=idle

which as man systemd.service explains:

Behavior of idle is very similar to simple; however, actual execution of the service program is delayed until all active jobs are dispatched. This may be used to avoid interleaving of output of shell services with the status output on the console. Note that this type is useful only to improve console output, it is not useful as a general unit ordering tool, and the effect of this service type is subject to a 5s timeout, after which the service program is invoked anyway.

  • 1
    Hi, would you care to elaborate the syntax if I was gonna use before or after? – r4ccoon Dec 28 '15 at 21:43
  • Somewhat different topic, but if someone wants to run user processes separate from system processes, there's askubuntu.com/a/859583/457417 – Ben Creasy Oct 8 '17 at 5:25
  • worked perfectly to set /proc/sys/kernel/modules_disabled to 1 at the end of the boot process – Stuart Cardall Jul 25 '18 at 20:35
0

It really depends on your definition of "booted". I assume you want it to run immediately after the getty starts. To do this, you need to add your service to /etc/systemd/system/getty.target.wants/ directory. You should also ensure your file is using similar code to the other services in this directory. To run a custom service on bootup and shutdown (just beeps my motherboard buzzer) I use the following script in /etc/systemd/system/getty.target.wants/service_name.service

[Unit]
After=systemd-user-sessions.service plymouth-quit-wait.service
After=rc-local.service
Before=getty.target
IgnoreOnIsolate=yes

[Service]
ExecStart=/usr/bin/myinitscript.sh start
ExecStop=/usr/bin/myinitscript.sh stop
Type=oneshot
RemainAfterExit=true

[Install]
WantedBy=basic.target

/usr/bin/myinitscript.sh is executable and has a shebang at the start.

Note that not everything will be started at this point in the boot, but this is the point at which the logon prompt appears to the user

Although this does use Before= and After=, it was for me much more understandable and actually works; I didn't find the above answer informative enough. This is also allows you to use both ExecStart= and ExecStop=, rather than being limited to a Type=simple-like service.

-2

I'm not familiar with the specifics or ArchLinux, but here is how to manage systemd in general.

Well, basically systemd is a collection of scripts in /etc/init.d/ that are pointed by symlinks from /etc/rcX.d, where X is the number of run level. Symlinks themselves are of the following format:

[K | S] + nn + [string]

where:

  • nn is a number that determines the order in which those scripts run
  • string is the name of the script as it appears in /etc/init.d/
  • and finally K or S determine the command that the script is invoked with: stop or start respectively.

So, if you want your script to run last in the boot sequence, you need to do the following:

  1. put your script in /etc/init.d/ and make it executable
  2. determine the target runlevel the script should start at (tipically 2 for console and 5 for graphical user interface). Can be determined with something like runlevel
  3. have a look at what scripts are already there in this runlevel ls /etc/rc<target runlevel>.d/ and choose a two-digit number that is greater than any other already there.
  4. using an utility specific to your distribution like update-rc.d for Debian based or chkconfig for Fedora-like or manually, create a symlink /etc/rc.d/S to your init script.
  • 5
    What you've described is actually sysVinit. While it is true that systemd is compatible with how sysVinit worked, there is one key difference - everything is performed in parallel. There are also two types of services, sysVinit services, and systemd services. Your answer may help something execute after the sysVinit services, but not necessarily the systemd ones. – Sam Jul 26 '13 at 12:32
  • 1
    Systemd does not aim to be compatible with sysvinit at all, from the day one. – lzap Dec 18 '13 at 14:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.