[systemd-devel] Possible bug in configure.ac following recent commit
Hi, In a recent commit: units: rework systemd-exit.service to terminate systemd via signal rather... changes have been made in configure.ac There might be a bug in this line: AC_PATH_PROG([KILL], [kill], [/usr/bin/cap]) Is the /usr/bin/cap normal ? or is it a typo and so should be /usr/bin/kill ? Thanks Regards valr ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Too little information is shown when system enters emergency mode
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? Thank you -andrey ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Possible bug in configure.ac following recent commit
On Sun, Oct 21, 2012 at 12:27:55PM +0100, Valere Monseur wrote: Hi, In a recent commit: units: rework systemd-exit.service to terminate systemd via signal rather... changes have been made in configure.ac There might be a bug in this line: AC_PATH_PROG([KILL], [kill], [/usr/bin/cap]) Is the /usr/bin/cap normal ? or is it a typo and so should be /usr/bin/kill ? Should definitely be /usr/bin/kill. I suspect no one's ever noticed this, since it's merely the fallback value when kill isn't found via PATH lookup. I've pushed a fix for this now. Thanks! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Too little information is shown when system enters emergency mode
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. However, on a more general basis (not openSUSE specific), I think we should add some special handly in systemd for a kernel command line option (for instance debug or debug=1), which would expand into systemd.log_level=debug systemd.log_target=kmsg). This would be much easier to tell users when debug is needed and we could also add an additional menu entry in bootloader (under the advanced settings) so this setting would be always available, if needed. -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Unable to run systemd in an LXC / cgroup container.
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. 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. 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] Unable to run systemd in an LXC / cgroup container.
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 Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
