Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
On 06/14/2013 02:14 PM, Tom Gundersen wrote: On Fri, Jun 14, 2013 at 2:03 PM, Łukasz Stelmach l.stelm...@samsung.com wrote: It was 2013-06-14 pią 13:30, when Jan Janssen wrote: On 06/14/2013 01:08 PM, Tom Gundersen wrote: That said, I don't think libdir is appropriate as this data is not under the control of the package manager (as it is generated at install-time rather than at build-time, it would for instance not be suitable for sharing between hosts). I guess localstatedir would be another alternative, but the problem there is that it is not (necessarily) available during early boot when this db is needed. One could introduce a /cache where such files could be stored. Similar to how /run was introduced to fix a similar issue. The folder would be required to be available at boot time. What's wrong with /var/cache? /var may not be mounted at the time the caches are needed. So, why not mount /var also from the initramfs as we do with /usr already. Wouldn't that solve all the problems, and we can use /var/cache? :-) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
On Tue, Jun 18, 2013 at 9:15 AM, Harald Hoyer harald.ho...@gmail.com wrote: On 06/14/2013 02:14 PM, Tom Gundersen wrote: What's wrong with /var/cache? /var may not be mounted at the time the caches are needed. So, why not mount /var also from the initramfs as we do with /usr already. Because, so far we did not want to mandate an initramfs for a separate /var, which is unlike a separate /usr, a very common setup. Wouldn't that solve all the problems, and we can use /var/cache? It would be /var/lib, as it is not a cache; but sure, it would solve the problems. It would maybe significanlty complicate a few initramfs setups to reach /var, but sure, it would work. It would solve quite a few problems, but I'm not sure if that will be a generally accepted solution ... Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] how to end a socket activated daemon
It was 2013-06-17 pon 20:51, when Lennart Poettering wrote: On Fri, 14.06.13 14:33, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Fri, Jun 14, 2013 at 10:03:00AM +0200, Łukasz Stelmach wrote: We are converting some daemons to socket activation. Most of them open unix sockets and manage incoming connections in a main-loop, so the easiest way to convert it is to create Accept=false socket with systemd. Now, it is quite well described how to start such daemon, however, there is little about shutting it down. Should the daemon close(2) the received sockets? Should it unlink(2) them from a filesystem? close() yes, unlink() no. Strictly speaking you don't even have to do that. The kernel will clean up left-over fds when your process exits, hence you don't have to close it explicitly. But you certainly should not unlink() the socket in the fs, because then the socket will not be accessible anymore. Maybe I've asked the wrong question. I should rather have asked: Can I close? Can I unlink? Because that's what the code does now and we wanted to know which parts are common for standalone and systemd-socket-activated paths. Thanks for the information. PS. I think this information should be somewher in the docs. Do you think the paragraph describing Accept= in the systemd.socket.5 man page is the right place? -- Łukasz Stelmach Samsung RD Institute Poland Samsung Electronics ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles, man: Add xattr support to tmpfiles
2013/6/17 Lennart Poettering lenn...@poettering.net: On Mon, 17.06.13 16:27, Maciej Wereski (m.were...@partner.samsung.com) wrote: This patch makes it possible to set extended attributes on files created by tmpfiles. This can be especially used to set SMACK security labels on volatile files and directories. To keep backwards compatibility Argument field is used. If word starts with xattr=, then it is cut out from Argument and parsed. There may be many xattrs. Full format is: xattr=name=value If value contains spaces, then it must be surrounded by quotation marks. User can also put quotation mark in value by escaping it with backslash. I think adding this certainly makes sense, but I am not sure I like the syntax. Maybe it would be simpler to add an extra char for this (a or so?). That way creating a dir and applying an xattr would require two lines instead of one, but the stuff isn't atomic anyway. Admittedly adding a new a isn't particularly nice either, but I have no better idea than that... FWIW, I would like note that we might see similar problem if... when somebody will try to extend tmpfiles with ACLs. That would result in another type and another line. Maybe Type argument could be extended to contain one primary type and 0 to n optional subtypes where n-th subtype would parse n-th semicolon-terminated argument, i.e. fa /tmp/foobar ---- /dev/null ; security.SMACK=foo fxa /tmp/foobar ---- /dev/null ; security.SMACK=foo ; lmctl=rwx x - xattrs, a - acls I do agree this is a bit abusive... Cheers [ Lennart, sorry for two copies - first one didn't contain ML. ] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] how to end a socket activated daemon
On Tue, Jun 18, 2013 at 12:04:40PM +0200, Łukasz Stelmach wrote: It was 2013-06-17 pon 20:51, when Lennart Poettering wrote: On Fri, 14.06.13 14:33, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Fri, Jun 14, 2013 at 10:03:00AM +0200, Łukasz Stelmach wrote: We are converting some daemons to socket activation. Most of them open unix sockets and manage incoming connections in a main-loop, so the easiest way to convert it is to create Accept=false socket with systemd. Now, it is quite well described how to start such daemon, however, there is little about shutting it down. Should the daemon close(2) the received sockets? Should it unlink(2) them from a filesystem? close() yes, unlink() no. Strictly speaking you don't even have to do that. The kernel will clean up left-over fds when your process exits, hence you don't have to close it explicitly. But you certainly should not unlink() the socket in the fs, because then the socket will not be accessible anymore. Maybe I've asked the wrong question. I should rather have asked: Can I close? Can I unlink? Because that's what the code does now and we wanted to know which parts are common for standalone and systemd-socket-activated paths. Thanks for the information. PS. I think this information should be somewher in the docs. Do you think the paragraph describing Accept= in the systemd.socket.5 man page is the right place? Yes. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: handle network controllers in nonstandard domains
On Wed, Jun 12, 2013 at 3:32 PM, Sean McGovern gsean...@gmail.com wrote: Onboard network controllers are not always on PCI domain 0. Applied it with a couple of trivial changes. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] We are working on trying to scale up to 1000 containers.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 One concern we have is what will happen to systemd if we start 1000 services at boot. systemctl start httpd_sandbox.target For example. Is there anything we can do to throttle the start of so many unit files. Or would systemd do something itself. This will probably cause libvirt problems also. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHAXGkACgkQrlYvE4MpobNXfgCgkT3Sd9XgV387b5GDLuGyweIO K0oAn16rai7GjT9NVI6MK7534qnLRf13 =zmnm -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: make net_id more robust
Op 7 jun. 2013, om 20:25 heeft Kay Sievers k...@vrfy.org het volgende geschreven: On Fri, Jun 7, 2013 at 3:27 PM, Sean McGovern gsean...@gmail.com wrote: Onboard network controllers are not always on PCI domain 0. +sysname = udev_device_get_sysname(names-pcidev); + +if(!sysname) +return -ENOENT; + +if(!strlen(sysname)) +return -ENOENT; None of these checks should be needed. +if(sscanf(sysname, %lx:%x:%x.%d, domain, bus, slot, func) != 4) +return -ENOENT; We only support domain 0, and ignore all other devices so far. What about non-PCI devices, like the netwerk controllers in embedded SoCs? regards, Koen ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Feature wish - auto-complete
As I am lazy I would love to see the auto-complete feature implemented in systemd CLI. Dave. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Feature wish - auto-complete
On Tue, Jun 18, 2013 at 08:44:05AM -0500, David Lambert wrote: As I am lazy I would love to see the auto-complete feature implemented in systemd CLI. Wait, wait, ..., it's already here! Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Feature wish - auto-complete
Am 18.06.2013 15:44, schrieb David Lambert: As I am lazy I would love to see the auto-complete feature implemented in systemd CLI. Dave. Hi Dave, Well, I have autocompletion for systemctl, journalctl, loginctl, *ctl, etc. Are you sure bash-completion is installed and enabled? Regards signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Feature wish - auto-complete
On 13-06-18 08:58 AM, killermoehre wrote: Am 18.06.2013 15:44, schrieb David Lambert: As I am lazy I would love to see the auto-complete feature implemented in systemd CLI. Dave. Hi Dave, Well, I have autocompletion for systemctl, journalctl, loginctl, *ctl, etc. Are you sure bash-completion is installed and enabled? Regards I can auto complete the primary commands such as systemctl, etc. However, I would do not see auto completing further in the command line, such as: systemctl status partofmyservicenametab etc. I am running systemd on Angstrom: systemctl --version systemd 196 angstrom +PAM -LIBWRAP -AUDIT -SELINUX +IMA +SYSVINIT -LIBCRYPTSETUP +GCRYPT +ACL +XZ Dave. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: make net_id more robust
On Tue, Jun 18, 2013 at 3:19 PM, Koen Kooi k...@dominion.thruhere.net wrote: We only support domain 0, and ignore all other devices so far. What about non-PCI devices, like the netwerk controllers in embedded SoCs? I have no idea. This is so far all about PCI only, all the other parent buses are ignored entirely atm. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Feature wish - auto-complete
Am 18.06.2013 16:06, schrieb David Lambert: On 13-06-18 08:58 AM, killermoehre wrote: Am 18.06.2013 15:44, schrieb David Lambert: As I am lazy I would love to see the auto-complete feature implemented in systemd CLI. Dave. Hi Dave, Well, I have autocompletion for systemctl, journalctl, loginctl, *ctl, etc. Are you sure bash-completion is installed and enabled? Regards I can auto complete the primary commands such as systemctl, etc. However, I would do not see auto completing further in the command line, such as: systemctl status partofmyservicenametab etc. *again* install bash-completion and you are done [harry@srv-rhsoft:~]$ systemctl status a acpid.service alsa-store.serviceauditd.service avahi-daemon.socket alsa-restore.service apcupsd.service avahi-daemon.service [harry@srv-rhsoft:~]$ systemctl status a signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Feature wish - auto-complete
On Tue, 18.06.13 09:06, David Lambert (d...@lambsys.com) wrote: I can auto complete the primary commands such as systemctl, etc. However, I would do not see auto completing further in the command line, such as: systemctl status partofmyservicenametab etc. That's also implemented (and has been for at least a year or two). Maybe you aren't running bash or lack the completion support in your bash build? 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] how to get a device name matching .device to use into a dynamic@.unit ?
Kaixo! Li Mon, Jun 17, 2013 at 06:40:54PM +0200, Lennart Poettering scrijha: If firmware loading is a one-time thing you need to execute when the device is plugged in, and is relatively quick to execute there is no need to involve a systemd service and you can simply run this from a udev rule directly. Well, the problem is the loader is a user space program (it seems attemps to integrate a loader in the linux kernel have been rejected) that uses the hci0 (or hci1 or watever) interface to upload the firmware. And I find it more elegant to have systemd call the loader, as then there is a single place where it is called (a single file to edit if the loader program is moved, renamed or its command line options change); plus it has the extra bonus of being able to use systemctl status and journalctl to see if the firmware upload went correctly or not. that being said, if udev is the place to go, it's fine too; but then udev is missing an important feature: it should expose the bdaddr of a bluetooth device in it's normal form (eg: 00:02:72:32:DE:FB ) Should I switch to another mailing-list for further udev ? Thanks -- Ki ça vos våye bén, Pablo Saratxaga http://chanae.walon.org/pablo/ PGP Key available, key ID: 0xD9B85466 pgp_l4aAgvgYn.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] how to get a device name matching .device to use into a dynamic@.unit ?
On Tue, Jun 18, 2013 at 04:54:51PM +0200, Pablo Saratxaga wrote: Kaixo! Li Mon, Jun 17, 2013 at 06:40:54PM +0200, Lennart Poettering scrijha: If firmware loading is a one-time thing you need to execute when the device is plugged in, and is relatively quick to execute there is no need to involve a systemd service and you can simply run this from a udev rule directly. Well, the problem is the loader is a user space program (it seems attemps to integrate a loader in the linux kernel have been rejected) that uses the hci0 (or hci1 or watever) interface to upload the firmware. The kernel now has the firmware loader inside of it, no need to use an external program at all. Unless this is an odd device that needs something else? Any pointers to information about it? thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] how to get a device name matching .device to use into a dynamic@.unit ?
Kaixo! Li Mon, Jun 17, 2013 at 09:58:26AM -0700, Greg KH scrijha: Firmware should be loaded directly from the kernel itself these days, no need for a udev rule, or anything else, it should just work. I would prefer that myself too :) But it seems only Debian ships a kernel with a patch for that loader; and even then some people seem to have trouble and need to manually launch the loader to fix it. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1065400 thanks, greg k-h -- Ki ça vos våye bén, Pablo Saratxaga http://chanae.walon.org/pablo/ PGP Key available, key ID: 0xD9B85466 pgpohZxXA8bC4.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] how to end a socket activated daemon
On Tue, Jun 18, 2013 at 3:04 AM, Łukasz Stelmach l.stelm...@samsung.com wrote: It was 2013-06-17 pon 20:51, when Lennart Poettering wrote: On Fri, 14.06.13 14:33, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Fri, Jun 14, 2013 at 10:03:00AM +0200, Łukasz Stelmach wrote: We are converting some daemons to socket activation. Most of them open unix sockets and manage incoming connections in a main-loop, so the easiest way to convert it is to create Accept=false socket with systemd. Now, it is quite well described how to start such daemon, however, there is little about shutting it down. Should the daemon close(2) the received sockets? Should it unlink(2) them from a filesystem? close() yes, unlink() no. Strictly speaking you don't even have to do that. The kernel will clean up left-over fds when your process exits, hence you don't have to close it explicitly. But you certainly should not unlink() the socket in the fs, because then the socket will not be accessible anymore. Maybe I've asked the wrong question. I should rather have asked: Can I close? Can I unlink? Because that's what the code does now and we wanted to know which parts are common for standalone and systemd-socket-activated paths. The way I think about it is that if you are socket activated, you have a .socket unit and a .service unit. The .socket unit controls the socket. The .service unit does NOT control the socket. Therefore, the .service daemon should NOT unlink the socket. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Inhibiting plug and play
On Tue, Jun 18, 2013 at 01:45:09PM -0400, Phillip Susi wrote: 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? What events are you wishing to inhibit? And who is in control of them? thanks, greg k-h ___ 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 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
[systemd-devel] Inhibiting plug and play
-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? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRwJylAAoJEJrBOlT6nu75TlAH/1Eso89Jta4AFn/ynYZUWwVD xS1Nm8ZbRHQizBFmv5rq5Yunr6XUcUQlux9EeG81QwgJ2mgOAk3XE2ldzOp0lUei cqQYsrdWKHXz8ZXpNG1Jsgw77EUyrs39Z6NmNC+X1AcFbzxRXplGMTJfRSWtW3bw Ngi8MCjKZOx/qNzUcyZnR3tdAF0veLHWtr7j5XvgO+/iomnAxIOcYiSCv1OeDMdX SCx8bULT4/LaRWzbcmpzmh1irMsXavrOwuPzIGBTdMKhByyxnwxiOdIyhOs1OJda 059zK7CxMNidD37ON9hMyMtYz5BeCzZmPJdJ6Ef4G7ZrH++xiI4cGvgVOClP6vI= =Ym1b -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Inhibiting plug and play
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/18/2013 2:03 PM, David Zeuthen wrote: 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. I can't really extract any meaning from this without knowledge of what was tried and what problems it caused. I also don't see why it can't be something as simple as opening the device with O_EXCL. 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. I don't follow. You mean udisks delays auto mounting by 5 seconds? That's not going to help if, for instance, you use gparted to move a partition to the right. It first enlarges the partition, which generates a remove/add event, then starts moving data. 5 seconds later udisks tries to mount the partition, which very well may succeed with horrible consequences. 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. 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. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRwKm1AAoJEJrBOlT6nu75ZqMIAM/EUrDIQQn6O5dlCMAOwGSm h/D5Pbb6amPmDiFELooQgb+BMuUw9bAYwdcukMWZB1MqBTMBOtwLGTeI9TEeWH4y y2c753e2JBgkPnzY6iFkfPXDvsTEIZSHsx00YLZt06aDL5k/Fmt5eN+mD5pSiC2T l1qSdhtEw2IseWVuXOjwjy5K00vIDDAaLG1o2Ff135gNx/wUaOK8nL0vSUZhDK96 V3WS4LGKJDlrGESeAyDELfuExrvtmASgohlpUEy2IK9R9lpNicudStPDZFp+dzCA wv/D1HXkZiIRS74u6Nl3BLtWWd9rPF0ub2OXKCwURYXl2ULE7bPwaiJIdtYp/zo= =BWbx -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] We are working on trying to scale up to 1000 containers.
We have machines with thousands of containers on them. The key for us was understanding that we didn't need thousands of containers to run after start-up; we needed thousands of containers to be *accessible* after start-up. The vast majority of our containers use socket activation or resurrection (a sort of try-to-do-something-and-start-the-corresponding-service-on-failure path we use). That said, I'd be interested in allowing caps on parallelism in systemd. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] how to end a socket activated daemon
On Tue, Jun 18, 2013 at 10:23 AM, Kok, Auke-jan H auke-jan.h@intel.com wrote: Therefore, the .service daemon should NOT unlink the socket. And you can generally prevent the service from having the service unit drop permissions to something that can't delete the socket. The service get get the fd from socket activation and accept connections on it even if it doesn't have permission to unlink the socket. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Feature wish - auto-complete
It definitely works for me on Fedora, but it's terribly slow with 1000+ units. I've been meaning to look into that. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Problems with SWAP in 204
On Wed, Jun 19, 2013 at 12:16 AM, Henrik /KaarPoSoft hen...@kaarposoft.dk wrote: When booting, I get a few errors related to swap; in particular: Failed to reread /proc/swaps: File exists swapon: /dev/sda3: swapon failed: Device or resource busy The output of systemctl --full --all --type=swap might be useful as well. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Problems with SWAP in 204
В Wed, 19 Jun 2013 03:39:39 +0200 Tom Gundersen t...@jklm.no пишет: On Wed, Jun 19, 2013 at 12:16 AM, Henrik /KaarPoSoft hen...@kaarposoft.dk wrote: When booting, I get a few errors related to swap; in particular: Failed to reread /proc/swaps: File exists swapon: /dev/sda3: swapon failed: Device or resource busy The output of systemctl --full --all --type=swap might be useful as well. Should not path_equal() condition be reverted here? if (u SWAP(u)-from_proc_swaps !path_equal(SWAP(u)-parameters_proc_swaps.what, what_proc_swaps)) return -EEXIST; ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Masking socket activated services is broken
Hi, I've run systemctl mask rsyslog.service, but the service can still be started via systemctl start rsyslog.service or by generating a log message. Looks like a bug to me. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
