|
Home > Archive > Debian Developers > October 2005 > a place for a package directory in root
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
a place for a package directory in root
|
|
| Joerg Sommer 2005-08-27, 5:51 pm |
| Hi,
I will start maintaining the packages bootchart (#321784) and have a
question. Bootchart collects data while booting. It is started before
init, which means there is no place in the file tree to write to.
The upstream package creates a directory in /mnt/ where it mounts a
tmpfs. But using a directory under /mnt/ violates FHS, which is a policy
violation. Where should I create the directory? Directly In root? I.e.
/bootchart/?
Thanks for your help, Jörg.
--
Computer Science is no more about Computers than astronomy is about
telescopes.
-- Edsger Wybe Dijkstra
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| martin f krafft 2005-08-27, 5:51 pm |
| > > I will start maintaining the packages bootchart (#321784) and have a[vbcol=seagreen]
can't you hack the package to use RAM until the init process is
complete, when it can dump into /var? Doesn't bootlogd do something
like that?
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer and author: http://debiansystem.info
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
"... doch warum sollte nicht jeder einzelne
aus seinem leben ein kunstwerk machen koennen?"
-- michel foucault
| |
| Steve Langasek 2005-08-27, 5:51 pm |
| On Sat, Aug 27, 2005 at 06:31:20PM +0000, Joerg Sommer wrote:
> I will start maintaining the packages bootchart (#321784) and have a
> question. Bootchart collects data while booting. It is started before
> init, which means there is no place in the file tree to write to.
> The upstream package creates a directory in /mnt/ where it mounts a
> tmpfs. But using a directory under /mnt/ violates FHS, which is a policy
> violation. Where should I create the directory? Directly In root? I.e.
> /bootchart/?
/run/bootchart, but there seems to be some resistance to actually trying to
standardize on /run 
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
| |
| sean finney 2005-08-27, 8:49 pm |
| On Sat, Aug 27, 2005 at 12:53:09PM -0700, Steve Langasek wrote:
> /run/bootchart, but there seems to be some resistance to actually trying to
> standardize on /run
what about /dev/shm?
sean
--
| |
| Joerg Sommer 2005-08-27, 8:49 pm |
| martin f krafft <madduck@debian.org> wrote:
>
> can't you hack the package to use RAM until the init process is
> complete, when it can dump into /var? Doesn't bootlogd do something
> like that?
No. Is a simple shell script.
Jörg.
--
Das Recht, seine Meinung zu wechseln, ist eines der wichtigsten
menschlichen Previlegien.
(Robert Peel)
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Joerg Sommer 2005-08-27, 8:49 pm |
| sean finney <seanius@debian.org> wrote:
> On Sat, Aug 27, 2005 at 12:53:09PM -0700, Steve Langasek wrote:
> what about /dev/shm?
> sean
Is it available _before_ init is started?
Jörg.
--
Objektivität ist die Wahnvorstellung, Beobachtungen könnten ohne
Beobachter gemacht werden - Heinz v. Foerster
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Joerg Sommer 2005-08-27, 8:49 pm |
| Steve Langasek <vorlon@debian.org> wrote:
> On Sat, Aug 27, 2005 at 06:31:20PM +0000, Joerg Sommer wrote:
>
>
>
> /run/bootchart, but there seems to be some resistance to actually trying to
> standardize on /run
Is it said, that /run can not be a tmpfs which is mounted by mountvirtfs?
Jörg.
--
"UNIX was not designed to stop people from doing stupid things, because
that would also stop them from doing clever things."
-- Doug Gwyn
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2005-08-28, 5:51 pm |
| Joerg Sommer <joerg@alea.gnuu.de> writes:
> sean finney <seanius@debian.org> wrote:
>
> Is it available _before_ init is started?
>
> Jörg.
Nothing is available before init is started, init is always the first
thing to start, even on initrd or initramfs (some archs call init
linuxrc though).
If you are running from the initrd already then that is writeable
nowadays I think. You have to retrieve the file after pivot_root
though.
If it runs after the pivot_root then /run or /dev/shm is a good
place. You just have to mount them before or in bootchart.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Petter Reinholdtsen 2005-08-28, 5:51 pm |
| [Goswin von Brederlow]
> Nothing is available before init is started, init is always the
> first thing to start, even on initrd or initramfs (some archs call
> init linuxrc though).
You suspect you miss the point. bootchartd is a init _replacement_.
We use it by passing init=/sbin/bootchartd to the kernel. It starts
recording statistics about the boot, and then run init to continue the
boot process.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2005-08-28, 5:51 pm |
| Petter Reinholdtsen <pere@hungry.com> writes:
> [Goswin von Brederlow]
>
> You suspect you miss the point. bootchartd is a init _replacement_.
> We use it by passing init=/sbin/bootchartd to the kernel. It starts
> recording statistics about the boot, and then run init to continue the
> boot process.
Then you are init.
My suggestion still stands. You have to mount /run or /dev/shm to make
a place that is writable.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Roger Leigh 2005-08-28, 5:51 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
sean finney <seanius@debian.org> writes:
> On Sat, Aug 27, 2005 at 12:53:09PM -0700, Steve Langasek wrote:
>
> what about /dev/shm?
/dev/shm is an implementation detail of POSIX shared memory support by
the Linux kernel. See POSIX 1003.1 (2001)
http://www.cnop.net/docs/susv3/functions/shm_open.html (or download
from www.unix.org).
Some packages chose to place random junk in there (e.g. resolvconf).
This is wrong. This location is for (and *only* for) file-backed
shared memory storage, otherwise there is potential for namespace
clashes, and it's totally disgusting.
The fact that it's useful for other things should be an indication
that we need another tmpfs mount, mounted elsewhere, rather than
abusing a location intended for a specific, unrelated, use.
Regards,
Roger
- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iD8DBQFDEh3nVcFcaSW/ uEgRAiZHAJ9h1X7qiGEAyDHW6rnL3Ok3NteJOgCe
Po9K
WdxOdITvUQyPsArK7pmfZyI=
=QsqU
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Joerg Sommer 2005-08-28, 5:51 pm |
| Hello Goswin,
Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> wrote:
> Petter Reinholdtsen <pere@hungry.com> writes:
>
>
> Then you are init.
Yes.
> My suggestion still stands. You have to mount /run or /dev/shm to make
> a place that is writable.
I think /dev/shm is not usable, because the devfsd init script might
mount a new filesystem on /dev/ which would cover my mounted /dev/shm.
What about /run/? Can a new package simply use/create /run? I would add
/run to the directories of the package and mount a tmpfs there at
startup. Is this alright?
Good night, Jörg.
--
Es ist außerdem ein weit verbreiteter Irrtum das USENET "helfen" soll.
Tatsächlich wurde USENET nachweislich zur persönlichen Belustigung
seiner Erfinder geschaffen.
Jörg Klemenz <joerg@gmx.net>, <b4ai4o$1u8vmt$2@ID-21915.news.dfncis.de>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2005-08-28, 8:49 pm |
| Joerg Sommer <joerg@alea.gnuu.de> writes:
> Hello Goswin,
>
> Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> wrote:
>
> Yes.
>
>
> I think /dev/shm is not usable, because the devfsd init script might
> mount a new filesystem on /dev/ which would cover my mounted /dev/shm.
>
> What about /run/? Can a new package simply use/create /run? I would add
> /run to the directories of the package and mount a tmpfs there at
> startup. Is this alright?
>
> Good night, Jörg.
Do it and get enough things to use it. Then there is no stopping you.
Good candidates are mount and resolv-conf.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| sean finney 2005-08-29, 2:52 am |
| On Sun, Aug 28, 2005 at 09:26:16PM +0100, Roger Leigh wrote:
> sean finney <seanius@debian.org> writes:
>
> /dev/shm is an implementation detail of POSIX shared memory support by
> the Linux kernel. See POSIX 1003.1 (2001)
> http://www.cnop.net/docs/susv3/functions/shm_open.html (or download
> from www.unix.org).
didn't know about that, thanks for the reference.
> Some packages chose to place random junk in there (e.g. resolvconf).
> This is wrong. This location is for (and *only* for) file-backed
> shared memory storage, otherwise there is potential for namespace
> clashes, and it's totally disgusting.
>
> The fact that it's useful for other things should be an indication
> that we need another tmpfs mount, mounted elsewhere, rather than
> abusing a location intended for a specific, unrelated, use.
so it's a choice between abusing a pre-existing location but standards
specified for another use, or using a non-existing location with no
standards whatsover. can't say i really like either option. more
specifically because both are not addressed in policy/fhs, i'd be worried
about an in-flow of non-standard, first-come-first-serve namespace
usage.
sean
| |
| Steve Langasek 2005-08-29, 7:50 am |
| On Sat, Aug 27, 2005 at 06:32:26PM -0400, sean finney wrote:
> On Sat, Aug 27, 2005 at 12:53:09PM -0700, Steve Langasek wrote:
[vbcol=seagreen]
> what about /dev/shm?
Aside from the other objections voiced that it abuses that namespace, I
also object to it because it inappropriately ties the required feature
(early availability of read-write space for data that doesn't persist
across reboots) to a particular implementation, instead of leaving the
admin free to structure the mounts in a way that's most appropriate for
the system.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
| |
| Peter Samuelson 2005-08-29, 7:50 am |
|
[Steve Langasek]
> [use of /dev/shm] inappropriately ties the required feature (early
> availability of read-write space for data that doesn't persist across
> reboots) to a particular implementation, instead of leaving the admin
> free to structure the mounts in a way that's most appropriate for the
> system.
Well, this *is* early boot he's talking about. mountvirtfs.sh has not
been run yet, /etc/fstab lies disregarded. The admin only has so much
control over where /run is mounted from at this stage of the game.
I still support a tmpfs /run, but not because it gives the admin any
particular control.
| |
| Joerg Sommer 2005-08-29, 6:00 pm |
| Hello Goswin,
Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> wrote:
> Joerg Sommer <joerg@alea.gnuu.de> writes:
>
> Do it and get enough things to use it. Then there is no stopping you.
Well, I add /run/ to the directories of my package and mount a tmpfs
there on startup. But I leave it mounted after exit, because I don't know
if someone else use it.
Any objections?
Have a nice day, Jörg.
PS: Don't Cc me. I read the list.
--
Gienger's Law (http://www.bruhaha.de/laws.html):
Die Wichtigkeit eines Newspostings im Usenet ist reziprok zur Anzahl der
enthaltenenen, kumulierten Ausrufungszeichen.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Roger Leigh 2005-08-29, 6:01 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
sean finney <seanius@debian.org> writes:
> On Sun, Aug 28, 2005 at 09:26:16PM +0100, Roger Leigh wrote:
[vbcol=seagreen]
>
> so it's a choice between abusing a pre-existing location but standards
> specified for another use, or using a non-existing location with no
> standards whatsover. can't say i really like either option. more
> specifically because both are not addressed in policy/fhs, i'd be worried
> about an in-flow of non-standard, first-come-first-serve namespace
> usage.
In this case, it looks like we should standardise on something like
/run. Has this been brought up with the FHS/LSB folks? This sounds
like something other distributions will also need to tackle, so if it
gets standardised, so much the better.
Regards,
Roger
- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iD8DBQFDE28wVcFcaSW/uEgRAgC5AKCuXQMCDqO+2V/lemhMv4xE+H7r3wCfYEZt
jVnRh6bDSaiZQS41FyySZhE=
=MilK
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jim Crilly 2005-08-29, 6:01 pm |
| On 08/29/05 03:32:55AM -0500, Peter Samuelson wrote:
>
> [Steve Langasek]
>
> Well, this *is* early boot he's talking about. mountvirtfs.sh has not
> been run yet, /etc/fstab lies disregarded. The admin only has so much
> control over where /run is mounted from at this stage of the game.
As long as this is mounted and run via an initrd/initramfs image then
control over the script should be fine. The admin should be able to edit
either a config file or script under /etc/mkinitrd and regenerate the
image. If the locations are going to be hard coded into the init
replacement, then there's really no choice.
>
> I still support a tmpfs /run, but not because it gives the admin any
> particular control.
Jim.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Joerg Sommer 2005-08-29, 8:51 pm |
| Hi Roger,
Roger Leigh <rleigh@whinlatter.ukfsn.org> wrote:
>
> In this case, it looks like we should standardise on something like
> /run. Has this been brought up with the FHS/LSB folks? This sounds
> like something other distributions will also need to tackle, so if it
> gets standardised, so much the better.
Who is responsible in Debian for such things? Has Debian a FHS group?
Bye, Jörg.
--
Es ist außerdem ein weit verbreiteter Irrtum das USENET "helfen" soll.
Tatsächlich wurde USENET nachweislich zur persönlichen Belustigung
seiner Erfinder geschaffen.
Jörg Klemenz <joerg@gmx.net>, <b4ai4o$1u8vmt$2@ID-21915.news.dfncis.de>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Langasek 2005-08-30, 8:15 am |
| On Mon, Aug 29, 2005 at 09:25:22PM +0100, Roger Leigh wrote:
> sean finney <seanius@debian.org> writes:
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
> In this case, it looks like we should standardise on something like
> /run. Has this been brought up with the FHS/LSB folks? This sounds
> like something other distributions will also need to tackle, so if it
> gets standardised, so much the better.
It has not; I had intended to do so, but there was some resistance to
teh idea on debian-devel and the use cases disappeared into /dev/shm, so
I occupied myself with other things.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
| |
| Adeodato Simó 2005-08-30, 6:01 pm |
| * Joerg Sommer [Mon, 29 Aug 2005 12:51:16 +0000]:
[vbcol=seagreen]
> Well, I add /run/ to the directories of my package and mount a tmpfs
> there on startup. But I leave it mounted after exit, because I don't know
> if someone else use it.
> Any objections?
Only, if you implement this in your package, which is an init
replacement, what about other packages that may need this in the
future (or that are currently using /dev/shm when we'd rather they
didn't)? As the standard init does not mount it, they can't count on
/run being available, so either they do it themselves, or we get the
standard init to provide /run as well.
Thoughts about the latter?
--
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
A lie can go round the world before the truth has got its boots on.
-- Terry Pratchett
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Joerg Sommer 2005-09-01, 6:03 pm |
| Hello Adeodato,
Adeodato Simó <asp16@alu.ua.es> wrote:
> * Joerg Sommer [Mon, 29 Aug 2005 12:51:16 +0000]:
>
>
>
>
> Only, if you implement this in your package, which is an init
> replacement, what about other packages that may need this in the
> future (or that are currently using /dev/shm when we'd rather they
> didn't)?
It seems there is a misunderstanding. bootchart is a shell script that is
started as init (kernel prompt init=/sbin/bootchart), which then forks
the real init to start the real boot process. While init does its work
bootchart collects some data about cpu load and hard disk usage, and
(now) writes them to /run. After the boot process has ended, bootchart
packs the data, stores them in a file in the real filesystem and quits.
After the boot process there might be processes they rely on a mounted
/run, because bootchart can't unmount it. But we need it before init is
started, becaus we want to watch init what it does.
Regards, Jörg.
--
Da würde ich auch lieber den Panzerführerschein machen als den MCSE.
Bringt mehr, dürfte das gleiche kosten und macht sicher mehr Spaß.
Jens Dittmar in de.comp.security
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Langasek 2005-09-02, 2:55 am |
| On Thu, Sep 01, 2005 at 09:11:31PM +0000, Joerg Sommer wrote:
> It seems there is a misunderstanding. bootchart is a shell script that is
> started as init (kernel prompt init=/sbin/bootchart), which then forks
> the real init to start the real boot process. While init does its work
> bootchart collects some data about cpu load and hard disk usage, and
> (now) writes them to /run. After the boot process has ended, bootchart
> packs the data, stores them in a file in the real filesystem and quits.
> After the boot process there might be processes they rely on a mounted
> /run, because bootchart can't unmount it. But we need it before init is
> started, becaus we want to watch init what it does.
Hrm. If this information is all just being copied to the real
filesystem at the end of the boot process anyway, why does it need to
write it out to disk instead of just storing it in memory, anyway?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
| |
| Adeodato Simó 2005-09-02, 2:55 am |
| * Steve Langasek [Thu, 01 Sep 2005 23:03:21 -0700]:
> Hrm. If this information is all just being copied to the real
> filesystem at the end of the boot process anyway, why does it need to
> write it out to disk instead of just storing it in memory, anyway?
He claimed it's not possible:
http://lists.debian.org/debian-deve...8/msg01673.html
--
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
Taking any religion too seriously --even the Church of Emacs-- can be
hazardous to your health.
-- Richard Stallman
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Langasek 2005-09-02, 2:55 am |
| On Fri, Sep 02, 2005 at 08:53:19AM +0200, Adeodato Simó wrote:
> * Steve Langasek [Thu, 01 Sep 2005 23:03:21 -0700]:
[vbcol=seagreen]
> He claimed it's not possible:
> http://lists.debian.org/debian-deve...8/msg01673.html
That reads to me like "design flaw", not "impossible to solve". <shrug>
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
| |
| Miquel van Smoorenburg 2005-09-02, 5:58 pm |
| In article <20050902065319.GA4954@chistera.yi.org>,
Adeodato Simó <asp16@alu.ua.es> wrote:
>* Steve Langasek [Thu, 01 Sep 2005 23:03:21 -0700]:
>
>
> He claimed it's not possible:
>
> http://lists.debian.org/debian-deve...8/msg01673.html
Actually, it's pretty simple to do this, by using a lazy unmount.
No need to add an extra /run directory.
#! /bin/sh
cd /
mount -n -t tmpfs tmpfs /tmp
cd /tmp
umount -n -fl /tmp
# From this point on, the current working directory of this script
# and all its children is a tmpfs mount that isn't seen by the
# rest of the system. As soon as this script exits the tmpfs
# mount is cleaned up.
.... bla, blah ...
Mike.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Joerg Sommer 2005-09-02, 8:48 pm |
| Hello Steve,
Steve Langasek <vorlon@debian.org> wrote:
> On Thu, Sep 01, 2005 at 09:11:31PM +0000, Joerg Sommer wrote:
>
>
> Hrm. If this information is all just being copied to the real
> filesystem at the end of the boot process anyway, why does it need to
> write it out to disk instead of just storing it in memory, anyway?
Bootchart forks also a program that collects process informations: acct.
This can't hold its data in memory and write them later. This is out of
reach for bootchart.
Currently bootchart do not support holding data in memory, but I can talk
to upstream about this issue. Regardless of this, I need a writable
filesystem for acct.
Regards, Jörg.
--
Der Wille, und nicht die Gabe macht den Geber.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Thomas Hood 2005-09-29, 6:01 pm |
| The issue of where to put state information that needs to be stored
prior to the initialization of networking (or independently of
networking) has been discussed before. The longest discussion I can
recall was in the spring of 2003 and had the subject headings:
* ifupdown writes to /etc... a bug?
* /run and read-only /etc
* /run/, resolvconf and read-only root
As indicated by the last subject heading, the state-storage issue
is related to the issue of eliminating variable data from the root
filesystem so that the latter can be read-only. I created a web
page to summarize my views on this issue and in order to track the
development of resolvconf (now a mature package) and the removal of
variable files from /etc/.
http://panopticon.csustan.edu/thood/readonly-root.html
I won't summarize the whole discussion here. I will just say that
I see good reasons for adopting /run as a standard location for the
storage of state information that needs to be stored prior to the
availability of networking. I see no good reasons for not adopting
it. If /run is created as a standard location then of course I
will make resolvconf use that location. The only reason that
resolvconf currently uses /dev/shm is that the last time this was
discussed there was no consensus that /run should be created and
endorsed as a standard Debian directory. Using /dev/shm seemed
like a reasonable alternative, although using this location took
more work to debug than I expected.
One non-silly argument for not adopting /run as the standard
location was that using /run would (allegedly) violate the FHS.
However, it would NOT violate the FHS. FHS 2.2 contained language
that might reasonably be taken to rule out the use of any root
directories not already on the list, but, especially in light of
the fact that many distributions do create such directories for
special purposes, FHS 2.3 clarified this to:
Distributions should not create new directories in the
root hierarchy without extremely careful consideration
of the consequences including for application portability.
I spoke to Christopher Yeoh about getting explicit FHS endorsement
of /run and he said that so long as there is a justification for
creating the directory there is no reason why it shouldn't be
explicitly endorsed in the next version of the FHS.
At the present time I know of the following files which might
appropriately be kept in a subdirectory of /run/.
/etc/nologin
/etc/mtab
/etc/network/run/ifstate
/etc/resolvconf/run/*
--
Thomas Hood
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Joerg Sommer 2005-10-01, 7:48 am |
| Hello Thomas,
Thomas Hood <jdthood@yahoo.co.uk> wrote:
> http://panopticon.csustan.edu/thood/readonly-root.html
>
> I won't summarize the whole discussion here. I will just say that
> I see good reasons for adopting /run as a standard location for the
> storage of state information that needs to be stored prior to the
> availability of networking. I see no good reasons for not adopting
> it.
Then, why not create it and show it works? If it fails, you have a good
reason, why not do it. Otherwise its feasibility is proved.
But I've a question on it: How can I use it? How can I set up /run before
init runs the init script that is responsible for it? This script should
be resistant to multiple start calls.
Bye, Jörg.
--
Macht besitzen und nicht ausüben ist wahre Größe.
(Friedl Beutelrock)
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Anthony DeRobertis 2005-10-01, 8:48 pm |
| Joerg Sommer wrote:
> But I've a question on it: How can I use it? How can I set up /run before
> init runs the init script that is responsible for it?
I'd assume you'd make the mounting of /run be the first script init
runs. So, it'd be /etc/rcS.d/S00mountrun (under SysV-style init, of
course). Or maybe it'd become part of S02mountvirtfs.
If this is still too late, init itself would have to do it.
> This script should
> be resistant to multiple start calls.
S02mountvirtfs already is. Or at least so say the comments.
>
> Bye, Jörg.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|