For any OS that uses systemd to manage processes and follows the Filesystem Hierarchy Standard by the Linux Foundation

I recently asked where to but a systemd unit file: Where do I put my systemd unit file on Arch Linux?

I would like to run a python script every 5 minutes (not to be confused with a systemd unit file script that calls the python script). I read the answers to this question: Run script every 30 min with systemd

This is where my question comes in. Where should or could you store scripts that are run by systemd? Is there a reserved place for these, particularly on Arch Linux?

  • For example, logs are placed in /var/log
  • systemd unit files are placed under /etc/systemd/system


Here is an example service.

Description=Run python script that writes hello in file on /media/5TB/hello.txt

ExecStart=# <-- This is what I am looking for



Here is a corresponding timer. This is all stuff documented.





This is the path I am looking for.

#!/usr/bin/env python

import os
import datetime

now = datetime.datetime.now()

f1 = open('/media/mydrive/hello.txt','a')
f1.write('hello %s\n' % (now))
  • I'm not sure I see where there is a security concern here; can you edit your post to explain the problem and your motivations? – Michael Homer Aug 31 '15 at 7:56
  • But why are your script files world-writeable in the first place? That seems like the place to start looking. – Michael Homer Aug 31 '15 at 8:05
  • 3
    If that's really the question, the answer is just that no, there aren't (maybe you could make a case for sbin?). Putting it somewhere different wouldn't address this hypothetical concern though. I think there's a missing bit of motivation in here somewhere. – Michael Homer Aug 31 '15 at 8:10
  • 2
    This security concern just isn't real, so the whole premise of the question doesn't hold. – Michael Homer Aug 31 '15 at 8:23
  • 2
    question is good, upvoted – akostadinov Nov 27 '15 at 8:28

I also was thinking about this same question and wanted to see other's opinion. My take on it is /usr/local/sbin as sbin is where you put things that should be run by admin.

Your analysis is correct the /usr/local is the location dedicated for installing stuff not managed by package manager. But bin is for stuff that should be runnable by regular users. In either case, you should not allow write access to anybody but root to the files in /usr/local. That's the convention as far as I remember (for the whole /usr/).

/opt is usually used for packages that are not used by default on the system and user should set some environment variables to access by bin/man/etc. directories of specific package. Read the links I've provided above.

See RHEL FSH overview as well the latest FHS documentation.

| improve this answer | |

Here are the ideal locations for storing things that will be run (see links for details):

Quote from the File System Hierarchy Standard HS v2.3

Locally installed system administration programs should be placed in /usr/local/sbin.

I understood that when FHS documentation refers to "system", it is referring to some "root" user.

  1. /usr/local/bin OR /usr/local/sbin unique to this computer (not available to a package manager, e.g. scripts, software from a CD) i.e. not installed from a common source to all computers (not a package manager). /usr/local/bin stuff can be run by all users. /usr/local/sbin stuff can be run by root only (it is the system "binary" directory).

  2. /usr/bin not unique (shared stuff between computers e.g. from a package manager i.e. a package manager uses this location)

  3. /root/bin a root user could create this directory instead of using /usr/local/sbin. It is a good place to store things that only a root user runs OR can see (this folder is only executable by root or group root, therefore its contents is not visible to anyone except root) You could even make a bin folder in there to keep things consistent, but no one would know anyway :)

  4. /home/<user>/bin a standard user could create this directory. It is a good place to store scripts that are run as a standard user by systemd.

The conclusion is that number 1 would be an ideal place to store scripts that are run by a systemd daemon/service.

It makes sense,

  1. it is a standard location
  2. it is isolated from your package manager packages
| improve this answer | |

You usually do this with cron. If you worry that some lower-privileges user might edit python script maliciously, just grant him read-rights only, forbidding writing to this file.

| improve this answer | |
  • 2
    This answer does not address the question: Where should scripts be placed that are automatically executed by systemd? – Jonathan Komar Aug 31 '15 at 8:07
  • 1
    I show you different approach; usually you use cron to schedule jobs on your system that need to be run in some fixed time steps. For this, you don't need systemd. If you are trying to use systemd for some specific reason, you did not provide it, hence question is not as clear as it could be. – MatthewRock Aug 31 '15 at 8:12
  • 1
    There are people all over the place asking how to hammer a nail with screwdriver - in that case, the correct answer is: use hammer. I was trying to make sure you didn't forget you got your hammer out there. Anyway, leaving my answer, since might help someone in the future. – MatthewRock Aug 31 '15 at 8:25
  • 4
    For all that this question has its flaws, this answer really doesn't even attempt to address it (or any of the past revisions). It could well help someone in the future, but it'd be a coincidence. – Michael Homer Aug 31 '15 at 10:05

You can store your scripts in /usr/bin or /usr/local/bin (preferred) or /opt

You have to refer to script in ExecStart= key In service section of unit file

| improve this answer | |

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.