Discussion:
[PATCH] tmpfiles: move legacy flag-files handling to legacy.conf
(too old to reply)
Tom Gundersen
2013-01-05 23:12:41 UTC
Permalink
---
tmpfiles.d/legacy.conf | 22 +++++++++++++++++-----
tmpfiles.d/systemd.conf | 4 ----
2 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/tmpfiles.d/legacy.conf b/tmpfiles.d/legacy.conf
index 92bd71b..3fff347 100644
--- a/tmpfiles.d/legacy.conf
+++ b/tmpfiles.d/legacy.conf
@@ -8,15 +8,27 @@
# See tmpfiles.d(5) for details

# These files are considered legacy and are unnecessary on legacy-free
-# systems. /run/lock/subsys is used for serializing SysV service
-# execution, and hence without use on SysV-less systems.
-#
+# systems.
+
+d /run/lock 0755 root root -
+
+# /run/lock/subsys is used for serializing SysV service execution, and
+# hence without use on SysV-less systems.
+
+d /run/lock/subsys 0755 root root -
+
# /run/lock/lockdev is used to serialize access to tty devices via
# LCK..xxx style lock files, For more information see:
# http://lists.freedesktop.org/archives/systemd-devel/2011-March/001823.html
# On modern systems a BSD file lock is a better choice if
# serialization is needed on those devices.

-d /run/lock 0755 root root -
-d /run/lock/subsys 0755 root root -
d /run/lock/lockdev 0775 root lock -
+
+# /forcefsck, /fastboot and /forcequotecheck are deprecated in favor of the
+# kernel command line options 'fsck.mode=force', 'fsck.mode=skip' and
+# 'quotacheck.mode=force'
+
+r /forcefsck
+r /fastboot
+r /forcequotacheck
diff --git a/tmpfiles.d/systemd.conf b/tmpfiles.d/systemd.conf
index 965c6fc..f3928d6 100644
--- a/tmpfiles.d/systemd.conf
+++ b/tmpfiles.d/systemd.conf
@@ -15,10 +15,6 @@ f /var/log/btmp 0600 root utmp -

d /var/cache/man - - - 30d

-r /forcefsck
-r /forcequotacheck
-r /fastboot
-
d /run/systemd/ask-password 0755 root root -
d /run/systemd/seats 0755 root root -
d /run/systemd/sessions 0755 root root -
--
1.8.1
Reindl Harald
2013-01-05 23:17:28 UTC
Permalink
Post by Tom Gundersen
+# /forcefsck, /fastboot and /forcequotecheck are deprecated in favor of the
+# kernel command line options 'fsck.mode=force', 'fsck.mode=skip' and
+# 'quotacheck.mode=force'
oh yeah

add a kernel-param is so much easier as "touch /forcefsck" before reboot
Lennart Poettering
2013-01-05 23:25:51 UTC
Permalink
Post by Reindl Harald
Post by Tom Gundersen
+# /forcefsck, /fastboot and /forcequotecheck are deprecated in favor of the
+# kernel command line options 'fsck.mode=force', 'fsck.mode=skip' and
+# 'quotacheck.mode=force'
oh yeah
add a kernel-param is so much easier as "touch /forcefsck" before reboot
It's not about being easy. it's about making sense.

If you are suspicious that something's wrong with your file system so
that you want to force a fsck the least you should do is write to it by
creating a new file on it. That's easy to see, isn't it?

We support this flag file for compatility reasons. Not because it would
make any sense, because it doesn't.

Lennart
--
Lennart Poettering - Red Hat, Inc.
Reindl Harald
2013-01-05 23:47:40 UTC
Permalink
Post by Lennart Poettering
Post by Reindl Harald
Post by Tom Gundersen
+# /forcefsck, /fastboot and /forcequotecheck are deprecated in favor of the
+# kernel command line options 'fsck.mode=force', 'fsck.mode=skip' and
+# 'quotacheck.mode=force'
oh yeah
add a kernel-param is so much easier as "touch /forcefsck" before reboot
It's not about being easy. it's about making sense.
not really
Post by Lennart Poettering
If you are suspicious that something's wrong with your file system so
that you want to force a fsck the least you should do is write to it by
creating a new file on it. That's easy to see, isn't it?
* who says that you always suspicious about the rootfs?
* the reboot itself is touching the FS too
* on remote-machines it often makes no difference write
to boot-config or do "touch /forcefsck" and you can not
add commandline params in anay envirnoment
Post by Lennart Poettering
We support this flag file for compatility reasons. Not because it would
make any sense, because it doesn't
it does, not in all cases, but it does

Lennart, i love the idea of systemd and since F15 there
are many things improved, but please get rid of the
attitude that you are the one and only who knows
how a unix-system has to work
Reindl Harald
2013-01-05 23:59:35 UTC
Permalink
Post by Reindl Harald
* the reboot itself is touching the FS too
Surely not, as we support the rootfs being read-only. Or maybe I
misunderstood what you meant.
on a running system the rootfs is not readonly
so a regulary reboot will happen on a rw mounted rootfs

jesus christ, i have disabled on any server fsck after x days
or x boots because this will hit you always at the wrong moment
after a routine kernel update

i decide in my job as admin if the time is right for a fs-check
i decide this regulary with "touch /forcefsck; systemctl reboot"
i do not like to connect to the vCenter server, hold on the boot
in GRUB and add a param becaue it wastes time with no benefit in
such cases

so what is difficult to understand that it makes not sense to
declare ANYTHING of the pre-systemd area as "deperecated" nor
that you do not a favour for sysadmins to act this way
Reindl Harald
2013-01-06 00:17:10 UTC
Permalink
Post by Reindl Harald
on a running system the rootfs is not readonly
It may be (i.e., systemd supports that setup if the rest of your
software does), so it cannot be that a reboot always causes writes to
the rootfs.
please do not reply off-list and do not cut most of
the previous post, i explained why "touch /forcefsck"
is a godd idea and why deprecate anything which existed
before systemd is a bad attitude
Colin Guthrie
2013-01-06 18:35:59 UTC
Permalink
Post by Reindl Harald
Post by Reindl Harald
on a running system the rootfs is not readonly
It may be (i.e., systemd supports that setup if the rest of your
software does), so it cannot be that a reboot always causes writes to
the rootfs.
please do not reply off-list and do not cut most of
the previous post, i explained why "touch /forcefsck"
is a godd idea and why deprecate anything which existed
before systemd is a bad attitude
You have a very odd way of expressing yourself here. As Lennart
explained this is still *supported*. Putting it in a file called
legacy.conf means very little in all practice, especially as this is a
very simple tidyup routine, which is completely separate from the actual
checking part itself (which would typically remove the file itself after
the check anyway - this is just belt and braces).

Even on systems with rw root, if I get some strange behaviour the first
thing I'll do (if the kernel doesn't do it for me automatically) is
mount -o remount,ro /. If I want to check the root fs, then the initrd
will likely be the thing that actually does the check for me, not
anything on the drive itself, so it's still isolated from the partition
being checked.

So I fully support the rationale that "touch /forcefsck" is a *bad* idea
generally and any sysadmins that regularly use it should really try to
use something with less impact going forward and try not to pass on bad
habits. But there is no need to post sarcastic and unhelpful comments
about something that actually *is* still supported (even if it is, for
good reasons already mentioned, termed legacy).

Of course the question of whether it is or is not supported in the
future is more appropriate for the dracut mailing list (or
$initrd_generator of your choosing), not here in systemd - because
again, this is just a trivial tidy up routine to cleanup left over cruft
and nothing to do with any actual execution of the check itself.


Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
Reindl Harald
2013-01-06 18:56:47 UTC
Permalink
Post by Colin Guthrie
Post by Reindl Harald
Post by Reindl Harald
on a running system the rootfs is not readonly
It may be (i.e., systemd supports that setup if the rest of your
software does), so it cannot be that a reboot always causes writes to
the rootfs.
please do not reply off-list and do not cut most of
the previous post, i explained why "touch /forcefsck"
is a godd idea and why deprecate anything which existed
before systemd is a bad attitude
You have a very odd way of expressing yourself here.
odd is only cut most of my reply by Tom because with
it your last paragraph would have been not needed
Post by Colin Guthrie
As Lennart explained this is still *supported*.
after many years i know what "still" means........

"udev without systemd will still be supported after the merge"
is one example, "will still" menas "for a short timeframe"
in reality
Post by Colin Guthrie
Even on systems with rw root, if I get some strange behaviour the first
thing I'll do (if the kernel doesn't do it for me automatically) is
mount -o remount,ro /. If I want to check the root fs, then the initrd
will likely be the thing that actually does the check for me, not
anything on the drive itself, so it's still isolated from the partition
being checked
again the paragrph tom stripped:

jesus christ, i have disabled on any server fsck after x days
or x boots because this will hit you always at the wrong moment
after a routine kernel update

i decide in my job as admin if the time is right for a fs-check
i decide this regulary with "touch /forcefsck; systemctl reboot"
i do not like to connect to the vCenter server, hold on the boot
in GRUB and add a param becaue it wastes time with no benefit in
such cases
Lennart Poettering
2013-01-07 14:11:41 UTC
Permalink
Post by Reindl Harald
Post by Colin Guthrie
As Lennart explained this is still *supported*.
after many years i know what "still" means........
"udev without systemd will still be supported after the merge"
is one example, "will still" menas "for a short timeframe"
in reality
Hmm? We support using udev independently of systemd just fine. Not sure
what you are referring to here?

Lennart
--
Lennart Poettering - Red Hat, Inc.
Lennart Poettering
2013-01-07 14:09:47 UTC
Permalink
Post by Reindl Harald
jesus christ, i have disabled on any server fsck after x days
or x boots because this will hit you always at the wrong moment
after a routine kernel update
Fedora disables that anyway. Only Debian retains this automatic fsck at boot.
Post by Reindl Harald
i decide in my job as admin if the time is right for a fs-check i
decide this regulary with "touch /forcefsck; systemctl reboot" i do
not like to connect to the vCenter server, hold on the boot in GRUB
and add a param becaue it wastes time with no benefit in such cases
so what is difficult to understand that it makes not sense to declare
ANYTHING of the pre-systemd area as "deperecated" nor that you do not
a favour for sysadmins to act this way
Tom's patch doesn't remove this feature, it just moves this to another
file, which is for all the stuff we find suspicious and don't think
should be used by legacy-free systems. Fedora and the other big distros
are unlikely to go "legacy-free", hence nobody's taking anything away
from you.

Lennart
--
Lennart Poettering - Red Hat, Inc.
Lennart Poettering
2013-01-07 14:06:59 UTC
Permalink
On Sun, 06.01.13 00:12, Tom Gundersen (***@jklm.no) wrote:

Looks good! Please commit!
Post by Tom Gundersen
---
tmpfiles.d/legacy.conf | 22 +++++++++++++++++-----
tmpfiles.d/systemd.conf | 4 ----
2 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/tmpfiles.d/legacy.conf b/tmpfiles.d/legacy.conf
index 92bd71b..3fff347 100644
--- a/tmpfiles.d/legacy.conf
+++ b/tmpfiles.d/legacy.conf
@@ -8,15 +8,27 @@
# See tmpfiles.d(5) for details
# These files are considered legacy and are unnecessary on legacy-free
-# systems. /run/lock/subsys is used for serializing SysV service
-# execution, and hence without use on SysV-less systems.
-#
+# systems.
+
+d /run/lock 0755 root root -
+
+# /run/lock/subsys is used for serializing SysV service execution, and
+# hence without use on SysV-less systems.
+
+d /run/lock/subsys 0755 root root -
+
# /run/lock/lockdev is used to serialize access to tty devices via
# http://lists.freedesktop.org/archives/systemd-devel/2011-March/001823.html
# On modern systems a BSD file lock is a better choice if
# serialization is needed on those devices.
-d /run/lock 0755 root root -
-d /run/lock/subsys 0755 root root -
d /run/lock/lockdev 0775 root lock -
+
+# /forcefsck, /fastboot and /forcequotecheck are deprecated in favor of the
+# kernel command line options 'fsck.mode=force', 'fsck.mode=skip' and
+# 'quotacheck.mode=force'
+
+r /forcefsck
+r /fastboot
+r /forcequotacheck
diff --git a/tmpfiles.d/systemd.conf b/tmpfiles.d/systemd.conf
index 965c6fc..f3928d6 100644
--- a/tmpfiles.d/systemd.conf
+++ b/tmpfiles.d/systemd.conf
@@ -15,10 +15,6 @@ f /var/log/btmp 0600 root utmp -
d /var/cache/man - - - 30d
-r /forcefsck
-r /forcequotacheck
-r /fastboot
-
d /run/systemd/ask-password 0755 root root -
d /run/systemd/seats 0755 root root -
d /run/systemd/sessions 0755 root root -
Lennart
--
Lennart Poettering - Red Hat, Inc.
Continue reading on narkive:
Loading...