Origin of /var/run contents

[Dave Sherohman]

I've just made my first foray into creating systemd service files, and,
although I got them to work with manual startup, they failed miserably
on reboot. A short investigation revealed that this is because /var/run
is not persistent across reboots. (It's a link to /run, which is a
tmpfs mount.)

The service file runs a shell script which starts the actual daemon (a
starman server). The script runs as an unprivileged user, since we
don't want starman running as root. However, /run is only writable by
root, so starman can't create its pidfile.

To work around this, I had created a subdirectory, /var/run/myapp, owned
by the user I run starman as. This worked perfectly when it was set up,
but, of course, that subdirectory vanished when the system was rebooted
and, once again, starman couldn't create its pidfile.

So, is there somewhere that /run is initially populated from, where I
can create my myapp/ directory and set its ownership so that it will
exist and be writable by the app's user when systemd starts it up? Or
should I be going about this in a completely different manner?

[Sven Hartge]

Post by Dave Sherohman
I've just made my first foray into creating systemd service files,
and, although I got them to work with manual startup, they failed
miserably on reboot. A short investigation revealed that this is
because /var/run is not persistent across reboots. (It's a link to
/run, which is a tmpfs mount.)
The service file runs a shell script which starts the actual daemon (a
starman server). The script runs as an unprivileged user, since we
don't want starman running as root. However, /run is only writable by
root, so starman can't create its pidfile.

You need a config file in /etc/tmpfiles.d to setup a directory with the
correct permissions below /run. (Or, if the software is packaged, in
/usr/lib/tmpfiles.d/).

Grüße,
Sven.

[Gene Heskett]

Post by Sven Hartge

Post by Dave Sherohman
I've just made my first foray into creating systemd service files,
and, although I got them to work with manual startup, they failed
miserably on reboot. A short investigation revealed that this is
because /var/run is not persistent across reboots. (It's a link to
/run, which is a tmpfs mount.)
The service file runs a shell script which starts the actual daemon
(a starman server). The script runs as an unprivileged user, since
we don't want starman running as root. However, /run is only
writable by root, so starman can't create its pidfile.

You need a config file in /etc/tmpfiles.d to setup a directory with
the correct permissions below /run. (Or, if the software is packaged,
in /usr/lib/tmpfiles.d/).
Grüße,
Sven.

Just curious Sven. Why was this not supplied as a manpage or something,
as far back as wheezy?

I could fix the perms on /var, and restart everything that failed, and it
would be fine until the next reboot, which reset the perms so /var was
only writable as root. Didn't anyone think of the stuff that runs as a
user? Fetchmail/procmail/nut and heyu are all killed by that, so I
edited the configs to put their logfiles in ~/me/log. Works a treat
after also fixing logrotate to access them there. My thoughts on the
geniuses that decreed that aren't generally printable.

[Don Armstrong]

Post by Gene Heskett
Just curious Sven. Why was this not supplied as a manpage or
something, as far back as wheezy?

It's pretty common knowledge that initscripts and systemd units which
don't run as root have to create temporary directories in /run to track
their pid files and sockets before they drop permissions.

Post by Gene Heskett
Didn't anyone think of the stuff that runs as a user?

Stuff that runs as a user should use that user's home directory. [I have
a ~/var/ for this purpose, but other things use environmental variables
or ~/.something/foopid or similar.]

Post by Gene Heskett
Neither jessie nor stretch have a manpage for systemd.tmpfiles.

It's systemd-tmpfiles(8) and tmpfiles.d(5).

Post by Gene Heskett
And how does that work when /run is a link to /var/run? and it doesn't
work thru links. Confusing without a lot more study.

It's the other way around. /var/run should be a symlink to /run, which
is a temporary filesystem which goes away on reboot. [It's this way
because /var is sometimes a separate filesystem, and pid files need to
be written at early boot before /var is mounted.]

Post by Gene Heskett
I have no clue why the /log and /run directory's are root only, but
its for sure a PITA. And the "genius" who decreed that has yet to
surface and offer an explanation.

They're root only because otherwise someone could write 1 to something
like /run/apache2/apache2.pid and watch as your apache2 init script tried to
kill off init. Or something more original and evil.

[Gene Heskett]

Post by Don Armstrong

Post by Gene Heskett
Just curious Sven. Why was this not supplied as a manpage or
something, as far back as wheezy?

It's pretty common knowledge that initscripts and systemd units which
don't run as root have to create temporary directories in /run to
track their pid files and sockets before they drop permissions.

Post by Gene Heskett
Didn't anyone think of the stuff that runs as a user?

Stuff that runs as a user should use that user's home directory. [I
have a ~/var/ for this purpose, but other things use environmental
variables or ~/.something/foopid or similar.]

Post by Gene Heskett
Neither jessie nor stretch have a manpage for systemd.tmpfiles.

It's systemd-tmpfiles(8) and tmpfiles.d(5).

Post by Gene Heskett
And how does that work when /run is a link to /var/run? and it
doesn't work thru links. Confusing without a lot more study.

It's the other way around. /var/run should be a symlink to /run, which
is a temporary filesystem which goes away on reboot. [It's this way
because /var is sometimes a separate filesystem, and pid files need to
be written at early boot before /var is mounted.]

Post by Gene Heskett
I have no clue why the /log and /run directory's are root only, but
its for sure a PITA. And the "genius" who decreed that has yet to
surface and offer an explanation.

They're root only because otherwise someone could write 1 to something
like /run/apache2/apache2.pid and watch as your apache2 init script
tried to kill off init. Or something more original and evil.

I'll have to admit that thought never crossed my mind, whats left of
it. :)

[Sven Hartge]

Post by Don Armstrong
Stuff that runs as a user should use that user's home directory. [I have
a ~/var/ for this purpose, but other things use environmental variables
or ~/.something/foopid or similar.]

$HOME/.cache/foobar would be the (current) canonical place, I think.

S°

[Jonathan de Boyne Pollard]

Post by Gene Heskett
Didn't anyone think of the stuff that runs as a user?

They did. They gave you a /run/user/$UID directory owned by you, and an
XDG_RUNTIME_DIR environment variable whose value points to it that you
use so that its location is configurable. They also gave you a manual
entry.

*
https://freedesktop.org/software/systemd/man/file-hierarchy.html#Runtime%20Data

*
https://manpages.debian.org/wheezy/systemd/file-hierarchy.7.en.html#RUNTIME_DATA

* https://unix.stackexchange.com/questions/162900/

* http://jdebp.eu./Softwares/nosh/guide/gazetteer.html#user-runtime

* http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s15.html

* https://wiki.debian.org/ReleaseGoals/RunDirectory

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635131

*
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/migration_planning_guide/sect-red_hat_enterprise_linux-migration_planning_guide-file_system_layout#sect-Red_Hat_Enterprise_Linux-Migration_Planning_Guide-File_System_Layout-Changes_to_the_run_directory

[Gene Heskett]

Post by Jonathan de Boyne Pollard

Post by Gene Heskett
Didn't anyone think of the stuff that runs as a user?

They did. They gave you a /run/user/$UID directory owned by you, and
an XDG_RUNTIME_DIR environment variable whose value points to it that
you use so that its location is configurable. They also gave you a
manual entry.
*
https://freedesktop.org/software/systemd/man/file-hierarchy.html#Runti
me%20Data
*
https://manpages.debian.org/wheezy/systemd/file-hierarchy.7.en.html#RU
NTIME_DATA
* https://unix.stackexchange.com/questions/162900/
* http://jdebp.eu./Softwares/nosh/guide/gazetteer.html#user-runtime
* http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s15.html
* https://wiki.debian.org/ReleaseGoals/RunDirectory
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635131
*
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux
/7/html/migration_planning_guide/sect-red_hat_enterprise_linux-migratio
n_planning_guide-file_system_layout#sect-Red_Hat_Enterprise_Linux-Migra
tion_Planning_Guide-File_System_Layout-Changes_to_the_run_directory

I don't believe it was documented, or even existed at the time I moved my
stuff. This machine, and 3 others here, running linuxcnc, are still
wheezy. One experimental install on a pi is running jessie. And I've not
had that problem with jessie. So its possible we could both be right.
One stretch install on an arm64, not doing anything of note except
building rt kernels is also working well.

[Greg Wooledge]

Post by Gene Heskett

Post by Jonathan de Boyne Pollard

Post by Gene Heskett
Didn't anyone think of the stuff that runs as a user?

They did. They gave you a /run/user/$UID directory owned by you, and
an XDG_RUNTIME_DIR environment variable whose value points to it that
you use so that its location is configurable. They also gave you a
manual entry.

(snip)

Post by Gene Heskett
I don't believe it was documented, or even existed at the time I moved my
stuff. This machine, and 3 others here, running linuxcnc, are still
wheezy. One experimental install on a pi is running jessie.

All of the stuff Jonathan is describing is from systemd, which basically
means jessie and later.

Wheezy used sysvinit and related pacakges, not systemd.

Jessie does have the file-hierarchy(7) man page that Jonathan mentioned.
Note that the first sentence in this man page mentions systemd.

[Jonathan de Boyne Pollard]

Wheezy used sysvinit and related pacakges, not systemd. Jessie does
have the file-hierarchy(7) man page that Jonathan mentioned.

Debian 7 had systemd, and the sharp-eyed who read the URL will have
noticed that I pointed to the Debian 7 version of that manual page.

Have a manual page from Ubuntu 14, which likewise did in fact have
systemd, to go with it:

* http://manpages.ubuntu.com/manpages/trusty/man8/pam_systemd.8.html

This stuff does go back quite a number of years, now.

*
https://lists.freedesktop.org/archives/systemd-devel/2010-October/000686.html

All of the stuff Jonathan is describing is from systemd,

The sharp-eyed will have also spotted that that is untrue. At least one
of the things that I pointed to most definitely is not systemd.

[deloptes]

Post by Jonathan de Boyne Pollard

Wheezy used sysvinit and related pacakges, not systemd. Jessie does
have the file-hierarchy(7) man page that Jonathan mentioned.

Debian 7 had systemd, and the sharp-eyed who read the URL will have
noticed that I pointed to the Debian 7 version of that manual page.

$ ls /usr/share/man/man
man1/ man2/ man3/ man4/ man5/ man6/ man7/ man8/

for the record those (1...8) are not the debian version

man man

DESCRIPTION
man is the system's manual pager. Each page argument given to man is
normally the name of a program, utility or function. The manual page
associated with each of these arguments is then found and
displayed. A section, if provided, will direct man to look only in that
section of
the manual. The default action is to search in all of the available
sections following a pre-defined order ("1 n l 8 3 2 3posix 3pm 3perl 3am 5
4 9 6 7" by default, unless overridden by the SECTION directive
in /etc/manpath.config), and to show only the first page found, even if
page
exists in several sections.

The table below shows the section numbers of the manual followed by
the types of pages they contain.

1 Executable programs or shell commands
2 System calls (functions provided by the kernel)
3 Library calls (functions within program libraries)
4 Special files (usually found in /dev)
5 File formats and conventions eg /etc/passwd
6 Games
7 Miscellaneous (including macro packages and conventions), e.g.
man(7), groff(7)
8 System administration commands (usually only for root)
9 Kernel routines [Non standard]


regards

[Greg Wooledge]

Wheezy used sysvinit and related pacakges, not systemd. Jessie does have
the file-hierarchy(7) man page that Jonathan mentioned.

Debian 7 had systemd, and the sharp-eyed who read the URL will have noticed
that I pointed to the Debian 7 version of that manual page.

Not by default.

***@ebase-adm:~$ cat /etc/debian_version
7.11
***@ebase-adm:~$ man file-hierarchy
No manual entry for file-hierarchy

Optionally installable "technology preview" packages like wheezy's
unripe systemd do not count.

[Martin S. Weber]

Post by Dave Sherohman
(...)
So, is there somewhere that /run is initially populated from,
(...)

man 5 tmpfiles.d, see also its SEE ALSO.

Regards,
-Martin

[Dave Sherohman]

Thanks! That was just what I needed.

Post by Martin S. Weber

Post by Dave Sherohman
(...)
So, is there somewhere that /run is initially populated from,
(...)

man 5 tmpfiles.d, see also its SEE ALSO.
Regards,
-Martin

[Gene Heskett]

Post by Martin S. Weber

Post by Dave Sherohman
(...)
So, is there somewhere that /run is initially populated from,
(...)

man 5 tmpfiles.d, see also its SEE ALSO.
Regards,
-Martin

Apparently new with jessie. But neither the lone jessie install, or the
only stretch install actually have files in that directory. If its
there, why not make use of it?

Neither jessie nor stretch have a manpage for systemd.tmpfiles.

There is a manpage for systemd-tmpfiles, and apparently some of its
callable subroutines.

I've read that manual, but with all the options, figuring out which one
you need looks like a bit of Russian roulette with live ammo. And how
does that work when /run is a link to /var/run? and it doesn't work thru
links. Confusing without a lot more study.

Or have things changed that much while I was in the shop for 9 days
filtering heparin thru my kidneys for a DVT in my right leg I got from
sitting too many hours a day in front of this monitor?

Taint fun folks, take a break and do a loop around the house every 30
minutes. You will be far better off for doing it.

[Martin S. Weber]

Post by Gene Heskett

Post by Martin S. Weber

Post by Dave Sherohman
(...)
So, is there somewhere that /run is initially populated from,
(...)

man 5 tmpfiles.d, see also its SEE ALSO.
Regards,
-Martin

Apparently new with jessie. But neither the lone jessie install, or the
only stretch install actually have files in that directory.

In which of the three, /{etc,run,usr/lib}/tmpfiles.d ? According to systemdese,
the distribution files belong in /usr/lib/ (check the directory, I believe you
won't find it empty), administrator adjustments in /etc (so no surprise a
vanilla install doesn't have those) and /run, uhmm.. Ask a systemd disciple.

Post by Gene Heskett
If its there, why not make use of it?

Apparantly, it is being used.

Post by Gene Heskett
Neither jessie nor stretch have a manpage for systemd.tmpfiles.

Where'd you get that one from? tmpfiles.d(5) references systemd-tmpfiles(8),
which follows the typical systemd naming scheme of systemd-xxx for systemd
specific service applications. I suggest you report a docco bug for the
referencing file mentioning systemd.tmpfiles instead of systemd-tmpfiles.

Post by Gene Heskett
There is a manpage for systemd-tmpfiles, and apparently some of its
callable subroutines.

You're not exactly supposed to call systemd-tmpfiles yourself.
systemd-tmpfiles(8) documents the systemd services that call systemd-tmpfiles(8).
During configuration development, it might be helpful for the administrator to
manually verify their configuration though, so let's rejoice this manpage exists.

Post by Gene Heskett
I've read that manual,

systemd-tmpfiles(8) ? You're reading the wrong manual. Return to tmpfiles.d(5).

Post by Gene Heskett
(...) but with all the options, (...)

Some problems are inherently complex, and lead to verbose solutions, simply
because of the necessary configurability. "Of course" a shell script would
be "simpler", but then again you'd need different calls to binaries, touch,
chown, mkdir, mknod, cp, etc. If you can't be bothered to figure out the
character you need to create the type of filesystem entry you require, how
can you argue that you could be bothered to look up mknod vs. mkdir, touch
or chmod?

Post by Gene Heskett
figuring out which one
you need looks like a bit of Russian roulette with live ammo.

Your solution being? Besides, it's not russian roulette without live ammo.

Post by Gene Heskett
And how
does that work when /run is a link to /var/run? and it doesn't work thru
links. Confusing without a lot more study

I suggest you look at your "var.conf" tmpfiles.d entry (the one from your
distribution). The situation you describe creates a circular symbolic link.
Would you rather it worked?

Regards,
-Martin

[Gene Heskett]

Post by Martin S. Weber

Post by Gene Heskett

Post by Martin S. Weber

Post by Dave Sherohman
(...)
So, is there somewhere that /run is initially populated from,
(...)

man 5 tmpfiles.d, see also its SEE ALSO.
Regards,
-Martin

Apparently new with jessie. But neither the lone jessie install, or
the only stretch install actually have files in that directory.

In which of the three, /{etc,run,usr/lib}/tmpfiles.d ? According to
systemdese, the distribution files belong in /usr/lib/ (check the
directory, I believe you won't find it empty), administrator
adjustments in /etc (so no surprise a vanilla install doesn't have
those) and /run, uhmm.. Ask a systemd disciple.

Post by Gene Heskett
If its there, why not make use of it?

Apparantly, it is being used.

Post by Gene Heskett
Neither jessie nor stretch have a manpage for systemd.tmpfiles.

Where'd you get that one from? tmpfiles.d(5) references
systemd-tmpfiles(8), which follows the typical systemd naming scheme
of systemd-xxx for systemd specific service applications. I suggest
you report a docco bug for the referencing file mentioning
systemd.tmpfiles instead of systemd-tmpfiles.

Thats my mistake I guess, the dot got stuck in my 83 yo wet ram.

Post by Martin S. Weber

Post by Gene Heskett
There is a manpage for systemd-tmpfiles, and apparently some of its
callable subroutines.

You're not exactly supposed to call systemd-tmpfiles yourself.
systemd-tmpfiles(8) documents the systemd services that call
systemd-tmpfiles(8). During configuration development, it might be
helpful for the administrator to manually verify their configuration
though, so let's rejoice this manpage exists.

Post by Gene Heskett
I've read that manual,

man 5 tmpfiles.d

Post by Martin S. Weber
systemd-tmpfiles(8) ? You're reading the wrong manual. Return to tmpfiles.d(5).

Post by Gene Heskett
(...) but with all the options, (...)

Some problems are inherently complex, and lead to verbose solutions,
simply because of the necessary configurability. "Of course" a shell
script would be "simpler", but then again you'd need different calls
to binaries, touch, chown, mkdir, mknod, cp, etc. If you can't be
bothered to figure out the character you need to create the type of
filesystem entry you require, how can you argue that you could be
bothered to look up mknod vs. mkdir, touch or chmod?

Post by Gene Heskett
figuring out which one
you need looks like a bit of Russian roulette with live ammo.

Your solution being? Besides, it's not russian roulette without live ammo.

:)

Post by Martin S. Weber

Post by Gene Heskett
And how
does that work when /run is a link to /var/run? and it doesn't work
thru links. Confusing without a lot more study

I suggest you look at your "var.conf" tmpfiles.d entry (the one from
your distribution). The situation you describe creates a circular
symbolic link. Would you rather it worked?

No /run is indeed a link to /var/run, whish is real, so we're good there.
Being sorta forced to learn newer stuff after half a decade on nice
stable wheezy has spoilt me.

Post by Martin S. Weber
Regards,
-Martin

Thanks Martin.

[Gene Heskett]

ls -ld /var/run /run

ls -ld /var/run /run
drwxr-xr-x 23 root root 980 Feb 27 07:43 /run
lrwxrwxrwx 1 root root 4 Oct 28 12:46 /var/run -> /run

[Greg Wooledge]

Post by Gene Heskett
No /run is indeed a link to /var/run, whish is real, so we're good there.
Being sorta forced to learn newer stuff after half a decade on nice
stable wheezy has spoilt me.

Even on wheezy, that is not normal.

***@ebase-adm:~$ cat /etc/debian_version
7.11
***@ebase-adm:~$ ls -ld /var/run /run
drwxr-xr-x 16 root root 920 Jan 29 08:19 /run
lrwxrwxrwx 1 root root 4 Dec 23 2013 /var/run -> /run

[Sven Joachim]

Post by Greg Wooledge

Post by Gene Heskett
No /run is indeed a link to /var/run, whish is real, so we're good there.
Being sorta forced to learn newer stuff after half a decade on nice
stable wheezy has spoilt me.

Even on wheezy, that is not normal.
7.11
drwxr-xr-x 16 root root 920 Jan 29 08:19 /run
lrwxrwxrwx 1 root root 4 Dec 23 2013 /var/run -> /run

Indeed, the initscripts package in wheezy went to great lengths to
ensure that /var/run is a symlink to /run. Having it the wrong way
around was only really possible if you never rebooted, e.g. in a chroot.

Cheers,
Sven

[Sven Hartge]

Post by Martin S. Weber
In which of the three, /{etc,run,usr/lib}/tmpfiles.d ? According to systemdese,
the distribution files belong in /usr/lib/ (check the directory, I believe you
won't find it empty), administrator adjustments in /etc (so no surprise a
vanilla install doesn't have those) and /run, uhmm.. Ask a systemd disciple.

/run/tmpfiles.d is for dynamically generated config files. Having them
in /run (which is gone after reboot) resolves the problem of having to
handle leftover cruft after.

I so far only see kmod using to generate devices or directories in /dev
using this mechanism.

S°

[David Wright]

Post by Martin S. Weber

Post by Gene Heskett

Post by Martin S. Weber

Post by Dave Sherohman
(...)
So, is there somewhere that /run is initially populated from,
(...)

man 5 tmpfiles.d, see also its SEE ALSO.
Regards,
-Martin

Apparently new with jessie. But neither the lone jessie install, or the
only stretch install actually have files in that directory.

In which of the three, /{etc,run,usr/lib}/tmpfiles.d ? According to systemdese,
the distribution files belong in /usr/lib/ (check the directory, I believe you
won't find it empty), administrator adjustments in /etc (so no surprise a
vanilla install doesn't have those) and /run, uhmm.. Ask a systemd disciple.

Post by Gene Heskett
If its there, why not make use of it?

Apparantly, it is being used.

Post by Gene Heskett
Neither jessie nor stretch have a manpage for systemd.tmpfiles.

Where'd you get that one from? tmpfiles.d(5) references systemd-tmpfiles(8),
which follows the typical systemd naming scheme of systemd-xxx for systemd
specific service applications. I suggest you report a docco bug for the
referencing file mentioning systemd.tmpfiles instead of systemd-tmpfiles.

Post by Gene Heskett
There is a manpage for systemd-tmpfiles, and apparently some of its
callable subroutines.

You're not exactly supposed to call systemd-tmpfiles yourself.
systemd-tmpfiles(8) documents the systemd services that call systemd-tmpfiles(8).
During configuration development, it might be helpful for the administrator to
manually verify their configuration though, so let's rejoice this manpage exists.

I don't believe that's true. For example, with stretch, Debian no
longer sets up xconsole. The instructions in /usr/share/doc/rsyslog/README.Debian
show how to do this using the files provided under /usr/share/doc/rsyslog/examples.
During that, one types
# systemd-tmpfiles --create xconsole.conf
BTW, xconsole is one that goes in /dev.

Post by Martin S. Weber

Post by Gene Heskett
I've read that manual,

systemd-tmpfiles(8) ? You're reading the wrong manual. Return to tmpfiles.d(5).

Post by Gene Heskett
(...) but with all the options, (...)

Some problems are inherently complex, and lead to verbose solutions, simply
because of the necessary configurability. "Of course" a shell script would
be "simpler", but then again you'd need different calls to binaries, touch,
chown, mkdir, mknod, cp, etc. If you can't be bothered to figure out the
character you need to create the type of filesystem entry you require, how
can you argue that you could be bothered to look up mknod vs. mkdir, touch
or chmod?

And who tidies up after themselves? Bearing in mind that /var/tmp is
non-volatile, this scheme does do a good job of keeping it clean
(unless there's a crash).

Cheers,
David.

[Martin S. Weber]

Post by David Wright

Post by Martin S. Weber
(...)
You're not exactly supposed to call systemd-tmpfiles yourself.
systemd-tmpfiles(8) documents the systemd services that call systemd-tmpfiles(8).
During configuration development, it might be helpful for the administrator to
manually verify their configuration though, so let's rejoice this manpage exists.

I don't believe that's true. For example, with stretch, Debian no
longer sets up xconsole. The instructions in /usr/share/doc/rsyslog/README.Debian
show how to do this using the files provided under /usr/share/doc/rsyslog/examples.
During that, one types
# systemd-tmpfiles --create xconsole.conf
BTW, xconsole is one that goes in /dev.

I don't see this as contradictory to what I wrote (and how I understand it,
as a "mere" systemd user).

So yeah, during configuration development you'd run it manually, throw the file
into the correct spot (/etc in that case, I suppose) and future boots will
then no longer require manual interaction your behalf, i.e., you'd run the
command once, to get the tmp file(s) up during your current boot (i.e., after
systemd-tmpfiles-setup.service has already run) but rely on s-t-s.service
from then on.

Regards,
-Martin

[David Wright]

Post by Martin S. Weber

Post by David Wright

Post by Martin S. Weber
(...)
You're not exactly supposed to call systemd-tmpfiles yourself.
systemd-tmpfiles(8) documents the systemd services that call systemd-tmpfiles(8).
During configuration development, it might be helpful for the administrator to
manually verify their configuration though, so let's rejoice this manpage exists.

I don't believe that's true. For example, with stretch, Debian no
longer sets up xconsole. The instructions in /usr/share/doc/rsyslog/README.Debian
show how to do this using the files provided under /usr/share/doc/rsyslog/examples.
During that, one types
# systemd-tmpfiles --create xconsole.conf
BTW, xconsole is one that goes in /dev.

I don't see this as contradictory to what I wrote (and how I understand it,
as a "mere" systemd user).
So yeah, during configuration development you'd run it manually, throw the file
into the correct spot (/etc in that case, I suppose) and future boots will
then no longer require manual interaction your behalf, i.e., you'd run the
command once, to get the tmp file(s) up during your current boot (i.e., after
systemd-tmpfiles-setup.service has already run) but rely on s-t-s.service
from then on.

I don't believe that's true (nor Gene's assertion that /run is root only).:

$ umask
0027
$ cat /run/user/1000/tmpfiles.d/testing.conf
f /run/user/1000/testing 0444 david david 1d foo\nbar
r /run/user/1000/testing
$ ls -l /run/user/1000/t*
total 4
-rw-r--r-- 1 david david 79 Feb 27 17:42 testing.conf
$ systemd-tmpfiles --create /run/user/1000/tmpfiles.d/testing.conf
$ ls -l /run/user/1000/t*
-r--r--r-- 1 david david 7 Feb 27 17:45 /run/user/1000/testing

/run/user/1000/tmpfiles.d:
total 4
-rw-r--r-- 1 david david 79 Feb 27 17:42 testing.conf
cat /run/user/1000/testing
foo
bar$ systemd-tmpfiles --remove /run/user/1000/tmpfiles.d/testing.conf
$ ls -l /run/user/1000/t*
total 4
-rw-r--r-- 1 david david 79 Feb 27 17:42 testing.conf
$

So the whole apparatus runs perfectly as a user. If you want it set up
automatically, crontab will run it with
@reboot …
(might need to sleep for a bit).

Cheers,
David.

[Mart van de Wege]

Post by Martin S. Weber

Post by Gene Heskett

Post by Martin S. Weber

Post by Dave Sherohman
(...)
So, is there somewhere that /run is initially populated from,
(...)

man 5 tmpfiles.d, see also its SEE ALSO.
Regards,
-Martin

Apparently new with jessie. But neither the lone jessie install, or the
only stretch install actually have files in that directory.

In which of the three, /{etc,run,usr/lib}/tmpfiles.d ? According to systemdese,
the distribution files belong in /usr/lib/ (check the directory, I believe you
won't find it empty), administrator adjustments in /etc (so no surprise a
vanilla install doesn't have those) and /run, uhmm.. Ask a systemd disciple.

Eh. It's in the docs. /run is for runtime generated, ephemeral units and
other files.

What stumped me at first is that /etc has priority over /run

Mart

[Sven Hartge]

Post by Mart van de Wege
Eh. It's in the docs. /run is for runtime generated, ephemeral units
and other files.
What stumped me at first is that /etc has priority over /run

This is because /etc is designed to override (or amend) anything from
the system, either static from (/usr)/lib/systemd or generated from /run.

Grüße,
Sven.

[Mart van de Wege]

Post by Sven Hartge

Post by Mart van de Wege
Eh. It's in the docs. /run is for runtime generated, ephemeral units
and other files.
What stumped me at first is that /etc has priority over /run

This is because /etc is designed to override (or amend) anything from
the system, either static from (/usr)/lib/systemd or generated from /run.

I realise that *now*. Originally I likened the systemd config to the
usual defaults compiled in, then sysadmin overrides in /etc/, then user
overrides in ~/

That was the wrong mental model, as it turned out.

Mart

[Gene Heskett]

Post by Dave Sherohman
I've just made my first foray into creating systemd service files,
and, although I got them to work with manual startup, they failed
miserably on reboot. A short investigation revealed that this is
because /var/run is not persistent across reboots. (It's a link to
/run, which is a tmpfs mount.)
The service file runs a shell script which starts the actual daemon (a
starman server). The script runs as an unprivileged user, since we
don't want starman running as root. However, /run is only writable by
root, so starman can't create its pidfile.
To work around this, I had created a subdirectory, /var/run/myapp,
owned by the user I run starman as. This worked perfectly when it was
set up, but, of course, that subdirectory vanished when the system was
rebooted and, once again, starman couldn't create its pidfile.
So, is there somewhere that /run is initially populated from, where I
can create my myapp/ directory and set its ownership so that it will
exist and be writable by the app's user when systemd starts it up? Or
should I be going about this in a completely different manner?

I got tired of exactly this problem, but in /var, so I moved the log
directory for fetchmail, procmail and one or two others to a log
directory in my home directory, updating the logrotate scripts as I did
so. Whether you could do that with the /run directory is TBD. I have no
clue why the /log and /run directory's are root only, but its for sure a
PITA. And the "genius" who decreed that has yet to surface and offer an
explanation.

[Jonathan de Boyne Pollard]

Or should I be going about this in a completely different manner?

Yes.

[Service]
Type=simple
User=starman
RuntimeDirectory=starman

And simply do not use the --pid and --daemonize options in the first
place. You are using a service manager that tracks child processes and
that runs things in dæmon context to begin with. Employing the rickety
and dangerous PID file mechanism and vain attempts at self-dæmonization
is quite wrong.

*
http://jdebp.eu./FGA/unix-daemon-design-mistakes-to-avoid.html#DoNotCreatePIDFiles

*
http://jdebp.eu./FGA/unix-daemon-design-mistakes-to-avoid.html#DoNotBackgroundise