FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 11-23-2010, 07:48 PM
Lennart Poettering
 
Default Moving /var/run and /var/lock to tmpfs in Rawhide

Heya!

I hereby want to let everybody know that in the next days I will turn on
/var/run and /var/lock on tmpfs on Rawhide/F15. This is in accordance
with the following accepted F15 feature:

https://fedoraproject.org/wiki/Features/var-run-tmpfs

My current tests indicate that we will not run into too much trouble
with this and most things should continue to work just fine. However, of
course I run only a small subset of packages of the fedora archive on my
machine. So here's what might happen and which might need fixing over
the next weeks in various packages:

- Not all packages might be able to create their directory in /var/run
on start-up. Since SUSE and Ubuntu have already been shipping systems
with tmpfs on /var/run and /var/lock for quite a while I expect the
number of packages that are incapable of doing this to be very
small. If your software nonetheless fails witht this issue, then
there are two options to fix this: a) patch the program in
question, so that it is able to recreate the directories in
/var/run, or b) ship a simple drop-in file for /etc/tmpfiles.d/ which
recreates these directories on boot. (see below)

- There might be permission problems, since the rpms might have set
different perms on the subdirs of /var/run than the software itself
might apply when starting up. In this case, a drop-in file in
/etc/tmpfiles.d/ might help. (see below)

- The SELinux policy might trigger AVCs and disallow creation of the
dirs in question. In this case Dan will be of help of course, so make
sure to file a bug. And I guess I don't need to mention this but
temporarily falling back to permissive mode is a short-term workaround
for this.

- In some cases daemons might want to create more than one file/dir
below /var/run which are supposed to be labelled differently. In this
case the daemon can either be modified to fix its labels up itself, or
a drop-in file in /etc/tmpfiles.d/ might help (see below).

- Many .spec files currently own subdirs of /var/run. These need to be
updated to %ghost those dirs only, so that the automatic removal of
these files/dirs on boot doesnt cause rpm to complain. The list of packages
which own such files/subdir you find on the aforementioned feature
page. I will mass-file bugs against these packages later tonight,
requesting the %ghosting of these entries. For more information on the
%ghost directive in .spec files see this page:

http://www.rpm.org/max-rpm-snapshot/s1-rpm-inside-files-list-directives.html#S3-RPM-INSIDE-FLIST-GHOST-DIRECTIVE

Action items:

a) Lennart will mass-file bugs regarding %ghost usage tonight

b) Lennart will switch on /var/run and /var/lock on tmpfs either
tomorrow or the day after tomorrow

c) YOU need to edit your .spec file and place a %ghost where
appropriate.

c) YOU need to test if you package still works, and if necessary file
AVC bugs, add an /etc/tmpfiles.d drop-in file to your program, or patch
it so that it is able to recreate these directories beneath /var/run on
its own.

On /etc/tmpfiles.d:

This is a new feature of systemd, but which is apparently very much
liked by people outside of systemd, so this might actually find adoption
even on systems which will not adopt systemd any time soon, since it
actually is not specific at all to systemd. By dropping a simple
configuration file in /etc/tmpfiles.d you can ensure that volatile files
and directories are: a) created, deleted or emptied at boot b) their
permissions/ownership fixed c) its directory contents cleaned up in
regular intervals (a la tmpwatch) and d) it is properly relabeled at
boot.

As an example, here's how such a file might look like for the screen package
(name it /etc/tmpfiles.d/screen.conf):

<snip>
d /var/run/screens 1777 root root 10d
d /var/run/uscreens 0755 root root 10d12h
</snip>

This encodes that two directories are created under the listed names, with
automatic clean up after 10 days resp. 10 days and 12h.

For more details consult the man page:

http://0pointer.de/public/systemd-man/tmpfiles.d.html

Thank you for your attention!

Lennart

--
Lennart Poettering - Red Hat, Inc.
_______________________________________________
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-23-2010, 08:12 PM
Doug Ledford
 
Default Moving /var/run and /var/lock to tmpfs in Rawhide

On 11/23/2010 03:48 PM, Lennart Poettering wrote:
> Heya!
>
> I hereby want to let everybody know that in the next days I will turn on
> /var/run and /var/lock on tmpfs on Rawhide/F15. This is in accordance
> with the following accepted F15 feature:
>
> https://fedoraproject.org/wiki/Features/var-run-tmpfs

Will the tmpfs mounts be available in the initramfs, or only on the
running system?


--
Doug Ledford <dledford@redhat.com>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford

Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-23-2010, 08:19 PM
Paul Howarth
 
Default Moving /var/run and /var/lock to tmpfs in Rawhide

On Tue, 23 Nov 2010 21:48:30 +0100
Lennart Poettering <mzerqung@0pointer.de> wrote:
> - In some cases daemons might want to create more than one file/dir
> below /var/run which are supposed to be labelled differently. In
> this case the daemon can either be modified to fix its labels up
> itself, or a drop-in file in /etc/tmpfiles.d/ might help (see below).

Given that the tmpfiles.d format doesn't mention SELinux contexts, I
assume that the files/directories will be set up to have whatever their
default context would be under the running policy, as restorecon would
set it?

Paul.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-23-2010, 08:26 PM
Lennart Poettering
 
Default Moving /var/run and /var/lock to tmpfs in Rawhide

On Tue, 23.11.10 21:19, Paul Howarth (paul@city-fan.org) wrote:

>
> On Tue, 23 Nov 2010 21:48:30 +0100
> Lennart Poettering <mzerqung@0pointer.de> wrote:
> > - In some cases daemons might want to create more than one file/dir
> > below /var/run which are supposed to be labelled differently. In
> > this case the daemon can either be modified to fix its labels up
> > itself, or a drop-in file in /etc/tmpfiles.d/ might help (see below).
>
> Given that the tmpfiles.d format doesn't mention SELinux contexts, I
> assume that the files/directories will be set up to have whatever their
> default context would be under the running policy, as restorecon would
> set it?

Yes, SELinux contexts are exclusively configured in the policy, we do
not spread that around in other ocnfiguration files.

The tmpfiles stuff includes an implicit restorecon, basically.

Lennart

--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-23-2010, 08:32 PM
Lennart Poettering
 
Default Moving /var/run and /var/lock to tmpfs in Rawhide

On Tue, 23.11.10 16:12, Doug Ledford (dledford@redhat.com) wrote:

> On 11/23/2010 03:48 PM, Lennart Poettering wrote:
> > Heya!
> >
> > I hereby want to let everybody know that in the next days I will turn on
> > /var/run and /var/lock on tmpfs on Rawhide/F15. This is in accordance
> > with the following accepted F15 feature:
> >
> > https://fedoraproject.org/wiki/Features/var-run-tmpfs
>
> Will the tmpfs mounts be available in the initramfs, or only on the
> running system?

Since /var/run is a subdir of /var which might be separate file system
it is difficult mounting /var/run before /var. That means that it won't
be available in the intird.

(Yes, one can do stuff with show-through mount hierachies, that would
allow replacing /var later on, but I am not a fan of such hackery.)

Also note that by now it's somewhat standard that code that needs to be
run as part of early boot creates a subdir in /dev, such as /dev/.udev
or /dev/.systemd. Not super-pretty, but I guess it's too late to
complain about that.

Ideally the FHS would have never specified that /var/run and /var/lock
would lie beneath /var, but I guess that's too late now.

Lennart

--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-23-2010, 08:41 PM
Daniel J Walsh
 
Default Moving /var/run and /var/lock to tmpfs in Rawhide

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/23/2010 04:26 PM, Lennart Poettering wrote:
> On Tue, 23.11.10 21:19, Paul Howarth (paul@city-fan.org) wrote:
>
>>
>> On Tue, 23 Nov 2010 21:48:30 +0100
>> Lennart Poettering <mzerqung@0pointer.de> wrote:
>>> - In some cases daemons might want to create more than one file/dir
>>> below /var/run which are supposed to be labelled differently. In
>>> this case the daemon can either be modified to fix its labels up
>>> itself, or a drop-in file in /etc/tmpfiles.d/ might help (see below).
>>
>> Given that the tmpfiles.d format doesn't mention SELinux contexts, I
>> assume that the files/directories will be set up to have whatever their
>> default context would be under the running policy, as restorecon would
>> set it?
>
> Yes, SELinux contexts are exclusively configured in the policy, we do
> not spread that around in other ocnfiguration files.
>
> The tmpfiles stuff includes an implicit restorecon, basically.
>
> Lennart
>
And we do not want these labels leaking out into config files. Since
there are multiple policies. For example.

/var/run/BLAH might have different labels in MLS policy versus Targeted.
And some of our partners ship their own policies.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkzsNPYACgkQrlYvE4MpobNnawCfSGBUNfTq0a yy+RMdajBwDBuD
YpgAn1gRJvhHdOmtXvbTh461p6M/rNd3
=4FmN
-----END PGP SIGNATURE-----
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-23-2010, 08:41 PM
Nicholas Miell
 
Default Moving /var/run and /var/lock to tmpfs in Rawhide

On 11/23/2010 12:48 PM, Lennart Poettering wrote:
> Heya!
>
> I hereby want to let everybody know that in the next days I will turn on
> /var/run and /var/lock on tmpfs on Rawhide/F15. This is in accordance
> with the following accepted F15 feature:
>
> https://fedoraproject.org/wiki/Features/var-run-tmpfs
>

Is this actually an improvement?

I know that dentries and inodes for regular filesystems can be discarded
from RAM if they're not in use, is that the case for a tmpfs?
How often are the files in /var/run and /var/lock accessed? Is the
kernel likely to discard them?

Files in /var/run tend to be 4 or 5 bytes in length, does that mean they
each use an entire page of RAM or swap? There are vastly fewer swap
pages than there are filesystem blocks, isn't this less efficient?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-23-2010, 08:41 PM
Nicholas Miell
 
Default Moving /var/run and /var/lock to tmpfs in Rawhide

On 11/23/2010 12:48 PM, Lennart Poettering wrote:
> Heya!
>
> I hereby want to let everybody know that in the next days I will turn on
> /var/run and /var/lock on tmpfs on Rawhide/F15. This is in accordance
> with the following accepted F15 feature:
>
> https://fedoraproject.org/wiki/Features/var-run-tmpfs
>

Is this actually an improvement?

I know that dentries and inodes for regular filesystems can be discarded
from RAM if they're not in use, is that the case for a tmpfs?
How often are the files in /var/run and /var/lock accessed? Is the
kernel likely to discard them?

Files in /var/run tend to be 4 or 5 bytes in length, does that mean they
each use an entire page of RAM or swap? There are vastly fewer swap
pages than there are filesystem blocks, isn't this less efficient?

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-23-2010, 08:44 PM
Till Maas
 
Default Moving /var/run and /var/lock to tmpfs in Rawhide

On Tue, Nov 23, 2010 at 10:32:00PM +0100, Lennart Poettering wrote:

> Also note that by now it's somewhat standard that code that needs to be
> run as part of early boot creates a subdir in /dev, such as /dev/.udev
> or /dev/.systemd. Not super-pretty, but I guess it's too late to
> complain about that.

This is the first time I read about using a subdir in /dev. Is there
some inter-distro agreement about this? The last discussion I had with
someone from debian revealed that they use subdirs in /lib for stuff
that should be in /var according to the FHS but might be needed before
/var is mounted.

Regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-23-2010, 08:57 PM
Lennart Poettering
 
Default Moving /var/run and /var/lock to tmpfs in Rawhide

On Tue, 23.11.10 22:44, Till Maas (opensource@till.name) wrote:

> On Tue, Nov 23, 2010 at 10:32:00PM +0100, Lennart Poettering wrote:
>
> > Also note that by now it's somewhat standard that code that needs to be
> > run as part of early boot creates a subdir in /dev, such as /dev/.udev
> > or /dev/.systemd. Not super-pretty, but I guess it's too late to
> > complain about that.
>
> This is the first time I read about using a subdir in /dev. Is there
> some inter-distro agreement about this? The last discussion I had with
> someone from debian revealed that they use subdirs in /lib for stuff
> that should be in /var according to the FHS but might be needed before
> /var is mounted.

Well it's not really inter-distro. It mostly inter-maintainers-of-
packages-that-are-involved-with-early-boot. I know that at least some
storage stuff also puts stuff there, as will most likely u-l-ng to place
meta information about mounts.

Yes, Debian has /lib/init/rw, and we shortly considered adopting that as
suggested default in systemd, but we decided not to do that since more
software was already using /dev/.foo/ than /lib/init/rw (which in fact
is used only by debian specific scripts afaik at this point), and we
didn't want to add yet another fs just for this purpose to the mix.

I talked to some Debian guys about this and they have ben thinking about
moving /lib/init/rw to /dev/.foobar/ too.

I think everybody agrees that /dev/.foobar/ isn't particularly
pretty. But given that /dev is some kind of tmpfs these days this should
be fine.

I don't think it is really necessary to make /dev/.foobar/ some kind of
standard however. As the number of services involved with early boot and
which need runtime files like this is very limited it should be
sufficient to simply come to an agreement with the various maintainers
involved, which is a small group.

Lennart

--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 03:55 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org