Re: [systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
Hello all, Robert Milasan [2015-01-12 9:39 +0100]: > 1. add a CD/DVD into the driver > 2. mount the driver: mount /dev/sr0 /mnt/my_cd (ensure you don't > use the Gnome/KDE auto-mounting or reproduce this in a server setup) > 3. eject the media (using the hardware button) and add a new one media > (different disk) > 4. ls /mnt/my_cd (it will be an empty output or the previous media) > > Is this expected? no, it's not. It's been several years since I've actually had a CD drive and looked at this stuff, but this is how it is *supposed* to work today: - Mounting (manually or through udisks) keeps the kernel default policy of locking the door, so that users can't yank out a mounted medium. - *When* the tray is locked (the default), pressing the eject button is supposed to cause a change event with DISK_EJECT_REQUEST. - udev rules (60-cdrom_id.rules) picks that up and calls "eject /dev/srX" on the device; the eject program takes care to unmount everything before physical ejection. Note that the kernel will *not* generate DISK_EJECT_REQUEST uevents if the tray is not locked. Your case sounds exactly like that? I suggest running "udevadm monitor -e --udev", then press the eject button while a CD is mounted, and check whether you get such an uevent. Then clean up (umount, etc.), re-mount, and this time manually lock with "sudo hdparm -L 1 /dev/sr0", and check how it works then? Then you could compare hdparm -L vs. /lib/udev/cdrom_id --lock-media; maybe the former works but not the latter? Or do both report an error that the drive might not support locking? Until a few years ago I've never seen a drive which didn't, but who knows what modern drives do.. > Also, I remember a while back (long time ago) that once you added a > media into the driver and it was properly mounted, you couldn't > eject the media until you unmounted the media. Right, because we didn't have the kernel (or userspace in udisks, as it was before that) polling for eject button presses. But users (IMHO rightfully) complained about the non-working button, and with the current system it's indeed so much more natural (if it works :) ). Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
On Thu, Jan 15, 2015 at 11:03 AM, Martin Pitt wrote: > Hello all, > > Robert Milasan [2015-01-12 9:39 +0100]: >> 1. add a CD/DVD into the driver >> 2. mount the driver: mount /dev/sr0 /mnt/my_cd (ensure you don't >> use the Gnome/KDE auto-mounting or reproduce this in a server setup) >> 3. eject the media (using the hardware button) and add a new one media >> (different disk) >> 4. ls /mnt/my_cd (it will be an empty output or the previous media) >> >> Is this expected? > > no, it's not. It's been several years since I've actually had a CD > drive and looked at this stuff, but this is how it is *supposed* to > work today: > > - Mounting (manually or through udisks) keeps the kernel default >policy of locking the door, so that users can't yank out a mounted >medium. > > - *When* the tray is locked (the default), pressing the eject button is >supposed to cause a change event with DISK_EJECT_REQUEST. > > - udev rules (60-cdrom_id.rules) picks that up and calls "eject >/dev/srX" on the device; the eject program takes care to unmount >everything before physical ejection. > So what's the point of locking tray in the first place if it will be unlocked as soon as you press eject button? > > Right, because we didn't have the kernel (or userspace in udisks, as > it was before that) polling for eject button presses. But users (IMHO > rightfully) complained about the non-working button, and with the > current system it's indeed so much more natural (if it works :) ). > You call it natural that now we apparently do not have any way to actually lock CD tray? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] LLDP: Support locally assigned port subtype
On Thu, Jan 15, 2015 at 9:11 AM, Susant Sahani wrote: > The Zyxel switch sends port subtype as Locally assigned (7). > Add LLDP_PORT_SUBTYPE_LOCALLY_ASSIGNED as supported type > > reported by Mantas Mikulėnas > --- > src/libsystemd-network/lldp-internal.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/libsystemd-network/lldp-internal.c > b/src/libsystemd-network/lldp-internal.c > index f843fd2..c6a989a 100644 > --- a/src/libsystemd-network/lldp-internal.c > +++ b/src/libsystemd-network/lldp-internal.c > @@ -89,6 +89,7 @@ int lldp_read_port_id(tlv_packet *tlv, > case LLDP_PORT_SUBTYPE_PORT_COMPONENT: > case LLDP_PORT_SUBTYPE_INTERFACE_ALIAS: > case LLDP_PORT_SUBTYPE_INTERFACE_NAME: > +case LLDP_PORT_SUBTYPE_LOCALLY_ASSIGNED: > > r = tlv_packet_read_string(tlv, &s, length); > if (r < 0) > -- > 2.1.0 > Tested, works fine. -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd quietly ignores DHCPv6 leases
Hi, On Wed, 2015-01-14 at 16:37 +0100, Barbara Lazarowicz-Steube wrote: > As you can see in it, having received the RA networkd correctly > identifies the local network as managed and fires up the DHCPv6 > client. The client then receives a reply from the server and... does > absolutely nothing with it. Indeed. I so thought I had a patch applied that set the DHCPv6 address for the interface. Apparently such functionality has gone into /dev/null instead, and as a result you will need the next version of the DHCPv6 address assignment patch recently posted on the mailing list. Anyway it is excellent news that DHCPv6 is being used out there! Cheers, Patrik ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl status not showing still running processes in inactive .mount unit cgroups (NFS specifically)
Steve Dickson wrote on 15/01/15 00:50: > Hello, > > On 01/12/2015 04:43 PM, Colin Guthrie wrote: >> >> But FWIW, your check for whether systemctl is installed via calling >> "systemctl --help" is IMO not very neat. >> >> If you're using bash here anyway, you might as well just do a: >> >> if [ -d /sys/fs/cgroup/systemd ]; then >> >> type check or if you want to be super sure you could do: >> >> if mountpoint -q /sys/fs/cgroup/systemd; then >> >> This is a simple trick to detect if systemd is running. If systemctl is >> then not found, then I'd be pretty surprised (but your code would >> continue if the call fails anyway, so this should be safe). >> >> This avoids one more fork. >> >> Technicaly you could avoid calling "systemctl start" by calling >> "systemctl is-active" first, but to be honest this isn't really needed. > I took Michael advice and used 'test -d /run/systemd/system' Seems best indeed yes. Thanks (to both!) :) Although if the script is in bash I'd use "if [ -d ..." rather than "if test -d ..." as (and bash experts (Harald?) can correct me here if I'm wrong) I believe [ is a bash built in (even if it is a binary in /usr/bin/), whereas it would have to fork out to run "test". That seems to work OK (from a practical perspective things worked OK and I got my mount) but are obviously sub optimal, especially when the mount point is unmounted. In my case, I called umount but the rpc.statd process was still running: >>> What is the expectation? When the umount should bring down rpc.statd? >> >> If it started it's own instance, it should IMO kill it again on umount, >> but I was more talking about the systemd context here. If the >> start-statd thing had done it's job correctly we wouldn't have gotten >> into this situation in the first place (as rpc-statd.service would have >> been started and contained it's own rpc.statd process happily!t's >> >> I don't really know how it should work on non-systemd systems as in that >> case I presume start-statd is called for each mount there (forgive me if >> I'm wrong) and thus you'd likely end up with lots of rpc.statd processes >> running, especially if you do lots of mount/umount cycles on a given >> share. Perhaps all you need to do is some very, very minimal fallback >> support here? e.g. checking the pid file and that the process of that >> pid is an rpc.statd process and only actually start it if it's not >> already running? > Well, there is code in rpc.statd, sm-notify and mount.nfs that checks > to see if a rpc.statd is already running... But the code appears > to be a bit racy since in very a few environments, multiple rpc.statds > are being started up... Yeah, I actually doubted myself the other day when I made a suggestion regarding doing some code to make sure only one was running... I later remembered that rpc.statd had a pid file and thus must have this stuff sort of built in (and I remember seeing messages along the lines of rpc.statd is already running). I guess the reason I got two was due to the extreme parallelism that systemd offers on boot. My two mounts (with the faulty start-statd) must have come in at almost the same time and triggered the race in rpc.statd startup and I got two processes. I don't suppose there is much we can do about that other than teaching rpc.statd to be less racy, but to be honest, this should be avoided with systemd now (thanks to the fixed start-statd) and other inits probably won't trigger the race condition, so, practically speaking, it's probably one to quietly ignore... at least for this list :D >> For systemd systems generally all that would happen is you've have a lot >> of redundant calls to systemctl start, but they should generally be >> harmless. > Well, the environment I just described, where multiple statd getting > started which are going using systemd to do the start ups. On systemd systems, it should all be fine yes. It's only really a problem when on non-systemd systems now that start-statd is working properly! >> FWIW, I think there are a number of issues with the systemd units >> upstream. If you're interested in some feedback here is a small snippet. >> I'm happy to do some patches for you if you'd be willing to apply them. > Always... But I would like to have this conversation with the > NFS community at linux-...@vger.kernel.org. Maybe you could post > your ideas there? In a new thread? Sure I will do! >> Main issues are: >> >> 1. nfs-utils.service really is an abuse. It should be a nfs-utils.target >> (the comment inside aludes to the fact this is know, and it's just that >> you want "systemctl restart nfs-utils" to "just work" as a command. I >> can see the desire, but it's still an abuse. Perhaps someone would be >> willing to write a patch that does expansion to .service or .target >> should the unit type not be specified? Dunno how hard it would be tho' > Well we did make the nfs-client a target but the nfs-server was made > a service... I r
Re: [systemd-devel] systemctl status not showing still running processes in inactive .mount unit cgroups (NFS specifically)
Ross Lagerwall wrote on 14/01/15 22:41: > On Mon, Jan 12, 2015 at 09:04:35PM +0300, Andrei Borzenkov wrote: >> В Mon, 12 Jan 2015 10:34:07 + >> Colin Guthrie пишет: >> >>> >>> Anyway, assuming the process is in the .mount unit cgroup, should >>> systemd detect the umount and kill the processes accordingly, and if >> >> It does not do it currently. It only starts killing if (u)mount times >> out. Otherwise if umount is successful it goes to stopped state >> immediately. Although it probably should, even for the sake of user >> space helpers. >> >>> not, should calling "systemctl status" on .mount units show processes >>> even if it's in an inactive state? >>> >> >> I believe something very similar (not only for mount units) was >> reported recently, but I do not have reference handy. I mean, processes >> belonging to stopped unit (e.g. with KillMode=none) are not displayed. >> > > This commit is probably needed: > > http://cgit.freedesktop.org/systemd/systemd/commit/?id=dab5bf859900c0abdbf78c584e4aed42a19768cd That indeed looks like a likely candidate. I'll try breaking things again and checking status output with this patch applied. Thanks! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
On Thu, 2015-01-15 at 09:03 +0100, Martin Pitt wrote: > - udev rules (60-cdrom_id.rules) picks that up and calls "eject >/dev/srX" on the device; the eject program takes care to unmount >everything before physical ejection. > > Note that the kernel will *not* generate DISK_EJECT_REQUEST uevents if > the tray is not locked. Your case sounds exactly like that? No, the events are generated. And it is processed. There is just no unmounting. But what is the motivation of in effect disabling door locking? Regards Oliver ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
Andrei Borzenkov [2015-01-15 11:24 +0300]: > So what's the point of locking tray in the first place if it will be > unlocked as soon as you press eject button? So that we can do a clean unmount and avoid the situation in the original post :-) Also, we can delay or fail the unlocking and ejection if the device is busy, e. g. during burning. With the eject button directly working without telling userspace, we could never lock it during writing, nor do a clean unmounting. > > Right, because we didn't have the kernel (or userspace in udisks, as > > it was before that) polling for eject button presses. But users (IMHO > > rightfully) complained about the non-working button, and with the > > current system it's indeed so much more natural (if it works :) ). > > > > You call it natural that now we apparently do not have any way to > actually lock CD tray? Well, you deny someone with physical access the usage of a physical button. For any read-only mount I don't consider that friendly. Locking is of course desirable (and ought to work) if the device is being written to. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
Oliver Neukum [2015-01-15 11:31 +0100]: > No, the events are generated. And it is processed. > There is just no unmounting. That sounds like a bug/missing feature in cdrom_id --eject-media then. You could try and replace it with /usr/bin/eject, which does the unmounting of all partitions first, fail on busy, and does the eject at last? > But what is the motivation of in effect disabling door locking? We don't -- we specifically leave it locked so that we get the "eject button pressed" events. (See my other response for some details). Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
On Thu, 15 Jan 2015 11:31:48 +0100 "Oliver Neukum" wrote: > On Thu, 2015-01-15 at 09:03 +0100, Martin Pitt wrote: > > - udev rules (60-cdrom_id.rules) picks that up and calls "eject > >/dev/srX" on the device; the eject program takes care to unmount > >everything before physical ejection. > > > > Note that the kernel will *not* generate DISK_EJECT_REQUEST uevents > > if the tray is not locked. Your case sounds exactly like that? > > No, the events are generated. And it is processed. > There is just no unmounting. > > But what is the motivation of in effect disabling door locking? > > Regards > Oliver > > Unmounting usually happens, but only in the desktop environment, most probably because of udisk2 or whatever is called. In console mode or server mode lets say, if the media is mounted (usually manually) it is not unmounted if I press the eject button on the driver, on the other hand it is not unmounted even if I would use eject command, because none of this commands or the hardware button are aware of the media being mounted and it also makes sense. In Gnome/KDE the mount is not done by user but by the actual software, using most probably fuse or something like that and Gnome/KDE is aware when the disk is ejected, similar to a USB stick (I might be wrong). -- Robert Milasan L3 Support Engineer SUSE Linux (http://www.suse.com) email: rmila...@suse.com GPG fingerprint: B6FE F4A8 0FA3 3040 3402 6FE7 2F64 167C 1909 6D1A ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
On Thu, 15 Jan 2015 11:39:36 +0100 "Robert Milasan" wrote: > On Thu, 15 Jan 2015 11:31:48 +0100 > "Oliver Neukum" wrote: > > > On Thu, 2015-01-15 at 09:03 +0100, Martin Pitt wrote: > > > - udev rules (60-cdrom_id.rules) picks that up and calls "eject > > >/dev/srX" on the device; the eject program takes care to > > > unmount everything before physical ejection. > > > > > > Note that the kernel will *not* generate DISK_EJECT_REQUEST > > > uevents if the tray is not locked. Your case sounds exactly like > > > that? > > > > No, the events are generated. And it is processed. > > There is just no unmounting. > > > > But what is the motivation of in effect disabling door locking? > > > > Regards > > Oliver > > > > > > Unmounting usually happens, but only in the desktop environment, most > probably because of udisk2 or whatever is called. > In console mode or server mode lets say, if the media is mounted > (usually manually) it is not unmounted if I press the eject button on > the driver, on the other hand it is not unmounted even if I would use > eject command, because none of this commands or the hardware button > are aware of the media being mounted and it also makes sense. In > Gnome/KDE the mount is not done by user but by the actual software, > using most probably fuse or something like that and Gnome/KDE is > aware when the disk is ejected, similar to a USB stick (I might be > wrong). > > Sorry, eject command is aware and it will unmount the media if mounted. My bad. -- Robert Milasan L3 Support Engineer SUSE Linux (http://www.suse.com) email: rmila...@suse.com GPG fingerprint: B6FE F4A8 0FA3 3040 3402 6FE7 2F64 167C 1909 6D1A ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
On Thu, 15 Jan 2015 11:38:33 +0100 "Martin Pitt" wrote: > Oliver Neukum [2015-01-15 11:31 +0100]: > > No, the events are generated. And it is processed. > > There is just no unmounting. > > That sounds like a bug/missing feature in cdrom_id --eject-media then. > You could try and replace it with /usr/bin/eject, which does the > unmounting of all partitions first, fail on busy, and does the eject > at last? > > > But what is the motivation of in effect disabling door locking? > > We don't -- we specifically leave it locked so that we get the "eject > button pressed" events. (See my other response for some details). > > Martin We could add the unmount functionality also to cdrom_id if we are on the subject. -- Robert Milasan L3 Support Engineer SUSE Linux (http://www.suse.com) email: rmila...@suse.com GPG fingerprint: B6FE F4A8 0FA3 3040 3402 6FE7 2F64 167C 1909 6D1A ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
On Thu, 2015-01-15 at 11:38 +0100, Martin Pitt wrote: > Oliver Neukum [2015-01-15 11:31 +0100]: > > No, the events are generated. And it is processed. > > There is just no unmounting. > > That sounds like a bug/missing feature in cdrom_id --eject-media then. > You could try and replace it with /usr/bin/eject, which does the > unmounting of all partitions first, fail on busy, and does the eject > at last? That does work. > > But what is the motivation of in effect disabling door locking? > > We don't -- we specifically leave it locked so that we get the "eject > button pressed" events. (See my other response for some details). Well, yes, but why is policy that should be left to the GUI placed into udev? Regards Oliver ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 0/3] Miscellaneous systemd changes (v2)
On 01/14/2015 10:46 AM, Steve Dickson wrote: > v2: > * Corrected the numerous BindTo typos > > Here are a few systemd changes that were suggested > by the systemd folks: > >* Bind the nfs-idmap service to the nfs server. >* Correctly bind nfs-mountd service to the nfs server. >* Used approved way to check if systemd is install and running > > Steve Dickson (3): > systemd: Bind rpc.idmapd to the nfs-server service > systemd: Bind the nfs-mountd service to the nfs-server service > start-statd: Use the canonical to check if systemd is running. > > systemd/nfs-idmapd.service | 2 +- > systemd/nfs-mountd.service | 3 +-- > utils/statd/start-statd| 2 +- > 3 files changed, 3 insertions(+), 4 deletions(-) > All three committed steved. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
On Thu, 15 Jan 2015 12:00:15 +0100
"Oliver Neukum" wrote:
> On Thu, 2015-01-15 at 11:38 +0100, Martin Pitt wrote:
> > Oliver Neukum [2015-01-15 11:31 +0100]:
> > > No, the events are generated. And it is processed.
> > > There is just no unmounting.
> >
> > That sounds like a bug/missing feature in cdrom_id --eject-media
> > then. You could try and replace it with /usr/bin/eject, which does
> > the unmounting of all partitions first, fail on busy, and does the
> > eject at last?
>
> That does work.
>
> > > But what is the motivation of in effect disabling door locking?
> >
> > We don't -- we specifically leave it locked so that we get the
> > "eject button pressed" events. (See my other response for some
> > details).
>
> Well, yes, but why is policy that should be left to the GUI placed
> into udev?
>
> Regards
> Oliver
>
>
What about this little bundle of joy, the patch I mean, of course.
Please check attachment :)
Might need work, but the basic idea seems to work, at least in my tests.
--
Robert Milasan
L3 Support Engineer
SUSE Linux (http://www.suse.com)
email: rmila...@suse.com
GPG fingerprint: B6FE F4A8 0FA3 3040 3402 6FE7 2F64 167C 1909 6D1A
>From 59b5e141bb5a5ad99d6492c3764c220334a8833f Mon Sep 17 00:00:00 2001
From: Robert Milasan
Date: Thu, 15 Jan 2015 12:21:10 +0100
Subject: [PATCH] cdrom_id: unmount media if mount on --eject-media
Signed-off-by: Robert Milasan
---
src/udev/cdrom_id/cdrom_id.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/src/udev/cdrom_id/cdrom_id.c b/src/udev/cdrom_id/cdrom_id.c
index 6052f6a..50e6a42 100644
--- a/src/udev/cdrom_id/cdrom_id.c
+++ b/src/udev/cdrom_id/cdrom_id.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include "libudev.h"
@@ -200,6 +201,24 @@ static int media_lock(struct udev *udev, int fd, bool lock)
return err;
}
+static int media_umount(const char *node)
+{
+int err;
+
+if (!node)
+return -1;
+
+if (is_mounted(node)) {
+err = umount(node);
+if (err < 0) {
+log_debug("umount failed\n");
+return err;
+}
+}
+
+return 0;
+}
+
static int media_eject(struct udev *udev, int fd)
{
struct scsi_cmd sc;
@@ -971,6 +990,8 @@ work:
if (eject) {
log_debug("PREVENT_ALLOW_MEDIUM_REMOVAL (unlock)");
media_lock(udev, fd, false);
+log_debug("UNMOUNT_MEDIA (umount)\n");
+media_umount(node);
log_debug("START_STOP_UNIT (eject)");
media_eject(udev, fd);
}
--
1.8.4.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd quietly ignores DHCPv6 leases
On 2015-01-15 09:58, Patrik Flykt wrote: > Indeed. I so thought I had a patch applied that set the DHCPv6 address > for the interface. Apparently such functionality has gone into /dev/null > instead, and as a result you will need the next version of the DHCPv6 > address assignment patch recently posted on the mailing list. The "DHCPv6 address assignment" patch set from two days ago? I see there are still some changes for you to make there so I'll keep an eye out for the final version and once it has been pushed to Git, I'll apply it locally and let you know whether it has fixed the problem. > Anyway it is excellent news that DHCPv6 is being used out there! It is excellent systemd-networkd supports DHCPv6! The fact it only does so nominally at the moment is a minor thing, teething problems do happen. -- MS ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
On Thu, 15 Jan 2015 12:22:50 +0100 "Robert Milasan" wrote: > On Thu, 15 Jan 2015 12:00:15 +0100 > "Oliver Neukum" wrote: > > > On Thu, 2015-01-15 at 11:38 +0100, Martin Pitt wrote: > > > Oliver Neukum [2015-01-15 11:31 +0100]: > > > > No, the events are generated. And it is processed. > > > > There is just no unmounting. > > > > > > That sounds like a bug/missing feature in cdrom_id --eject-media > > > then. You could try and replace it with /usr/bin/eject, which does > > > the unmounting of all partitions first, fail on busy, and does the > > > eject at last? > > > > That does work. > > > > > > But what is the motivation of in effect disabling door locking? > > > > > > We don't -- we specifically leave it locked so that we get the > > > "eject button pressed" events. (See my other response for some > > > details). > > > > Well, yes, but why is policy that should be left to the GUI placed > > into udev? > > > > Regards > > Oliver > > > > > > What about this little bundle of joy, the patch I mean, of course. > Please check attachment :) > > Might need work, but the basic idea seems to work, at least in my > tests. > Forget about the patch. If we are using cdrom_id from the console, it actually works and unmounts the media, but not from within a udev rule. Need to see why and will get back. -- Robert Milasan L3 Support Engineer SUSE Linux (http://www.suse.com) email: rmila...@suse.com GPG fingerprint: B6FE F4A8 0FA3 3040 3402 6FE7 2F64 167C 1909 6D1A ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl status not showing still running processes in inactive .mount unit cgroups (NFS specifically)
On 15.01.2015 10:28, Colin Guthrie wrote: > Although if the script is in bash I'd use "if [ -d ..." rather than "if > test -d ..." as (and bash experts (Harald?) can correct me here if I'm > wrong) I believe [ is a bash built in (even if it is a binary in > /usr/bin/), whereas it would have to fork out to run "test". If you don't write "/usr/bin/test", then bash will use the builtin "test". $ help test test: test [expr] Evaluate conditional expression. so [ -d ] and test -d are basically equal. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Readahead collect - root filesystem only?
Hi all, Is it true that readahead collector defaults to only collect files within root filesystem? If so, is it possible to instruct it to also collect for e.g. /home (mounted on a separate media)? This is not mentioned anywhere in the docs. It probably should be? Thank you, Nikolai ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl status not showing still running processes in inactive .mount unit cgroups (NFS specifically)
On 15/01/15 09:28, Colin Guthrie wrote: > Although if the script is in bash I'd use "if [ -d ..." rather than "if > test -d ..." as (and bash experts (Harald?) can correct me here if I'm > wrong) I believe [ is a bash built in (even if it is a binary in > /usr/bin/), whereas it would have to fork out to run "test". bash, dash, zsh and busybox sh all have both "test" and "[" as builtins, at least as they're configured on Debian (and presumably Ubuntu too). No idea about more obscure shells like ksh, but there's really no good reason to implement one and not the other. GNU coreutils provides /usr/bin/test and /usr/bin/[ as a fallback, but they'd rarely be used. Here's how you tell: smcv@archetype:~$ type [ [ is a shell builtin smcv@archetype:~$ type test test is a shell builtin smcv@archetype:~$ type dd # a random non-builtin for comparison dd is /bin/dd S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Readahead collect - root filesystem only?
El 15/01/15 a las 09:38, Nikolai Zhubr escribió: Hi all, Is it true that readahead collector defaults to only collect files within root filesystem? If so, is it possible to instruct it to also collect for e.g. /home (mounted on a separate media)? This is not mentioned anywhere in the docs. It probably should be? The readahead collector is no longer included in systemd. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH udev v5] udev: Add builtin/rule to export evdev information as udev properties
Hi On Mon, Jan 12, 2015 at 5:52 AM, Zbigniew Jędrzejewski-Szmek wrote: > On Sun, Jan 11, 2015 at 08:47:19PM +0100, Carlos Garnacho wrote: >> This rule is only run on tablet/touchscreen devices, and extracts their size >> in millimeters, as it can be found out through their struct input_absinfo. >> >> The first usecase is exporting device size from tablets/touchscreens. This >> may be useful to separate policy and application at the time of mapping >> these devices to the available outputs in windowing environments that don't >> offer that information as readily (eg. Wayland). This way the compositor can >> stay deterministic, and the mix-and-match heuristics are performed outside. >> >> Conceivably, size/resolution information can be changed through EVIOCSABS >> anywhere else, but we're only interested in values prior to any calibration, >> this rule is thus only run on "add", and no tracking of changes is performed. >> This should only remain a problem if calibration were automatically applied >> by an earlier udev rule (read: don't). >> >> v2: Folded rationale into commit log, made a builtin, set properties >> on device nodes themselves >> v3: Use inline function instead of macro for mm. size calculation, >> use DECIMAL_STR_MAX, other code style issues >> v4: Made rule more selective >> v5: Minor style issues, renamed to a more generic builtin, refined >> rule further. > Applied. After some more discussion (sorry for being late), I now merged it into input_id. You can now run input_id on any input sysfs path and it will do the right thing. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Readahead collect - root filesystem only?
Hi, 15.01.2015 16:07, Cristian Rodríguez: The readahead collector is no longer included in systemd. Hm. It is still there in not-very-old opensuse 13.2 ... Anyway. Where has it gone then? Is it a separate tool now or got obsoleted by something else? I actually just started to like it... Quite a usefull thing... Thank you, Nikolai ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Readahead collect - root filesystem only?
Am 15.01.2015 um 14:40 schrieb Nikolai Zhubr: 15.01.2015 16:07, Cristian Rodríguez: The readahead collector is no longer included in systemd. Hm. It is still there in not-very-old opensuse 13.2 ... Anyway. Where has it gone then? Is it a separate tool now or got obsoleted by something else? I actually just started to like it... Quite a usefull thing... it was completly removed with no replacement by assuming eveorybody in a short term will use only SSD drives http://lists.freedesktop.org/archives/systemd-devel/2014-August/022002.html 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] Readahead collect - root filesystem only?
On Thu, Jan 15, 2015 at 02:31:22PM +0100, Reindl Harald wrote: > > Am 15.01.2015 um 14:40 schrieb Nikolai Zhubr: > >15.01.2015 16:07, Cristian Rodríguez: > >>The readahead collector is no longer included in systemd. > > > >Hm. It is still there in not-very-old opensuse 13.2 ... > >Anyway. Where has it gone then? Is it a separate tool now or got > >obsoleted by something else? > >I actually just started to like it... Quite a usefull thing... > > it was completly removed with no replacement by assuming eveorybody > in a short term will use only SSD drives > > http://lists.freedesktop.org/archives/systemd-devel/2014-August/022002.html That's not the complete story. The other is that there were issues with it, and nobody was working on them. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Readahead collect - root filesystem only?
Am 15.01.2015 um 14:33 schrieb Zbigniew Jędrzejewski-Szmek: On Thu, Jan 15, 2015 at 02:31:22PM +0100, Reindl Harald wrote: Am 15.01.2015 um 14:40 schrieb Nikolai Zhubr: 15.01.2015 16:07, Cristian Rodríguez: The readahead collector is no longer included in systemd. Hm. It is still there in not-very-old opensuse 13.2 ... Anyway. Where has it gone then? Is it a separate tool now or got obsoleted by something else? I actually just started to like it... Quite a usefull thing... it was completly removed with no replacement by assuming eveorybody in a short term will use only SSD drives http://lists.freedesktop.org/archives/systemd-devel/2014-August/022002.html That's not the complete story. The other is that there were issues with it, and nobody was working on them that's all fine but why the heck was there a need to include it in systemd, replace the all the years existing readahead daemon from Fedora and then abandon and remove it finally? that's one reason why so many people are annoyed be systemd take over more and more components far away from an init-daemon and if systemd-upstream later decides that part is no longer interesting and nobody has a need to use it like readahead what happens then? 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] Readahead collect - root filesystem only?
El jue, 15-01-2015 a las 14:38 +0100, Reindl Harald escribió:
> Am 15.01.2015 um 14:33 schrieb Zbigniew Jędrzejewski-Szmek:
> > On Thu, Jan 15, 2015 at 02:31:22PM +0100, Reindl Harald wrote:
> >> Am 15.01.2015 um 14:40 schrieb Nikolai Zhubr:
> >>> 15.01.2015 16:07, Cristian Rodríguez:
> The readahead collector is no longer included in systemd.
> >>>
> >>> Hm. It is still there in not-very-old opensuse 13.2 ...
> >>> Anyway. Where has it gone then? Is it a separate tool now or got
> >>> obsoleted by something else?
> >>> I actually just started to like it... Quite a usefull thing...
> >>
> >> it was completly removed with no replacement by assuming eveorybody
> >> in a short term will use only SSD drives
> >>
> >> http://lists.freedesktop.org/archives/systemd-devel/2014-August/022002.html
> >
> > That's not the complete story. The other is that there were issues
> > with it, and nobody was working on them
>
> that's all fine
>
> but why the heck was there a need to include it in systemd, replace the
> all the years existing readahead daemon from Fedora and then abandon and
> remove it finally?
>
> that's one reason why so many people are annoyed be systemd take over
> more and more components far away from an init-daemon and if
> systemd-upstream later decides that part is no longer interesting and
> nobody has a need to use it like readahead what happens then?
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
I have been able to compile, install and run only the readahead part
from systemd-216 with newer systemd as I would still
want to run it (I don't have any SSD device and I still notice its
action when booting + login in my Gnome session... also I neither plan
to renew my main laptop or try to change its harddisk).
The problem is that I don't know how could I
make the systemd-readahead-done part to work as systemd-notify dropped
the readahead support:
http://cgit.freedesktop.org/systemd/systemd/diff/src/notify/notify.c?id=d6bc8348d5be8576a475ac8ced2b0146e60fb71f
Anyway, I got surprised by /.readahead looking to not grow more a bit
after booting (without "done" it should supposedly grow forever). One
workaround could be to call systemd-readahead-collect with the --timeout
option and hardcode there a value (a bit like e4rat behaves) but I am
not sure if something better could be done :/
From the old manpage I can see this info about "-done":
systemd-readahead-done.service is executed a short while after
boot completed and signals systemd-readahead-collect.service to end data
collection. On this signal, this service will then sort the
collected disk accesses and store information about them in /.readahead.
Reading the -collect .service file, looks like manually creating
a /run/systemd/readahead/done file should stop the service but I would
appreciate if anyone with more knowledge could confirm :|
The full drop commit is:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=d6bc8348d5be8576a475ac8ced2b0146e60fb71f
And looking to the readahead-collect.c part:
http://cgit.freedesktop.org/systemd/systemd/diff/src/readahead/readahead-collect.c?id=d6bc8348d5be8576a475ac8ced2b0146e60fb71f
Seems that playing with /run/systemd/readahead/{cancel,done,noreplay}
files should be enough, then, maybe I could create a shell wrapper to
mimic "systemd-notify --readahead" and use that to create the desired
files under /run/systemd/readahead.
Thanks a lot for your help
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Readahead collect - root filesystem only?
El 15/01/15 a las 10:40, Nikolai Zhubr escribió: Hi, 15.01.2015 16:07, Cristian Rodríguez: The readahead collector is no longer included in systemd. Hm. It is still there in not-very-old opensuse 13.2 ... for whatever reason, current openSUSE releases have systemd 210.. that's old. Anyway. Where has it gone then? Is it a separate tool now or got obsoleted by something else? It is gone, has no replacement. I actually just started to like it... Quite a usefull thing... Not very useful unfortunately, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Readahead collect - root filesystem only?
On Thu, Jan 15, 2015 at 2:38 PM, Reindl Harald wrote: > > Am 15.01.2015 um 14:33 schrieb Zbigniew Jędrzejewski-Szmek: >> >> On Thu, Jan 15, 2015 at 02:31:22PM +0100, Reindl Harald wrote: >>> >>> Am 15.01.2015 um 14:40 schrieb Nikolai Zhubr: 15.01.2015 16:07, Cristian Rodríguez: > > The readahead collector is no longer included in systemd. Hm. It is still there in not-very-old opensuse 13.2 ... Anyway. Where has it gone then? Is it a separate tool now or got obsoleted by something else? I actually just started to like it... Quite a usefull thing... >>> >>> >>> it was completly removed with no replacement by assuming eveorybody >>> in a short term will use only SSD drives >>> >>> >>> http://lists.freedesktop.org/archives/systemd-devel/2014-August/022002.html >> >> >> That's not the complete story. The other is that there were issues >> with it, and nobody was working on them > > > that's all fine > > but why the heck was there a need to include it in systemd, replace the all > the years existing readahead daemon from Fedora and then abandon and remove > it finally? > > that's one reason why so many people are annoyed be systemd take over more > and more components far away from an init-daemon and if systemd-upstream > later decides that part is no longer interesting and nobody has a need to > use it like readahead what happens then? The problem was that no one worked on the readahead tool. Regardless of what repository it lived in. My understanding is that systemd-readahead was the best tool out there, so anyone could still resurrect that if they want to (but my understanding is that there are no one with both the interest and the opportunity to work in it a the moment). Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Readahead collect - root filesystem only?
Hi, 15.01.2015 16:31, Reindl Harald: [...] it was completly removed with no replacement by assuming eveorybody in a short term will use only SSD drives http://lists.freedesktop.org/archives/systemd-devel/2014-August/022002.html Thanks. The reasoning may well be valid, but this still does not give a warm feeling... Thank you, Nikolai ___ 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
[systemd-devel] [PATCH] cdrom_id: unmount media on --eject-media if media mounted
Signed-off-by: Robert Milasan
---
src/udev/cdrom_id/cdrom_id.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/src/udev/cdrom_id/cdrom_id.c b/src/udev/cdrom_id/cdrom_id.c
index 6052f6a..72a1357 100644
--- a/src/udev/cdrom_id/cdrom_id.c
+++ b/src/udev/cdrom_id/cdrom_id.c
@@ -217,6 +217,39 @@ static int media_eject(struct udev *udev, int fd)
return 0;
}
+static int media_umount(const char *node)
+{
+int err = 0;
+
+if (!node) {
+err = -1;
+goto exit;
+}
+
+if (is_mounted(node)) {
+pid_t pid;
+
+pid = fork();
+switch (pid) {
+case 0:
+err = execl("/bin/umount", "/bin/umount",
node, NULL);
+if (err < 0) {
+log_error("umount failed\n");
+goto exit;
+}
+case -1:
+log_error("failed to fork\n");
+err = -1;
+break;
+default:
+break;
+}
+}
+
+exit:
+return err;
+}
+
static int cd_capability_compat(struct udev *udev, int fd)
{
int capability;
@@ -969,6 +1002,8 @@ work:
}
if (eject) {
+log_debug("UNMOUNT_MEDIA (umount)\n");
+media_umount(node);
log_debug("PREVENT_ALLOW_MEDIUM_REMOVAL (unlock)");
media_lock(udev, fd, false);
log_debug("START_STOP_UNIT (eject)");
--
1.8.4.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cdrom_id: unmount media on --eject-media if media mounted
Hey Robert,
thanks for working on this!
Robert Milasan [2015-01-15 15:24 +0100]:
> +err = execl("/bin/umount", "/bin/umount",
> node, NULL);
If this succeeds, umount will completely "take over" the process, and
cdrom_id is gone.
This also isn't sufficient if there are multiple partitions, which
even on CDs/DVDs isn't that uncommon (especially for operating
systems).
So I think this should instead find all mount points that belong to
target, and call umount2(target, MNT_DETACH) on them. The actual
"eject" program does that.
... which leads me to the question: why don't we just call the actual
"eject" program? Just to avoid that dependency?
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cdrom_id: unmount media on --eject-media if media mounted
On Thu, 15 Jan 2015 15:42:28 +0100
"Martin Pitt" wrote:
> Hey Robert,
>
> thanks for working on this!
>
> Robert Milasan [2015-01-15 15:24 +0100]:
> > +err = execl("/bin/umount", "/bin/umount",
> > node, NULL);
>
> If this succeeds, umount will completely "take over" the process, and
> cdrom_id is gone.
>
> This also isn't sufficient if there are multiple partitions, which
> even on CDs/DVDs isn't that uncommon (especially for operating
> systems).
>
> So I think this should instead find all mount points that belong to
> target, and call umount2(target, MNT_DETACH) on them. The actual
> "eject" program does that.
No its not, eject uses umount binary also, but yes it tries to find all
submounts too (I haven't seen a scenario like that).
I've tried using umount or umount2 function, but I need the actual
mount point, which would need another function to find it or find them.
>
> ... which leads me to the question: why don't we just call the actual
> "eject" program? Just to avoid that dependency?
Yes, we could do this, I didn't think of it :)
>
> Thanks,
>
> Martin
>
--
Robert Milasan
L3 Support Engineer
SUSE Linux (http://www.suse.com)
email: rmila...@suse.com
GPG fingerprint: B6FE F4A8 0FA3 3040 3402 6FE7 2F64 167C 1909 6D1A
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Add support for "ROOT=" on the kernel command line
From: Harald Hoyer
"ROOT=" mounts the initial ramdisk with a tmpfs filesystem.
---
src/fstab-generator/fstab-generator.c | 5 +
src/gpt-auto-generator/gpt-auto-generator.c | 7 +++
2 files changed, 12 insertions(+)
diff --git a/src/fstab-generator/fstab-generator.c
b/src/fstab-generator/fstab-generator.c
index bc4c155..3d2e4dd 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -498,6 +498,11 @@ static int parse_proc_cmdline_item(const char *key, const
char *value) {
if (free_and_strdup(&arg_root_what, value) < 0)
return log_oom();
+} else if (streq(key, "ROOT") && value) {
+
+if (free_and_strdup(&arg_root_what, value) < 0)
+return log_oom();
+
} else if (streq(key, "rootfstype") && value) {
if (free_and_strdup(&arg_root_fstype, value) < 0)
diff --git a/src/gpt-auto-generator/gpt-auto-generator.c
b/src/gpt-auto-generator/gpt-auto-generator.c
index 909fdda..85ceffd 100644
--- a/src/gpt-auto-generator/gpt-auto-generator.c
+++ b/src/gpt-auto-generator/gpt-auto-generator.c
@@ -613,6 +613,13 @@ static int parse_proc_cmdline_item(const char *key, const
char *value) {
arg_root_enabled = streq(value, "gpt-auto");
+} else if (streq(key, "ROOT") && value) {
+
+/* Disable root disk logic if there's a ROOT= value
+ * specified (unless it happens to be "gpt-auto") */
+
+arg_root_enabled = streq(value, "gpt-auto");
+
} else if (streq(key, "rw") && !value)
arg_root_rw = true;
else if (streq(key, "ro") && !value)
--
2.2.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] LLDP: Support locally assigned port subtype
Thanks to both. Pushed! On Thu, Jan 15, 2015 at 9:33 AM, Mantas Mikulėnas wrote: > On Thu, Jan 15, 2015 at 9:11 AM, Susant Sahani wrote: >> >> The Zyxel switch sends port subtype as Locally assigned (7). >> Add LLDP_PORT_SUBTYPE_LOCALLY_ASSIGNED as supported type >> >> reported by Mantas Mikulėnas >> --- >> src/libsystemd-network/lldp-internal.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/src/libsystemd-network/lldp-internal.c >> b/src/libsystemd-network/lldp-internal.c >> index f843fd2..c6a989a 100644 >> --- a/src/libsystemd-network/lldp-internal.c >> +++ b/src/libsystemd-network/lldp-internal.c >> @@ -89,6 +89,7 @@ int lldp_read_port_id(tlv_packet *tlv, >> case LLDP_PORT_SUBTYPE_PORT_COMPONENT: >> case LLDP_PORT_SUBTYPE_INTERFACE_ALIAS: >> case LLDP_PORT_SUBTYPE_INTERFACE_NAME: >> +case LLDP_PORT_SUBTYPE_LOCALLY_ASSIGNED: >> >> r = tlv_packet_read_string(tlv, &s, length); >> if (r < 0) >> -- >> 2.1.0 > > > Tested, works fine. > > -- > Mantas Mikulėnas > > ___ > 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] Add support for "ROOT=" on the kernel command line
On 15.01.2015 16:24, har...@redhat.com wrote: > From: Harald Hoyer > > "ROOT=" mounts the initial ramdisk with a tmpfs filesystem. Ok, not true. Omitting "root=" will mount the initial ramdisk as a tmpfs filesystem, if tmpfs support is compiled in the kernel. Seems like the preferred way of having the initrd as tmpfs, is to specify "ROOT=" instead of "root=". ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add support for "ROOT=" on the kernel command line
On 15.01.2015 16:45, Harald Hoyer wrote: > On 15.01.2015 16:24, har...@redhat.com wrote: >> From: Harald Hoyer >> >> "ROOT=" mounts the initial ramdisk with a tmpfs filesystem. > > Ok, not true. Omitting "root=" will mount the initial ramdisk as a tmpfs > filesystem, if tmpfs support is compiled in the kernel. > > Seems like the preferred way of having the initrd as tmpfs, is to specify > "ROOT=" instead of "root=". > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6e19eded3684dc184181093af3bff2ff440f5b53 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cdrom_id: unmount media on --eject-media if media mounted
On Thu, 15.01.15 15:24, Robert Milasan (rmila...@suse.com) wrote:
> Signed-off-by: Robert Milasan
Humm, I am not convinced that this is really a good idea, first of all
it's pretty incomplete, given that there atons of ways how a device
can be kept busy, and mounts are just one of it. And even mounts might
keept things busy in many different ways, for example because of
overlayfs, or inner bind mounts or whatnot...
I think the best way to fix this is in the kernel properly. And if the
kernel folks are not willing to do add code for that, then I think
it's still better to make sure systemd unmounts it. It can do so
asynchronously, simply via the right dependencies. In fact, are you
sure that this isn't handled properly yet anyway? The .mount units
would just need a BindsTo= on the .device units, and the right thing
should happen?
> +static int media_umount(const char *node)
> +{
> +int err = 0;
> +
> +if (!node) {
> +err = -1;
> +goto exit;
> +}
Please never return "fake" error codes like -1 in new code. We use
negative errno pretty universally these days.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cdrom_id: unmount media on --eject-media if media mounted
On Thu, 15 Jan 2015 17:05:54 +0100 "Lennart Poettering" wrote: > > I think the best way to fix this is in the kernel properly. And if the > kernel folks are not willing to do add code for that, then I think > it's still better to make sure systemd unmounts it. It can do so > asynchronously, simply via the right dependencies. In fact, are you > sure that this isn't handled properly yet anyway? The .mount units > would just need a BindsTo= on the .device units, and the right thing > should happen? > Got no clue, didn't try. I never said that adding the code to cdrom_id is the best idea, but it's an idea. If there are better ways, I prefer them too. -- Robert Milasan L3 Support Engineer SUSE Linux (http://www.suse.com) email: rmila...@suse.com GPG fingerprint: B6FE F4A8 0FA3 3040 3402 6FE7 2F64 167C 1909 6D1A ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cdrom_id: unmount media on --eject-media if media mounted
On Thu, Jan 15, 2015 at 5:13 PM, Robert Milasan wrote: > On Thu, 15 Jan 2015 17:05:54 +0100 > "Lennart Poettering" wrote: >> >> I think the best way to fix this is in the kernel properly. And if the >> kernel folks are not willing to do add code for that, then I think >> it's still better to make sure systemd unmounts it. It can do so >> asynchronously, simply via the right dependencies. In fact, are you >> sure that this isn't handled properly yet anyway? The .mount units >> would just need a BindsTo= on the .device units, and the right thing >> should happen? >> > > Got no clue, didn't try. > > I never said that adding the code to cdrom_id is the best idea, but > it's an idea. If there are better ways, I prefer them too. The best idea is probably to start to describe the exact problem. And adding *why* it is needed to a patch or git subject. The *what* is it doing is usually pretty easy to find in the changed code, the *why* isn't. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add support for "ROOT=" on the kernel command line
On 15.01.2015 16:51, Harald Hoyer wrote: > On 15.01.2015 16:45, Harald Hoyer wrote: >> On 15.01.2015 16:24, har...@redhat.com wrote: >>> From: Harald Hoyer >>> >>> "ROOT=" mounts the initial ramdisk with a tmpfs filesystem. >> >> Ok, not true. Omitting "root=" will mount the initial ramdisk as a tmpfs >> filesystem, if tmpfs support is compiled in the kernel. >> >> Seems like the preferred way of having the initrd as tmpfs, is to specify >> "ROOT=" instead of "root=". >> > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6e19eded3684dc184181093af3bff2ff440f5b53 > > Thinking more about it, this would also require uppercase ROOTFSTYPE and ROOTFSFLAGS to not conflict with the new definition in the kernel of "root" as being the tmpfs. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Fix systemd crash (on assert) during shutdown/reboot in unprivileged container
Hello,
The last big issue I'm running into when running systemd in an
unprivileged LXC container is that it's crashing on an assert in the
shutdown/reboot path right after unmounting all devices.
That's because due to mknod not being allowed inside a user namespace,
we have to bind-mount all the required device nodes from the host's /dev on
top of empty files in the container's /dev.
This all works great until systemd unmounts everything. At which point,
all of those are 0 byte files. Systemd then opens /dev/urandom and
attempts to read some bytes from there, gets 0 bytes back and trips an
assertion.
To fix that, I've got two different approaches, both with an associated
patch attached to this e-mail:
- 0001-Add-dev-urandom-to-ignore_paths.patch:
This very simply adds /dev/urandom to the ignore_paths list alongside
/dev/console. That way all the other mount entries are unmounted but
/dev/urandom isn't, fixing the issue we're currently seeing.
- 0001-Ignore-devices-bind-mounts.patch:
This one is a more generic take on the problem and should be more
future-proof. Rather than hardcoding /dev/urandom, it extends the
existing mount_point_ignore function to ignore any mountpoint which is a
character or block device.
I tend to prefer the latter because it's future-proof and avoids
hardcoding paths, however it certainly is more likely to have
side-effects than the first (though I can't think of any obvious one).
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
From ef87932352d505b477c27c40f33af6015ea2b2b5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?St=C3=A9phane=20Graber?=
Date: Thu, 15 Jan 2015 12:04:54 -0500
Subject: [PATCH] Add /dev/urandom to ignore_paths
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
systemd opens /dev/urandom during the shutdown sequence after it's done
unmounting everything. If /dev/urandom is a bind-mounted file, that will
unmount it and systemd will then crash on an assert when attempting to
read some random bytes and getting 0 back.
Signed-off-by: Stéphane Graber
---
src/core/mount-setup.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/core/mount-setup.c b/src/core/mount-setup.c
index bd3a035..b8ada98 100644
--- a/src/core/mount-setup.c
+++ b/src/core/mount-setup.c
@@ -130,6 +130,7 @@ static const char ignore_paths[] =
/* Container bind mounts */
"/proc/sys\0"
"/dev/console\0"
+"/dev/urandom\0"
"/proc/kmsg\0";
bool mount_point_is_api(const char *path) {
--
1.9.1
From 251cd89d77befb77238e4f6dd7903adcc8bbf035 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?St=C3=A9phane=20Graber?=
Date: Thu, 15 Jan 2015 10:45:28 -0500
Subject: [PATCH] Ignore devices bind-mounts
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Devices bind-mounts are typically used in unprivileged containers where
mknod isn't possible.
On those systems, all entries under /dev are empty files with the device
node bind-mounted on top.
Current systemd code will unmount all of those during the shutdown
sequence even though systemd may still need them, ultimately leading to
crashes in the shutdown/reboot sequence.
Signed-off-by: Stéphane Graber
---
src/core/mount-setup.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/core/mount-setup.c b/src/core/mount-setup.c
index bd3a035..faa7ab2 100644
--- a/src/core/mount-setup.c
+++ b/src/core/mount-setup.c
@@ -147,11 +147,21 @@ bool mount_point_is_api(const char *path) {
bool mount_point_ignore(const char *path) {
const char *i;
+struct stat st;
+/* Skip any mountpoint that's listed in ignore_paths */
NULSTR_FOREACH(i, ignore_paths)
if (path_equal(path, i))
return true;
+/* Additionaly skip any block/character device bind-mount as
+ those can't possibly be blocking anything and are very likely
+ to be required by systemd itself. */
+if (lstat(path, &st) == 0 &&
+(st.st_mode & S_IFBLK || st.st_mode & S_IFCHR)) {
+return true;
+}
+
return false;
}
--
1.9.1
signature.asc
Description: Digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] units: move machines.target to dist_systemunit_DATA
2014-12-30 0:22 GMT+01:00 Filipe Brandenburger : > Move units/machines.target from nodist_systemunit_DATA to > dist_systemunit_DATA, > since it's not a generated file. Otherwise, `make clean` would remove the > committed copy of the file. > > Tested that `./autogen.sh c` will not remove it and that `make distcheck` > works > after this fix. > --- Hi, Another patch has been applied fixing the same issue: 699b7227a2faeb9818e90e90837794aef18f9bef Thanks > Makefile.am | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Makefile.am b/Makefile.am > index 8cdf1db..c12f2f6 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -506,6 +506,7 @@ dist_systemunit_DATA = \ > units/systemd-udevd-control.socket \ > units/systemd-udevd-kernel.socket \ > units/system-update.target \ > + units/machines.target \ > units/initrd-switch-root.target > > if ENABLE_KDBUS > @@ -549,7 +550,6 @@ nodist_systemunit_DATA = \ > units/initrd-udevadm-cleanup-db.service \ > units/initrd-switch-root.service \ > units/systemd-nspawn@.service \ > - units/machines.target \ > units/systemd-update-done.service > > if HAVE_UTMP > -- > 1.8.3.1 > > ___ > 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] Fix systemd crash (on assert) during shutdown/reboot in unprivileged container
On Thu, 15.01.15 12:14, Stéphane Graber (stgra...@ubuntu.com) wrote: > Hello, > > The last big issue I'm running into when running systemd in an > unprivileged LXC container is that it's crashing on an assert in the > shutdown/reboot path right after unmounting all devices. > > That's because due to mknod not being allowed inside a user namespace, > we have to bind-mount all the required device nodes from the host's /dev on > top of empty files in the container's /dev. > > This all works great until systemd unmounts everything. At which point, > all of those are 0 byte files. Systemd then opens /dev/urandom and > attempts to read some bytes from there, gets 0 bytes back and trips an > assertion. > > > To fix that, I've got two different approaches, both with an associated > patch attached to this e-mail: > - 0001-Add-dev-urandom-to-ignore_paths.patch: >This very simply adds /dev/urandom to the ignore_paths list alongside >/dev/console. That way all the other mount entries are unmounted but >/dev/urandom isn't, fixing the issue we're currently seeing. > > - 0001-Ignore-devices-bind-mounts.patch: >This one is a more generic take on the problem and should be more >future-proof. Rather than hardcoding /dev/urandom, it extends the >existing mount_point_ignore function to ignore any mountpoint which is a >character or block device. I think I'd prefer if we simply would avoid unmounting anything that sits below /sys, /dev, /proc. i.e. a simple path_startswith() check before the unmount... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Wierd Segfault in sd_rtnl_message_unref (libnss_myhostname.so.2 by sshd )
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Tom,
I will be happy to run different tests, but I need a serious amount of
handholding, as I haven't done this kind of work for ages...
You could start with how I run it through Valgrind... (which I do have
installed, but no clue how to use in this context...)
Svenne
On 13-01-2015 23:33, Tom Gundersen wrote:
> Hi Svenne,
>
> On Mon, Jan 12, 2015 at 10:08 PM, Svenne Krap
wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Hi.
>>
>> On Arch X64 using 218-1 (first packaging of 218) I have run into the
>> following wierd problem.
>>
>> When trying to connect to a ssh server running dualstack (both ipv4 and
>> ipv6) by ipv6, ssh segfaults when I have loaded the full ipv4 bgp
>> routing table (~500k+ routes). IPv4 connections works for some reason,
>> and Ipv6 recovers if I kill the routing daemon (bird).
>>
>> The stack trace of the core-file starts with
>>
>> Stack trace of thread 515:
>> #0 0x7f48334a3dd5 _int_free (libc.so.6)
>> #1 0x7f4834a1e62a sd_rtnl_message_unref (libnss_myhostname.so.2)
>> #2 0x7f4834a1e657 sd_rtnl_message_unref (libnss_myhostname.so.2)
>>
>> And continues with that line (#1 and #2) until frame 63.
>>
>> I have looked in src/libsystemd/sd-rtnl/rtnl-message.c and have two
>> observations (my C is very rusty so feel free to correct me).
>>
>> Line 589, shouldn't the line
>> if (m && REFCNT_DEC(m->n_ref) <= 0) {
>>
>> be
>>
>> if (m && REFCNT_DEC(m->n_ref) >= 0) {
>>
>> (I.e. greater-than-equal instead of less-than-equal)
>
> As Zbigniew explained, this is actually correct, but misleading. I
> fixed it to use equality now, which should hopefully make it clearer.
>
> Any chance you could run this through valgrind to get a bit more info
> about what's going wrong?
>
>> Also, perhaps a test of whether m->next is equal to m on line 597
>
> Hm, well, if there is a loop in the message list we are in trouble,
> but checking just for two messages pointing at each other is not
> enough, as the loop could be bigger. That said, such a loop can only
> happen if there is a real bug in our code, so I don't think we should
> be checking for that all the time.
>
> Thanks for the report!
>
> Tom
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQI5BAEBCAAjBQJUuBQPHBpodHRwOi8vc3Zlbm5lLmRrL3BncC9wb2xpY3kACgkQ
/zLSj+olL/J/9w//VsorJ1y93yQzSw5SiOegSEr1tZulWP4v41mNRW32ufx22uaz
5KnBbUaokyueArHw2iNRoYpydSK/7yadp/hU9yFTwVnwEuwd/PwFSzPuIpdye2Xz
STpIAlu4bBYgP5I4Tmue64VZDXxmrj24BbHd0yM5ycwApGxMtTdYnvrzfeRv0Hkf
B0G6W/uRmYkFs2/oFf/4brhikK1EZuZzJPeV0v77SCQBxFyVrllwFcvnoW3cyFMa
Co5Mz+5vgCpA2J8mOMFSTDJ3S+kUe6iwS1N5ijC3cM8mvIsQKEGG6xzKJ+mlLkdz
J5E7OHoqBT7rEvKBq0LcHMsOC0wpIb9SG3YtXNeUuJNGm01FM0tvqyP57q63DW0r
vH7u4y75DMQHeM0e/0uEuCiLVb1FHxQxH49NdwhLhFbA8hR6dq6nFL1zB0XnMTvi
lPZdAnEv0WKkkMEVsWH1xABvoYF+VxV3DE/g1Ju/SUW2xmHNQABsp6RB9roDPrGF
8u9FnCbpu/QjM7C4MQR1OH1Z6r4sE/hLcDeNkBQRQRk//8V4W7AkIWQoi7clEAyi
OsJc4YQVfIAebFDRukIEd3xKhNvgsH5ERPQSJPJ8FE/2BwXb8b7qzbiJyTfjQQLs
RWq2zm1rB2UXjZtazEsZFx9VLmwly9blPolpXxSDYHSMp/uBMSS3KrXj2vk=
=kUqi
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] missing: add macros for OFD locks
--- src/shared/missing.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/src/shared/missing.h b/src/shared/missing.h index cdc38b2..d074405 100644 --- a/src/shared/missing.h +++ b/src/shared/missing.h @@ -79,6 +79,12 @@ #define F_SEAL_WRITE0x0008 /* prevent writes */ #endif +#ifndef F_OFD_GETLK +#define F_OFD_GETLK 36 +#define F_OFD_SETLK 37 +#define F_OFD_SETLKW38 +#endif + #ifndef MFD_ALLOW_SEALING #define MFD_ALLOW_SEALING 0x0002U #endif -- 2.0.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] networkd: accept a trailing '.' on the end of domains
While not common outside of BIND configs the implied top level '.' in
domains is commonly accepted and crops up in random places. Starting
with commit 784d9b9c networkd began validating domains as hostnames
which rejects trailing dots, breaking short name resolution in some
environments such as Google Compute Engine. This change splits the
validation code into two functions to be more tolerant for domains.
---
src/libsystemd-network/sd-dhcp-lease.c | 2 +-
src/network/networkd-network.c | 2 +-
src/shared/util.c | 13 ++---
src/shared/util.h | 1 +
src/test/test-util.c | 14 ++
5 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/src/libsystemd-network/sd-dhcp-lease.c
b/src/libsystemd-network/sd-dhcp-lease.c
index 00fef16..53a329e 100644
--- a/src/libsystemd-network/sd-dhcp-lease.c
+++ b/src/libsystemd-network/sd-dhcp-lease.c
@@ -502,7 +502,7 @@ int dhcp_lease_parse_options(uint8_t code, uint8_t len,
const uint8_t *option,
if (r < 0)
return r;
-if (!hostname_is_valid(domainname) || is_localhost(domainname))
+if (!domainname_is_valid(domainname) ||
is_localhost(domainname))
break;
free(lease->domainname);
diff --git a/src/network/networkd-network.c b/src/network/networkd-network.c
index 34a06d3..1c4c1ff 100644
--- a/src/network/networkd-network.c
+++ b/src/network/networkd-network.c
@@ -407,7 +407,7 @@ int config_parse_domains(const char *unit,
STRV_FOREACH(domain, *domains) {
if (is_localhost(*domain))
log_syntax(unit, LOG_ERR, filename, line, EINVAL,
"'localhost' domain names may not be configured, ignoring assignment: %s",
*domain);
-else if (!hostname_is_valid(*domain)) {
+else if (!domainname_is_valid(*domain)) {
if (!streq(*domain, "*"))
log_syntax(unit, LOG_ERR, filename, line,
EINVAL, "domain name is not valid, ignoring assignment: %s", *domain);
} else
diff --git a/src/shared/util.c b/src/shared/util.c
index 884e782..9e03da4 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -4231,7 +4231,7 @@ static bool hostname_valid_char(char c) {
c == '.';
}
-bool hostname_is_valid(const char *s) {
+bool domainname_is_valid(const char *s) {
const char *p;
bool dot;
@@ -4252,10 +4252,17 @@ bool hostname_is_valid(const char *s) {
}
}
-if (dot)
+if (p-s > HOST_NAME_MAX)
return false;
-if (p-s > HOST_NAME_MAX)
+return true;
+}
+
+bool hostname_is_valid(const char *s) {
+if (!domainname_is_valid(s))
+return false;
+
+if (s[strlen(s)-1] == '.')
return false;
return true;
diff --git a/src/shared/util.h b/src/shared/util.h
index fdb9fb6..e332239 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -547,6 +547,7 @@ bool nulstr_contains(const char*nulstr, const char *needle);
bool plymouth_running(void);
bool hostname_is_valid(const char *s) _pure_;
+bool domainname_is_valid(const char *s) _pure_;
char* hostname_cleanup(char *s, bool lowercase);
bool machine_name_is_valid(const char *s) _pure_;
diff --git a/src/test/test-util.c b/src/test/test-util.c
index 4bb5154..010d93b 100644
--- a/src/test/test-util.c
+++ b/src/test/test-util.c
@@ -539,6 +539,20 @@ static void test_hostname_is_valid(void) {
assert_se(!hostname_is_valid(""));
}
+static void test_domainname_is_valid(void) {
+assert_se(domainname_is_valid("foobar"));
+assert_se(domainname_is_valid("foobar."));
+assert_se(domainname_is_valid("foobar.com"));
+assert_se(domainname_is_valid("foobar.com."));
+assert_se(!domainname_is_valid("fööbar"));
+assert_se(!domainname_is_valid(""));
+assert_se(!domainname_is_valid("."));
+assert_se(!domainname_is_valid(".."));
+assert_se(!domainname_is_valid(".foobar"));
+assert_se(!domainname_is_valid("foo..bar"));
+
assert_se(!domainname_is_valid(""));
+}
+
static void test_u64log2(void) {
assert_se(u64log2(0) == 0);
assert_se(u64log2(8) == 3);
--
2.0.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix systemd crash (on assert) during shutdown/reboot in unprivileged container
On Thu, Jan 15, 2015 at 07:20:55PM +0100, Lennart Poettering wrote:
> On Thu, 15.01.15 12:14, Stéphane Graber (stgra...@ubuntu.com) wrote:
>
> > Hello,
> >
> > The last big issue I'm running into when running systemd in an
> > unprivileged LXC container is that it's crashing on an assert in the
> > shutdown/reboot path right after unmounting all devices.
> >
> > That's because due to mknod not being allowed inside a user namespace,
> > we have to bind-mount all the required device nodes from the host's /dev on
> > top of empty files in the container's /dev.
> >
> > This all works great until systemd unmounts everything. At which point,
> > all of those are 0 byte files. Systemd then opens /dev/urandom and
> > attempts to read some bytes from there, gets 0 bytes back and trips an
> > assertion.
> >
> >
> > To fix that, I've got two different approaches, both with an associated
> > patch attached to this e-mail:
> > - 0001-Add-dev-urandom-to-ignore_paths.patch:
> >This very simply adds /dev/urandom to the ignore_paths list alongside
> >/dev/console. That way all the other mount entries are unmounted but
> >/dev/urandom isn't, fixing the issue we're currently seeing.
> >
> > - 0001-Ignore-devices-bind-mounts.patch:
> >This one is a more generic take on the problem and should be more
> >future-proof. Rather than hardcoding /dev/urandom, it extends the
> >existing mount_point_ignore function to ignore any mountpoint which is a
> >character or block device.
>
> I think I'd prefer if we simply would avoid unmounting anything that
> sits below /sys, /dev, /proc. i.e. a simple path_startswith() check
> before the unmount...
>
> Lennart
Something like that?
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
From efbb09d4b0be9a059e4a0444ceeedb873c598b31 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?St=C3=A9phane=20Graber?=
Date: Thu, 15 Jan 2015 19:22:06 -0500
Subject: [PATCH] Skip anything in dev, sys or proc on unmount
When getting around to unmounting things, don't actually call
/sbin/umount for anything inside /dev, /sys or /proc.
You really shouldn't have any block device mounted in there and any
remaining mount may well be used by systemd itself during the last few
steps of shutdown.
---
src/core/mount.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/core/mount.c b/src/core/mount.c
index 612d150..4de878e 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -871,6 +871,14 @@ static void mount_enter_unmounting(Mount *m) {
m->control_command_id = MOUNT_EXEC_UNMOUNT;
m->control_command = m->exec_command + MOUNT_EXEC_UNMOUNT;
+/* Ignore any mounts under /dev, /proc or /sys */
+if (path_startswith(m->where, "/dev/") ||
+path_startswith(m->where, "/proc/") ||
+path_startswith(m->where, "/sys/")) {
+mount_set_state(m, MOUNT_DEAD);
+return;
+}
+
r = exec_command_set(m->control_command, "/bin/umount", m->where, NULL);
if (r >= 0 && UNIT(m)->manager->running_as == SYSTEMD_SYSTEM)
r = exec_command_append(m->control_command, "-n", NULL);
--
1.9.1
signature.asc
Description: Digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
В Thu, 15 Jan 2015 11:36:33 +0100 Martin Pitt пишет: > Andrei Borzenkov [2015-01-15 11:24 +0300]: > > So what's the point of locking tray in the first place if it will be > > unlocked as soon as you press eject button? > > So that we can do a clean unmount and avoid the situation in the > original post :-) Also, we can delay or fail the unlocking and > ejection if the device is busy, e. g. during burning. With the eject > button directly working without telling userspace, we could never lock > it during writing, nor do a clean unmounting. > > > > Right, because we didn't have the kernel (or userspace in udisks, as > > > it was before that) polling for eject button presses. But users (IMHO > > > rightfully) complained about the non-working button, and with the > > > current system it's indeed so much more natural (if it works :) ). > > > > > > > You call it natural that now we apparently do not have any way to > > actually lock CD tray? > > Well, you deny someone with physical access the usage of a physical > button. Yes. This is the whole point of locking tray. > For any read-only mount I don't consider that friendly. When you are performing installation and someone passing by ejects installation media from your system? Sure, it is mush more friendly. Tray is locked because it is in use. How can udev know mount point is not being used right now? > Locking is of course desirable (and ought to work) if the device is > being written to. > Locking is desirable when you have long term work from CD and want to make sure it is not interrupted. It does not matter whether this is reading or writing. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
