[systemd-devel] mount failed during system start but after systemctl daemon-reload everything works
Hello. Could anyone tell me a reason why a mount (regardless of via fstab or mountpoint.mount unit file) during system boot leads to a timeout because of device timeout and after i do a systemctl daemon-reload the mount is successful? Detailed information: My system is a Linuxfromscratch 7.5 (so no real distribution - everything is self-compiled) and it runs as a paravirtualized Xen DomU. Therefore the block devices are /dev/xvda1 and /dev/xvdb1. The first is the root fs and mount and remount are okay. Then the second block device should mount and it timed out with Dependency failed and dev-xvdb1.device/start timed out When I run udevadm info /dev/xvdb1 everything seems to be okay, but any try of mount this via systemd failes. When I mount manually via mount /dev/xvdb1 /mountpoint it's fine. Then systemctl status mountpoint.mount says active. Manually unmount is okay and after this a mount via systemd failes again. If I do, and only if I do systemctl daemon-reload and then systemctl start mountpoint.mount it works. I'm a beginner with a systemd based system and do not know much about the internals. What could lead to this behaviour? Is it possible that I do anything wrong? Please help. I'm very frustrated. If you need more Input, please tell me. Best regards Oliver ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemctl: systemctl --root=container/ set-default ... is totally borked.
On Thu, Apr 17, 2014 at 01:42:23PM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Apr 17, 2014 at 10:40:37AM +0200, Jan Chaloupka wrote: On 04/17/2014 04:59 AM, Zbigniew Je;drzejewski-Szmek wrote: On Thu, Apr 17, 2014 at 01:41:51AM +0100, Djalal Harouni wrote: BTW, I've a question, why there is this item in the TODO: systemctl --root=container/ set-default ... is totally borked. Can someone please shed some light on this? I added this, and I guess I should have been more specific, because I had to test this again, to see what is wrong :) systemctl --root=/var/tmp/inst1 set-default multi-user.target creates a symlink /var/tmp/inst1//usr/etc/systemd/system/default.target - /var/tmp/inst1//lib/systemd/system/multi-user.target, i.e. leaks the container name. If understood correctly, proper symlink should be /var/tmp/inst1//usr/etc/systemd/system/default.target - /lib/systemd/system/multi-user.target Hmm, I really can't follow here, when I was fixing that bug I looked at the other switches running against a container and the origin of the --root patch: http://lists.freedesktop.org/archives/systemd-devel/2011-June/002708.html And my understanding is that this should behave as we are inside a chroot IOW container...! and this is what the commit log suggests but not the man page :-/ So ? -- 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] names: take the registry write lock in kdbus_name_release()
Hi On Fri, Apr 18, 2014 at 3:16 AM, Djalal Harouni tix...@opendz.org wrote: Take the write lock in kdbus_name_release() instead of kdbus_cmd_name_release() in order to reduce the lock hold time. This change permits to convert the kdbus_bus_find_conn_by_id() call to kdbus_conn_find_peer() since the bus lock will also be taken later in kdbus_name_release(). Another advantage is that now kdbus_cmd_name_release() and kdbus_name_release() have the same semantic of kdbus_cmd_name_acquire() and kdbus_name_acquire() Signed-off-by: Djalal Harouni tix...@opendz.org Looks good to me. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
