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
  

/etc/systemd/system/writehello.service

Here is an example service.

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

[Service]
Type=oneshot
ExecStart=# <-- This is what I am looking for

[Install]
WantedBy=multi-user.target

/etc/systemd/system/writehello.timer

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

[Unit]
Description=test

[Timer]
Persistent=true
OnUnitActiveSec=10s
OnBootSec=10s

[Install]
WantedBy=timers.target

/path/to/writehello.py

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 %sn' % (now))
f1.close

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.

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.

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

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