{"id":5515,"date":"2024-05-31T02:15:00","date_gmt":"2024-05-31T06:15:00","guid":{"rendered":"https:\/\/www.both.org\/?p=5515"},"modified":"2025-08-16T16:44:18","modified_gmt":"2025-08-16T20:44:18","slug":"replacing-rc-local-in-systemd-linux-systems","status":"publish","type":"post","link":"https:\/\/www.both.org\/?p=5515","title":{"rendered":"Replacing rc.local in systemd Linux systems"},"content":{"rendered":"
\r\n
\r\n \r\n <\/i>\r\n <\/a>\r\n <\/span>\r\n<\/div><\/div>\n

Are you missing rc.local<\/code> for adding commands to run on startup? Here’s how to set up similar functionality with today’s systemd<\/code>.<\/p>\n\n\n\n

A few years ago I encountered two different problems on two different Linux hosts. Each required a unique circumvention because I had not yet found a real solution. However, the method for delivering each circumvention was the same: Run a command during or soon after Linux startup.<\/p>\n\n\n\n

The rc.local<\/code> file was\u2014and in some cases still is\u2014the place for Linux sysadmins to put commands that need to be run at startup. Use of the rc.local<\/code> file is not only deprecated but after a couple of hours worth of attempts, was not working in any event. This despite the fact that the systemd<\/code> documentation mentions the use of a “generator” that generates systemd<\/code> services from an rc.local<\/code> file if one exists. That seems to be a good way as any to enforce deprecation\u2014make it not work.<\/p>\n\n\n\n

The details of my specific problem are not particularly relevant to this discussion, so I will use a simple and easily tracked command as the content of our local startup file. We will add a date-stamped line to a local log file to verify that the Bash program we need to run at startup actually works.<\/p>\n\n\n\n

Boot vs. startup<\/h2>\n\n\n\n

Understanding the Linux boot and startup process is important for configuring Linux and resolving startup issues. In reality, there are two sequences of events that are required to boot a Linux computer and make it usable: boot and startup. The boot sequence starts when the computer is turned on and finishes when the kernel is initialized and systemd<\/code> is launched. The startup process then takes over and finishes the task of getting the Linux computer into an operational state.<\/p>\n\n\n\n

Overall, the Linux boot and startup process is fairly simple to understand. It is comprised of the following steps, which will be described later in more detail:<\/p>\n\n\n\n

    \n
  1. BIOS Power-On Self-Test (POST)<\/li>\n\n\n\n
  2. Boot loader (GRUB2)<\/li>\n\n\n\n
  3. Kernel<\/li>\n\n\n\n
  4. systemd<\/code><\/li>\n<\/ol>\n\n\n\n

    For a much more detailed description of both the boot and startup sequences, refer to my other article, An introduction to the Linux boot and startup processes with GPT and GRUB2 <\/a>.<\/p>\n\n\n\n

    Local startup<\/h2>\n\n\n\n

    System administrators sometimes add commands to the startup sequence that are locally useful. These additions may aim to start or run local processes that are not part of the standard systemd<\/code> startup. It is possible to add a new systemd<\/code> service unit to launch each program needed at startup, but the old rc.local<\/code> method provided a single executable file for any and all local startup needs. We, too, can use this single file approach with systemd<\/code>. The elegance of this solution is that it makes it easy to add more startup commands at a later time, without the need to add more service units to systemd<\/code>.<\/p>\n\n\n\n

    Our solution is to create a single systemd<\/code> service unit and place any needed Linux commands into the executable file. There are two parts to this solution. One is obvious: We need an executable file. And two, we need to create a service unit for systemd<\/code> that runs the executable.<\/p>\n\n\n\n

    Create the executable file<\/h3>\n\n\n\n

    This is a trivial exercise for any sysadmin familiar with Bash programming. In fact, we will create a Bash program and place it in the Linux Filesystem Hierarchical Standard (FHS)<\/a> location for local executable files, \/usr\/local\/bin<\/code>. An argument could be made for placing this executable file in another location, but \/usr\/local\/bin<\/code> is the one that makes the most sense to me since this location makes it easy for the sysadmin to run the script from the command line if necessary. The \/usr\/local\/bin<\/code> directory is always in every user\u2019s $PATH<\/code>, including that of the root user.<\/p>\n\n\n\n

    Create the mystartup.sh<\/code> file shown here and place it in \/usr\/local\/bin<\/code> (be sure to make it executable). Be sure to use the location for Bash that is correct for your distribution. For example, Debian-based distributions locate Bash at \/bin\/bash<\/code>.<\/p>\n\n\n\n

    #!\/usr\/bin\/bash\n\n################################################################################\n# mystartup.sh\n#\n# This shell program is for testing a startup like rc.local using systemd.\n# By David Both\n# Licensed under GPL V2\n#\n################################################################################\n# This program should be placed in \/usr\/local\/bin\n################################################################################\n# This is a test entry\necho `date +%F\" \"%T` \"Startup worked\" >> \/root\/mystartup.log<\/code><\/pre>\n\n\n\n
    Note:<\/strong> The comments in the included files tell you where they need to be located.<\/p>\n\n\n\n
    Be sure to test this executable by running it from the command line. The first time you run this shell script, you should see a new file, \/root\/mystartup.log<\/code>, with a time and date along with the text, \"Startup worked\"<\/code>. We create this log file and add lines to it every time the script is run as a simple test to ensure that our script is working.<\/p>\n\n\n\n
    Run the script a couple more times. Your results should be similar to those here:<\/p>\n\n\n\n
    [root@testvm1 ~]#  mystartup.sh<\/strong>\n[root@testvm1 ~]#  cat mystartup.log<\/strong>\n2019-09-12 19:58:00 Startup worked\n2019-09-12 19:58:17 Startup worked\n2019-09-12 19:58:54 Startup worked\n2019-09-12 19:59:00 Startup worked\n2019-09-12 20:01:08 Startup worked\n2019-09-12 20:04:01 Startup worked\n2019-09-12 20:04:13 Startup worked\n2019-09-12 20:06:11 Startup worked\n2019-09-12 20:06:28 Startup worked\n2019-09-16 09:51:21 Startup worked\n2019-09-16 09:51:51 Startup worked<\/code><\/pre>\n\n\n\n
    That is all we need to do to create the file that may eventually contain our local startup commands. Just add anything that needs to run at startup to this file.<\/p>\n\n\n\n
    Create the systemd service<\/h3>\n\n\n\n
    The service unit we will now create is a standard systemd<\/code> service unit file. This simple file is used only to run the mystartup.sh<\/code> script at startup. Create a new file, \/usr\/local\/lib\/systemd\/system\/mystartup.service<\/code>, and add the contents shown below:<\/p>\n\n\n\n
    ################################################################################\n# mystartup.service\n#\n# This service unit is for testing my systemd startup service\n# By David Both\n# Licensed under GPL V2\n#\n################################################################################\n# This program should be placed in \/usr\/local\/lib\/systemd\/system\/.\n# Create a symlink to it from the \/etc\/systemd\/system directory.\n################################################################################\n\n[Unit]\nDescription=Runs \/usr\/local\/bin\/mystartup.sh\n  \n[Service]\nExecStart=\/usr\/local\/bin\/mystartup.sh\n\n[Install]\nWantedBy=multi-user.target<\/code><\/pre>\n\n\n\n
    This file does not need to be executable. This file could also be located in \/etc\/systemd\/system<\/code>, but as a local file it is better placed in the \/usr\/local<\/code> branch of the directory structure, with a link to it from \/etc\/systemd.system<\/code>.<\/p>\n\n\n\n
    Now, go to \/etc\/systemd\/system<\/code> and create the symbolic link in the service unit file:<\/p>\n\n\n\n
    [root@testvm1 system]# ln -s \/usr\/local\/lib\/systemd\/system\/mystartup.service<\/strong><\/code><\/pre>\n\n\n\n
    Test the service unit<\/h3>\n\n\n\n
    We should test the final service unit file before rebooting the Linux host for the final test. First, let\u2019s verify that systemd<\/code> sees the service:<\/p>\n\n\n\n
    [root@testvm1 ~]#  systemctl status mystartup<\/strong>\n\u25cf mystartup.service - Runs \/usr\/local\/bin\/mystartup.sh\nLoaded: loaded (\/usr\/local\/lib\/systemd\/system\/mystartup.service; linked; vendor preset: disabled)\nActive: inactive (dead)\n[root@testvm1 ~]#<\/code><\/pre>\n\n\n\n
    This result tells us that the service is recognized by systemd<\/code>. Now, let\u2019s start the service. Doing so will run the script but will not configure the new service to run at boot time:<\/p>\n\n\n\n
    [root@testvm1 ~]# systemctl start mystartup<\/strong><\/code><\/pre>\n\n\n\n
    Check the log file\u2019s contents to verify the new line was added.<\/p>\n\n\n\n
    Enable the service<\/h3>\n\n\n\n
    All that is left is to enable the service so that it runs on startup:<\/p>\n\n\n\n
    [root@testvm1 ~]# systemctl enable mystartup<\/strong>\nCreated symlink \/etc\/systemd\/system\/multi-user.target.wants\/mystartup.service \u2192\n\/usr\/local\/lib\/systemd\/system\/mystartup.service.\n[root@testvm1 ~]#<\/code><\/pre>\n\n\n\n
    Final test<\/h3>\n\n\n\n
    Before we reboot, let\u2019s look the journalctl<\/code> command and how we can use it to view the journal entries that relate to mystartup.service<\/code>. We can also use the journalctl<\/code> command to verify this because systemd<\/code> keeps a journal of everything it does.<\/p>\n\n\n\n
    In the following command, the -u<\/code> option shows only entries for the mystartup<\/code> unit:<\/p>\n\n\n\n
    [root@testvm1 ~]#  journalctl -u mystartup<\/strong>\n-- Logs begin at Mon 2019-04-15 22:50:27 EDT, end at Mon 2019-09-16 11:44:30 EDT. --\nSep 16 11:09:28 testvm1 systemd[1]: Started Runs \/usr\/local\/bin\/mystartup.sh.\n[root@testvm1 ~]#<\/code><\/pre>\n\n\n\n
    Now, reboot the Linux host and check the log file to ensure that a new line was added:<\/p>\n\n\n\n
    [root@testvm1 ~]#  systemctl status mystartup<\/strong>\n\u25cf mystartup.service - Runs \/usr\/local\/bin\/mystartup.sh\nLoaded: loaded (\/usr\/local\/lib\/systemd\/system\/mystartup.service; enabled; vendor preset: disabled)\nActive: inactive (dead) since Mon 2019-09-16 11:45:59 EDT; 1min 30s ago\nProcess: 819 ExecStart=\/usr\/local\/bin\/mystartup.sh (code=exited, status=0\/SUCCESS)\nMain PID: 819 (code=exited, status=0\/SUCCESS)\nSep 16 11:45:55 testvm1 systemd[1]: Started Runs \/usr\/local\/bin\/mystartup.sh.\n\n[root@testvm1 ~]#  journalctl -u mystartu<\/strong>p\n-- Logs begin at Mon 2019-04-15 22:50:27 EDT, end at Mon 2019-09-16 11:47:45 EDT. --\nSep 16 11:09:28 testvm1 systemd[1]: Started Runs \/usr\/local\/bin\/mystartup.sh.\n-- Reboot --\nSep 16 11:45:55 testvm1 systemd[1]: Started Runs \/usr\/local\/bin\/mystartup.sh.\n[root@testvm1 ~]#<\/code><\/pre>\n\n\n\n
    Conclusion<\/h2>\n\n\n\n
    The Bash shell script we have created for this experiment runs once at startup and then exits. It does not remain in memory as a daemon because it was not designed to do so. In case you had not noticed, the procedure we used to create our local startup service can also be used to create any new service for systemd<\/code>. It is not that hard once we know how to do it.<\/p>\n\n\n\n
    Update<\/h2>\n\n\n\n
    Soon after this article was originally published at Opensource.com I received an email from Tom Murphy who informed me of the existence of the rc-local <\/code>service that is part of systemd<\/code>. I appreciate that email because I was not aware of that service so I learned something new.<\/p>\n\n\n\n
    It is possible to add support for the old rc.local<\/code> file by enabling the service with the command, systemctl enable rc-local<\/strong><\/code>. The commands in the rc.local file will run at the next boot. Of course, you can use systemctl enable --now rc-local<\/code> to run rc.local <\/code>immediately.<\/p>\n\n\n\n
    However, it is still true that rc.local is obsolete. The man page for systemd-rc-local-generator <\/code>states, \u201cSupport for \/etc\/rc.local is provided for compatibility with specific System V systems only. However, it is strongly recommended to avoid making use of this script today, and instead provide proper unit files with appropriate dependencies for any scripts to run during the boot process.\u201d<\/p>\n\n\n\n
    Resources<\/h2>\n\n\n\n