Re: [systemd-devel] failing boot start jobs delay reboot
Andrei Borzenkov composed on 2015-01-20 06:35 (UTC+0300): > Mon, 19 Jan 2015 17:59:41 -0500 Felix Miata composed: >> Has anything been done in more recent releases about this? I do a lot of >> cloning, and sometimes produce typos on grub cmdlines and fstab lines. This >> produces long delays in init followed by emergency mode when the >> non-essential mount fails and fstab for that device does not include the >> nofail option. When I recognize early in init that I have made a fstab typo, >> I try to CAD to choose another boot choice that isn't broken and fix the >> typo, but that produces yet another start job wait for the same broken job, >> often followed by a gazillion failed to save sound card state messages from >> holding down CAD. >> openSUSEes, Mageias & Fedoras (including Factories, Cauldrons & Rawhides) >> comprise most of my installations subject to these self-inflicted delays that >> I can't recall being a problem with sysvinit. > "Self inflicted delays" during boot or during Ctrl-Alt-Del? Both. When they occur during init they repeat during shutdown. Even when I let init complete and succeed to fix the typo or oversight, the init failure gets remembered and repeated at shutdown. Often the start job is on account of a volume label that has been replaced, usually along with a UUID, because the clone is a partition on the same HD. Fedora is particularly frustrating by embedding dependent root volume label and not obeying root= on cmdline (openSUSE obeys root=). Those typos usually have to be fixed by chroot to run dracut. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] failing boot start jobs delay reboot
В Mon, 19 Jan 2015 17:59:41 -0500 Felix Miata пишет: > Has anything been done in more recent releases about this? I do a lot of > cloning, and sometimes produce typos on grub cmdlines and fstab lines. This > produces long delays in init followed by emergency mode when the > non-essential mount fails and fstab for that device does not include the > nofail option. When I recognize early in init that I have made a fstab typo, > I try to CAD to choose another boot choice that isn't broken and fix the > typo, but that produces yet another start job wait for the same broken job, > often followed by a gazillion failed to save sound card state messages from > holding down CAD. > > openSUSEes, Mageias & Fedoras (including Factories, Cauldrons & Rawhides) > comprise most of my installations subject to these self-inflicted delays that > I can't recall being a problem with sysvinit. "Self inflicted delays" during boot or during Ctrl-Alt-Del? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] failing boot start jobs delay reboot
Has anything been done in more recent releases about this? I do a lot of cloning, and sometimes produce typos on grub cmdlines and fstab lines. This produces long delays in init followed by emergency mode when the non-essential mount fails and fstab for that device does not include the nofail option. When I recognize early in init that I have made a fstab typo, I try to CAD to choose another boot choice that isn't broken and fix the typo, but that produces yet another start job wait for the same broken job, often followed by a gazillion failed to save sound card state messages from holding down CAD. openSUSEes, Mageias & Fedoras (including Factories, Cauldrons & Rawhides) comprise most of my installations subject to these self-inflicted delays that I can't recall being a problem with sysvinit. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] persisting sriov_numvfs
On 01/19/2015 09:57 PM, Dan Kenigsberg wrote: On Mon, Jan 19, 2015 at 04:51:48PM +, "Jóhann B. Guðmundsson" wrote: On 01/19/2015 02:18 PM, Dan Kenigsberg wrote: How should this be implemented in the realm of systemd? I would think via udev rule + systemd-networkd Could you elaborate your idea? Do you suggest adding a udev rule to take effect when enp2s0f0 is brought to life? Right I was thinking something along Li Dongyang patch [¹] Bottom line udev handles the low-level settings of network interfaces while systemd-networkd replaces the legacy network initscript and handles the setup of basic or more complex network settings (static IP/dhcp, bridge,vlan, veth..) for containers/virtualzation. Any tweaks beyond that is just conf snippets in modprobe.d/sysctl.d I suggest if you guys are not up to speed to take a trip, grap a beer and attend Tom's talk and the network track at fosdem [2] JBG 1. http://www.spinics.net/lists/hotplug/msg05082.html 2. https://fosdem.org/2015/schedule/track/network_management_and_sdn/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] persisting sriov_numvfs
On Mon, Jan 19, 2015 at 04:51:48PM +, "Jóhann B. Guðmundsson" wrote: > > On 01/19/2015 02:18 PM, Dan Kenigsberg wrote: > >How should this be implemented in the realm of systemd? > > I would think via udev rule + systemd-networkd Could you elaborate your idea? Do you suggest adding a udev rule to take effect when enp2s0f0 is brought to life? But where does networkd comes into play? Please also note that my own trouble stems from networking, but the need to persist sriov_numvfs may come up on storage of graphics devices, too. > > What are ovirt's plan regarding systemd-networkd support/integration? There are no immediate plans to use networkd to configure networking on the host. We are still using legacy ifcfg by default. However we now have a modular design that lets us use something more modern when the need arises. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to speed up journalctl -n foo ?
Is there something else I can do to help you figure out how to fix this problem? Do you have a system with lots of logs to test on yourself? There is at least one Fedora/Redhat bug that is similar, but seems it was opened a long time ago and not much came of it. Thanks, Ben On 01/14/2015 10:50 AM, Ben Greear wrote: > On 01/14/2015 10:42 AM, Matthias Urlichs wrote: >> Hi, >> >> Ben Greear: real 0m25.618s user 0m2.361s sys0m23.197s >> Something seems broken here. Do you have any old and/or inconsistent >> journal files lying around? >> >>> [root@ath9k-f ~]# time tail -2000 /var/log/messages > /tmp/foo.txt >>> >>> real0m0.005s >>> user0m0.002s >>> sys 0m0.003s >>> >> To be fair, journalctl is of course slower if you don't filter for >> anything -- but the -nX case should be fast enough anyway. >> >> $ time journalctl -n 2000 > /tmp/foo.txt >> >> real 0m0.068s >> user 0m0.056s >> sys 0m0.008s > > I have lots of files, no idea if they are inconsistent or not: > > I am running with lots of debug info in a driver I'm debugging..that is why > there are lots of files..but hopefully journalctl would just look at the last > part of the last file > with the -n foo option? > > > [root@ath10k ~]# ls -l /var/log/journal/bf26e8cfb1544f5cae11ee07464e3f59/ > total 12665456 > -rwxr-xr-x+ 1 root systemd-journal 75497472 Jan 13 13:36 > system@00050c8f68f46127-cd71aa162eaa71ab.journal~ > -rwxr-xr-x+ 1 root systemd-journal 33554432 Jan 13 13:40 > system@00050c8f78c613a7-a7087b0b63534b7c.journal~ > -rwxr-xr-x+ 1 root systemd-journal 92274688 Jan 13 13:55 > system@23dff71cb596433388d8160b4f1bc213-0001-00050c8f78215de4.journal > -rwxr-xr-x+ 1 root systemd-journal 92274688 Jan 13 14:08 > system@23dff71cb596433388d8160b4f1bc213-000249aa-00050c8fadfb17c6.journal > -rwxr-xr-x+ 1 root systemd-journal 92274688 Jan 13 14:23 > system@23dff71cb596433388d8160b4f1bc213-00049dca-00050c8fddea9cb6.journal > -rwxr-xr-x+ 1 root systemd-journal 92274688 Jan 13 14:38 > system@23dff71cb596433388d8160b4f1bc213-0006f6a8-00050c90129c0d6f.journal > -rwxr-xr-x+ 1 root systemd-journal 92274688 Jan 13 14:55 > system@23dff71cb596433388d8160b4f1bc213-00093081-00050c904975f80d.journal > -rwxr-xr-x+ 1 root systemd-journal 92274688 Jan 13 15:10 > system@23dff71cb596433388d8160b4f1bc213-000b8fec-00050c9086a611d8.journal > -rwxr-xr-x+ 1 root systemd-journal 92274688 Jan 13 15:25 > system@23dff71cb596433388d8160b4f1bc213-000de8b1-00050c90bb19dec5.journal > -rwxr-xr-x+ 1 root systemd-journal 92274688 Jan 13 15:44 > system@23dff71cb596433388d8160b4f1bc213-00103f7c-00050c90f0ce3ab4.journal > -rwxr-xr-x+ 1 root systemd-journal 92274688 Jan 13 15:56 > system@23dff71cb596433388d8160b4f1bc213-001281ca-00050c913320dcf9.journal > -rwxr-xr-x+ 1 root systemd-journal 92274688 Jan 13 16:08 > system@23dff71cb596433388d8160b4f1bc213-0014e282-00050c915f764321.journal > -rwxr-xr-x+ 1 root systemd-journal 92274688 Jan 13 16:22 > system@23dff71cb596433388d8160b4f1bc213-00173c3f-00050c918bc65f87.journal > -rwxr-xr-x+ 1 root systemd-journal 92274688 Jan 13 16:35 > system@23dff71cb596433388d8160b4f1bc213-0019914e-00050c91bc2f5387.journal > -rwxr-xr-x+ 1 root systemd-journal 92274688 Jan 13 16:49 > system@23dff71cb596433388d8160b4f1bc213-001bf05f-00050c91e97a1175.journal > -rwxr-xr-x+ 1 root systemd-journal 92274688 Jan 13 17:03 > system@23dff71cb596433388d8160b4f1bc213-001e5234-00050c921baaa89d.journal > -rwxr-xr-x+ 1 root systemd-journal 92274688 Jan 13 17:13 > system@23dff71cb596433388d8160b4f1bc213-0020af61-00050c924de647df.journal > -rwxr-xr-x+ 1 root systemd-journal 92274688 Jan 13 17:24 > system@23dff71cb596433388d8160b4f1bc213-0023039f-00050c92734ba48b.journal > -rwxr-xr-x+ 1 root systemd-journal 92274688 Jan 13 17:35 > system@23dff71cb596433388d8160b4f1bc213-0025575b-00050c929a1d123a.journal > -rwxr-xr-x+ 1 root systemd-journal 92274688 Jan 13 17:46 > system@23dff71cb596433388d8160b4f1bc213-0027ab47-00050c92bfa64c20.journal > -rwxr-xr-x+ 1 root systemd-journal 92274688 Jan 13 17:57 > system@23dff71cb596433388d8160b4f1bc213-002a0f4e-00050c92e8f6fa3d.journal > -rwxr-xr-x+ 1 root systemd-journal 92274688 Jan 13 18:06 > system@23dff71cb596433388d8160b4f1bc213-002c754a-00050c9310915f0a.journal > -rwxr-xr-x+ 1 root systemd-journal 92274688 Jan 13 18:14 > system@23dff71cb596433388d8160b4f1bc213-002eafed-00050c932f956aaf.journal > -rwxr-xr-x+ 1 root systemd-journal 92274688 Jan 13 18:26 > system@23dff71cb596433388d8160b4f1bc213-003104bb-00050c934da956dc.journal > -rwxr-xr-x+ 1 root systemd-journal 92274688 Jan 13 18:38 > system@23dff71cb596433388d8160b4f1bc213-0033674c-00050c9378f9952e.journal > -rwxr-xr-x+ 1 root systemd-journal 92274688 Jan 13 18:50 > system@23dff71cb596433388d8160b4f1bc213-0035cdc0-0
Re: [systemd-devel] systemd build process, stripped ELF flags (MIPS)
On Mon, Jan 19, 2015 at 3:14 PM, Lennart Poettering wrote: > On Mon, 19.01.15 09:47, Manuel Lauss (manuel.la...@gmail.com) wrote: > >> Can anyone please point out why the .MIPS.abiflags sections are >> omitted entirely? >> I've tried to build with STRIP=/bin/true but that didn't help, and I don't >> know >> enough about the build process to fix it myself. > > Maybe the MIPS toolchain strips these if --gc-sections is passed to > LD, which we do? Turned out to be something completely different: systemd tries to us gold as the default linked. gold on mips isn't really quite usable yet; after removing the ld.gold binary systemd now has the necessary abiflags. Thanks! Manuiel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Docker vs PrivateTmp
On Mon, Jan 19, 2015 at 08:54:52PM +0300, Andrei Borzenkov wrote:
> > What is causing this behavior? I have tried to replicate it by hand through
> > a
> > combination of mount and unshare, and the only way I can get a mount to
> > persist
> > in the unshare namespace after being unmounted in the global namespace is by
> > explicitly calling mount `--make-rprivate /` *inside* the unshare
> > namespace, which
> > is obviously not happening in the above Docker example.
> >
>
> It obviously happens. Your mount is private (it does not have any of
> shared/master/.. flags). May be docker does it?
I think you may not have read the above correctly...with the Docker
exmaple, I am never explicitly using "--make-rprivate" in the child
mount namespace that I create with 'unshare'.
Docker may indeed be creating private mounts, but I can't replicate
that behavior myself doing something like:
global# mount --make-private /dev/testvol /mnt
In this case, if I create a new namespace with 'unshare -m', I see:
unshar# grep testvol /proc/self/mountinfo
860 749 253:16 / /mnt rw,relatime - ext4 /dev/mapper/fedora-testvol
rw,seclabel,data=ordered
And if I unmount the filesystem from the global namespace:
global# umount /mnt
It disappears from the "unshare" namespace as well:
unshare# grep testvol /proc/self/mountinfo
unshare#
If you can produce a sequence that replicates the behavior I'm seeing
with docker using just 'mount' and 'unshare' that would help
tremendously, because I'm still not entirely sure how we end up in
this state.
--
Lars Kellogg-Stedman | larsks @ {freenode,twitter,github}
Cloud Engineering / OpenStack | http://blog.oddbit.com/
pgpDxjun8R0RR.pgp
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Docker vs PrivateTmp
В Mon, 19 Jan 2015 11:33:42 -0500
Lars Kellogg-Stedman пишет:
> On Sat, Jan 17, 2015 at 11:02:01PM -0500, Lars Kellogg-Stedman wrote:
> > The TL;DR is that restarting a service with PrivateTmp=true appears to
> > preserve references to any mounts in the parent mount namespace that
> > were active at the time the service was started. If these mounts are
> > later unmounted in the parent namespace, the reference persists in the
> > child mount namespace, which means among other things that the
> > mountpoint cannot be deleted ("Device or resource busy")...
>
> While I think we've probably identified the solution, I'm still trying
> to understand how we get into this situation in the first place.
>
> With neither `MountFlags` nor `PrivateTmp` specified in my docker.service,
> starting a container results in the following mount visible in the global
> mount
> namespace:
>
> global# grep /mnt /proc/self/mountinfo
> 685 433 253:22 /
> /var/lib/docker/devicemapper/mnt/297bf7ae64bd5cf552b45b098b22df85a49deeadb2d71b330e2f866dac95a448
> rw,relatime - ext4
> /dev/mapper/docker-253:6-98310-297bf7ae64bd5cf552b45b098b22df85a49deeadb2d71b330e2f866dac95a448
>
> rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c138,c268",discard,stripe=16,data=ordered
>
> If I create a new mount namespace (as a child of the global namespace) with
> `unshare -m`, I can as expected see the same mount:
>
> unshare# grep /mnt /proc/self/mountinfo
> 805 804 253:22 /
> /var/lib/docker/devicemapper/mnt/297bf7ae64bd5cf552b45b098b22df85a49deeadb2d71b330e2f866dac95a448
> rw,relatime - ext4
> /dev/mapper/docker-253:6-98310-297bf7ae64bd5cf552b45b098b22df85a49deeadb2d71b330e2f866dac95a448
>
> rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c138,c268",discard,stripe=16,data=ordered
>
> If I attempt to stop that container, the mount disappears from the global
> namespace:
>
> global# grep /mnt /proc/self/mountinfo
> global#
>
> But is still visible in the mount namespace I created with unshare:
>
> unshare# grep /mnt /proc/self/mountinfo
> 805 804 253:22 /
> /var/lib/docker/devicemapper/mnt/297bf7ae64bd5cf552b45b098b22df85a49deeadb2d71b330e2f866dac95a448
> rw,relatime - ext4
> /dev/mapper/docker-253:6-98310-297bf7ae64bd5cf552b45b098b22df85a49deeadb2d71b330e2f866dac95a448
>
> rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c138,c268",discard,stripe=16,data=ordered
>
> What is causing this behavior? I have tried to replicate it by hand through a
> combination of mount and unshare, and the only way I can get a mount to
> persist
> in the unshare namespace after being unmounted in the global namespace is by
> explicitly calling mount `--make-rprivate /` *inside* the unshare namespace,
> which
> is obviously not happening in the above Docker example.
>
It obviously happens. Your mount is private (it does not have any of
shared/master/.. flags). May be docker does it?
pgpZ4nCiXQPVT.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timedated: support split usr v3
On Sun, Jan 18, 2015 at 12:52 PM, Kay Sievers wrote:
> On Sun, Jan 18, 2015 at 7:53 PM, Shawn Landden
> wrote:
> > From: Shawn Paul Landden
> >
> > The current Debian solution to this is really ugly, and I would rather
> > have them use the correct patch even if split usr is dumb.
>
> Please keep this local to the distro, this is no upstream material.
> /etc/timezon is redundant information in a separate file. We do not
> want to support this thing in systemd.
>
> The split /usr support is pretty much limited to locations of files,
> but should not change fundamental logic or introduce new concepts or
> config files.
>
> While I have no problem with this position as I support unified usr,
realize that without this timedated does not support split usr, and systemd
be clear about this in the "split-usr-is-broken" warning/essay.
> Thanks,
> Kay
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
--
Shawn Landden
From 0f0d2f6b3e295c8d67a689e48b23188a027ce6b3 Mon Sep 17 00:00:00 2001
From: Shawn Paul Landden
Date: Sun, 21 Dec 2014 23:00:01 -0800
Subject: [PATCH] timedated: support split usr v3
The current Debian solution to this is really ugly, and I would rather
have them use the correct patch even if split usr is dumb.
Read: http://rusty.ozlabs.org/?p=236
("Why Everyone Must Oppose The Merging of /usr and /")
(I managed to skip the pulseaudio implamentation mess because I
had a fancy emu10k1 SoundBlaster Live! 5.1 which does its own
hardware mixing.)
Putting the reading of /etc/timezone inside #ifdef CONFIG_SPLIT_USR
assumes a system with never go from NORMAL_USR to SPLIT_USR
v3: revert 99f861310d3f05f4
v4: was missing a git add
---
src/timedate/timedated.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
index 753c3d1..7f748df 100644
--- a/src/timedate/timedated.c
+++ b/src/timedate/timedated.c
@@ -29,6 +29,7 @@
#include "sd-bus.h"
#include "util.h"
+#include "copy.h"
#include "strv.h"
#include "def.h"
#include "clock-util.h"
@@ -95,6 +96,14 @@ static int context_read_data(Context *c) {
}
}
+#ifdef HAVE_SPLIT_USR
+r = read_one_line_file("/etc/timezone", &c->zone);
+if (r < 0) {
+if (r != -ENOENT)
+log_warning("Failed to read /etc/timezone: %s", strerror(-r));
+}
+#endif
+
have_timezone:
if (isempty(c->zone)) {
free(c->zone);
@@ -123,9 +132,21 @@ static int context_write_data_timezone(Context *c) {
if (!p)
return log_oom();
+#ifdef HAVE_SPLIT_USR
+r = write_string_file_atomic("/etc/timezone", c->zone);
+if (r < 0)
+return r;
+
+ /* "/usr/sha..." */
+r = copy_file((p + 2), "/etc/localtime", O_TRUNC,
+S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH, 0); /*644*/
+if (r < 0)
+return r;
+#else
r = symlink_atomic(p, "/etc/localtime");
if (r < 0)
return r;
+#endif
return 0;
}
--
2.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 05/11] tmpfiles: add 'a' type to set ACLs
On Mon, Jan 19, 2015 at 12:07:16PM -0500, Chris Atkinson wrote: > s/aditional/additional/ Thanks. It is fixed by one of the later patches fortunately. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 05/11] tmpfiles: add 'a' type to set ACLs
s/aditional/additional/ Regards, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] persisting sriov_numvfs
On 01/19/2015 02:18 PM, Dan Kenigsberg wrote: How should this be implemented in the realm of systemd? I would think via udev rule + systemd-networkd What are ovirt's plan regarding systemd-networkd support/integration? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Docker vs PrivateTmp
On Sat, Jan 17, 2015 at 11:02:01PM -0500, Lars Kellogg-Stedman wrote:
> The TL;DR is that restarting a service with PrivateTmp=true appears to
> preserve references to any mounts in the parent mount namespace that
> were active at the time the service was started. If these mounts are
> later unmounted in the parent namespace, the reference persists in the
> child mount namespace, which means among other things that the
> mountpoint cannot be deleted ("Device or resource busy")...
While I think we've probably identified the solution, I'm still trying
to understand how we get into this situation in the first place.
With neither `MountFlags` nor `PrivateTmp` specified in my docker.service,
starting a container results in the following mount visible in the global mount
namespace:
global# grep /mnt /proc/self/mountinfo
685 433 253:22 /
/var/lib/docker/devicemapper/mnt/297bf7ae64bd5cf552b45b098b22df85a49deeadb2d71b330e2f866dac95a448
rw,relatime - ext4
/dev/mapper/docker-253:6-98310-297bf7ae64bd5cf552b45b098b22df85a49deeadb2d71b330e2f866dac95a448
rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c138,c268",discard,stripe=16,data=ordered
If I create a new mount namespace (as a child of the global namespace) with
`unshare -m`, I can as expected see the same mount:
unshare# grep /mnt /proc/self/mountinfo
805 804 253:22 /
/var/lib/docker/devicemapper/mnt/297bf7ae64bd5cf552b45b098b22df85a49deeadb2d71b330e2f866dac95a448
rw,relatime - ext4
/dev/mapper/docker-253:6-98310-297bf7ae64bd5cf552b45b098b22df85a49deeadb2d71b330e2f866dac95a448
rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c138,c268",discard,stripe=16,data=ordered
If I attempt to stop that container, the mount disappears from the global
namespace:
global# grep /mnt /proc/self/mountinfo
global#
But is still visible in the mount namespace I created with unshare:
unshare# grep /mnt /proc/self/mountinfo
805 804 253:22 /
/var/lib/docker/devicemapper/mnt/297bf7ae64bd5cf552b45b098b22df85a49deeadb2d71b330e2f866dac95a448
rw,relatime - ext4
/dev/mapper/docker-253:6-98310-297bf7ae64bd5cf552b45b098b22df85a49deeadb2d71b330e2f866dac95a448
rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c138,c268",discard,stripe=16,data=ordered
What is causing this behavior? I have tried to replicate it by hand through a
combination of mount and unshare, and the only way I can get a mount to persist
in the unshare namespace after being unmounted in the global namespace is by
explicitly calling mount `--make-rprivate /` *inside* the unshare namespace,
which
is obviously not happening in the above Docker example.
Thanks,
--
Lars Kellogg-Stedman | larsks @ {freenode,twitter,github}
Cloud Engineering / OpenStack | http://blog.oddbit.com/
pgp717y6GE84v.pgp
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd build process, stripped ELF flags (MIPS)
El 19/01/15 a las 05:47, Manuel Lauss escribió: The systemd build process manages to create binaries without this .MIPS.abiflags section, and this leads the 3.18 kernel to refuse to load it: Nope, the build process does no such thing, your toolchain is buggy, wild guess is that --gc-sections does not know that section is mandatory and removes it. Please talk about this with binutils developers ;-) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Docker vs PrivateTmp
On 19/01/15 08:39 -0500, Daniel J Walsh wrote: On 01/19/2015 12:27 AM, Lars Kellogg-Stedman wrote: On Sun, Jan 18, 2015 at 11:38:12PM -0500, Lars Kellogg-Stedman wrote: I think we actually want MountFlags=slave, which will permit mounts from the global namespace to propagate into the service namespace without permitting propagation in the other direction. It seems like this would the Least Surprising behavior. ...which would be the default if docker.service were itself using PrivateTmp=true, because from systemd.exec: Note that the file system namespace related options (PrivateTmp=, PrivateDevices=, ProtectSystem=, ProtectHome=, ReadOnlyDirectories=, InaccessibleDirectories= and ReadWriteDirectories=) require that mount and unmount propagation from the unit's file system namespace is disabled, and hence downgrade shared to slave. So either explicitly setting MountFlags=slave, or setting PrivateTmp=true if that doesn't cause any issues of which I am not aware. Vincent what do you think about MountFlags=slave? 'slave' sounds like the correct subtree mount. We were targeting 'MountFlags' to make use of unsharing the mount namespace. vb pgpbxSgwQKy9E.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] persisting sriov_numvfs
Hello, list. I'm an http://oVirt.org developer, and we plan to (finally) support SR-IOV cards natively. Working on this feature, we've noticed that something is missing in the platform OS. If I maintain a host with sr-iov cards, I'd like to use the new kernel method of defining how many virtual functions (VFs) are to be exposed by each physical function: # echo 3 > /sys/class/net/enp2s0f0/device/sriov_numvfs This spawns 3 new devices, for which udev allocated (on my host) the names enp2s16, enp2s16f2 and enp2s16f4. I can attach these VFs to virtual machines, but I can also use them as yet another host NIC. Let's assume that I did the latter, and persisted its IP address using initscripts in /etc/sysconfig/network-scripts/ifcfg-enp2s16f4. However, on the next boot, sriov_numvfs is reset to 0, there's no device named enp2s16f4, and certainly no IP address asigned to it. The admin can solve his own private issue by writing a service to start after udev allocats device names but before network services kick in, and re-apply his "echo" there. But it feels like something that should be solved in a more generic fashion. It is also not limitted to network device. As similar issue would affect anything that attempts to refer to a VF by its name, and survive reboot. How should this be implemented in the realm of systemd? Regards, Dan. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd build process, stripped ELF flags (MIPS)
On Mon, 19.01.15 09:47, Manuel Lauss (manuel.la...@gmail.com) wrote: > Can anyone please point out why the .MIPS.abiflags sections are > omitted entirely? > I've tried to build with STRIP=/bin/true but that didn't help, and I don't > know > enough about the build process to fix it myself. Maybe the MIPS toolchain strips these if --gc-sections is passed to LD, which we do? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Docker vs PrivateTmp
On 01/19/2015 12:27 AM, Lars Kellogg-Stedman wrote: > On Sun, Jan 18, 2015 at 11:38:12PM -0500, Lars Kellogg-Stedman wrote: >> I think we actually want MountFlags=slave, which will permit mounts >> from the global namespace to propagate into the service namespace >> without permitting propagation in the other direction. It seems like >> this would the Least Surprising behavior. > ...which would be the default if docker.service were itself using > PrivateTmp=true, because from systemd.exec: > > Note that the file system namespace related options (PrivateTmp=, > PrivateDevices=, ProtectSystem=, ProtectHome=, ReadOnlyDirectories=, > InaccessibleDirectories= and ReadWriteDirectories=) require that mount > and unmount propagation from the unit's file system namespace is > disabled, and hence downgrade shared to slave. > > So either explicitly setting MountFlags=slave, or setting > PrivateTmp=true if that doesn't cause any issues of which I am not > aware. > > > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel Vincent what do you think about MountFlags=slave? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Assorted typo fixes
On Mon, Jan 19, 2015 at 2:26 PM, Djalal Harouni wrote: > Hi, > > On Mon, Jan 19, 2015 at 10:46:23AM +0100, Rémi Audebert wrote: > > Signed-off-by: Rémi Audebert > Your email is in base64 format, the following was set: > "Content-Transfer-Encoding: base64" > > Classic tools do not understand it and we have to decode in order to > inspect... please check this link [1] mutt and `git am` both understand it, what else does one need? :) -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Assorted typo fixes
On Mon, Jan 19, 2015 at 02:42:31PM +0200, Mantas Mikulėnas wrote: > On Mon, Jan 19, 2015 at 2:26 PM, Djalal Harouni wrote: > > > Hi, > > > > On Mon, Jan 19, 2015 at 10:46:23AM +0100, Rémi Audebert wrote: > > > Signed-off-by: Rémi Audebert > > Your email is in base64 format, the following was set: > > "Content-Transfer-Encoding: base64" > > > > Classic tools do not understand it and we have to decode in order to > > inspect... please check this link [1] > > > mutt and `git am` both understand it, what else does one need? :) yep :-) perhaps classic patch command ? and kernel checkpatch.pl ? on lkml base64 format is rejected... > -- > Mantas Mikulėnas -- Djalal Harouni http://opendz.org ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Assorted typo fixes
Hi,
On Mon, Jan 19, 2015 at 10:46:23AM +0100, Rémi Audebert wrote:
> Signed-off-by: Rémi Audebert
Your email is in base64 format, the following was set:
"Content-Transfer-Encoding: base64"
Classic tools do not understand it and we have to decode in order to
inspect... please check this link [1]
This one is clean and only touches doc, so patch applied, thanks!
[1] https://www.kernel.org/doc/Documentation/email-clients.txt
> ---
> kdbus.txt | 6 +++---
> match.c| 2 +-
> pool.c | 2 +-
> queue.c| 4 ++--
> test/kdbus-util.c | 2 +-
> test/test-connection.c | 4 ++--
> 6 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/kdbus.txt b/kdbus.txt
> index 2592a7e..b2392ea 100644
> --- a/kdbus.txt
> +++ b/kdbus.txt
> @@ -864,7 +864,7 @@ struct kdbus_msg {
>
> KDBUS_MSG_NO_AUTO_START
>By default, when a message is sent to an activator connection, the
> - activator notified and will start an implementer. This flag inhibits
> + activator is notified and will start an implementer. This flag inhibits
>that behavior. With this bit set, and the remote being an activator,
>-EADDRNOTAVAIL is returned from the ioctl.
>
> @@ -2010,7 +2010,7 @@ For KDBUS_CMD_NAME_ACQUIRE:
> For KDBUS_CMD_NAME_RELEASE:
>
>-EINVALInvalid command flags, or invalid name provided
> - -ESRCH Name is not found found in the registry
> + -ESRCH Name is not found in the registry
>-EADDRINUSEName is owned by a different connection and can't be
> released
>
> For KDBUS_CMD_NAME_LIST:
> @@ -2057,7 +2057,7 @@ For KDBUS_CMD_MATCH_REMOVE:
> This is a simplified outline of the internal kdbus object relations, for
> those interested in the inner life of the driver implementation.
>
> -From the a mount point's (domain's) perspective:
> +From a mount point's (domain's) perspective:
>
> struct kdbus_domain
>|» struct kdbus_domain_user *user (many, owned)
> diff --git a/match.c b/match.c
> index d4f2184..aae9a85 100644
> --- a/match.c
> +++ b/match.c
> @@ -356,7 +356,7 @@ static int kdbus_match_db_remove_unlocked(struct
> kdbus_match_db *mdb,
> * kdbus_notify_id_change
> *
> * For kdbus_notify_{id,name}_change structs, only the ID and name fields
> - * are looked at at when adding an entry. The flags are unused.
> + * are looked at when adding an entry. The flags are unused.
> *
> * Also note that KDBUS_ITEM_BLOOM_MASK, KDBUS_ITEM_NAME and KDBUS_ITEM_ID
> * are used to match messages from userspace, while the others apply to
> diff --git a/pool.c b/pool.c
> index 1fff68d..44667dd 100644
> --- a/pool.c
> +++ b/pool.c
> @@ -346,7 +346,7 @@ static void __kdbus_pool_slice_release(struct
> kdbus_pool_slice *slice)
>
> /**
> * kdbus_pool_slice_release() - drop kernel-reference on allocated slice
> - * @slice: Slice allocated from the the pool
> + * @slice: Slice allocated from the pool
> *
> * This releases the kernel-reference on the given slice. If the
> * kernel-reference and the user-reference on a slice are dropped, the slice
> is
> diff --git a/queue.c b/queue.c
> index 53ab51a..04e010b 100644
> --- a/queue.c
> +++ b/queue.c
> @@ -401,8 +401,8 @@ int kdbus_queue_entry_install(struct kdbus_queue_entry
> *entry,
> }
>
> /*
> - * The offsets stored in the slice are relative to the the start
> - * of the payload slice. When exporting them, they need to become
> + * The offsets stored in the slice are relative to the start of
> + * the payload slice. When exporting them, they need to become
>* relative to the pool, so get the payload slice's offset first.
>*/
> if (entry->slice_vecs)
> diff --git a/test/kdbus-util.c b/test/kdbus-util.c
> index 264d7ab..4a57c95 100644
> --- a/test/kdbus-util.c
> +++ b/test/kdbus-util.c
> @@ -1184,7 +1184,7 @@ int kdbus_name_list(struct kdbus_conn *conn, uint64_t
> flags)
> }
>
> kdbus_printf("%8llu flags=0x%08llx conn=0x%08llx '%s'\n",
> - name->owner_id, (unsigned long long )flags,
> + name->owner_id, (unsigned long long) flags,
>name->conn_flags, n);
> }
> kdbus_printf("\n");
> diff --git a/test/test-connection.c b/test/test-connection.c
> index db19b81..c2ae653 100644
> --- a/test/test-connection.c
> +++ b/test/test-connection.c
> @@ -75,8 +75,8 @@ int kdbus_test_hello(struct kdbus_test_env *env)
>
> /*
>* The connection created by the core requires ALL meta flags
> - * to be sent. An attempt to send less that that should result
> - * in -ECONNREFUSED.
> + * to be sent. An attempt to send less than that should result in
> + * -ECONNREFUSED.
>*/
> hello.attach_flags_send = _KDBUS_ATTACH_ALL & ~KDBUS_ATTACH_TIMESTAMP;
> ret = ioctl(fd, KDBUS_CMD_HELLO,
Re: [systemd-devel] Target updating status for dependencies
Hey Andrei, Andrei Borzenkov [2015-01-17 16:00 +0300]: > > | Requires=ifup@eth0.service > > | After=ifup@eth0.service > > After should be redundant here - Requires implies After for target. No, both are required in this case. If you just say Requires, then ifup@eth0.service will be started, but that unit won't wait for it to succeed. > > So far so good. But now I make eth42 appear (simulating server > > situations where network interfaces just take a while to init) [1]. > > This causes ifup@eth42.service to get re-triggered via systemd's udev > > rules, thus the status changes to "active (exited)", i. e. "success". > > > > However, this doesn't seem to cause re-evaluation of the depending > > units: After that, ifup-all-auto.target (and network-online.target) > > are still in the same "dependency failed" state. > > > > Calling "systemctl start ifup-all-auto.target" manually updates the > > status, but at least in this case this should obviously happen > > automatically. > > > > Is this not how dependencies are supposed to work? > > No. Dependencies really make sense and are evaluated only for the > running transaction and only between units that are part of running > transaction. "A Requires B" means - *if* A is being started, B mist > also be started. It never implied reverse dependency of any sort from B > to A. Yes of course, but that's what I'm doing here -- I have a service that has Requires/After=network-online.target (see systemd.special(7)). That service is pulled into boot with WantedBy=multi-user.target. I had expected that to start network-online.target and start once network-online.target started, not fail because network-online.target is waiting for one of its dependencies. So this "within one transaction" was the part that I didn't understand. > > If not, I suppose I > > rather need some active program in ifup-all-auto.target which waits > > for all expected interfaces to appear by itself? > > I guess it depends on end goal. You can disable timeout for your target > and it will wait indefinitely How would I do that? I experimented with JobTimeoutSec=, but it doesn't seem to make any difference wrt. waiting for dependencies to become active. > but then some other unit will likely timeout on startup anyway. You > do not really want to wait indefinitely during boot. And once boot > is over, what use this unit has? Of course these days the line where booting ends and usage starts is quite blurry, and so is the definition of network-online.target. I was told that on servers, initializing all network cards may take a while, so in our Ubuntu upstart world we modeled it so that we have a state "all network cards are up" which can take up to two minutes after boot. I need to provide an equivalent for that, and I thought the most appropriate place would be to delay network-online.target until all configured ifupdown interfaces appear. > > Or can I somehow > > cause the reverse dependencies of ifup@.service to re-trigger? I > > didn't see anything obvious in the manpages. > > > > You can simply add Wants=ifup-all-auto.target to ifup@.service but I > still do not see why - this does not make much sense outside booting > context. Oh, thanks for the hint! This indeed does what I need -- re-evaluate ifup-all-auto.target everytime an ifup@.service unit is triggered via udev. So this part is solved now, the part that's still outstanding is the above timeout for top-level services which depend on network-online.target. Obviously I don't want to enumerate all of those in the network-online.target unit. This is pretty much the same problem one level up.. (BTW: I'll try to eliminiate the intermediate ifup-all-auto.target and try to hook the ifup@.service instances directly into network-online.target in the generator; this was mostly just for experimentation.) Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Assorted typo fixes
Signed-off-by: Rémi Audebert
---
kdbus.txt | 6 +++---
match.c| 2 +-
pool.c | 2 +-
queue.c| 4 ++--
test/kdbus-util.c | 2 +-
test/test-connection.c | 4 ++--
6 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/kdbus.txt b/kdbus.txt
index 2592a7e..b2392ea 100644
--- a/kdbus.txt
+++ b/kdbus.txt
@@ -864,7 +864,7 @@ struct kdbus_msg {
KDBUS_MSG_NO_AUTO_START
By default, when a message is sent to an activator connection, the
- activator notified and will start an implementer. This flag inhibits
+ activator is notified and will start an implementer. This flag inhibits
that behavior. With this bit set, and the remote being an activator,
-EADDRNOTAVAIL is returned from the ioctl.
@@ -2010,7 +2010,7 @@ For KDBUS_CMD_NAME_ACQUIRE:
For KDBUS_CMD_NAME_RELEASE:
-EINVAL Invalid command flags, or invalid name provided
- -ESRCH Name is not found found in the registry
+ -ESRCH Name is not found in the registry
-EADDRINUSE Name is owned by a different connection and can't be released
For KDBUS_CMD_NAME_LIST:
@@ -2057,7 +2057,7 @@ For KDBUS_CMD_MATCH_REMOVE:
This is a simplified outline of the internal kdbus object relations, for
those interested in the inner life of the driver implementation.
-From the a mount point's (domain's) perspective:
+From a mount point's (domain's) perspective:
struct kdbus_domain
|» struct kdbus_domain_user *user (many, owned)
diff --git a/match.c b/match.c
index d4f2184..aae9a85 100644
--- a/match.c
+++ b/match.c
@@ -356,7 +356,7 @@ static int kdbus_match_db_remove_unlocked(struct
kdbus_match_db *mdb,
* kdbus_notify_id_change
*
* For kdbus_notify_{id,name}_change structs, only the ID and name fields
- * are looked at at when adding an entry. The flags are unused.
+ * are looked at when adding an entry. The flags are unused.
*
* Also note that KDBUS_ITEM_BLOOM_MASK, KDBUS_ITEM_NAME and KDBUS_ITEM_ID
* are used to match messages from userspace, while the others apply to
diff --git a/pool.c b/pool.c
index 1fff68d..44667dd 100644
--- a/pool.c
+++ b/pool.c
@@ -346,7 +346,7 @@ static void __kdbus_pool_slice_release(struct
kdbus_pool_slice *slice)
/**
* kdbus_pool_slice_release() - drop kernel-reference on allocated slice
- * @slice: Slice allocated from the the pool
+ * @slice: Slice allocated from the pool
*
* This releases the kernel-reference on the given slice. If the
* kernel-reference and the user-reference on a slice are dropped, the slice is
diff --git a/queue.c b/queue.c
index 53ab51a..04e010b 100644
--- a/queue.c
+++ b/queue.c
@@ -401,8 +401,8 @@ int kdbus_queue_entry_install(struct kdbus_queue_entry
*entry,
}
/*
-* The offsets stored in the slice are relative to the the start
-* of the payload slice. When exporting them, they need to become
+* The offsets stored in the slice are relative to the start of
+* the payload slice. When exporting them, they need to become
* relative to the pool, so get the payload slice's offset first.
*/
if (entry->slice_vecs)
diff --git a/test/kdbus-util.c b/test/kdbus-util.c
index 264d7ab..4a57c95 100644
--- a/test/kdbus-util.c
+++ b/test/kdbus-util.c
@@ -1184,7 +1184,7 @@ int kdbus_name_list(struct kdbus_conn *conn, uint64_t
flags)
}
kdbus_printf("%8llu flags=0x%08llx conn=0x%08llx '%s'\n",
-name->owner_id, (unsigned long long )flags,
+name->owner_id, (unsigned long long) flags,
name->conn_flags, n);
}
kdbus_printf("\n");
diff --git a/test/test-connection.c b/test/test-connection.c
index db19b81..c2ae653 100644
--- a/test/test-connection.c
+++ b/test/test-connection.c
@@ -75,8 +75,8 @@ int kdbus_test_hello(struct kdbus_test_env *env)
/*
* The connection created by the core requires ALL meta flags
-* to be sent. An attempt to send less that that should result
-* in -ECONNREFUSED.
+* to be sent. An attempt to send less than that should result in
+* -ECONNREFUSED.
*/
hello.attach_flags_send = _KDBUS_ATTACH_ALL & ~KDBUS_ATTACH_TIMESTAMP;
ret = ioctl(fd, KDBUS_CMD_HELLO, &hello);
--
2.2.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd build process, stripped ELF flags (MIPS)
Hello, MIPS Linux recently introduced updates to its FPU ABI, and for that to work correctly, ELF binaries now have to have a ".MIPS.abiflags" section. This is an example binary built with binutils 2.25+: readelf -hl /lib/libc.so.6 [...] Section to Segment mapping: Segment Sections... 00 01 .interp 02 .MIPS.abiflags [...] Newer MIPS kernels will refuse to load binaries and libs which have mismatched values in .MIPS.abiflags or of one of the involved binaries has .MIPS.abiflags missing (a patch to linux has been posted to relax that though). The systemd build process manages to create binaries without this .MIPS.abiflags section, and this leads the 3.18 kernel to refuse to load it: Failed to execute /usr/lib/systemd/systemd (error -84). Attempting default readelf -hl /usr/lib/systemd/systemd [...] Section to Segment mapping: Segment Sections... 00 01 .interp 02 .interp .note.ABI-tag .dynsym .dynstr .hash .gnu.version .gnu.version_r .rel.dyn .init .text .fini .rodata .eh_frame .eh_frame_hdr 03 .tdata .data.rel.ro.local .jcr .fini_array .init_array .data.rel.ro .dynamic .tm_clone_table .sdata .data BUS_ERROR_MAP .got .bss 04 05 .dynamic 06 .note.ABI-tag 07 .eh_frame_hdr 08 .tdata .tbss 09 .tdata .data.rel.ro.local .jcr .fini_array .init_array .data.rel.ro .dynamic Can anyone please point out why the .MIPS.abiflags sections are omitted entirely? I've tried to build with STRIP=/bin/true but that didn't help, and I don't know enough about the build process to fix it myself. Thanks! Manuel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
