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 2 of 2 — ← Prev page 1 [2]

#193186

Don Armstrong <don@debian.org> 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.

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

#193299

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

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

#193300

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 <http://geneslinuxbox.net:6309/gene>

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

#193372

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.

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

#193435

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.

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

#193444

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

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

#193465

On Tue, Mar 06, 2018 at 11:26:19PM +0000, 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.

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

#193168

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>

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

#193297

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web