Re: [systemd-devel] Problems with rootfs over nfs
On 15 May 2011 15:16, Kay Sievers kay.siev...@vrfy.org wrote: Just a first quick check of an issue we ran into with ATA disks: what's in /proc/sys/kernel/hotplug before you shut down? Or what's CONFIG_UEVENT_HELPER in your kernel setup, it must be = on modern systems, otherwise the kernel will they to exec() binaries all the time and keep the system's rootfs busy. I'm also having trouble shutting down with systemd, and I have CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug So I'll try this solution. Thanks. Just a quick question: is the same also true for Fedora 14 (upstart-1.2, udev-161)? i.e. can and should that config option be cleared under that setup too? I guess so, given that /sbin/hotplug doesn't even exist. Thanks, Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Problems with rootfs over nfs
On Mon, May 16, 2011 at 13:39, Daniel Drake d...@laptop.org wrote: On 15 May 2011 15:16, Kay Sievers kay.siev...@vrfy.org wrote: Just a first quick check of an issue we ran into with ATA disks: what's in /proc/sys/kernel/hotplug before you shut down? Or what's CONFIG_UEVENT_HELPER in your kernel setup, it must be = on modern systems, otherwise the kernel will they to exec() binaries all the time and keep the system's rootfs busy. I'm also having trouble shutting down with systemd, and I have CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug So I'll try this solution. Thanks. Just a quick question: is the same also true for Fedora 14 (upstart-1.2, udev-161)? i.e. can and should that config option be cleared under that setup too? I guess so, given that /sbin/hotplug doesn't even exist. Yeah, /sbin/hotplug is ancient history or (broken) embedded-like setups, it should always be disabled. In earlier udev/init setups we used to do: echo /proc/sys/kernel/hotplug, but we don't do it in systemd setups, that's why it pops up now. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Problems with rootfs over nfs
On Mon, May 16, 2011 at 8:44 AM, Kay Sievers kay.siev...@vrfy.org wrote: On Mon, May 16, 2011 at 13:39, Daniel Drake d...@laptop.org wrote: On 15 May 2011 15:16, Kay Sievers kay.siev...@vrfy.org wrote: Just a first quick check of an issue we ran into with ATA disks: what's in /proc/sys/kernel/hotplug before you shut down? Or what's CONFIG_UEVENT_HELPER in your kernel setup, it must be = on modern systems, otherwise the kernel will they to exec() binaries all the time and keep the system's rootfs busy. I'm also having trouble shutting down with systemd, and I have CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug So I'll try this solution. Thanks. Just a quick question: is the same also true for Fedora 14 (upstart-1.2, udev-161)? i.e. can and should that config option be cleared under that setup too? I guess so, given that /sbin/hotplug doesn't even exist. Yeah, /sbin/hotplug is ancient history or (broken) embedded-like setups, it should always be disabled. In earlier udev/init setups we used to do: echo /proc/sys/kernel/hotplug, but we don't do it in systemd setups, that's why it pops up now. Maybe state that in the README and even check during startup if such thing is set and warn the user? -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Problems with rootfs over nfs
On Mon, 16.05.11 13:44, Kay Sievers (kay.siev...@vrfy.org) wrote: On Mon, May 16, 2011 at 13:39, Daniel Drake d...@laptop.org wrote: On 15 May 2011 15:16, Kay Sievers kay.siev...@vrfy.org wrote: Just a first quick check of an issue we ran into with ATA disks: what's in /proc/sys/kernel/hotplug before you shut down? Or what's CONFIG_UEVENT_HELPER in your kernel setup, it must be = on modern systems, otherwise the kernel will they to exec() binaries all the time and keep the system's rootfs busy. I'm also having trouble shutting down with systemd, and I have CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug So I'll try this solution. Thanks. Just a quick question: is the same also true for Fedora 14 (upstart-1.2, udev-161)? i.e. can and should that config option be cleared under that setup too? I guess so, given that /sbin/hotplug doesn't even exist. Yeah, /sbin/hotplug is ancient history or (broken) embedded-like setups, it should always be disabled. In earlier udev/init setups we used to do: echo /proc/sys/kernel/hotplug, but we don't do it in systemd setups, that's why it pops up now. I could add a taint check for this? Shall I? 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] Communicating need
On Thu, 12.05.11 09:09, Scott James Remnant (sc...@netsplit.com) wrote: On Mon, May 9, 2011 at 4:32 PM, Lennart Poettering lenn...@poettering.netwrote: On Mon, 09.05.11 13:13, Scott James Remnant (sc...@netsplit.com) wrote: The System Daemon seems to be where systemd is much more clever; a Bluetooth device unit would want the System Daemon, but that could be joined with socket/D-Bus Activation right? So the presence of the device creates the socket, but doesn't start the daemon until an actual connection from a Userspace Agent/Applet arrives. Well, systemd allows you to do such a thing, but I don't think we want this really. Let me give you another example, then. I've already touched in the other thread on the problem with input devices being delayed by other probing work udev is doing. Actually, it's more than that. When we start the X server it enumerates the udev known input devices on the system, since getting something on the screen is our top priority, the X server comes up before that udevadm trigger (and maybe even before udevd is running - I don't think there's a dep there). Obviously there are no devices, and they are not tagged ID_INPUT by udev, so X sees no devices. It's not until a few seconds later that the show up - udevadm trigger may take meer hundreds of milliseconds (that sounds cheap to you, expensive to us :p) but it takes udevd many seconds to actually deal with the result. Our entire userspace bootup takes 1s here on an older X300. I think nobody expects that the mouse reacts any quicker than that. But as mentioned elsewhere: if this really is a problem we could modify udev trigger to sort the devices according to some user specific rules before triggering them. That way we can ensure that input gets triggered before network, or whatever else you want to express. But again, I'd really like to see this profiled before look into this. Right now if userspace booting takes 1s this should be more then sufficiently good for desktop machines, include ChromeOS machines. This would be kernel 2.2 style module loading? I think that makes sense only for very few devices, mostly static singleton, even virtual devices only. Well, that style loading was on activation whereas you seem to be arguing for on event here ;-) I thought systemd was all about the former, whereas Upstart was all about the latter :p systemd is not about lazily doing things. It's about parallelization. That includes that we do things as early as possible so that things are finished when they are actually used. So I think the emphasis should be on priorizing the jobs that are executed in parallel in the best way, but not to serialize them. Of course, specific rules might be slow. If they are we can optimize them, and potentially move them elsewhere, but I think this must be done as result of profiling. 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] [PATCH] pull rpcbind.target to multi-user.target
On Sat, 14.05.11 01:29, Alexey Shabalin (a.shaba...@gmail.com) wrote: This patch rpcbind.target to multi-user.target. After apply this path, you can add to rpcbind.service only: [Install] WantedBy=rpcbind.target without multi-user.target. Hmm, rpcbind.service should pull in rpcbind.target, not the other way round. It might be surprising but in general we want the services implementing the targets to pull in the targets, and not vice versa. That also applies to rpcbind. 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] Communicating need
On Mon, May 16, 2011 at 2:23 PM, Lennart Poettering lenn...@poettering.netwrote: Our entire userspace bootup takes 1s here on an older X300. I think nobody expects that the mouse reacts any quicker than that. Your older X300 is probably rather more powerful than a single-core Atom CPU. But as mentioned elsewhere: if this really is a problem we could modify udev trigger to sort the devices according to some user specific rules before triggering them. That way we can ensure that input gets triggered before network, or whatever else you want to express. But again, I'd really like to see this profiled before look into this. Right now if userspace booting takes 1s this should be more then sufficiently good for desktop machines, include ChromeOS machines. It depends what you mean by userspace booting. We are able to start the entire system, X server and Chromium browser in about 2.2s It takes about 5-6s for udev to run input_id on the keyboard + touchpad, and thus for them to be available to X. Scott ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Communicating need
On Mon, 16.05.11 14:43, Scott James Remnant (sc...@netsplit.com) wrote: On Mon, May 16, 2011 at 2:23 PM, Lennart Poettering lenn...@poettering.netwrote: Our entire userspace bootup takes 1s here on an older X300. I think nobody expects that the mouse reacts any quicker than that. Your older X300 is probably rather more powerful than a single-core Atom CPU. It probably is, but it's not a superduper fast CPU either. But again, I'd really like to see this profiled before look into this. Right now if userspace booting takes 1s this should be more then sufficiently good for desktop machines, include ChromeOS machines. It depends what you mean by userspace booting. systemd booting a reasonably complete GNOME system (cups, ck, pk, gdm, all that stuff). The time that passes from systemd being invoked until systemd has nothing more to do. I presume a much bigger set of components than on ChromeOS. It takes about 5-6s for udev to run input_id on the keyboard + touchpad, and thus for them to be available to X. How come this takes so long? Does this actually delay X? Nromally X should be fine without kbd/mouse and then be able to make use of it the moment it becomes available? 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] Communicating need
On Mon, May 16, 2011 at 2:46 PM, Lennart Poettering lenn...@poettering.netwrote: It takes about 5-6s for udev to run input_id on the keyboard + touchpad, and thus for them to be available to X. How come this takes so long? Does this actually delay X? Nromally X should be fine without kbd/mouse and then be able to make use of it the moment it becomes available? Well, X is sitting there with a nice screen that the user can't use because the keyboard and touchpad don't work yet ... so no, it doesn't delay X, it delays the user experience ;-) Scott ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] how check enabled service
Hi. How i can check enabled service? 1) # systemctl enable acpid.service ln -s '/lib/systemd/system/acpid.service' '/etc/systemd/system/multi-user.target.wants/acpid.service' # systemctl is-enabled acpid.service; echo $? 0 OK 2) # systemctl disable acpid.service rm '/etc/systemd/system/multi-user.target.wants/acpid.service' # systemctl is-enabled acpid.service; echo $? 0 ^^^ Ok? i waiting non-zero exit code. i have a systemd-v26. -- Alexey Shabalin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
