Re: Origin of /var/run contents

[Greg Wooledge]

On Tue, Mar 06, 2018 at 11:26:19PM +, Jonathan de Boyne Pollard wrote:
> 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@ebase-adm:~$ cat /etc/debian_version 
7.11
ebase@ebase-adm:~$ man file-hierarchy
No manual entry for file-hierarchy

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

Re: Origin of /var/run contents

[deloptes]

Jonathan de Boyne Pollard wrote:

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

Origin of /var/run contents

[Jonathan de Boyne Pollard]

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.


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



Greg Wooledge:


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.

Re: Origin of /var/run contents

[Greg Wooledge]

On Sat, Mar 03, 2018 at 12:09:54PM -0500, Gene Heskett wrote:
> On Saturday 03 March 2018 11:14:34 Jonathan de Boyne Pollard wrote:
> > 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)

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

Re: Origin of /var/run contents

[Gene Heskett]

On Saturday 03 March 2018 11:14:34 Jonathan de Boyne Pollard wrote:

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


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

Origin of /var/run contents

[Jonathan de Boyne Pollard]

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

Re: Origin of /var/run contents

[Jonathan de Boyne Pollard]

Dave Sherohman:


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

Re: Origin of /var/run contents

[Mart van de Wege]

Sven Hartge  writes:

> Mart van de Wege  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.

Re: Origin of /var/run contents

[Sven Hartge]

Mart van de Wege  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.

Re: Origin of /var/run contents

[David Wright]

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.

Re: Origin of /var/run contents

[Mart van de Wege]

"Martin S. Weber"  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.

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

Re: Origin of /var/run contents

[David Wright]

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.

Re: Origin of /var/run contents

[Sven Hartge]

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

S°

-- 
Sigmentation fault. Core dumped.

Re: Origin of /var/run contents

[Sven Hartge]

Martin S. Weber  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.

Re: Origin of /var/run contents

[Sven Joachim]

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

Re: Origin of /var/run contents

[Gene Heskett]

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 

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

Re: Origin of /var/run contents

[Gene Heskett]

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 

Re: Origin of /var/run contents

[Gene Heskett]

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 

Re: Origin of /var/run contents

[Martin S. Weber]

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

Re: Origin of /var/run contents

[Don Armstrong]

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

Re: Origin of /var/run contents

[Gene Heskett]

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 

Re: Origin of /var/run contents

[Gene Heskett]

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

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

Re: Origin of /var/run contents

[Gene Heskett]

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 

Re: Origin of /var/run contents

[Dave Sherohman]

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

Re: Origin of /var/run contents

[Martin S. Weber]

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

Re: Origin of /var/run contents

[Sven Hartge]

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.

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.

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?

-- 
Dave Sherohman