Re: [systemd-devel] Inhibiting plug and play
Hi, On Tue, Jun 18, 2013 at 10:45 AM, Phillip Susi ps...@ubuntu.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Various tools, but most notably partitioners, manipulate disks in such a way that they need to prevent the rest of the system from racing with them while they are in the middle of manipulating the disk. Presently this is done with a hodge podge of hacks that involve running some script or executable to temporarily hold off on some aspects ( typically only auto mounting ) of plug and play processing. Which one depends on whether you are running hal, udisks, udisks2, or systemd. There really needs to be a proper way at a lower level, either udev, or maybe in the kernel, to inhibit processing events until the tool changing the device has finished completely. The question is, should this be in the kernel, or in udev, and what should the interface be? When I was younger I used to think things like this was a good idea and, in fact, did a lot of work to add complex interfaces for this in the various components you mention. These interfaces didn't really work well, someone would always complain that this or that edge-case didn't work. Or some other desktop environment ended up not using the interfaces. Or some kernel hacker running twm (with carefully selected bits of GNOME or KDE to get automounting) ran into problems. It was awful. Just awful. What _did_ turn out to work really well - and what GNOME is using today and have been for the last couple of years - is that the should_automount flag [1] is set only if, and only if, the device the volume is on, has been added within the last five seconds [2]. It's incredibly simple (and low-tech). And judging from bug reports, it works really well. So please don't add complicated inhibit interfaces. They're probably not going to work and probably not everybody is going to use them. Thanks, David [1] : as used in GNOME and probably things like Ubuntu Unity and XFCE as well, see https://developer.gnome.org/gio/2.35/GVolume.html#g-volume-should-automount [2] : this is where should_automount is being set https://git.gnome.org/browse/gvfs/tree/monitor/udisks2/gvfsudisks2volume.c?id=1.17.2#n377 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Inhibiting plug and play
Hi, On Tue, Jun 18, 2013 at 11:40 AM, Phillip Susi ps...@ubuntu.com wrote: I don't follow. You mean udisks delays auto mounting by 5 seconds? No, it works like this: if you plug in the device, then - for example - /dev/sdb is added and then /dev/sdb1 is added and /dev/sdb1 is deemed to contain a FAT filesystem that could be mounted. The trick is to only decide to automount /dev/sdb1 if /dev/sdb appeared recently - e.g. within the last five seconds. The problem also goes beyond udisks and auto mounting, which is why I say it really needs done either at the udev or kernel level. Disagree. We don't want this level of complexity in either the kernel or udev. Why? Because it can be solved by the policy manager (such as the GNOME auto-mounter described above or the RAID auto-assembly machinery described below) do the right thing - e.g. be extremely careful before it's doing something (such as mounting it or assembling several of them to a RAID or VG) to a device. For instance, a udev script may identify the new volume as part of a raid ( leftover metadata ) and try to attach mdadm to it, at the same time you're running mkfs. I'm also pretty sure that I have seen the mdadm udev script race with mdadm itself while you are trying to create a new raid volume. This is indeed a problem with the RAID auto-assembler being overeager and not careful enough. In fact, I routinely just delete udev rules for RAID and LVM assembly because they keep doing the wrong thing. The solution here is not to add complex machinery and frameworks and abstractions. The solution is simply to fix the underlying problems, not paper over them. David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] Packaging systemd
Hi Lennart, On Sat, Jul 3, 2010 at 9:16 AM, Lennart Poettering lenn...@poettering.net wrote: On Fri, 25.06.10 03:14, Michael Biebl (mbi...@gmail.com) wrote: 2010/6/25 Kay Sievers kay.siev...@vrfy.org: and converted udev init scripts to native systemd configurations to place into /lib/systemd/system/ are here: http://people.freedesktop.org/~kay/systemd/ Looking at the udev.service file, I noticed: [Service] Type=notify ExecStart=/sbin/udevd ExecStartPost=/sbin/udevadm trigger --type=subsystems --action=add ExecStartPost=/sbin/udevadm trigger --type=devices --action=add That duplicate ExecStartPost, is that a bug or intentional? If the latter, what is the order in which those commands are run? Is it possible to run other Exec* commands, like ExecStart= in parallel/multiple times? Intentional. They are executed one after the other, serially. If you want parallelization, use multiple service files. Interesting. So one one hand, you're saying we're using the a Desktop-file format because there's so many parsers / API for it, yet with this move you break compatibility with a lot of them (in particular GKeyFile [1]). Embrace and extend? Anyway, it's a bit too clever... and, without getting all emotional... a bit inconsiderate for my taste. Not that I'm super-invested in this (I'm not planning to parse any of these files myself, anyway), but, any chance you can figure out a better way to do this? Thanks! David [1] : While GKeyFile will load/save such files correctly (because it uses a list to store key/value pairs and jumps through a lot of hoops to preserve comments etc), its API doesn't really cater for it. I haven't reviewed other ini-file/.desktop-file APIs but I guess it's the same. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
