66

On Ubuntu:

touch: cannot touch `/var/run/test.pid': Permission denied

I am starting start-stop-daemon and like to write the PID file in /var/run start-stop-daemon is run as my-program-user

/var/run setting is drwxr-xr-x  9 root  root

I like to avoid putting my-program-user in the root group.

7 Answers 7

88

By default, you can only write to /var/run as a user with an effective user ID of 0 (ie as root). This is for good reasons, so whatever you do, don't go and change the permissions of /var/run... Instead, as root, create a directory under /var/run:

# mkdir /var/run/mydaemon

Then change its ownership to the user/group under which you wish to run your process:

# chown myuser:myuser /var/run/mydaemon

Now specify to use /var/run/mydaemon rather than /var/run.

You can always test this by running a test as the user in question.

6
  • 10
    This worked fine for me but when I restarted my server then the /var/run/mydaemon directory was gone. Commented May 15, 2014 at 14:22
  • 27
    This is not a complete answer, /var/run is tmpfs by default on Ubuntu. Each time the server is started up the mkdir and chown command need to be re-run.
    – Tim
    Commented Feb 23, 2015 at 7:31
  • 1
    @Tim how about editing the answer and complete it?
    – kaiser
    Commented Mar 2, 2016 at 20:29
  • 1
    A better extensive answer is here: superuser.com/a/1127720/71795 a wrong answer which seems very elegant is here: stackoverflow.com/a/5174433. Summary: use either /tmp or ~.
    – Tim
    Commented May 18, 2018 at 20:53
  • 1
    For systemd users see serverfault.com/questions/779634/…
    – rogerdpack
    Commented Jul 18, 2019 at 21:34
17
mkdir /var/run/mydaemon
chown myuser:myuser /var/run/mydaemon

this will not work, since it will be lost at the next reboot (/var/run is a tmpfs on Ubuntu).

The only feasible solution is to run mkdir and chmod as part of the startup scripts.

1
  • Yes, you are right! CentOS will remove the dir when next reboot too. I like to set pid file to "/tmp", or just add "mkdir -p /var/run/mydaemon" to mydaemon.service
    – Zhuo YING
    Commented Apr 3, 2022 at 8:55
4

In systemd-managed distributions, such as Ubuntu, no permissions are needed, and none are desirable.

On such systems, by design, all non-interactive services that could possibly need such access are either launched from a root-owned process - or use a per-user runtime directory. All permission matters can and will be taken care of the manager service.

No system-wide program will ever write to /run directly, but instead have a writeable directory provisioned for then by the system manager, only the latter having the permission to do so. The relevant configuration in a identifier.service file reads

[Service]
RuntimeDirectory=identifier

Which results in, when started as a system service, a directory /run/identifier being created. Or, when started from a non-root user, a directory /run/[UID]/identifier. Both directories, by default, are setup such that the program launched in conjunction is able to write there, and communicated to the launched program by providing the environment variable RUNTIME_DIRECTORY.

1
  • Thank you this is what I've been looking for
    – Kiwy
    Commented Mar 21, 2023 at 8:39
3

You can try this. Create a directory /var/run/test/ and then change the permission of this directory to the same user as your program runs. " chown /var/run/test/" . Now in your application change the location of the PID file to /var/run/test/test.pid. This should get things working for you.

3

What about using the "sticky" bit on /var/run ?

chmod +t /var/run ?

Probably mess up some other apps, but it seems like it would be another solution.

I'll stick with creating a separate /var/run folder for now, however.

2

Entries in the /etc/permissions are permanent. Make an entry there to make the ownership and permissions for a directory permanent.

1
-8

To avoid putting your program-user in the root group, allow others write access:

# chmod 757
4
  • 5
    Never do a chmod 757 on /var/run! This would cause a serious security problem
    – michel
    Commented Dec 2, 2010 at 10:57
  • 2
    This is a terrible idea. It would cause a potentially massive security problem Commented Dec 2, 2010 at 11:17
  • Even if we ignore the security problem, chmod 757 will also only work until the next reboot. Sorry about creating a new answer, but there seems to be no way to reply to the other comment. Commented Jan 7, 2013 at 19:25
  • @michel, the author never said to do a chmod on /var/run. The author may have meant it for the application subdirectory. Not sure what all the fuss is about.
    – Asclepius
    Commented Feb 25, 2013 at 17:39

You must log in to answer this question.

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