Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #193150 > unrolled thread

Origin of /var/run contents

Back to article view | Back to linux.debian.user

Contents

  Origin of /var/run contents Dave Sherohman <dave@sherohman.org> - 2018-02-27 12:10 +0100
    Re: Origin of /var/run contents "Martin S. Weber" <Ephaeton@gmx.net> - 2018-02-27 12:50 +0100
      Re: Origin of /var/run contents Dave Sherohman <dave@sherohman.org> - 2018-02-27 14:00 +0100
      Re: Origin of /var/run contents Gene Heskett <gheskett@shentel.net> - 2018-02-27 18:50 +0100
        Re: Origin of /var/run contents "Martin S. Weber" <Ephaeton@gmx.net> - 2018-02-27 19:30 +0100
          Re: Origin of /var/run contents Gene Heskett <gheskett@shentel.net> - 2018-02-27 19:40 +0100
            Re: Origin of /var/run contents Gene Heskett <gheskett@shentel.net> - 2018-02-27 19:50 +0100
            Re: Origin of /var/run contents Greg Wooledge <wooledg@eeg.ccf.org> - 2018-02-27 19:50 +0100
              Re: Origin of /var/run contents Sven Joachim <svenjoac@gmx.de> - 2018-02-27 20:00 +0100
          Re: Origin of /var/run contents Sven Hartge <sven@svenhartge.de> - 2018-02-27 20:10 +0100
          Re: Origin of /var/run contents David Wright <deblis@lionunicorn.co.uk> - 2018-02-27 20:30 +0100
            Re: Origin of /var/run contents "Martin S. Weber" <Ephaeton@gmx.net> - 2018-02-27 21:00 +0100
              Re: Origin of /var/run contents David Wright <deblis@lionunicorn.co.uk> - 2018-02-28 01:20 +0100
          Re: Origin of /var/run contents Mart van de Wege <mvdwege@gmail.com> - 2018-02-27 22:20 +0100
            Re: Origin of /var/run contents Sven Hartge <sven@svenhartge.de> - 2018-02-28 09:50 +0100
              Re: Origin of /var/run contents Mart van de Wege <mvdwege@gmail.com> - 2018-02-28 12:50 +0100
    Re: Origin of /var/run contents Sven Hartge <sven@svenhartge.de> - 2018-02-27 12:50 +0100
      Re: Origin of /var/run contents Gene Heskett <gheskett@shentel.net> - 2018-02-27 18:20 +0100
        Re: Origin of /var/run contents Don Armstrong <don@debian.org> - 2018-02-27 19:20 +0100
          Re: Origin of /var/run contents Gene Heskett <gheskett@shentel.net> - 2018-02-27 19:30 +0100
          Re: Origin of /var/run contents Sven Hartge <sven@svenhartge.de> - 2018-02-27 20:10 +0100
        Origin of /var/run contents Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2018-03-03 17:40 +0100
          Re: Origin of /var/run contents Gene Heskett <gheskett@shentel.net> - 2018-03-03 18:20 +0100
            Re: Origin of /var/run contents Greg Wooledge <wooledg@eeg.ccf.org> - 2018-03-05 16:10 +0100
              Origin of /var/run contents Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2018-03-07 00:50 +0100
                Re: Origin of /var/run contents deloptes <deloptes@gmail.com> - 2018-03-07 08:00 +0100
                Re: Origin of /var/run contents Greg Wooledge <wooledg@eeg.ccf.org> - 2018-03-07 14:40 +0100
    Re: Origin of /var/run contents Gene Heskett <gheskett@shentel.net> - 2018-02-27 18:10 +0100
    Re: Origin of /var/run contents Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2018-03-03 16:50 +0100

Page 1 of 2  [1] 2  Next page →

#193150 — Origin of /var/run contents

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

[toc] | [next] | [standalone]

#193151

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

[toc] | [prev] | [next] | [standalone]

#193153

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

[toc] | [prev] | [next] | [standalone]

#193170

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>

[toc] | [prev] | [next] | [standalone]

#193178

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

[toc] | [prev] | [next] | [standalone]

#193180

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>

[toc] | [prev] | [next] | [standalone]

#193181

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>

[toc] | [prev] | [next] | [standalone]

#193182

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

[toc] | [prev] | [next] | [standalone]

#193183

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

[toc] | [prev] | [next] | [standalone]

#193184

Martin S. Weber <Ephaeton@gmx.net> 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.

S°

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#193187

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.

[toc] | [prev] | [next] | [standalone]

#193189

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

[toc] | [prev] | [next] | [standalone]

#193197

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.

[toc] | [prev] | [next] | [standalone]

#193192

"Martin S. Weber" <Ephaeton@gmx.net> 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.

[toc] | [prev] | [next] | [standalone]

#193213

Mart van de Wege <mvdwege@gmail.com> wrote:

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

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#193216

Sven Hartge <sven@svenhartge.de> writes:

> Mart van de Wege <mvdwege@gmail.com> wrote:
>
>> 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

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

[toc] | [prev] | [next] | [standalone]

#193152

Dave Sherohman <dave@sherohman.org> 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.

[toc] | [prev] | [next] | [standalone]

#193169

On Tuesday 27 February 2018 06:45:36 Sven Hartge wrote:

> Dave Sherohman <dave@sherohman.org> 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>

[toc] | [prev] | [next] | [standalone]

#193173

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

[toc] | [prev] | [next] | [standalone]

#193174

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>

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web