Re: [systemd-devel] Too little information is shown when system enters emergency mode
On Sun, Oct 21, 2012 at 03:13:22PM +0200, Frederic Crozat wrote: Le dimanche 21 octobre 2012 à 15:59 +0400, Andrey Borzenkov a écrit : This issue comes up relatively often on openSUSE forums. Users complaint that when system drops in emergency, there is nothing that would explain user why it happened or what to do. Typical situation is https://bugzilla.novell.com/show_bug.cgi?id=782904. openSUSE by default is using splash quiet kernel parameter. So the first issue is, interpretation of quite changed in systemd. Now it means suppress all output of systemd services. As result we have the following (even without boot splash involved) when some device in fstab is missing: doing fast boot Creating device nodes with udev Waiting for device /dev/root to appear: ok fsck from util-linux 2.21.2 [/sbin/fsck.ext4 (1) -- /] fsck.ext4 -a /dev/sda6 /dev/sda6: clean, 31805/705744 files, 344231/2819584 blocks fsck succeeded. Mounting root device read-write. Mounting root /dev/root mount -o rw,acl,user_xattr -t ext4 /dev/root /root [ 10.706463] piix4_smbus :00:07.3: SMBus base address uninitialized - upgrade BIOS or use force_addr=0xaddr Welcome to emergency mode. Use systemctl default or ^D to enter default mode. Give root password for login: This is literally everything that user sees on console. My first reaction was to add systemctl --failed as pre-exec to emergency. Unfortunately: linux-q652:~ # systemctl --no-pager --failed UNIT LOAD ACTIVE SUB JOB DESCRIPTION LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB= The low-level unit activation state, values depend on unit type. JOB= Pending job for the unit. 0 units listed. Pass --all to see inactive units, too. Everything is fine. This is understandable - we are now in different transaction and as far as I understand, systemctl --failed shows only results of currently active transaction (am I right?). Only when quiet is turned off, do I really see something (again - assuming we do not have bootsplash ...) Started /boot/efi [ OK ] Dependency failed. Aborted start of /mnt [ ABORT] Dependency failed. Aborted start of Login Service [ ABORT] Dependency failed. Aborted start of D-Bus System Message Bus [ ABORT] Welcome to emergency mode. Use systemctl default or ^D to enter default mode. So right now if anything goes extremely wrong we have baffled user sitting before emergency mode prompt and not knowing what to do next. Is it considered a problem by someone else? Would it be feasible to turn off quiet and bootsplash immediately after any unit failed during system boot? Please note the version of systemd (v44) in openSUSE doesn't have all the needed bits to always display on the screen why dependency failed (and you end up in emergency mode). This is fixed with systemd 195 which should land in Factory pretty soon. As an experiment, I tried the same (add '/dev/sda9 /mnt' to /etc/fstab) under v194-138-g20f59e4, i.e. very recent. After rebooting all I see is the emergency mode prompt. Now the problem is that 'dev-sda9.device' is loaded inactive(dead). This means that it doesn't show up in --failed. So 'systemctl' with various options doesn't show what failed in an easy to recognize way. OTOH 'journalctl -b' is immensly useful: red Timed out waiting for device dev-disk-by\x2duuid\x5cx2fdev\x5cx2fsda9.device. Dependency failed for /mnt. Dependency failed for Local File Systemds. ... /red This is great, and it would be really nice to expose it more. I guess that the first change would be to advertise 'journalctl -b' in the emergency mode intro. Would be nice to also un-eescape the device name: Timed out waiting for device /dev/sda9 should be much more understandable for the non-systemd-knowledgable person than Timed out waiting for device dev-disk-by\x2duuid\x5cx2fdev\x5cx2fsda9.device. But it would be best to provide a short status like: systemd was trying to reach target 'default.target' (which points to 'Multi-User', multi-user.target), but failed, because device /dev/sda9 is missing (dev-disk-by\x2duuid\x5cx2fdev\x5cx2fsda9.device). in turn this caused '/mnt' mount to fail (mnt.mount), in turn this caused 'Local File Systems' target to fail (local-fs.target), ... in turn this caused 'Multi User' target to fail (multi-user.target). And a hint how to e.g. temporarily disable the failing mount point. I admit that I'm not sure what is the proper way, short of editing /etc/fstab and rebooting. Would be nice if this output could be easily retrieved again. If the user starts looking at the system, and then forgets what exactly failed, he or she should be able to repeat this short diagnosis. However,
[systemd-devel] [PATCH] vlan: set sysfs device_type to 'vlan'
Sets the sysfs device_type to 'vlan' for udev. This makes it easier for
applications that query network information via udev to identify vlans
instead of using strrchr().
Signed-off-by: Doug Goldstein car...@cardoe.com
---
Pre-patch output:
swanson ~ # udevadm info -q all -p /sys/devices/virtual/net/br0.4
P: /devices/virtual/net/br0.4
E: UDEV_LOG=3
E: DEVPATH=/devices/virtual/net/br0.4
E: INTERFACE=br0.4
E: IFINDEX=6
E: SUBSYSTEM=net
Post-patch output:
swanson ~ # udevadm info -q all -p /sys/devices/virtual/net/br0.4
P: /devices/virtual/net/br0.4
E: UDEV_LOG=3
E: DEVPATH=/devices/virtual/net/br0.4
E: DEVTYPE=vlan
E: INTERFACE=br0.4
E: IFINDEX=12
E: SUBSYSTEM=net
The intent was to match other virtual network types such as bridges.
swanson ~ # udevadm info -q all -p /sys/devices/virtual/net/br0
P: /devices/virtual/net/br0
E: UDEV_LOG=3
E: DEVPATH=/devices/virtual/net/br0
E: DEVTYPE=bridge
E: INTERFACE=br0
E: IFINDEX=5
E: SUBSYSTEM=net
---
net/8021q/vlan_dev.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index 4024424..78a8744 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -531,6 +531,10 @@ static const struct header_ops vlan_header_ops = {
.parse = eth_header_parse,
};
+static struct device_type vlan_type = {
+ .name = vlan,
+};
+
static const struct net_device_ops vlan_netdev_ops;
static int vlan_dev_init(struct net_device *dev)
@@ -579,6 +583,8 @@ static int vlan_dev_init(struct net_device *dev)
dev-netdev_ops = vlan_netdev_ops;
+ SET_NETDEV_DEVTYPE(dev, vlan_type);
+
if (is_vlan_dev(real_dev))
subclass = 1;
--
1.7.8.6
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Lxc-users] Unable to run systemd in an LXC / cgroup container.
On Mon, 2012-10-22 at 09:06 +0100, John wrote: On 22/10/12 03:06, Michael H. Warfield wrote: On Mon, 2012-10-22 at 02:53 +0200, Kay Sievers wrote: On Sun, Oct 21, 2012 at 11:25 PM, Michael H. Warfield m...@wittsend.com wrote: This is being directed to the systemd-devel community but I'm cc'ing the lxc-users community and the Fedora community on this for their input as well. I know it's not always good to cross post between multiple lists but this is of interest to all three communities who may have valuable input. I'm new to this particular list, just having joined after tracking a problem down to some systemd internals... Several people over the last year or two on the lxc-users list have been discussions trying to run certain distros (notably Fedora 16 and above, recent Arch Linux and possibly others) in LXC containers, virualizing entire servers this way. This is very similar to Virtuoso / OpenVZ only it's using the native Linux cgroups for the containers (primary reason I dumped OpenVZ was to avoid their custom patched kernels). These recent distros have switched to systemd for the main init process and this has proven to be disastrous for those of us using LXC and trying to install or update our containers. To put it bluntly, it doesn't work and causes all sorts of problems on the host. To summarize the problem... The LXC startup binary sets up various things for /dev and /dev/pts for the container to run properly and this works perfectly fine for SystemV start-up scripts and/or Upstart. Unfortunately, systemd has mounts of devtmpfs on /dev and devpts on /dev/pts which then break things horribly. This is because the kernel currently lacks namespaces for devices and won't for some time to come (in design). When devtmpfs gets mounted over top of /dev in the container, it then hijacks the hosts console tty and several other devices which had been set up through bind mounts by LXC and should have been LEFT ALONE. Yes! I recognize that this problem with devtmpfs and lack of namespaces is a potential security problem anyways that could (and does) cause serious container-to-host problems. We're just not going to get that fixed right away in the linux cgroups and namespaces. How do we work around this problem in systemd where it has hard coded mounts in the binary that we can't override or configure? Or is it there and I'm just missing it trying to examine the sources? That's how I found where the problem lay. As a first step, this probably explains most of it: http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface A very long ways, yeah. That looks like it could be just what we've been looking for. Just gotta figure out how to set that environment variable but that's up to a couple of others to comment on in the lxc-users list. Then we'll see where we go from there. Many thanks! Kay Regards, Mike I've just performed a very quick check on my Arch Linux system here. on host (running systemd): # cat /proc/1/environ TERM=linuxRD_TIMESTAMP= In a container (running sysvinit): # cat /proc/1/environ STY=623.systemd-lithiumTERM=screenTERMCAP=SC|screen|VT 100/ANSI X3.64 virtual terminal:\ :DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:bs:bt=\E[Z:\ :cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:ct=\E[3g:\ :do=^J:nd=\E[C:pt:rc=\E8:rs=\Ec:sc=\E7:st=\EH:up=\EM:\ :le=^H:bl=^G:cr=^M:it#8:ho=\E[H:nw=\EE:ta=^I:is=\E)0:\ :li#24:co#80:am:xn:xv:LP:sr=\EM:al=\E[L:AL=\E[%dL:\ :cs=\E[%i%d;%dr:dl=\E[M:DL=\E[%dM:dc=\E[P:DC=\E[%dP:\ :im=\E[4h:ei=\E[4l:mi:IC=\E[%d@:ks=\E[?1h\E=:\ :ke=\E[?1l\E:vi=\E[?25l:ve=\E[34h\E[?25h:vs=\E[34l:\ :ti=\E[?1049h:te=\E[?1049l:k0=\E[10~:k1=\EOP:k2=\EOQ:\ :k3=\EOR:k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E[18~:\ :k8=\E[19~:k9=\E[20~:k;=\E[21~:F1=\E[23~:F2=\E[24~:\ :kh=\E[1~:@1=\E[1~:kH=\E[4~:@7=\E[4~:kN=\E[6~:kP=\E[5~:\ :kI=\E[2~:kD=\E[3~:ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:WINDOW=0SHELL=/bin/shPATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binLANG=en_GB.UTF-8container=lxc So it looks like that container environment variable is already set on PID1 Yeah, I saw that myself last night. Testing that out and it's still not working here (although it doesn't seem to be grabbing the host console now) if I use systemd but upstart fires right up and I see that container variable set. Looked like a number of mounts listed on that wiki page. Maybe something is missing. Right now it's just hanging trying to start the container and, when I subsequently try to shut the container down it results in a hung resource and it can't delete the cgroups directory because it's busy. Only thing I did was change the link to /sbin/init from upstart to systemd and it's now dead and I'll have to reboot the host to free the resource. :-P Regards, John Regards, Mike -- Michael H. Warfield (AI4NB)
[systemd-devel] [PATCH] rules: Remove HP iLO from USB HID PM rules
HP iLO fw versions below 1.50 incorrectly report that HP iLO virtual
Kbd/Mouse supports remote wakeup. With the rules change in commit
3bfc7a97b1824fcdfb738617d9a5450a20a22a0f, the HP iLO was listed for
power control.
In iLO fw versions less than 1.50, the iLO Kbd/Mouse become unresponsive
once they are suspended. HP iLO fw versions 1.50+ correctly report that
they don't support remote wakeup, which makes the rules moot in any case.
rules/42-usb-hid-pm.rules | 10 --
1 file changed, 10 deletions(-)
Signed-off-by: Tony Camuso tcam...@redhat.com
diff --git a/rules/42-usb-hid-pm.rules b/rules/42-usb-hid-pm.rules
index ac671f1..c9f67c7 100644
--- a/rules/42-usb-hid-pm.rules
+++ b/rules/42-usb-hid-pm.rules
@@ -12,12 +12,6 @@ ACTION==add, SUBSYSTEM==usb, ATTR{product}==QEMU USB
Mouse, ATTR{serial}==
ACTION==add, SUBSYSTEM==usb, ATTR{product}==QEMU USB Tablet,
ATTR{serial}==42, TEST==power/control, ATTR{power/control}=auto
ACTION==add, SUBSYSTEM==usb, ATTR{product}==QEMU USB Keyboard,
ATTR{serial}==42, TEST==power/control, ATTR{power/control}=auto
-#
-# Enable autosuspend for KVM and iLO usb hid devices. These are
-# effectively self-powered (despite what some claim in their USB
-# profiles) and so it's safe to do so.
-#
-
# AMI 046b:ff10
ACTION==add, SUBSYSTEM==usb, ATTR{idVendor}==046b,
ATTR{idProduct}==ff10, TEST==power/control, ATTR{power/control}=auto
@@ -33,10 +27,6 @@ ACTION==add, SUBSYSTEM==usb, ATTR{idVendor}==413c,
ATTR{idProduct}==2500
# Dell DRAC 5
ACTION==add, SUBSYSTEM==usb, ATTR{idVendor}==413c,
ATTR{idProduct}==, TEST==power/control, ATTR{power/control}=auto
-# Hewlett Packard iLO
-ACTION==add, SUBSYSTEM==usb, ATTR{idVendor}==03f0,
ATTR{idProduct}==7029, TEST==power/control, ATTR{power/control}=auto
-ACTION==add, SUBSYSTEM==usb, ATTR{idVendor}==03f0,
ATTR{idProduct}==1027, TEST==power/control, ATTR{power/control}=auto
-
# IBM remote access
ACTION==add, SUBSYSTEM==usb, ATTR{idVendor}==04b3,
ATTR{idProduct}==4001, TEST==power/control, ATTR{power/control}=auto
ACTION==add, SUBSYSTEM==usb, ATTR{idVendor}==04b3,
ATTR{idProduct}==4002, TEST==power/control, ATTR{power/control}=auto
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unable to run systemd in an LXC / cgroup container.
On Sun, 21.10.12 17:25, Michael H. Warfield (m...@wittsend.com) wrote: Hello, This is being directed to the systemd-devel community but I'm cc'ing the lxc-users community and the Fedora community on this for their input as well. I know it's not always good to cross post between multiple lists but this is of interest to all three communities who may have valuable input. I'm new to this particular list, just having joined after tracking a problem down to some systemd internals... Several people over the last year or two on the lxc-users list have been discussions trying to run certain distros (notably Fedora 16 and above, recent Arch Linux and possibly others) in LXC containers, virualizing entire servers this way. This is very similar to Virtuoso / OpenVZ only it's using the native Linux cgroups for the containers (primary reason I dumped OpenVZ was to avoid their custom patched kernels). These recent distros have switched to systemd for the main init process and this has proven to be disastrous for those of us using LXC and trying to install or update our containers. Note that it is explicitly our intention to make running systemd inside of containers as smooth as possibly. The notes Kay linked summarize what the container manager needs to do for best integration. To summarize the problem... The LXC startup binary sets up various things for /dev and /dev/pts for the container to run properly and this works perfectly fine for SystemV start-up scripts and/or Upstart. Unfortunately, systemd has mounts of devtmpfs on /dev and devpts on /dev/pts which then break things horribly. This is because the kernel currently lacks namespaces for devices and won't for some time to come (in design). When devtmpfs gets mounted over top of /dev in the container, it then hijacks the hosts console tty and several other devices which had been set up through bind mounts by LXC and should have been LEFT ALONE. Please initialize a minimal tmpfs on /dev. systemd will then work fine. Yes! I recognize that this problem with devtmpfs and lack of namespaces is a potential security problem anyways that could (and does) cause serious container-to-host problems. We're just not going to get that fixed right away in the linux cgroups and namespaces. No, devtmpfs really doesn't need updating, containers simply shouldn't use it. How do we work around this problem in systemd where it has hard coded mounts in the binary that we can't override or configure? Or is it there and I'm just missing it trying to examine the sources? That's how I found where the problem lay. systemd will make use of pre-existing mounts if they exist, and only mount something new if they don't exist. Note that there are reports that LXC has issues with the fact that newer systemd enables shared mount propagation for all mounts by default (this should actually be beneficial for containers as this ensures that new mounts appear in the containers). LXC when run on such a system fails as soon as it tries to use pivot_root(), as that is incompatible with shared mount propagation. The needs fixing in LXC: it should use MS_MOVE or MS_BIND to place the new root dir in / instead. A short term work-around is to simply remount the root tree to private before invoking LXC. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] pm-utils quirks
On Mon, 22.10.12 15:20, Colin Guthrie (gm...@colin.guthr.ie) wrote: Hi, Heya, Might have been covered elsewhere in some docs but is there any info on how to plan for a post-pm-utils world? Not really, the interesting bits of pm-utils are done by systemd in C code directly. pm-utils doesn't really have any purpose anymore and upower can defer to systemd's logind instead. pm-utils had several quirks (many of which are likely obsolete - for me the vt switching stuff which is apparently quirked on my h/w makes suspend/resume uglier and gives no benefit), but with a switch to systemd for suspend all these quirks obviously no longer apply. According to the X driver folks the quirks are entirey unnecessary these days, and if there indeed is something left over then it should be fixed in the drivers, not in userspace quirks. We only did the in-systemd suspending after ensuring that the quirks are entirely unnecessary now. So the question is, what should be done about it? Nothing, really. Just don't pull it in anymore. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unable to run systemd in an LXC / cgroup container.
On Mon, 2012-10-22 at 16:11 +0200, Lennart Poettering wrote: On Sun, 21.10.12 17:25, Michael H. Warfield (m...@wittsend.com) wrote: Hello, This is being directed to the systemd-devel community but I'm cc'ing the lxc-users community and the Fedora community on this for their input as well. I know it's not always good to cross post between multiple lists but this is of interest to all three communities who may have valuable input. I'm new to this particular list, just having joined after tracking a problem down to some systemd internals... Several people over the last year or two on the lxc-users list have been discussions trying to run certain distros (notably Fedora 16 and above, recent Arch Linux and possibly others) in LXC containers, virualizing entire servers this way. This is very similar to Virtuoso / OpenVZ only it's using the native Linux cgroups for the containers (primary reason I dumped OpenVZ was to avoid their custom patched kernels). These recent distros have switched to systemd for the main init process and this has proven to be disastrous for those of us using LXC and trying to install or update our containers. Note that it is explicitly our intention to make running systemd inside of containers as smooth as possibly. The notes Kay linked summarize what the container manager needs to do for best integration. To summarize the problem... The LXC startup binary sets up various things for /dev and /dev/pts for the container to run properly and this works perfectly fine for SystemV start-up scripts and/or Upstart. Unfortunately, systemd has mounts of devtmpfs on /dev and devpts on /dev/pts which then break things horribly. This is because the kernel currently lacks namespaces for devices and won't for some time to come (in design). When devtmpfs gets mounted over top of /dev in the container, it then hijacks the hosts console tty and several other devices which had been set up through bind mounts by LXC and should have been LEFT ALONE. Please initialize a minimal tmpfs on /dev. systemd will then work fine. My containers have a reasonable /dev that work with Upstart just fine but they are not on tmpfs. Is mounting tmpfs on /dev and recreating that minimal /dev required? Yes! I recognize that this problem with devtmpfs and lack of namespaces is a potential security problem anyways that could (and does) cause serious container-to-host problems. We're just not going to get that fixed right away in the linux cgroups and namespaces. No, devtmpfs really doesn't need updating, containers simply shouldn't use it. Ok, yeah. That seems to be at the heart of the problem we're trying to solve. How do we work around this problem in systemd where it has hard coded mounts in the binary that we can't override or configure? Or is it there and I'm just missing it trying to examine the sources? That's how I found where the problem lay. systemd will make use of pre-existing mounts if they exist, and only mount something new if they don't exist. So you're saying that, if we have something mounted on /dev, that's what prevents systemd from mounting devtmpfs on /dev? That could be problematical. Tested out a couple of options there that didn't work. That's going to take some effort. Note that there are reports that LXC has issues with the fact that newer systemd enables shared mount propagation for all mounts by default (this should actually be beneficial for containers as this ensures that new mounts appear in the containers). LXC when run on such a system fails as soon as it tries to use pivot_root(), as that is incompatible with shared mount propagation. The needs fixing in LXC: it should use MS_MOVE or MS_BIND to place the new root dir in / instead. A short term work-around is to simply remount the root tree to private before invoking LXC. But, I have systemd running on my host system (F17) and containers with sysvinit or upstart inits are all starting just fine. That sounds like it should impact all containers as pivot_root() is issued before systemd in the container is started. Or am I missing something here? That sounds like a problem for Serge and others to investigate further. I'll see about trying that workaround though. Lennart -- Lennart Poettering - Red Hat, Inc. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [RFC] systemd-bootchart: merge bootchart.
On Sat, Oct 20, 2012 at 8:01 AM, Colin Walters walt...@verbum.org wrote: On Wed, 2012-10-17 at 16:01 -0700, Auke Kok wrote: The goal of this patch is to get comments on the overall integration style. Man pages were added to cover the various ways of starting bootchart: - as replacement init process - as standalone program - not implemented yet: as early process by systemd - not implemented yet: as regular systemd service unit Does it make sense to support all 4 modes? What's the tradeoffs of running it as init versus an early process? The replacement init method allows you to capture more of what happens really early on. If we'd wait until systemd is loaded and linked and the basics done, we've essentially loaded quite a bit of extra libraries into memory, called many syscalls etc. The best comparison with other boot sequences would be to always run bootchart as init, since it would be the fairest comparison. It would be even fairer if you'd compile bootchart as a static binary. At that point you're not influencing the OS boot at all, since you're not linking anything. The tradeoff is 10 lines of C code, it's almost negligent. Does all of the bootchart code need to be merged in here versus say systemd exporting whatever information is needed, and tightly integrating with it if it exists? The plymouth integration may be a good precedent here. systemd-bootchart will be a standalone component in any case, and use external interfaces to grab service data - preferably. I'd rather implement it as a good example of how to use the DBus methods than link it internally. There's just no reason to do that, and it will just make it more complex. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unable to run systemd in an LXC / cgroup container.
On Mon, 22.10.12 11:48, Michael H. Warfield (m...@wittsend.com) wrote: To summarize the problem... The LXC startup binary sets up various things for /dev and /dev/pts for the container to run properly and this works perfectly fine for SystemV start-up scripts and/or Upstart. Unfortunately, systemd has mounts of devtmpfs on /dev and devpts on /dev/pts which then break things horribly. This is because the kernel currently lacks namespaces for devices and won't for some time to come (in design). When devtmpfs gets mounted over top of /dev in the container, it then hijacks the hosts console tty and several other devices which had been set up through bind mounts by LXC and should have been LEFT ALONE. Please initialize a minimal tmpfs on /dev. systemd will then work fine. My containers have a reasonable /dev that work with Upstart just fine but they are not on tmpfs. Is mounting tmpfs on /dev and recreating that minimal /dev required? Well, it can be any kind of mount really. Just needs to be a mount. And the idea is to use tmpfs for this. What /dev are you currently using? It's probably not a good idea to reuse the hosts' /dev, since it contains so many device nodes that should not be accessible/visible to the container. systemd will make use of pre-existing mounts if they exist, and only mount something new if they don't exist. So you're saying that, if we have something mounted on /dev, that's what prevents systemd from mounting devtmpfs on /dev? Yes. But, I have systemd running on my host system (F17) and containers with sysvinit or upstart inits are all starting just fine. That sounds like it should impact all containers as pivot_root() is issued before systemd in the container is started. Or am I missing something here? That sounds like a problem for Serge and others to investigate further. I'll see about trying that workaround though. The shared issue is F18, and it's about running LXC on a systemd system, not about running systemd inside of LXC. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unable to run systemd in an LXC / cgroup container.
On Mon, 2012-10-22 at 22:50 +0200, Lennart Poettering wrote: On Mon, 22.10.12 11:48, Michael H. Warfield (m...@wittsend.com) wrote: To summarize the problem... The LXC startup binary sets up various things for /dev and /dev/pts for the container to run properly and this works perfectly fine for SystemV start-up scripts and/or Upstart. Unfortunately, systemd has mounts of devtmpfs on /dev and devpts on /dev/pts which then break things horribly. This is because the kernel currently lacks namespaces for devices and won't for some time to come (in design). When devtmpfs gets mounted over top of /dev in the container, it then hijacks the hosts console tty and several other devices which had been set up through bind mounts by LXC and should have been LEFT ALONE. Please initialize a minimal tmpfs on /dev. systemd will then work fine. My containers have a reasonable /dev that work with Upstart just fine but they are not on tmpfs. Is mounting tmpfs on /dev and recreating that minimal /dev required? Well, it can be any kind of mount really. Just needs to be a mount. And the idea is to use tmpfs for this. What /dev are you currently using? It's probably not a good idea to reuse the hosts' /dev, since it contains so many device nodes that should not be accessible/visible to the container. Got it. And that explains the problems we're seeing but also what I'm seeing in some libvirt-lxc related pages, which is a separate and distinct project in spite of the similarities in the name... http://wiki.1tux.org/wiki/Lxc/Installation#Additional_notes Unfortunately, in our case, merely getting a mount in there is a complication in that it also has to be populated but, at least, we understand the problem set now. systemd will make use of pre-existing mounts if they exist, and only mount something new if they don't exist. So you're saying that, if we have something mounted on /dev, that's what prevents systemd from mounting devtmpfs on /dev? Yes. But, I have systemd running on my host system (F17) and containers with sysvinit or upstart inits are all starting just fine. That sounds like it should impact all containers as pivot_root() is issued before systemd in the container is started. Or am I missing something here? That sounds like a problem for Serge and others to investigate further. I'll see about trying that workaround though. The shared issue is F18, and it's about running LXC on a systemd system, not about running systemd inside of LXC. Whew! I'll deal with F18 when I need to deal with F18. That explains why my F17 hosts are running and gives Serge and others a chance to address this, forewarned. Thanks for that info. Lennart -- Lennart Poettering - Red Hat, Inc. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] pm-utils quirks
Hi, 'Twas brillig, and Lennart Poettering at 22/10/12 15:28 did gyre and gimble: Might have been covered elsewhere in some docs but is there any info on how to plan for a post-pm-utils world? Not really, the interesting bits of pm-utils are done by systemd in C code directly. pm-utils doesn't really have any purpose anymore and upower can defer to systemd's logind instead. A colleague did some poking and pointed out the following issue: upower 0.9.18 still requires pm-utils for some features: - up_backend_supports_sleep_state (src/linux/up-backend.c line 360) calls /usr/bin/pm-is-supported to determine if suspend or hibernate are available on the system. upower uses this to reply to dbus call on org.freedesktop.UPower.CanSuspend or .CanHibernate. Without pm-utils, org.freedesktop.UPower.CanSuspend or .CanHibernate always return false. At startup, KDE asks org.freedesktop.UPower.CanSuspend and .CanHibernate to know if, respectively, suspend and hibernate are possible on the system. So, without pm-utils installed, suspend and hibernate entries are not available in KDE's menus and applets (it's needed to reboot after the removal of pm-utils). So, should the org.freedesktop.UPower.CanSuspend/Hibernate properties be cooked up instead to logind rather than shelling out to pm-is-supported? pm-utils had several quirks (many of which are likely obsolete - for me the vt switching stuff which is apparently quirked on my h/w makes suspend/resume uglier and gives no benefit), but with a switch to systemd for suspend all these quirks obviously no longer apply. According to the X driver folks the quirks are entirey unnecessary these days, and if there indeed is something left over then it should be fixed in the drivers, not in userspace quirks. We only did the in-systemd suspending after ensuring that the quirks are entirely unnecessary now. Nice to know, thanks. So the question is, what should be done about it? Nothing, really. Just don't pull it in anymore. As well as the above problem, my colleague also pointed out: - up_backend_get_powersave_command (src/linux/up-backend.c line 615) calls /usr/sbin/pm-powersave to apply powersave's adjustments. So what is the systemd blessed way of doing this? 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/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] mount: make sure m-where is set before unit_add_exec_dependencies()
On Tue, 16.10.12 17:04, Will Woods (wwo...@redhat.com) wrote: If you enter unit_add_exec_dependencies with m-where = NULL, you'll very likely end up aborting somewhere under socket_needs_mount. (When systemd goes to check to see if the journald socket requires your mount, it'll do path_startswith(path, m-where)... *kaboom*) This patch should ensure that: a) both branches in mount_add_one() set m-where, and b) mount_add_extras() calls unit_add_exec_dependencies() *after* setting m-where. Thanks! Applied! Sorry for the delay! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [ANNOUNCE] systemd 195
Heya! A non-trivial amount of cool new features, but primarily bug fixes bug fixes bug fixes. Note that I intend to make this the final version we push into Fedora 18. systemd 196 will be the first release we commit to Fedora 19. This might or might not be a good idea for other distros to keep in mind, if you guys need something stabilized. From now we'll just backport cherry-picked fixes to F18, the way this is done for F17. So it might be cool to watch our F18 packaging repo. Oh, and one more thing. In Fedora I added cap_dac_override,cap_sys_ptrace+ep as file capabilities to /usr/bin/systemd-detect-virt, so that this useful tool works for unprivileged users too. (Yeah, cap_sys_ptrace sounds crazy, but Linux sucks, it's required to read a few things off /proc/1/). The systemd makefile will do the same, but if you package systemd for your distro with RPM or suchlike you probably need to declare this explicitly in your spec file. Note that not adding these caps is not a problem, you'll just get a clean permission error if you run it as non-privileged user. Also nothing depends on this being run as unprivileged user that I was aware of, so this is really just about making a useful tool more widely available, and not really a dependency for anything. http://www.freedesktop.org/software/systemd/systemd-195.tar.xz * journalctl gained the new --since= and --until= switches to filter by time. It also now supports nice filtering for units via --unit=/-u. * Type=oneshot services not may use ExecReload= and do the right thing. * The journal daemon now supports time-based rotation and vacuuming, in addition to the usual disk-space based rotation. * The journal will now index the available field values for each field name. This enables clients to show pretty drop downs of available match values when filtering. The bash completion of journalctl has been updated accordingly. journalctl gained a new switch -F to list all values a certain field takes in the journal database. * More service events are now written as structured messages to the journal, and made recognizable via message IDs. * The timedated, localed and hostnamed mini-services which previously only provided support for changing time, locale and hostname settings from graphical DEs such as GNOME now also have a minimal (but very useful) text-based client utility each. This is probably the nicest way to changing these settings from the command line now, especially since it lists available options and is fully integrated with bash completion. * There's now a new tool systemd-coredumpctl to list and extract coredumps from the journal. * We now install a README each in /var/log/ and /etc/rc.d/init.d explaining where the system logs and init scripts went. This hopefully should help folks who go to that dirs and look into the otherwise now empty void and scratch their heads. * When user-services are invoked (by systemd --user) the $MANAGERPID env var is set to the PID of systemd. * SIGRTMIN+24 when sent to a --user instance will now result in immediate termination of systemd. * gatewayd received numerous feature additions such as a follow mode, for live syncing and filtering. * browse.html now allows filtering and showing detailed information on specific entries. Keyboard navigation and mouse screen support has been added. * gatewayd/journalctl now supports HTML5/JSON Server-Sent-Events as output. * The SysV init script compatibility logic will now heuristically determine whether a script supports the reload verb, and only then make this available as systemctl reload. * systemctl status --follow has been removed, use journal -u instead. * journald.conf's RuntimeMinSize=, PersistentMinSize= settings have been removed since they are hardly useful to be configured. * And I'd like to take the opportunity to specifically mention Zbigniew for his great contributions. Zbigniew, you rock! Contributions from: Andrew Eikum, Christian Hesse, Colin Guthrie, Daniel J Walsh, Dave Reisner, Eelco Dolstra, Ferenc Wágner, Kay Sievers, Lennart Poettering, Lukas Nykryn, Mantas Mikulėnas, Martin Mikkelsen, Martin Pitt, Michael Olbrich, Michael Stapelberg, Michal Schmidt, Sebastian Ott, Thomas Bächler, Umut Tezduyar, Will Woods, Wulf C. Krueger, Zbigniew Jędrzejewski-Szmek, Сковорода Никита Андреевич Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list
