Origin of /var/run contents

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Origin of /var/run contents

Dave Sherohman-3
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?

--
Dave Sherohman

Reply | Threaded
Open this post in threaded view
|

Re: Origin of /var/run contents

Sven Hartge-5
Dave Sherohman <[hidden email]> wrote:

> 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.
--
Sigmentation fault. Core dumped.

Reply | Threaded
Open this post in threaded view
|

Re: Origin of /var/run contents

Martin S. Weber
In reply to this post by Dave Sherohman-3
On 2018-02-27 05:03:15, Dave Sherohman wrote:
> (...)
> So, is there somewhere that /run is initially populated from,
> (...)

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

Regards,
-Martin

Reply | Threaded
Open this post in threaded view
|

Re: Origin of /var/run contents

Dave Sherohman-3
Thanks!  That was just what I needed.

On Tue, Feb 27, 2018 at 12:46:50PM +0100, Martin S. Weber wrote:

> On 2018-02-27 05:03:15, Dave Sherohman wrote:
> > (...)
> > So, is there somewhere that /run is initially populated from,
> > (...)
>
> man 5 tmpfiles.d, see also its SEE ALSO.
>
> Regards,
> -Martin
>


--
Dave Sherohman

Reply | Threaded
Open this post in threaded view
|

Re: Origin of /var/run contents

Gene Heskett-4
In reply to this post by Dave Sherohman-3
On Tuesday 27 February 2018 06:03:15 Dave Sherohman wrote:

> 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.

--
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

Reply | Threaded
Open this post in threaded view
|

Re: Origin of /var/run contents

Gene Heskett-4
In reply to this post by Sven Hartge-5
On Tuesday 27 February 2018 06:45:36 Sven Hartge wrote:

> Dave Sherohman <[hidden email]> wrote:
> > 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.

--
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

Reply | Threaded
Open this post in threaded view
|

Re: Origin of /var/run contents

Gene Heskett-4
In reply to this post by Martin S. Weber
On Tuesday 27 February 2018 06:46:50 Martin S. Weber wrote:

> On 2018-02-27 05:03:15, Dave Sherohman wrote:
> > (...)
> > 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.

--
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

Reply | Threaded
Open this post in threaded view
|

Re: Origin of /var/run contents

Don Armstrong
In reply to this post by Gene Heskett-4
On Tue, 27 Feb 2018, Gene Heskett wrote:
> 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.

> 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.]

On Tue, 27 Feb 2018, Gene Heskett wrote:
> Neither jessie nor stretch have a manpage for systemd.tmpfiles.

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

> 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.]

On Tue, 27 Feb 2018, Gene Heskett wrote:
> 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.

--
Don Armstrong                      https://www.donarmstrong.com

[M]en and nations do behave wisely once they have exhausted all other
alternatives.
 -- Abba Ebban

Reply | Threaded
Open this post in threaded view
|

Re: Origin of /var/run contents

Martin S. Weber
In reply to this post by Gene Heskett-4
On 2018-02-27 12:46:46, Gene Heskett wrote:

> On Tuesday 27 February 2018 06:46:50 Martin S. Weber wrote:
>
> > On 2018-02-27 05:03:15, Dave Sherohman wrote:
> > > (...)
> > > 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.

> If its there, why not make use of it?

Apparantly, it is being used.

> 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.

> 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've read that manual,

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

> (...) 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?

> 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.

> 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

Reply | Threaded
Open this post in threaded view
|

Re: Origin of /var/run contents

Gene Heskett-4
In reply to this post by Don Armstrong
On Tuesday 27 February 2018 13:13:34 Don Armstrong wrote:

> On Tue, 27 Feb 2018, Gene Heskett wrote:
> > 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.
>
> > 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.]
>
> On Tue, 27 Feb 2018, Gene Heskett wrote:
> > Neither jessie nor stretch have a manpage for systemd.tmpfiles.
>
> It's systemd-tmpfiles(8) and tmpfiles.d(5).
>
> > 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.]
>
> On Tue, 27 Feb 2018, Gene Heskett wrote:
> > 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. :)

--
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

Reply | Threaded
Open this post in threaded view
|

Re: Origin of /var/run contents

Gene Heskett-4
In reply to this post by Martin S. Weber
On Tuesday 27 February 2018 13:20:09 Martin S. Weber wrote:

> On 2018-02-27 12:46:46, Gene Heskett wrote:
> > On Tuesday 27 February 2018 06:46:50 Martin S. Weber wrote:
> > > On 2018-02-27 05:03:15, Dave Sherohman wrote:
> > > > (...)
> > > > 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.
>
> > If its there, why not make use of it?
>
> Apparantly, it is being used.
>
> > 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.

>
> > 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've read that manual,
>
man 5 tmpfiles.d

> systemd-tmpfiles(8) ? You're reading the wrong manual. Return to
> tmpfiles.d(5).
>
> > (...) 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?
>
> > 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.

:)

> > 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.

> Regards,
> -Martin

Thanks Martin.

--
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

Reply | Threaded
Open this post in threaded view
|

Re: Origin of /var/run contents

Greg Wooledge
On Tue, Feb 27, 2018 at 01:38:08PM -0500, Gene Heskett wrote:
> 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@ebase-adm:~$ cat /etc/debian_version
7.11
ebase@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

Reply | Threaded
Open this post in threaded view
|

Re: Origin of /var/run contents

Gene Heskett-4
On Tuesday 27 February 2018 13:40:34 Greg Wooledge wrote:

> 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

--
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

Reply | Threaded
Open this post in threaded view
|

Re: Origin of /var/run contents

Sven Joachim
In reply to this post by Greg Wooledge
On 2018-02-27 13:40 -0500, Greg Wooledge wrote:

> On Tue, Feb 27, 2018 at 01:38:08PM -0500, Gene Heskett wrote:
>> 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@ebase-adm:~$ cat /etc/debian_version
> 7.11
> ebase@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

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

Reply | Threaded
Open this post in threaded view
|

Re: Origin of /var/run contents

Sven Hartge-5
In reply to this post by Martin S. Weber
Martin S. Weber <[hidden email]> wrote:

> 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.



--
Sigmentation fault. Core dumped.

Reply | Threaded
Open this post in threaded view
|

Re: Origin of /var/run contents

Sven Hartge-5
In reply to this post by Don Armstrong
Don Armstrong <[hidden email]> wrote:

> 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.



--
Sigmentation fault. Core dumped.

Reply | Threaded
Open this post in threaded view
|

Re: Origin of /var/run contents

David Wright-3
In reply to this post by Martin S. Weber
On Tue 27 Feb 2018 at 19:20:09 (+0100), Martin S. Weber wrote:

> On 2018-02-27 12:46:46, Gene Heskett wrote:
> > On Tuesday 27 February 2018 06:46:50 Martin S. Weber wrote:
> >
> > > On 2018-02-27 05:03:15, Dave Sherohman wrote:
> > > > (...)
> > > > 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.
>
> > If its there, why not make use of it?
>
> Apparantly, it is being used.
>
> > 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.
>
> > 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.

> > I've read that manual,
>
> systemd-tmpfiles(8) ? You're reading the wrong manual. Return to tmpfiles.d(5).
>
> > (...) 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.

Reply | Threaded
Open this post in threaded view
|

Re: Origin of /var/run contents

Martin S. Weber
On 2018-02-27 13:29:09, David Wright wrote:

> On Tue 27 Feb 2018 at 19:20:09 (+0100), Martin S. Weber wrote:
> > (...)
> > 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

Reply | Threaded
Open this post in threaded view
|

Re: Origin of /var/run contents

Mart van de Wege
In reply to this post by Martin S. Weber
"Martin S. Weber" <[hidden email]> writes:

> On 2018-02-27 12:46:46, Gene Heskett wrote:
>> On Tuesday 27 February 2018 06:46:50 Martin S. Weber wrote:
>>
>> > On 2018-02-27 05:03:15, Dave Sherohman wrote:
>> > > (...)
>> > > 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

--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.

Reply | Threaded
Open this post in threaded view
|

Re: Origin of /var/run contents

David Wright-3
In reply to this post by Martin S. Weber
On Tue 27 Feb 2018 at 20:56:29 (+0100), Martin S. Weber wrote:

> On 2018-02-27 13:29:09, David Wright wrote:
> > On Tue 27 Feb 2018 at 19:20:09 (+0100), Martin S. Weber wrote:
> > > (...)
> > > 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.

12