Re: [systemd-devel] systemd pam and O_CLOEXEC problem
On Mon, May 5, 2014 at 6:48 AM, dedede gfgfgf trtrtrtrtrtr wrote: Investigations showed that since in pam module we started to dup fifo descriptor problem appeared. Dup does not set O_CLOEXEC flag. So after fork/exec all children processes have that descriptor and when parent which open pam session dies, children processes continue to run. I think you should change your login program to close unnecessary FDs before executing children. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] rules: add by-parttypeuuid rule for GPT labeled partitions
The Ceph OSD initialization relies on identifying GPT partitions by type in order to mount data volumes and start daemons. Currently we ship this rule separately, but it is awkward to duplicate the conditional logic that precedes this block and it would be much simpler if it were simply included in the upstream rules. Signed-off-by: Sage Weil --- rules/60-persistent-storage.rules |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/rules/60-persistent-storage.rules b/rules/60-persistent-storage.rules index 475b151..42f5edb 100644 --- a/rules/60-persistent-storage.rules +++ b/rules/60-persistent-storage.rules @@ -80,9 +80,10 @@ ENV{ID_FS_USAGE}=="filesystem|other", ENV{ID_FS_LABEL_ENC}=="?*", SYMLINK+="disk ENV{DEVTYPE}=="disk", ENV{ID_WWN_WITH_EXTENSION}=="?*", SYMLINK+="disk/by-id/wwn-$env{ID_WWN_WITH_EXTENSION}" ENV{DEVTYPE}=="partition", ENV{ID_WWN_WITH_EXTENSION}=="?*", SYMLINK+="disk/by-id/wwn-$env{ID_WWN_WITH_EXTENSION}-part%n" -# by-partlabel/by-partuuid links (partition metadata) +# by-partlabel/by-partuuid/by-parttypeuuid links (partition metadata) ENV{ID_PART_ENTRY_SCHEME}=="gpt", ENV{ID_PART_ENTRY_UUID}=="?*", SYMLINK+="disk/by-partuuid/$env{ID_PART_ENTRY_UUID}" ENV{ID_PART_ENTRY_SCHEME}=="gpt", ENV{ID_PART_ENTRY_NAME}=="?*", SYMLINK+="disk/by-partlabel/$env{ID_PART_ENTRY_NAME}" +ENV{ID_PART_ENTRY_SCHEME}=="gpt", ENV{ID_PART_ENTRY_TYPE}=="?*", ENV{ID_PART_ENTRY_UUID}=="?*", SYMLINK+="disk/by-parttypeuuid/$env{ID_PART_ENTRY_TYPE}.$env{ID_PART_ENTRY_UUID}" # add symlink to GPT root disk ENV{ID_PART_ENTRY_SCHEME}=="gpt", ENV{ID_PART_GPT_AUTO_ROOT}=="1", SYMLINK+="gpt-auto-root" -- 1.7.9.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] rules: add by-parttypeuuid rule for GPT labeled partitions
On Fri, May 9, 2014 at 11:31 PM, Sage Weil wrote: > The Ceph OSD initialization relies on identifying GPT partitions by type > in order to mount data volumes and start daemons. Currently we ship this > rule separately, but it is awkward to duplicate the conditional logic that > precedes this block and it would be much simpler if it were simply included > in the upstream rules. Types are by definition not unique. The symlinks in /dev/disk/by-*/ are *expected* to be unique. We handle duplicated labels, but they are specified by humans, multiple partitions with the same GPT types are just normal expected behavior; and they would have no order or priority, they just overwrite each other depending on probing order. We should not add such things, the logic to find these volumes at bootup are better handled by a specific program like systemd's systemd-gpt-auto-generator, without putting unreliable and unpredictable content into /dev. http://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/ Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] rules: add by-parttypeuuid rule for GPT labeled partitions
Hi Kay, On Fri, 9 May 2014, Kay Sievers wrote: > On Fri, May 9, 2014 at 11:31 PM, Sage Weil wrote: > > The Ceph OSD initialization relies on identifying GPT partitions by type > > in order to mount data volumes and start daemons. Currently we ship this > > rule separately, but it is awkward to duplicate the conditional logic that > > precedes this block and it would be much simpler if it were simply included > > in the upstream rules. > > Types are by definition not unique. The symlinks in /dev/disk/by-*/ > are *expected* to be unique. > > We handle duplicated labels, but they are specified by humans, > multiple partitions with the same GPT types are just normal expected > behavior; and they would have no order or priority, they just > overwrite each other depending on probing order. This is why the label has both the type (fixed, to identify this as a ceph partition) and the label (random): /dev/disk/by-parttypeuuid/$env{ID_PART_ENTRY_TYPE}.$env{ID_PART_ENTRY_UUID} > We should not add such things, the logic to find these volumes at > bootup are better handled by a specific program like systemd's > systemd-gpt-auto-generator, without putting unreliable and > unpredictable content into /dev. I think this is what we're trying to accomplish with the ceph-disk tool, which relies on these (reliable and predictable) symlinks. The labels alone (by-partuuid) aren't sufficient since we want to be able to scan for partitions of a given type without re-running blkid on every volume. Right now sysvinit, upstart, and udev may trigger ceph-disk to activate volumes. Hopefully we'll have native systemd support sometime soon. But first I want to make sure the approach has been validated, and hopefully avoid shipping custom rules... Thanks! sage ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] rules: add by-parttypeuuid rule for GPT labeled partitions
On Sat, May 10, 2014 at 12:00 AM, Sage Weil wrote: > On Fri, 9 May 2014, Kay Sievers wrote: >> On Fri, May 9, 2014 at 11:31 PM, Sage Weil wrote: >> > The Ceph OSD initialization relies on identifying GPT partitions by type >> > in order to mount data volumes and start daemons. Currently we ship this >> > rule separately, but it is awkward to duplicate the conditional logic that >> > precedes this block and it would be much simpler if it were simply included >> > in the upstream rules. >> >> Types are by definition not unique. The symlinks in /dev/disk/by-*/ >> are *expected* to be unique. >> >> We handle duplicated labels, but they are specified by humans, >> multiple partitions with the same GPT types are just normal expected >> behavior; and they would have no order or priority, they just >> overwrite each other depending on probing order. > > This is why the label has both the type (fixed, to identify this as a ceph > partition) and the label (random): > > /dev/disk/by-parttypeuuid/$env{ID_PART_ENTRY_TYPE}.$env{ID_PART_ENTRY_UUID} > >> We should not add such things, the logic to find these volumes at >> bootup are better handled by a specific program like systemd's >> systemd-gpt-auto-generator, without putting unreliable and >> unpredictable content into /dev. > > I think this is what we're trying to accomplish with the ceph-disk tool, > which relies on these (reliable and predictable) symlinks. The labels > alone (by-partuuid) aren't sufficient since we want to be able to scan for > partitions of a given type without re-running blkid on every volume. /dev is an API which should by default not contain custom links which are not generally useful, and these links are not useful for other tools. These links are not even recognizable by type without doing readdir() over it and string match operations to find the types, we really should not add such stuff to the default rules set. We have to be careful here, it seems like the wrong approach to put that in the public visible /dev API. Tools can get all this information programatically out of the udev database, there is no create symlinks or to run blkid. Ultimately, there is nothing wrong with tools shipping their own rules, but please do not use generic names like /dev/disk/by-parttypeuuid/. The name does even sound misleading because it combines two different things in one name, with a '.' as a separator. Why don't you just use a leading directory for the type instead of stuffing that into one name? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] rules: add by-parttypeuuid rule for GPT labeled partitions
On Sat, 10 May 2014, Kay Sievers wrote: > On Sat, May 10, 2014 at 12:00 AM, Sage Weil wrote: > > On Fri, 9 May 2014, Kay Sievers wrote: > >> On Fri, May 9, 2014 at 11:31 PM, Sage Weil wrote: > >> > The Ceph OSD initialization relies on identifying GPT partitions by type > >> > in order to mount data volumes and start daemons. Currently we ship this > >> > rule separately, but it is awkward to duplicate the conditional logic > >> > that > >> > precedes this block and it would be much simpler if it were simply > >> > included > >> > in the upstream rules. > >> > >> Types are by definition not unique. The symlinks in /dev/disk/by-*/ > >> are *expected* to be unique. > >> > >> We handle duplicated labels, but they are specified by humans, > >> multiple partitions with the same GPT types are just normal expected > >> behavior; and they would have no order or priority, they just > >> overwrite each other depending on probing order. > > > > This is why the label has both the type (fixed, to identify this as a ceph > > partition) and the label (random): > > > > /dev/disk/by-parttypeuuid/$env{ID_PART_ENTRY_TYPE}.$env{ID_PART_ENTRY_UUID} > > > >> We should not add such things, the logic to find these volumes at > >> bootup are better handled by a specific program like systemd's > >> systemd-gpt-auto-generator, without putting unreliable and > >> unpredictable content into /dev. > > > > I think this is what we're trying to accomplish with the ceph-disk tool, > > which relies on these (reliable and predictable) symlinks. The labels > > alone (by-partuuid) aren't sufficient since we want to be able to scan for > > partitions of a given type without re-running blkid on every volume. > > /dev is an API which should by default not contain custom links which > are not generally useful, and these links are not useful for other > tools. FWIW I was surprised that there wasn't already a way to find partitions by type in /dev, but I assume you know better than I how other tools are using udev. It seems at least as useful as by-partuuid to me. > These links are not even recognizable by type without doing readdir() > over it and string match operations to find the types, we really > should not add such stuff to the default rules set. We have to be > careful here, it seems like the wrong approach to put that in the > public visible /dev API. > > Tools can get all this information programatically out of the udev > database, there is no create symlinks or to run blkid. I just looked up libudev and it looks like there is even a pyudev wrapper, so that could indeed work better. I take it that queries via udev_enumerate for (say) ID_PART_ENTRY_TYPE=x are efficient? > Ultimately, there is nothing wrong with tools shipping their own > rules, but please do not use generic names like > /dev/disk/by-parttypeuuid/. The name does even sound misleading > because it combines two different things in one name, with a '.' as a > separator. > > Why don't you just use a leading directory for the type instead of > stuffing that into one name? I'd happily replace the . with /. I suspect I wasn't sure at the time if nested directories were handled properly. Anyway, libudev + pyudev looks like a better solution for ceph-disk. Thanks! sage ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel