I have a systemd service that needs to create a directory in /run, but otherwise run as a non-root user. From a blog example, I derived the following solution:

Description=Startup Thing

ExecStart=/usr/bin/python3 -u /opt/thing/doStartup
# Make sure the /run/thing directory exists
ExecStartPre=-/bin/mkdir -p /run/thing
ExecStartPre=/bin/chmod -R 777 /run/thing


The magic is in the 3 lines that follow the comment. Apparently the ExecStartPre's will run as root this way, but the ExecStart will run as the specified user.

This has lead to 3 questions though:

  1. What does the - do in front of the /bin/mkdir? I don't know why it's there or what it does.
  2. When there are multiple ExecStartPre's in a unit file, are they just run serially in the order that they are found in the unit file? Or some other method?
  3. Is this actually the best technique to accomplish my goal of getting the run directory created so that the non-root user can use it?

2 Answers 2


For any questions about a systemd directives, you can use man systemd.directives to lookup the man page that documents the directive. In the case of ExecStartPre=, you'll find it documented in man systemd.service.

There in docs for ExecStartPre=, you'll find it explained that the leading "-" is used to note that failure is tolerated for these commands. In this case, it's tolerated if /run/thing already exists.

The docs there also explain that "multiple command lines are allowed and the commands are executed one after the other, serially."

One improvement to your method of pre-creating the directory is not make it world-writable when you only need it to be writable by a particular user. More limited permissions would be accomplished with:

 ExecStartPre=-/bin/chown thingUser /run/thing
 ExecStartPre=-/bin/chmod 700       /run/thing

That makes the directory owned by and fully accessible from a particular user.

  • Awesome answer, thank you for the systemd.directives hint, I always find systemd difficult to figure out where to go. That helps. Mar 1, 2017 at 18:27
  • 4
    You should probably cover RuntimeDirectory and RuntimeDirectoryMode too.
    – JdeBP
    Mar 1, 2017 at 19:34
  • 1
    I believe the - should not be there then. mkdir -p only fails if the directory does not exist and could not be created and then the service probably should just fail. And the permissions are probably important, so error in setting those probably shouldn't be ignored either.
    – Jan Hudec
    Oct 9, 2020 at 13:40

Answer to #3:

Check out the RuntimeDirectory= & RuntimeDirectoryMode= directives. Full docs here. But in summary (slight modification to text, but essence should remain):


       This option take a whitespace-separated list of directory names. The 
       specified directory names must be relative, and may not include "..". If
       set, one or more directories by the specified names will be created
       (including their parents) below /run (for system services) or below 
       $XDG_RUNTIME_DIR (for user services) when the unit is started. Also, the  
       $RUNTIME_DIRECTORY environment variable is defined with the full path of 
       directories. If multiple directories are set, then in the environment 
       variable the paths are concatenated with colon (":").

       The innermost subdirectories are removed when the unit is stopped. It is 
       possible to preserve the specified directories in this case if 
       RuntimeDirectoryPreserve= is configured to restart or yes. The innermost 
       specified directories will be owned by the user and group specified in 
       User= and Group=.

       If the specified directories already exist and their owning user or group 
       do not match the configured ones, all files and directories below the 
       specified directories as well as the directories themselves will have their 
       file ownership recursively changed to match what is configured. As an 
       optimization, if the specified directories are already owned by the right 
       user and group, files and directories below of them are left as-is, even if 
       they do not match what is requested. The innermost specified directories 
       will have their access mode adjusted to the what is specified in 

       Use RuntimeDirectory= to manage one or more runtime directories for the 
       unit and bind their lifetime to the daemon runtime. This is particularly 
       useful for unprivileged daemons that cannot create runtime directories in 
       /run due to lack of privileges, and to make sure the runtime directory is 
       cleaned up automatically after use. For runtime directories that require 
       more complex or different configuration or lifetime guarantees, please 
       consider using tmpfiles.d(5).


       Specifies the access mode of the directories specified in 
       RuntimeDirectory= as an octal number. Defaults to 0755. See "Permissions" 
       in path_resolution(7) for a discussion of the meaning of permission bits.

So to leverage that, this should do the trick:

Description=Startup Thing

ExecStart=/usr/bin/python3 -u /opt/thing/doStartup
# Make sure the /run/thing directory exists

  • 3
    I don't think the PermissionsStartOnly should be left in there when there is no ExecPreStart left.
    – Jan Hudec
    Oct 9, 2020 at 13:45
  • It's deprecated now anyways... Oct 12, 2020 at 1:20
  • It is deprecated in favor of the + and ! prefixes to commands, but it is likely to continue working for many years to come, because some software maintainers still want their packages to be installable on ancient systems that don't understand those prefixes yet.
    – Jan Hudec
    Oct 12, 2020 at 6:14

You must log in to answer this question.

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