Re: [systemd-devel] [PATCH] sd-bus: make sure type=error messages are also dumped
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1432885691-22650-1-git-send-email-umut.tezduyar%40axis.com -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl as non-root
On Fri, May 29, 2015 at 11:05 AM, Umut Tezduyar Lindskog u...@tezduyar.com wrote: On May 28, 2015 2:28 PM, aaron_wri...@selinc.com wrote: I'm working on an embedded system, and I ran into a situation where a non-root user needs to runs systemctl, but when I try I get: ~ $ systemctl status Failed to get D-Bus connection: No such file or directory So, I try with the suid bit on systemctl set, but then I get: ~ $ systemctl status Failed to read server status: Operation not permitted My question is, is something broken, or is this expected behavior? If you do not use D-Bus daemon systemd will be listening on private socket. In this case the only check it does is that peer runs as UID=0 (note - not EUID, so suid does not really help). I think with or without dbus systemd listens on the private socket (/run/systemd/private). No, private socket is used only as fallback when full D-Bus is not available. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl as non-root
On 29 May 2015 at 01:21, aaron_wri...@selinc.com wrote: Brandon Philips bran...@ifup.co wrote on 05/28/2015 05:10:33 PM: Access to the system dbus is controlled by dbus policies. You will need to write a policy for giving this user access to the systemd1 object. I compiled systemd without dbus support (--disable-dbus), and there is no dbus daemon or dbus lib on the system. Is that a requirement to get the functionality I want? I didn't see much need for dbus as the system works quite well without it. Well, except for this of course. the term dbus is used loosely and it's a few distinct things. On the most basic level, it's used as a marshalling/demarshling format of messages passed to/from systemd, on the protocol level this is exposed via private socket or systemd may join the system bus which is operated by something, e.g. kdbus or the dbus1 daemon. When there is a dbus daemon available policy can be checked and enforced and e.g. unprivilledged users can be granted to execute certain actions on per dbus api level. Further more policykit can be used in conjunction with that to seamlessly ask to elevate / allow more privileged api calls. However just on the private systemd socket these complex measures are not available and one really needs to be root... ... if not done carefully, it is easy to introduce vulnerabilities into the system e.g. if one allows unprivileged things start/stop privileged jobs. On May 28, 2015 2:28 PM, aaron_wri...@selinc.com wrote: I'm working on an embedded system, and I ran into a situation where a non-root user needs to runs systemctl, but when I try I get: ~ $ systemctl status Failed to get D-Bus connection: No such file or directory So, I try with the suid bit on systemctl set, but then I get: ~ $ systemctl status Failed to read server status: Operation not permitted My question is, is something broken, or is this expected behavior? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Regards, Dimitri. Pura Vida! https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl as non-root
On Fri, May 29, 2015 at 10:23 AM, Andrei Borzenkov arvidj...@gmail.com wrote:
On Fri, May 29, 2015 at 11:05 AM, Umut Tezduyar Lindskog
u...@tezduyar.com wrote:
On May 28, 2015 2:28 PM, aaron_wri...@selinc.com wrote:
I'm working on an embedded system, and I ran into a situation where
a non-root user needs to runs systemctl, but when I try I get:
~ $ systemctl status
Failed to get D-Bus connection: No such file or directory
So, I try with the suid bit on systemctl set, but then I get:
~ $ systemctl status
Failed to read server status: Operation not permitted
My question is, is something broken, or is this expected behavior?
If you do not use D-Bus daemon systemd will be listening on private
socket. In this case the only check it does is that peer runs as UID=0
(note - not EUID, so suid does not really help).
I think with or without dbus systemd listens on the private socket
(/run/systemd/private).
No, private socket is used only as fallback when full D-Bus is not available.
I don't think so.
root@lnxumuttl:/home/umuttl/Development# strace -f systemctl 21 | grep connect
connect(3, {sa_family=AF_LOCAL, sun_path=/run/systemd/private}, 22) = 0
root@lnxumuttl:/home/umuttl/Development# systemctl status dbus
● dbus.service - D-Bus System Message Bus
Loaded: loaded (/lib/systemd/system/dbus.service; static)
Active: active (running) since Tue 2015-05-26 16:43:56 CEST; 2 days ago
Docs: man:dbus-daemon(1)
Main PID: 967 (dbus-daemon)
CGroup: /system.slice/dbus.service
└─967 /usr/bin/dbus-daemon --system --address=systemd:
--nofork --nopidfile --systemd-activation
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl as non-root
On 05/29/2015 05:26 AM, Andrei Borzenkov wrote: If you do not use D-Bus daemon systemd will be listening on private socket. In this case the only check it does is that peer runs as UID=0 (note - not EUID, so suid does not really help). I wonder how access control is implemented in kdbus case. kdbus implements its own policy logic to allow given UIDs to talk to, see, or own well-known-names. See kdbus.policy(7) in the standalone kdbus repository. For individual method calls, kdbus can optionally pass a number of metadata along, so services can in some cases make authorization decisions based on them, without talking to polkit. This is similar to SCM_CREDENTIALS on sockets but offers a lot more information. Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Separating gudev from systemd
2015-05-19 17:06 GMT+02:00 David Herrmann dh.herrm...@gmail.com: Hi We're about to remove gudev from the systemd repository, as it is in no way related to the systemd code-base, nor used by the systemd project. To preserve backwards compatibility, gudev was extracted into a separate repository and is now managed on gnome.org: Homepage: https://wiki.gnome.org/Projects/libgudev Bugtracker: http://bugzilla.gnome.org/browse.cgi?product=libgudev Releases: http://download.gnome.org/sources/libgudev/ Repository: http://git.gnome.org/browse/libgudev/ ArchLinux: https://aur.archlinux.org/packages/li/libgudev/PKGBUILD Others: TBD FYI Ubuntu/Debian: https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=experimentalid=ff3e6f6fc82adeeb5341b3bbd9824b2591965af6 https://anonscm.debian.org/cgit/collab-maint/libgudev.git/commit/?id=c48853e54064485c8c1d4904139e6050f3f6462e Thanks for splitting off gudev. It makes bootstrapping systemd on new architectures quite a bit simpler. Cheers, Michael -- 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
[systemd-devel] [PATCH] sd-bus: make sure type=error messages are also dumped
---
src/libsystemd/sd-bus/sd-bus.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/src/libsystemd/sd-bus/sd-bus.c b/src/libsystemd/sd-bus/sd-bus.c
index edc27ae..a6096f9 100644
--- a/src/libsystemd/sd-bus/sd-bus.c
+++ b/src/libsystemd/sd-bus/sd-bus.c
@@ -49,6 +49,17 @@
#include bus-track.h
#include bus-slot.h
+#define log_debug_bus_message(m) log_debug(Got message type=%s sender=%s
destination=%s object=%s interface=%s member=%s cookie=% PRIu64
reply_cookie=% PRIu64 error=%s, \
+ bus_message_type_to_string(m-header-type), \
+ strna(sd_bus_message_get_sender(m)), \
+ strna(sd_bus_message_get_destination(m)), \
+ strna(sd_bus_message_get_path(m)), \
+ strna(sd_bus_message_get_interface(m)), \
+ strna(sd_bus_message_get_member(m)), \
+ BUS_MESSAGE_COOKIE(m), \
+ m-reply_cookie, \
+ strna(m-error.message))
+
static int bus_poll(sd_bus *bus, bool need_more, uint64_t timeout_usec);
static int attach_io_events(sd_bus *b);
static void detach_io_events(sd_bus *b);
@@ -2006,8 +2017,10 @@ _public_ int sd_bus_call(
r = sd_bus_error_setf(error,
SD_BUS_ERROR_INCONSISTENT_MESSAGE, Reply message contained file descriptors
which I couldn't accept. Sorry.);
-} else if (incoming-header-type ==
SD_BUS_MESSAGE_METHOD_ERROR)
+} else if (incoming-header-type ==
SD_BUS_MESSAGE_METHOD_ERROR) {
+log_debug_bus_message(incoming);
r = sd_bus_error_copy(error,
incoming-error);
+}
else
r = -EIO;
@@ -2480,16 +2493,7 @@ static int process_message(sd_bus *bus, sd_bus_message
*m) {
bus-current_message = m;
bus-iteration_counter++;
-log_debug(Got message type=%s sender=%s destination=%s object=%s
interface=%s member=%s cookie=% PRIu64 reply_cookie=% PRIu64 error=%s,
- bus_message_type_to_string(m-header-type),
- strna(sd_bus_message_get_sender(m)),
- strna(sd_bus_message_get_destination(m)),
- strna(sd_bus_message_get_path(m)),
- strna(sd_bus_message_get_interface(m)),
- strna(sd_bus_message_get_member(m)),
- BUS_MESSAGE_COOKIE(m),
- m-reply_cookie,
- strna(m-error.message));
+log_debug_bus_message(m);
r = process_hello(bus, m);
if (r != 0)
--
2.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] 'udevadm settle' brakes lvm on top of imsm raid
Thanks, I made more debbuging with LVM and I realised, that lvm always uses the last device it has scanned. Scanning of devices is called by udev rules using lvm pvscan --cache device command. So the reason of using /dev/sdb2 instead of /dev/md126p2 is that udev runs lvm in the following order: 1. lvm pvscan --cash /dev/md126p2 2. lvm pvscan --cash /dev/sda2 3. lvm pvscan --cash /dev/sdb2 But there were no /dev/sda2 and /dev/sdb2 before running anaconda at all. [root@localhost ~]# ls -ld /dev/md* /dev/sd* drwxr-xr-x. 2 root root 120 May 29 03:43 /dev/md brw-rw. 1 root disk 9, 126 May 29 03:43 /dev/md126 brw-rw. 1 root disk 259, 0 May 29 03:43 /dev/md126p1 brw-rw. 1 root disk 259, 1 May 29 03:43 /dev/md126p2 brw-rw. 1 root disk 9, 127 May 29 03:43 /dev/md127 brw-rw. 1 root disk 8, 0 May 29 03:43 /dev/sda brw-rw. 1 root disk 8, 16 May 29 03:43 /dev/sdb brw-rw. 1 root disk 8, 32 May 29 03:43 /dev/sdc brw-rw. 1 root disk 8, 33 May 29 03:43 /dev/sdc1 brw-rw. 1 root disk 8, 34 May 29 03:43 /dev/sdc2 brw-rw. 1 root disk 8, 48 May 29 03:43 /dev/sdd brw-rw. 1 root disk 8, 49 May 29 03:43 /dev/sdd1 brw-rw. 1 root disk 8, 50 May 29 03:43 /dev/sdd2 brw-rw. 1 root disk 8, 64 May 29 03:43 /dev/sde They appear only after launching anaconda: [root@localhost ~]# ls -ld /dev/md* /dev/sd* drwxr-xr-x. 2 root root 120 May 29 03:47 /dev/md brw-rw. 1 root disk 9, 126 May 29 03:47 /dev/md126 brw-rw. 1 root disk 259, 2 May 29 03:47 /dev/md126p1 brw-rw. 1 root disk 259, 3 May 29 03:47 /dev/md126p2 brw-rw. 1 root disk 9, 127 May 29 03:46 /dev/md127 brw-rw. 1 root disk 8, 0 May 29 03:47 /dev/sda brw-rw. 1 root disk 8, 1 May 29 03:47 /dev/sda1 brw-rw. 1 root disk 8, 2 May 29 03:47 /dev/sda2 brw-rw. 1 root disk 8, 16 May 29 03:47 /dev/sdb brw-rw. 1 root disk 8, 17 May 29 03:47 /dev/sdb1 brw-rw. 1 root disk 8, 18 May 29 03:47 /dev/sdb2 brw-rw. 1 root disk 8, 32 May 29 03:46 /dev/sdc brw-rw. 1 root disk 8, 33 May 29 03:46 /dev/sdc1 brw-rw. 1 root disk 8, 34 May 29 03:46 /dev/sdc2 brw-rw. 1 root disk 8, 48 May 29 03:47 /dev/sdd brw-rw. 1 root disk 8, 49 May 29 03:47 /dev/sdd1 brw-rw. 1 root disk 8, 50 May 29 03:47 /dev/sdd2 brw-rw. 1 root disk 8, 64 May 29 03:47 /dev/sde So the root problem is not in lvm. The root problem is why devices /sd[ab]? appear? They shoud not exist because of /dev/sd[ab] are parts of /dev/md126 raid. I'm not insist that 'udevadm --settle' is the reason. But where should I make future research? 2015-05-28 13:06 GMT+03:00 Lennart Poettering lenn...@poettering.net: On Thu, 28.05.15 11:10, Oleg Samarin (osamari...@gmail.com) wrote: Hi! I have an imsm raid-1 device /dev/md126 assembled of /dev/sda and /dev/sdb. I have a lvm group on top of /dev/md126p2 with some logical volumes. All this work fine with Fedora 21. I'm trying to fresh install Fedora 22 in some of lvm logical volume. I boot with Fedora USB live media and run Install to hard disk. But anaconda does not see any existing lvm volumes so I can not choose them as a destination. Please ask LVM people for help on this, the systemd mailing list is really not the right forum for this. Thanks, 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 0/2] Using XML entities for paths in manpages
On 05/29/2015 05:18 AM, Michael Biebl wrote: 2015-05-28 19:47 GMT+02:00 Filipe Brandenburger filbran...@google.com: We're actually still missing a small part of it (A sentence like Files in /etc have the highest priority, files in /run take precedence over files with the same name in */usr/lib*. in files like hwdb.xml, the last /usr/lib won't get fixed) but it requires new variables. I'm leaning towards introducing a rootsysconfdir=/etc and rootlibdir=$(rootprefix)/lib (we already have a rootbindir) so I'll follow up with a patch doing that. Though having the first patchset in certainly helps. Indeed. I just ran my small shell script which I used to generate the original diff over current git head. The only occurences which it still replaces can be found at [1]. It's like you said, the override bits which are still missing. Otherwise it looks fine. Could you try the attached patch? I had to introduce a new entity in custom-entites.ent, because with --with-rootprefix=/, rootprefix;/lib resolves to //lib, and with the default behaviour of configure, rootprefix;lib becomes /usrlib. That is solved with a subsitiution in Makefile.am now, which cleans up all double slashes in custom-entites.ent. Thanks, Daniel From f60d5707246d3a1ce8bcb11f3874ef696425a446 Mon Sep 17 00:00:00 2001 From: Daniel Mack dan...@zonque.org Date: Fri, 29 May 2015 10:53:35 +0200 Subject: [PATCH] Makefile, man: replace hard-coded /usr/lib Replace some /usr/lib occurences in man/ with a new rootprefixlibdir; entity, and define it in Makefile.am. Also make sure to avoid leading double slashes in path names in custom-entities.ent, which otherwise occur with ./configure --enable-split-usr --with-rootprefix=/ --- Makefile.am | 4 +++- man/hwdb.xml| 4 ++-- man/systemd.link.xml| 4 ++-- man/systemd.netdev.xml | 4 ++-- man/systemd.network.xml | 4 ++-- man/udev.xml| 4 ++-- 6 files changed, 13 insertions(+), 11 deletions(-) diff --git a/Makefile.am b/Makefile.am index e4a8616..cf3742c 100644 --- a/Makefile.am +++ b/Makefile.am @@ -105,6 +105,7 @@ systemsleepdir=$(rootlibexecdir)/system-sleep systemunitdir=$(rootprefix)/lib/systemd/system systempresetdir=$(rootprefix)/lib/systemd/system-preset udevlibexecdir=$(rootprefix)/lib/udev +rootprefixlibdir=$(rootprefix)/lib udevhomedir=$(udevlibexecdir) udevrulesdir=$(udevlibexecdir)/rules.d udevhwdbdir=$(udevlibexecdir)/hwdb.d @@ -6500,6 +6501,7 @@ substitutions = \ '|includedir=$(includedir)|' \ '|VERSION=$(VERSION)|' \ '|rootprefix=$(rootprefix)|' \ + '|rootprefixlibdir=$(rootprefixlibdir)|' \ '|udevlibexecdir=$(udevlibexecdir)|' \ '|SUSHELL=$(SUSHELL)|' \ '|SULOGIN=$(SULOGIN)|' \ @@ -6605,7 +6607,7 @@ if ENABLE_MANPAGES man/custom-entities.ent: configure.ac $(AM_V_GEN)$(MKDIR_P) $(dir $@) $(AM_V_GEN)(echo '?xml version=1.0 encoding=utf-8 ?' \ - printf '$(subst '|,!ENTITY ,$(subst =, ,$(subst |',\n,$(substitutions') \ + printf '$(subst '|,!ENTITY ,$(subst =, ,$(subst |',\n,$(subst =//,=/,$(substitutions)') \ $@ # ' DISTCLEANFILES += \ diff --git a/man/hwdb.xml b/man/hwdb.xml index b3602ac..60763e2 100644 --- a/man/hwdb.xml +++ b/man/hwdb.xml @@ -50,10 +50,10 @@ regardless of the directories in which they live. However, files with identical filenames replace each other. Files in filename/etc/filename have the highest priority, files in filename/run/filename take precedence - over files with the same name in filename/usr/lib/filename. This can be + over files with the same name in filenamerootprefixlibdir;/filename. This can be used to override a system-supplied hwdb file with a local file if needed; a symlink in filename/etc/filename with the same name as a hwdb file in - filename/usr/lib/filename, pointing to filename/dev/null/filename, + filenamerootprefixlibdir;/filename, pointing to filename/dev/null/filename, disables the hwdb file entirely. hwdb files must have the extension filename.hwdb/filename; other extensions are ignored./para diff --git a/man/systemd.link.xml b/man/systemd.link.xml index 75cf6e1..001df38 100644 --- a/man/systemd.link.xml +++ b/man/systemd.link.xml @@ -70,10 +70,10 @@ However, files with identical filenames replace each other. Files in filename/etc/filename have the highest priority, files in filename/run/filename take precedence over files with the same -name in filename/usr/lib/filename. This can be used to +name in filenamerootprefixlibdir;/filename. This can be used to override a system-supplied link file with a local file if needed; a symlink in filename/etc/filename with the same name as a -link file in filename/usr/lib/filename, pointing to +link file in filenamerootprefixlibdir;/filename, pointing to filename/dev/null/filename, disables the link file entirely./para diff --git
Re: [systemd-devel] [PATCH] build-sys: pass originally configured --enable-split-usr to distcheck
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:20150529054907.GD3340%40piware.de -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] cgroup-util: fix is_valid check to pass for unified cgroup hierchy.
On 29 May 2015 at 11:25, Lennart Poettering lenn...@poettering.net wrote: On Fri, 29.05.15 00:24, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: On 28 May 2015 at 18:08, Lennart Poettering lenn...@poettering.net wrote: On Thu, 28.05.15 16:42, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: It appears in /proc/self/cgroup as `0::/' What precisely does this fix? I mean, we need to do some major rework of things before the unified hierarchy is really supported in systemd, and this one thing won't really get us too much in this regard, does it? I'm starting to explore possibilities to start work towards supporting unified cgroups hierarchy, or at least be able to boot with it. I'll send a larger patch series in one go later than with all the bits that offer something more tangible, albeit disabled by default behind configure options (like kdbus) given that unified hierarchy is still marked experimental in the kernel. Ah, it's actually my big thing to work on for the next weeks too... My current priority is to port at least enough bits to get usable /sys/fs/cgroup/systemd on top of unified cgroups, with immediate benefit of dropping systemd-cgroups-agent and getting release notifications in containers. Not sure about transition / re-exec plan, at the moment I am assuming either/or situation but I guess we'd need to support a dual case, where upon re-exec we might still be in name=systemd rather than in the unified structure. -- Regards, Dimitri. Pura Vida! https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] build-sys: fix typo
There is nothing like systemd_verify_* in Makefile.am. The bug has been invisible because automake uses the default CFLAGS when component CFLAGS are undefined. --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index d6010c5..ed5135d 100644 --- a/Makefile.am +++ b/Makefile.am @@ -2131,7 +2131,7 @@ systemd_analyze_SOURCES = \ src/analyze/analyze-verify.c \ src/analyze/analyze-verify.h -systemd_verify_CFLAGS = \ +systemd_analyze_CFLAGS = \ $(AM_CFLAGS) \ $(SECCOMP_CFLAGS) -- 2.4.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build-sys: fix typo
Hey Karel, Karel Zak [2015-05-29 13:42 +0200]: There is nothing like systemd_verify_* in Makefile.am. The bug has been invisible because automake uses the default CFLAGS when component CFLAGS are undefined. Applied, looks/works fine. 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] systemctl disable service not working as expected
Hi Martin, Thanks for the very quick reply :) So, are you saying that there is no guaranteed way in which PA can be enabled/disabled in a systemd based system? That too, if I want to keep the binary in so if a user needs he can enable/disable PA as per need. How can I disable PA in such a scenario? BR, Awais From: Martin Pitt [martin.p...@ubuntu.com] Sent: Friday, May 29, 2015 4:24 PM To: Belal, Awais Cc: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] systemctl disable service not working as expected Hello Belal, Belal, Awais [2015-05-29 11:19 +]: I am working on an x86_64 platform with a yocto based environment. I was trying to disable pulseaudio which is included in the system by default so I did a 'systemctl disable pulseaudio' but when I reboot it seems pulseaudio is still run for a very short period of time and this is messing up some sound controls on my system. Although SYSVINIT capability is enabled but no sysv init style scripts are available on the target. Any pointers will be really helpful. Note that the pulseaudio daemon is commonly be auto-spawned from the library (libpulse) from the user session. It's not very common to enable a system-wide daemon with the .service file. So presumably it's just from that? 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] systemctl disable service not working as expected
Hello Belal, Belal, Awais [2015-05-29 11:19 +]: I am working on an x86_64 platform with a yocto based environment. I was trying to disable pulseaudio which is included in the system by default so I did a 'systemctl disable pulseaudio' but when I reboot it seems pulseaudio is still run for a very short period of time and this is messing up some sound controls on my system. Although SYSVINIT capability is enabled but no sysv init style scripts are available on the target. Any pointers will be really helpful. Note that the pulseaudio daemon is commonly be auto-spawned from the library (libpulse) from the user session. It's not very common to enable a system-wide daemon with the .service file. So presumably it's just from that? 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] 'udevadm settle' brakes lvm on top of imsm raid
On Fri, 29.05.15 11:15, Oleg Samarin (osamari...@gmail.com) wrote: Thanks, I made more debbuging with LVM and I realised, that lvm always uses the last device it has scanned. Scanning of devices is called by udev rules using lvm pvscan --cache device command. So the reason of using /dev/sdb2 instead of /dev/md126p2 is that udev runs lvm in the following order: 1. lvm pvscan --cash /dev/md126p2 2. lvm pvscan --cash /dev/sda2 3. lvm pvscan --cash /dev/sdb2 But there were no /dev/sda2 and /dev/sdb2 before running anaconda at all. [root@localhost ~]# ls -ld /dev/md* /dev/sd* drwxr-xr-x. 2 root root 120 May 29 03:43 /dev/md brw-rw. 1 root disk 9, 126 May 29 03:43 /dev/md126 brw-rw. 1 root disk 259, 0 May 29 03:43 /dev/md126p1 brw-rw. 1 root disk 259, 1 May 29 03:43 /dev/md126p2 brw-rw. 1 root disk 9, 127 May 29 03:43 /dev/md127 brw-rw. 1 root disk 8, 0 May 29 03:43 /dev/sda brw-rw. 1 root disk 8, 16 May 29 03:43 /dev/sdb brw-rw. 1 root disk 8, 32 May 29 03:43 /dev/sdc brw-rw. 1 root disk 8, 33 May 29 03:43 /dev/sdc1 brw-rw. 1 root disk 8, 34 May 29 03:43 /dev/sdc2 brw-rw. 1 root disk 8, 48 May 29 03:43 /dev/sdd brw-rw. 1 root disk 8, 49 May 29 03:43 /dev/sdd1 brw-rw. 1 root disk 8, 50 May 29 03:43 /dev/sdd2 brw-rw. 1 root disk 8, 64 May 29 03:43 /dev/sde They appear only after launching anaconda: [root@localhost ~]# ls -ld /dev/md* /dev/sd* drwxr-xr-x. 2 root root 120 May 29 03:47 /dev/md brw-rw. 1 root disk 9, 126 May 29 03:47 /dev/md126 brw-rw. 1 root disk 259, 2 May 29 03:47 /dev/md126p1 brw-rw. 1 root disk 259, 3 May 29 03:47 /dev/md126p2 brw-rw. 1 root disk 9, 127 May 29 03:46 /dev/md127 brw-rw. 1 root disk 8, 0 May 29 03:47 /dev/sda brw-rw. 1 root disk 8, 1 May 29 03:47 /dev/sda1 brw-rw. 1 root disk 8, 2 May 29 03:47 /dev/sda2 brw-rw. 1 root disk 8, 16 May 29 03:47 /dev/sdb brw-rw. 1 root disk 8, 17 May 29 03:47 /dev/sdb1 brw-rw. 1 root disk 8, 18 May 29 03:47 /dev/sdb2 brw-rw. 1 root disk 8, 32 May 29 03:46 /dev/sdc brw-rw. 1 root disk 8, 33 May 29 03:46 /dev/sdc1 brw-rw. 1 root disk 8, 34 May 29 03:46 /dev/sdc2 brw-rw. 1 root disk 8, 48 May 29 03:47 /dev/sdd brw-rw. 1 root disk 8, 49 May 29 03:47 /dev/sdd1 brw-rw. 1 root disk 8, 50 May 29 03:47 /dev/sdd2 brw-rw. 1 root disk 8, 64 May 29 03:47 /dev/sde So the root problem is not in lvm. The root problem is why devices /sd[ab]? appear? They shoud not exist because of /dev/sd[ab] are parts of /dev/md126 raid. Nope. Things don't work that way. If you have any form of software raid then both the underlying block devices and the resulting virtual block device will be exposed with device nodes in /dev. The underlying block devices don't suddenly disappear just because they are used in a RAID setup... Again, please ask the MD raid or LVM people for help. This is a systemd mailing list, and this is not the right place to ask questions about MD raid or LVM. Thank you, 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] Alienware graphics amplifier scancodes
On Thu, 28.05.15 13:25, Mario Limonciello (mario_limoncie...@dell.com) wrote: On 05/28/2015 11:48 AM, Lennart Poettering wrote: On Wed, 27.05.15 15:59, Mario Limonciello (mario_limoncie...@dell.com) wrote: You are aware that the kernel has PCI hotplug support? It sounds really weird rebooting the machine due to hotplug events. That's not how these things are done... Are you sure the kernel folks would be happy with a patch that chickens out and instead of proper PCI hotplug just always reboots? Also, why map this to input events at all? If it's really deemed OK to do such a weird reboot-on-unplug logic, then this should probably be a uevent or so... But generally, this all appears very questionnable to me... Lennart Hi Lennart, Yes, I'm aware that PCI hotplug support is in the kernel. The kernel doesn't panic on the PCIe device being removed from the bus, but the graphics driver and X don't continue working. What should you really do then? You can ask AMD and NVIDIA to fix the drivers and work with the X guys to handle the scenario cleanly, but what does that even mean? Hotplug graphics cards are not precisely new. This has been supported on Linux just fine for USB graphics cards, and why should PCI be any different? There are many better strategies for handling graphics card unplug than simply rebooting the system. A very simple one that is already vastly better is to simply let X die, and rely on gdm to bring up a new login. A much better one is to use a display server that actually has a sane strategy and can recover from graphics cards coming and going away. That's absolutely noch rocket science. Either way: simply rebooting is a completely weird choice. That's not how things are done on Linux. You can't guarantee that there is another GPU to display things on. X's architecture isn't cut out for GPU's disappearing and reappearing. Of course it is, see the support for USB graphics chips. And even if it wasn't: as long as the X server just dies userspace can still restart it with new gfx config in place. It's just wrong hardcoding your (incorrect) assumptions about supposedly crappy userspace into the kernel. 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] shared: do not include aux_h if it is off
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1432892866-27109-1-git-send-email-umut.tezduyar%40axis.com -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl as non-root
On Fri, 29.05.15 10:54, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:
On Fri, May 29, 2015 at 10:23 AM, Andrei Borzenkov arvidj...@gmail.com
wrote:
On Fri, May 29, 2015 at 11:05 AM, Umut Tezduyar Lindskog
u...@tezduyar.com wrote:
On May 28, 2015 2:28 PM, aaron_wri...@selinc.com wrote:
I'm working on an embedded system, and I ran into a situation where
a non-root user needs to runs systemctl, but when I try I get:
~ $ systemctl status
Failed to get D-Bus connection: No such file or directory
So, I try with the suid bit on systemctl set, but then I get:
~ $ systemctl status
Failed to read server status: Operation not permitted
My question is, is something broken, or is this expected behavior?
If you do not use D-Bus daemon systemd will be listening on private
socket. In this case the only check it does is that peer runs as UID=0
(note - not EUID, so suid does not really help).
I think with or without dbus systemd listens on the private socket
(/run/systemd/private).
No, private socket is used only as fallback when full D-Bus is not
available.
I don't think so.
root@lnxumuttl:/home/umuttl/Development# strace -f systemctl 21 | grep
connect
connect(3, {sa_family=AF_LOCAL, sun_path=/run/systemd/private}, 22) = 0
root@lnxumuttl:/home/umuttl/Development# systemctl status dbus
● dbus.service - D-Bus System Message Bus
Loaded: loaded (/lib/systemd/system/dbus.service; static)
Active: active (running) since Tue 2015-05-26 16:43:56 CEST; 2 days ago
Docs: man:dbus-daemon(1)
Main PID: 967 (dbus-daemon)
CGroup: /system.slice/dbus.service
└─967 /usr/bin/dbus-daemon --system --address=systemd:
--nofork --nopidfile --systemd-activation
We always listen on the private socket. We also listen on the proper
bus, but only if dbus-daemon is actually running.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] cryptsetup: craft a unique ID with the source device
From: Harald Hoyer har...@redhat.com
If cryptsetup is called with a source device as argv[3], then craft the
ID for the password agent with a unique device path.
If possible /dev/block/maj:min is used, otherwise the original
argv[3] is used.
This enables password agents like petera [1] to provide a password
according to the source device. The original ID did not carry enough
information and was more targeted for a human readable string, which
is specified in the Message field anyway.
With this patch the ID of the ask.XXX ini file looks like this:
ID=cryptsetup:/dev/block/maj:min
[1] https://github.com/npmccallum/petera
---
src/cryptsetup/cryptsetup.c | 97 ++---
1 file changed, 66 insertions(+), 31 deletions(-)
diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
index a5018f1..130c36e 100644
--- a/src/cryptsetup/cryptsetup.c
+++ b/src/cryptsetup/cryptsetup.c
@@ -238,6 +238,33 @@ static void log_glue(int level, const char *msg, void
*usrptr) {
log_debug(%s, msg);
}
+static char* disk_maj_min(const char *path) {
+struct stat st, st2;
+char *i = NULL;
+int r;
+
+assert(path);
+
+if (stat(path, st) 0)
+return NULL;
+
+if (!S_ISBLK(st.st_mode))
+return NULL;
+
+asprintf(i, /dev/block/%d:%d, major(st.st_rdev), minor(st.st_rdev));
+
+if (!i)
+return strdup(path);
+
+r = stat(i, st2);
+if ((r 0) || (st.st_rdev != st2.st_rdev)) {
+free(i);
+return strdup(path);
+}
+
+return i;
+}
+
static char* disk_description(const char *path) {
static const char name_fields[] =
@@ -295,20 +322,54 @@ static char *disk_mount_point(const char *label) {
return NULL;
}
-static int get_password(const char *name, usec_t until, bool accept_cached,
char ***passwords) {
-int r;
+static int get_password(const char *vol, const char *src, usec_t until, bool
accept_cached, char ***passwords) {
+int r = 0;
char **p;
_cleanup_free_ char *text = NULL;
_cleanup_free_ char *escaped_name = NULL;
char *id;
+const char *name = NULL;
+_cleanup_free_ char *description = NULL, *name_buffer = NULL,
+*mount_point = NULL, *maj_min = NULL;
assert(name);
assert(passwords);
+description = disk_description(src);
+mount_point = disk_mount_point(vol);
+
+if (description streq(vol, description)) {
+/* If the description string is simply the
+ * volume name, then let's not show this
+ * twice */
+free(description);
+description = NULL;
+}
+
+if (mount_point description)
+r = asprintf(name_buffer, %s (%s) on %s, description, vol,
mount_point);
+else if (mount_point)
+r = asprintf(name_buffer, %s on %s, vol, mount_point);
+else if (description)
+r = asprintf(name_buffer, %s (%s), description, vol);
+
+if (r 0) {
+log_oom();
+return r;
+}
+name = name_buffer ? name_buffer : vol;
+
if (asprintf(text, Please enter passphrase for disk %s!, name) 0)
return log_oom();
-escaped_name = cescape(name);
+if (src)
+maj_min = disk_maj_min(src);
+
+if (maj_min)
+escaped_name = maj_min;
+else
+escaped_name = cescape(name);
+
if (!escaped_name)
return log_oom();
@@ -552,8 +613,7 @@ int main(int argc, char *argv[]) {
unsigned tries;
usec_t until;
crypt_status_info status;
-const char *key_file = NULL, *name = NULL;
-_cleanup_free_ char *description = NULL, *name_buffer = NULL,
*mount_point = NULL;
+const char *key_file;
/* Arguments: systemd-cryptsetup attach VOLUME SOURCE-DEVICE
[PASSWORD] [OPTIONS] */
@@ -581,31 +641,6 @@ int main(int argc, char *argv[]) {
/* A delicious drop of snake oil */
mlockall(MCL_FUTURE);
-description = disk_description(argv[3]);
-mount_point = disk_mount_point(argv[2]);
-
-if (description streq(argv[2], description)) {
-/* If the description string is simply the
- * volume name, then let's not show this
- * twice */
-free(description);
-description = NULL;
-}
-
-k = 0;
-if (mount_point description)
-k = asprintf(name_buffer, %s (%s) on %s,
description, argv[2], mount_point);
-else if
Re: [systemd-devel] systemctl as non-root
On Thu, 28.05.15 17:21, aaron_wri...@selinc.com (aaron_wri...@selinc.com) wrote: Brandon Philips bran...@ifup.co wrote on 05/28/2015 05:10:33 PM: Access to the system dbus is controlled by dbus policies. You will need to write a policy for giving this user access to the systemd1 object. I compiled systemd without dbus support (--disable-dbus), and there is no dbus daemon or dbus lib on the system. Is that a requirement to get the functionality I want? I didn't see much need for dbus as the system works quite well without it. Well, except for this of course. systemd will always use D-Bus (the protocol) for IPC, that's not optional, and you cannot turn it off neither during build-time nor during runtime. systemd does not use libdbus to implement this however, but instead it uses its own D-Bus client implementation, dubbed sd-bus, which is going to be a public API with the next systemd release. Optional however is whether dbus-daemon (the daemon) is used as for IPC, or if all dbus IPC takes place only between systemd and its clients via direct AF_UNIX connections, without the central bus concept. We support this mode mostly to cover for the early-boot phase where dbus-daemon is not running yet, and hence cannot be used for communication. Running in this mode even during normal operation is supported, but not recommended (which is why the README says: dbus is strictly speaking optional, but recommended). The direct AF_UNIX communication is available exclusively for privileged clients. Normally it's the duty of dbus-daemon to enforce more complex policy on dbus1 systems. If you take dbus-daemon out of the equation however, then this policy component will be missing, and hence systemd refuses to talk to any unprivileged clients. Long story short: you cannot avoid dbus IPC really. Please use dbus-daemon, it's recommended. If you choose not to anyway, then you will not have access to systemd's APIs from unprivileged APIs. 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] build-sys: Stop depending on current configure options for EXTRA_DIST
Lennart Poettering [2015-05-29 12:20 +0200]: From all I can see this looks fine. Please push. Pushed. -- 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] systemctl as non-root
On Fri, May 29, 2015 at 1:02 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 28.05.15 17:21, aaron_wri...@selinc.com (aaron_wri...@selinc.com) wrote: Brandon Philips bran...@ifup.co wrote on 05/28/2015 05:10:33 PM: Access to the system dbus is controlled by dbus policies. You will need to write a policy for giving this user access to the systemd1 object. I compiled systemd without dbus support (--disable-dbus), and there is no dbus daemon or dbus lib on the system. Is that a requirement to get the functionality I want? I didn't see much need for dbus as the system works quite well without it. Well, except for this of course. systemd will always use D-Bus (the protocol) for IPC, that's not optional, and you cannot turn it off neither during build-time nor during runtime. systemd does not use libdbus to implement this however, but instead it uses its own D-Bus client implementation, dubbed sd-bus, which is going to be a public API with the next systemd release. Optional however is whether dbus-daemon (the daemon) is used as for IPC, or if all dbus IPC takes place only between systemd and its clients via direct AF_UNIX connections, without the central bus concept. We support this mode mostly to cover for the early-boot phase where dbus-daemon is not running yet, and hence cannot be used for communication. Running in this mode even during normal operation is supported, but not recommended (which is why the README says: dbus is strictly speaking optional, but recommended). The direct AF_UNIX communication is available exclusively for privileged clients. Normally it's the duty of dbus-daemon to enforce more complex policy on dbus1 systems. If you take dbus-daemon out of the equation however, then this policy component will be missing, and hence systemd refuses to talk to any unprivileged clients. Hmm, in a kdbus world, systemd (the service) itself would be responsible for policy checks anyway, wouldn't it? I mean, it already does the polkit/selinux checks even on dbus1 systems. -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemctl disable service not working as expected
Hi, I am working on an x86_64 platform with a yocto based environment. I was trying to disable pulseaudio which is included in the system by default so I did a 'systemctl disable pulseaudio' but when I reboot it seems pulseaudio is still run for a very short period of time and this is messing up some sound controls on my system. Although SYSVINIT capability is enabled but no sysv init style scripts are available on the target. Any pointers will be really helpful. root@mytarget:~# systemctl status pulseaudio ● pulseaudio.service Loaded: masked (/dev/null) Active: inactive (dead) root@mytarget:~# root@mytarget:~# root@mytarget:~# systemctl --version systemd 216 -PAM -AUDIT -SELINUX +IMA -APPARMOR +SMACK +SYSVINIT -LIBCRYPTSETUP -GCRYPT -GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID -ELFUTILS +KMOD -IDN root@mytarget:~# root@mytarget:~# ls /etc/init.d ls: /etc/init.d: No such file or directory root@mytarget:~# root@mytarget:~# dmesg | grep pulse systemd[1]: Received SIGCHLD from PID 894 (pulseaudio). systemd[1]: Child 894 (pulseaudio) died (code=exited, status=0/SUCCESS) systemd[1]: Received SIGCHLD from PID 903 (pulseaudio). systemd[1]: Child 901 (pulseaudio) died (code=exited, status=0/SUCCESS) systemd[1]: Child 903 (pulseaudio) died (code=exited, status=0/SUCCESS) systemd[1]: Received SIGCHLD from PID 895 (pulseaudio). systemd[1]: Child 895 (pulseaudio) died (code=exited, status=0/SUCCESS) If I rename the pulseaudio binary and reboot the system my sound controls come up sane. BR, Awais ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Alienware graphics amplifier scancodes
On Thu, 28.05.15 13:53, Mario Limonciello (mario_limoncie...@dell.com) wrote: On 05/28/2015 01:46 PM, Greg KH wrote: You can't guarantee that there is another GPU to display things on. Yes you can. Wait, what? No, you can't. 1) Not everyone has multiple monitors plugged into multiple GPU's. 2) The system ships with a dGPU and supports an xGPU. If you remove the dGPU from the chassis, all you have is the xGPU. If you unplug xGPU, there's nothing left.. gdm has multi seat support btw: it will spawn X servers on all seats capable of graphics. if you unplug all graphics cards than this simply means that your number of graphics-capable seats went from 0 to 0. That's all. And if you plug in a graphics card then, then it goes from 0 to 1 again and you get a fresh new login prompt on it. 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] path-util: Fix path_is_mount_point for files
On Thu, 28.05.15 21:03, Martin Pitt (martin.p...@ubuntu.com) wrote:
Hello Lennart,
Lennart Poettering [2015-05-28 19:44 +0200]:
On Wed, 27.05.15 10:07, Martin Pitt (martin.p...@ubuntu.com) wrote:
-int fd_is_mount_point(int fd) {
+int fd_is_mount_point(int fd, const char *parent) {
Hmm, now I am confused? Why parent?
I really think this should work as close as the usual *at() calls
work. i.e. take a dir fd as first argument, and a filename
*within*that*directory* to check. Maybe even give it the _at() suffix:
int fd_is_mount_point_at(int fd, const char *filename, int flags);
int path_is_mount_point(const char *path, int flags);
path_is_mount_point() simply seperates the last part of the path,
opens its parent directory, and then invokes fd_is_mount_point_at()
^^
with the parent dir and the last component...
^^
Exactly, that's why I called it parent; but I'm not fussed about the
name, dir or containing_dir would work as well. I'd just not call
it filename as that would be confusing -- this is *not* the file
name of fd, but the directory it lives in (i. e. fd's parent if you
will).
Now even more confused.
I say: the fd parameter should refer to the directory, and the string
parameter to the file name in that directory.
But I really don't grok what you think it should refer to: what does
the fd param refer to? the file itself, and the string parameter the
path to the directory this is in? That'd be very weird, no?
I am completely puzzled...
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] [systemd-commits] Makefile.am
On Fri, 29.05.15 03:03, Daniel Mack (zon...@kemper.freedesktop.org) wrote: Makefile.am |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) New commits: commit 6096d9ccc3f0b963010a47febce7e44c8632c23b Author: Daniel Mack dan...@zonque.org Date: Fri May 29 12:00:58 2015 +0200 Makefile: make custom-entities.ent depend on Makefile.am When Makefile.am is modified, make sure custom-entities.ent is rebuilt. After all, $(substitutions) is defined there, so changes of that variable must be reflected in the resulting file. Hmm, so we used have a lot of rules like this that mathematically correctly rebuilt really everything touched by a change. However, this resulted in soo much wasted build time, that we removed parts of it again, even if this means that some man pages might be slightly out of date if the Makefile.am changes. hence: what is the impact of this change precisely? does this mean a slight change of the makefile will always result in all man pages to be rebuilt? we don#t do that for the C compilation logic when a Makefile.am changes, so should we do this in this case? diff --git a/Makefile.am b/Makefile.am index e4a8616..e18bb5c 100644 --- a/Makefile.am +++ b/Makefile.am @@ -6602,7 +6602,7 @@ EXTRA_DIST += \ # -- if ENABLE_MANPAGES -man/custom-entities.ent: configure.ac +man/custom-entities.ent: Makefile.am configure.ac $(AM_V_GEN)$(MKDIR_P) $(dir $@) $(AM_V_GEN)(echo '?xml version=1.0 encoding=utf-8 ?' \ printf '$(subst '|,!ENTITY ,$(subst =, ,$(subst |',\n,$(substitutions') \ ___ systemd-commits mailing list systemd-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-commits 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] build-sys: Stop depending on current configure options for EXTRA_DIST
On Thu, 28.05.15 12:16, Martin Pitt (martin.p...@ubuntu.com) wrote: Hello all, for the quest of doing daily builds/distcheck/etc. on Debian/Ubuntu I started running distcheck on current trunk. It failed with GEN units/kmod-static-nodes.service make[3]: *** No rule to make target 'units/systemd-sysusers.service.in', needed by 'units/systemd-sysusers.service'. Stop. because I apparently ./configure'd my checkout with a few --disable-*. But make dist really ought to not depend on my configure options. The problem is that several (not all) of the EXTRA_DIST are conditional. This patch makes them all unconditional, so that make dist should produce more reliable tarballs. From all I can see this looks fine. Please push. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) From d9602540fb4c511eb3d60ce6708367d1d1e90fd0 Mon Sep 17 00:00:00 2001 From: Martin Pitt martin.p...@ubuntu.com Date: Thu, 28 May 2015 12:03:17 +0200 Subject: [PATCH] build-sys: Stop depending on current configure options for EXTRA_DIST Consistently move EXTRA_DIST out of conditional blocks. This would have produced incomplete dist tarballs when being run in a built tree with not every feature enabled, which can cause broken dist tarballs. --- Makefile.am | 99 - 1 file changed, 46 insertions(+), 53 deletions(-) diff --git a/Makefile.am b/Makefile.am index e8abef0..8d9044f 100644 --- a/Makefile.am +++ b/Makefile.am @@ -733,12 +733,6 @@ man/systemd.directives.xml: $(top_srcdir)/tools/make-directive-index.py $(SOURCE $(AM_V_at)$(MKDIR_P) $(dir $@) $(AM_V_GEN)$(PYTHON) $ $@ $(filter-out $,$^) -EXTRA_DIST += \ - man/systemd.index.xml \ - man/index.html \ - man/systemd.directives.xml \ - man/glib-event-glue.c - CLEANFILES += \ man/systemd.index.xml \ man/systemd.directives.xml @@ -754,7 +748,12 @@ EXTRA_DIST += \ $(man_MANS) \ tools/make-man-index.py \ tools/make-directive-index.py \ - tools/xml_helper.py + tools/xml_helper.py \ + man/systemd.index.xml \ + man/index.html \ + man/systemd.directives.xml \ + man/glib-event-glue.c \ + $(NULL) # -- noinst_LTLIBRARIES += \ @@ -2323,15 +2322,15 @@ nodist_sysusers_DATA = \ sysusers.d/systemd.conf \ sysusers.d/basic.conf +INSTALL_DIRS += \ + $(sysusersdir) +endif + EXTRA_DIST += \ units/systemd-sysusers.service.in \ sysusers.d/systemd.conf.m4 \ sysusers.d/basic.conf.in -INSTALL_DIRS += \ - $(sysusersdir) -endif - # -- dist_factory_etc_DATA = \ factory/etc/nsswitch.conf @@ -2360,13 +2359,13 @@ rootbin_PROGRAMS += \ nodist_systemunit_DATA += \ units/systemd-firstboot.service -EXTRA_DIST += \ - units/systemd-firstboot.service.in - SYSINIT_TARGET_WANTS += \ systemd-firstboot.service endif +EXTRA_DIST += \ + units/systemd-firstboot.service.in + # -- systemd_machine_id_setup_SOURCES = \ src/machine-id-setup/machine-id-setup-main.c \ @@ -2497,11 +2496,6 @@ systemd_hibernate_resume_generator_LDADD = \ libsystemd-label.la \ libsystemd-shared.la -EXTRA_DIST += \ - units/systemd-hibernate.service.in \ - units/systemd-hibernate-res...@.service.in \ - units/systemd-hybrid-sleep.service.in - dist_systemunit_DATA += \ units/hibernate.target \ units/hybrid-sleep.target @@ -2512,6 +2506,11 @@ nodist_systemunit_DATA += \ units/systemd-hybrid-sleep.service endif +EXTRA_DIST += \ + units/systemd-hibernate.service.in \ + units/systemd-hibernate-res...@.service.in \ + units/systemd-hybrid-sleep.service.in + # -- if ENABLE_EFI systemgenerator_PROGRAMS += \ @@ -2697,7 +2696,6 @@ $(stub): $(stub_solib) # -- CLEANFILES += test-efi-disk.img -EXTRA_DIST += test/test-efi-create-disk.sh test-efi-disk.img: $(systemd_boot) $(stub) test/test-efi-create-disk.sh $(AM_V_GEN)test/test-efi-create-disk.sh @@ -2707,6 +2705,8 @@ test-efi: test-efi-disk.img endif endif +EXTRA_DIST += test/test-efi-create-disk.sh + # -- if HAVE_BLKID systemgenerator_PROGRAMS += \ @@ -3952,11 +3952,6 @@ dist_udevhwdb_DATA = \ hwdb/70-pointingstick.hwdb \ hwdb/70-touchpad.hwdb -EXTRA_DIST += \ -
Re: [systemd-devel] [PATCH v2] udev: input_id: fix detection of various touchscreens
Hi,
On Fri, May 29, 2015 at 2:07 AM, Peter Hutterer peter.hutte...@who-t.net
wrote:
On Thu, May 28, 2015 at 02:47:35PM +0200, Andreas Pokorny wrote:
There are touch screens that do not provide 'BTN_TOUCH' and hence no
'EV_KEY'. Previously those would not get any properties assigned and
note: I consider this a kernel bug. From the kernel's documentation:
* BTN_TOUCH:
BTN_TOUCH is used for touch contact. While an input tool is determined
to be within meaningful physical contact, the value of this property must
be set to 1.
Yes and somewhat further down in the text:
[snip]
Note: Historically a touch device with BTN_TOOL_FINGER and BTN_TOUCH was
interpreted as a touchpad by userspace, while a similar device without
BTN_TOOL_FINGER was interpreted as a touchscreen. For backwards
compatibility
with current userspace it is recommended to follow this distinction. In the
future, this distinction will be deprecated and the device properties ioctl
EVIOCGPROP, defined in linux/input.h, will be used to convey the device
type.
[snip]
I try to ensure that we capture most devices with and without broken
drivers as possible.
With the various soc vendors it is hard to fix all kernel source providers.
As far as I can
see from the source code I counted three kernel drivers that do not emit
BTN_TOUCH.
But I believe I only have access to one of those devices. Then there are
various other
that have not been sent upstream. But all of those seemed to set the DIRECT
property.
[...]
+has_3d_coordinates = has_coordinates test_bit(ABS_Z,
bitmask_abs);
+has_mt_coordinates = test_bit(ABS_MT_POSITION_X, bitmask_abs)
+test_bit(ABS_MT_POSITION_Y, bitmask_abs);
pretty sure the second line must be aligned with the =, applies for the
others too
as a follow-up: this test should be updated to check if ABS_MT_SLOT - 1
*and* ABS_MT_SLOT are set. If both are set, the device is *not* a
touchscreen.
ACK to all of the above, but ABS_MT_SLOT - 1? I never saw that axis
anywhere. Oh
or is that a joystick device with so so many axis that it hits the touch
pad/screen range of axis?
[...]
+else if (has_3d_coordinates !has_keys)
+is_accelerometer = true;
this is a behaviour change: before anything with INPUT_PROP_ACCELEROMETER
was tagged as such, now some of these may be tagged as other devices.
specifically, the Wacom cintiq 27QHD remote would be tagged as tablet now.
BTN_STYLUS + ABS_X/Y/Z + KEY_PROG1/2/3 + INPUT_PROP_ACCELEROMETER
I think you should reinstate the if it says it's an accelerometer,
anything
else doesn't matter.
The initial code was similar to
if (!keys) {
if(has_3d_coordinates) is_accelerometer = true
return false;
}
I had to change that part for nexus4 and nexus10 devices, because there was
no EV_KEY bit set.
Hence test_pointers returned false. But yes I can reinstate a if 3d axis +
no buttons it is an
accelerometer and anything else does not matter...
But then what about devices like the PS4 controller? As far as I can tell
it has three rotational axis
respective joystick axis and a touchpad. So I believe the device should
have all three udev properties
set?
[...]
all the other bits go into the first patch. also, please CC me on the next
version, this way I'll see it quicker.
Thank you for the review. I will make a patch series out of that, and send
it again soon.
regards
Andreas Pokorny
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup: craft a unique ID with the source device
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1432894632-2417-1-git-send-email-harald%40redhat.com -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I am adding RegisterMachine to docker.
Daniel J Walsh wrote on 28/05/15 21:05: When container stops machinectl still shows it registered? Do I need to Unregister the machine? I though systemd would notice the pid died and remove the machine. IIRC there was a really old problem with lingering machine name registrations. It prevented nspawn being used multiple times too (without specifying a new, unique, machine name explicitly) I can't recall where the problem lied but I suspect it was in an old kernel. Doubt this is your issue, but figured I'd mention it just in case. It was quite old (1.5y+ IIRC) 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] [PATCH 0/2] Using XML entities for paths in manpages
On Thu, 28.05.15 10:47, Filipe Brandenburger (filbran...@google.com) wrote: On Thu, May 28, 2015 at 10:44 AM, Michael Biebl mbi...@gmail.com wrote: 2015-05-28 19:41 GMT+02:00 Martin Pitt martin.p...@ubuntu.com: \o/ Many thanks Filipe, that's great! Biggest patch gone :) A huge thanks from me as well to everyone involved! Lennart: Thanks for applying it. Martin and Michael: You're welcome, glad to help! We're actually still missing a small part of it (A sentence like Files in /etc have the highest priority, files in /run take precedence over files with the same name in */usr/lib*. in files like hwdb.xml, the last /usr/lib won't get fixed) but it requires new variables. I'm leaning towards introducing a rootsysconfdir=/etc and rootlibdir=$(rootprefix)/lib (we already have a rootbindir) so I'll follow up with a patch doing that. In these cases we actually end up looking in both /usr/lib and /lib usually (with exceptions). Hence be careful if you want to correct this in the man pages. I'd prefer not to document both paths if both are supported simultaneously, distros and users should be pushed to only consider one of the two even if we read from both. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] shared: do not include aux_h if it is off
--- src/shared/random-util.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/shared/random-util.c b/src/shared/random-util.c index 88f5182..b230044 100644 --- a/src/shared/random-util.c +++ b/src/shared/random-util.c @@ -23,7 +23,9 @@ #include sys/stat.h #include fcntl.h #include time.h +#ifdef HAVE_SYS_AUXV_H #include sys/auxv.h +#endif #include linux/random.h #include random-util.h -- 2.1.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] path-util: Fix path_is_mount_point for files
Lennart Poettering [2015-05-29 11:33 +0200]: Exactly, that's why I called it parent; but I'm not fussed about the name, dir or containing_dir would work as well. I'd just not call it filename as that would be confusing -- this is *not* the file name of fd, but the directory it lives in (i. e. fd's parent if you will). Now even more confused. [...] I say: the fd parameter should refer to the directory, and the string parameter to the file name in that directory. Aah! I modeled it after what fd_is_mount_point() currently uses, where the fd really *is* the fd to the actual file, *not* to the directory. But I understand now that you want to change that, and what you mean by make it work like openat(). Right, all clear now. The only consumer of this is rm_rf(), it's simple enough to adjust to passing file name and parent dir fd instead of file fd. Yes, that will make the whole thing a lot cleaner. 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] [systemd-commits] Makefile.am
On 05/29/2015 12:07 PM, Lennart Poettering wrote: On Fri, 29.05.15 03:03, Daniel Mack (zon...@kemper.freedesktop.org) wrote: Makefile.am |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) New commits: commit 6096d9ccc3f0b963010a47febce7e44c8632c23b Author: Daniel Mack dan...@zonque.org Date: Fri May 29 12:00:58 2015 +0200 Makefile: make custom-entities.ent depend on Makefile.am When Makefile.am is modified, make sure custom-entities.ent is rebuilt. After all, $(substitutions) is defined there, so changes of that variable must be reflected in the resulting file. Hmm, so we used have a lot of rules like this that mathematically correctly rebuilt really everything touched by a change. However, this resulted in soo much wasted build time, that we removed parts of it again, even if this means that some man pages might be slightly out of date if the Makefile.am changes. hence: what is the impact of this change precisely? does this mean a slight change of the makefile will always result in all man pages to be rebuilt? we don#t do that for the C compilation logic when a Makefile.am changes, so should we do this in this case? This came up during the hackery around the custom entity logic. With changes to what $substitutions in Makefile.am contains, the resulting file man/custom-entities.ent was never rebuilt, and hence went out of date and had to be deleted manually. But yes, that means the man pages will now be rebuilt every time Makefile.am is touched of course. Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-logind and selinux enforcing: Assertion failed
As i was trying to enforce selinux on a fedora 21 i got this which seems more related to systemd-mailing list rather than the selinux one. systemd-logind[355]: Assertion 's-user-slice' failed at ../src/login/logind-session.c:496, function session_start_scope(). Aborting. As a result loginctl doesnt pick up the user logins and sessions and polkit is totally unusable. Running in permissive mode everything works as expected ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v3 0/3] udev: input_id - extended device detection for touch screens
Hi,
This is the revised version, split up into a series of changes. The first
separates
evdev property evaluation from decision taking and udev property application.
The
second adds INPUT_PROP_DIRECT and MT axis to detect touch screens. The final one
adds a check for overlapping axis ranges.
regards
Andreas Pokorny
Andreas Pokorny (3):
udev: input_id - refactor device detection
udev: input_id - use direct property and mt axis for touch screen
detection
udev: input_id - use ABS_MT_SLOT{-1} to exclude non touch screen
devices
src/udev/udev-builtin-input_id.c | 141 ++-
1 file changed, 79 insertions(+), 62 deletions(-)
--
2.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v3 1/3] udev: input_id - refactor device detection
This change switches to bools and separates bit flag evaluation from
decision making and application of udev properties, while hopefully
keeping the same semantics. Apart from using BTN_LEFT instead of BTN_MOUSE
for mouse detection.
---
src/udev/udev-builtin-input_id.c | 134 +--
1 file changed, 72 insertions(+), 62 deletions(-)
diff --git a/src/udev/udev-builtin-input_id.c b/src/udev/udev-builtin-input_id.c
index b14190e..421ea83 100644
--- a/src/udev/udev-builtin-input_id.c
+++ b/src/udev/udev-builtin-input_id.c
@@ -133,79 +133,89 @@ static bool test_pointers(struct udev_device *dev,
const unsigned long* bitmask_rel,
const unsigned long* bitmask_props,
bool test) {
-int is_mouse = 0;
-int is_touchpad = 0;
-bool ret = false;
-
-if (test_bit(INPUT_PROP_ACCELEROMETER, bitmask_props)) {
+bool has_abs_coordinates = false;
+bool has_rel_coordinates = false;
+bool has_joystick_axes_or_buttons = false;
+bool has_touch = false;
+bool has_3d_coordinates = false;
+bool has_keys = false;
+bool stylus_or_pen = false;
+bool finger_but_no_pen = false;
+bool has_mouse_button = false;
+bool is_mouse = false;
+bool is_touchpad = false;
+bool is_touchscreen = false;
+bool is_tablet = false;
+bool is_joystick = false;
+bool is_accelerometer = false;
+bool is_pointing_stick= false;
+
+has_keys = test_bit(EV_KEY, bitmask_ev);
+has_abs_coordinates = test_bit(ABS_X, bitmask_abs) test_bit(ABS_Y,
bitmask_abs);
+has_3d_coordinates = has_abs_coordinates test_bit(ABS_Z,
bitmask_abs);
+is_accelerometer = test_bit(INPUT_PROP_ACCELEROMETER, bitmask_props);
+
+if (!has_keys has_3d_coordinates)
+is_accelerometer = true;
+
+if (is_accelerometer) {
udev_builtin_add_property(dev, test, ID_INPUT_ACCELEROMETER,
1);
return true;
}
-if (!test_bit(EV_KEY, bitmask_ev)) {
-if (test_bit(EV_ABS, bitmask_ev)
-test_bit(ABS_X, bitmask_abs)
-test_bit(ABS_Y, bitmask_abs)
-test_bit(ABS_Z, bitmask_abs)) {
-udev_builtin_add_property(dev, test,
ID_INPUT_ACCELEROMETER, 1);
-ret = true;
-}
-return ret;
-}
-
-if (test_bit(EV_ABS, bitmask_ev)
-test_bit(ABS_X, bitmask_abs) test_bit(ABS_Y, bitmask_abs)) {
-if (test_bit(BTN_STYLUS, bitmask_key) ||
test_bit(BTN_TOOL_PEN, bitmask_key)) {
-udev_builtin_add_property(dev, test,
ID_INPUT_TABLET, 1);
-ret = true;
-} else if (test_bit(BTN_TOOL_FINGER, bitmask_key)
!test_bit(BTN_TOOL_PEN, bitmask_key)) {
-is_touchpad = 1;
-} else if (test_bit(BTN_MOUSE, bitmask_key)) {
+is_pointing_stick = test_bit(INPUT_PROP_POINTING_STICK, bitmask_props);
+stylus_or_pen = test_bit(BTN_STYLUS, bitmask_key) ||
test_bit(BTN_TOOL_PEN, bitmask_key);
+finger_but_no_pen = test_bit(BTN_TOOL_FINGER, bitmask_key)
!test_bit(BTN_TOOL_PEN, bitmask_key);
+has_mouse_button = test_bit(BTN_LEFT, bitmask_key);
+has_rel_coordinates = test_bit(EV_REL, bitmask_ev) test_bit(REL_X,
bitmask_rel) test_bit(REL_Y, bitmask_rel);
+has_touch = test_bit(BTN_TOUCH, bitmask_key);
+/* joysticks don't necessarily have buttons; e. g.
+ * rudders/pedals are joystick-like, but buttonless; they have
+ * other fancy axes */
+has_joystick_axes_or_buttons = test_bit(BTN_TRIGGER, bitmask_key) ||
+ test_bit(BTN_A, bitmask_key) ||
+ test_bit(BTN_1, bitmask_key) ||
+ test_bit(ABS_RX, bitmask_abs) ||
+ test_bit(ABS_RY, bitmask_abs) ||
+ test_bit(ABS_RZ, bitmask_abs) ||
+ test_bit(ABS_THROTTLE, bitmask_abs) ||
+ test_bit(ABS_RUDDER, bitmask_abs) ||
+ test_bit(ABS_WHEEL, bitmask_abs) ||
+ test_bit(ABS_GAS, bitmask_abs) ||
+ test_bit(ABS_BRAKE, bitmask_abs);
+
+if (has_abs_coordinates) {
+if (stylus_or_pen)
+is_tablet = true;
+else if (finger_but_no_pen)
+is_touchpad = true;
+else if (has_mouse_button)
/* This path is taken by VMware's USB mouse, which has
* absolute axes,
[systemd-devel] [PATCH v3 3/3] udev: input_id - use ABS_MT_SLOT{-1} to exclude non touch screen devices
Require touch screens to have a ABS_MT_SLOT axis while exclude devices that overlap with the MT range of axes. --- src/udev/udev-builtin-input_id.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/udev/udev-builtin-input_id.c b/src/udev/udev-builtin-input_id.c index 0f9f021..59616c8 100644 --- a/src/udev/udev-builtin-input_id.c +++ b/src/udev/udev-builtin-input_id.c @@ -170,7 +170,8 @@ static bool test_pointers(struct udev_device *dev, finger_but_no_pen = test_bit(BTN_TOOL_FINGER, bitmask_key) !test_bit(BTN_TOOL_PEN, bitmask_key); has_mouse_button = test_bit(BTN_LEFT, bitmask_key); has_rel_coordinates = test_bit(EV_REL, bitmask_ev) test_bit(REL_X, bitmask_rel) test_bit(REL_Y, bitmask_rel); -has_mt_coordinates = test_bit(ABS_MT_POSITION_X, bitmask_abs) test_bit(ABS_MT_POSITION_Y, bitmask_abs); +has_mt_coordinates = test_bit(ABS_MT_POSITION_X, bitmask_abs) test_bit(ABS_MT_POSITION_Y, bitmask_abs) + test_bit(ABS_MT_SLOT, bitmask_abs) !test_bit(ABS_MT_SLOT - 1, bitmask_abs); is_direct = test_bit(INPUT_PROP_DIRECT, bitmask_props); has_touch = test_bit(BTN_TOUCH, bitmask_key); /* joysticks don't necessarily have buttons; e. g. -- 2.1.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v3 2/3] udev: input_id - use direct property and mt axis for touch screen detection
A lot of touch screens use INPUT_PROP_DIRECT to indicate that touch input
maps directly to the underlying screen, while the BTN_TOUCH bit might not be
set.
---
src/udev/udev-builtin-input_id.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/udev/udev-builtin-input_id.c b/src/udev/udev-builtin-input_id.c
index 421ea83..0f9f021 100644
--- a/src/udev/udev-builtin-input_id.c
+++ b/src/udev/udev-builtin-input_id.c
@@ -135,7 +135,9 @@ static bool test_pointers(struct udev_device *dev,
bool test) {
bool has_abs_coordinates = false;
bool has_rel_coordinates = false;
+bool has_mt_coordinates = false;
bool has_joystick_axes_or_buttons = false;
+bool is_direct = false;
bool has_touch = false;
bool has_3d_coordinates = false;
bool has_keys = false;
@@ -168,6 +170,8 @@ static bool test_pointers(struct udev_device *dev,
finger_but_no_pen = test_bit(BTN_TOOL_FINGER, bitmask_key)
!test_bit(BTN_TOOL_PEN, bitmask_key);
has_mouse_button = test_bit(BTN_LEFT, bitmask_key);
has_rel_coordinates = test_bit(EV_REL, bitmask_ev) test_bit(REL_X,
bitmask_rel) test_bit(REL_Y, bitmask_rel);
+has_mt_coordinates = test_bit(ABS_MT_POSITION_X, bitmask_abs)
test_bit(ABS_MT_POSITION_Y, bitmask_abs);
+is_direct = test_bit(INPUT_PROP_DIRECT, bitmask_props);
has_touch = test_bit(BTN_TOUCH, bitmask_key);
/* joysticks don't necessarily have buttons; e. g.
* rudders/pedals are joystick-like, but buttonless; they have
@@ -187,7 +191,7 @@ static bool test_pointers(struct udev_device *dev,
if (has_abs_coordinates) {
if (stylus_or_pen)
is_tablet = true;
-else if (finger_but_no_pen)
+else if (finger_but_no_pen !is_direct)
is_touchpad = true;
else if (has_mouse_button)
/* This path is taken by VMware's USB mouse, which has
@@ -198,6 +202,8 @@ static bool test_pointers(struct udev_device *dev,
else if (has_joystick_axes_or_buttons)
is_joystick = true;
}
+if (has_mt_coordinates is_direct)
+is_touchscreen = true;
if (has_rel_coordinates has_mouse_button)
is_mouse = true;
--
2.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3 3/3] udev: input_id - use ABS_MT_SLOT{-1} to exclude non touch screen devices
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1432904094-28288-4-git-send-email-andreas.pokorny%40canonical.com -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl disable service not working as expected
On Fri, May 29, 2015 at 3:04 PM, Belal, Awais awais_be...@mentor.com wrote: Hi Martin, Thanks for the very quick reply :) So, are you saying that there is no guaranteed way in which PA can be enabled/disabled in a systemd based system? pulseaudio is *very rarely* run as a system service in the first place. Whether it's systemd-based or not is irrelevant. Most often it's managed at session level, e.g. started during login by gnome-session, sometimes `systemctl --user`, but usually launched automatically by libpulse. That too, if I want to keep the binary in so if a user needs he can enable/disable PA as per need. How can I disable PA in such a scenario? You could set autospawn = no in pulse-client.conf(5). -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] cgroup-util: fix is_valid check to pass for unified cgroup hierchy.
On Fri, 29.05.15 12:42, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: On 29 May 2015 at 11:25, Lennart Poettering lenn...@poettering.net wrote: On Fri, 29.05.15 00:24, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: On 28 May 2015 at 18:08, Lennart Poettering lenn...@poettering.net wrote: On Thu, 28.05.15 16:42, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: It appears in /proc/self/cgroup as `0::/' What precisely does this fix? I mean, we need to do some major rework of things before the unified hierarchy is really supported in systemd, and this one thing won't really get us too much in this regard, does it? I'm starting to explore possibilities to start work towards supporting unified cgroups hierarchy, or at least be able to boot with it. I'll send a larger patch series in one go later than with all the bits that offer something more tangible, albeit disabled by default behind configure options (like kdbus) given that unified hierarchy is still marked experimental in the kernel. Ah, it's actually my big thing to work on for the next weeks too... My current priority is to port at least enough bits to get usable /sys/fs/cgroup/systemd on top of unified cgroups, with immediate benefit of dropping systemd-cgroups-agent and getting release notifications in containers. Not sure about transition / re-exec plan, at the moment I am assuming either/or situation but I guess we'd need to support a dual case, where upon re-exec we might still be in name=systemd rather than in the unified structure. My intention is to make this all work so that we can support both modes for a while, but you have to pick at boot-time which mode you want: the unified hierarchy or the classic one. And if we pick the former you won't get the latter, and if you pick the latter you won't get the former. And yeah, getting proper notifications especially for the container case is the most important thing for me too. 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] systemd-logind and selinux enforcing: Assertion failed
On Fri, 29.05.15 14:04, George Karakougioumtzis (mad-proffes...@hotmail.com) wrote: As i was trying to enforce selinux on a fedora 21 i got this which seems more related to systemd-mailing list rather than the selinux one. systemd-logind[355]: Assertion 's-user-slice' failed at ../src/login/logind-session.c:496, function session_start_scope(). Aborting. As a result loginctl doesnt pick up the user logins and sessions and polkit is totally unusable. Running in permissive mode everything works as expected Are you sure you are running the latest systemd rpm? A bug like this was fixed quite some time ago upstream and to my knowledge also in Fedora. Also, please report issues like this to the distro bug trackers first, unless the distro maintainers ask you to escalate this upstream or you are running the most recent released systemd version from upstream (v220 at this point). 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] [systemd-commits] Makefile.am
On Fri, 29.05.15 12:26, Daniel Mack (dan...@zonque.org) wrote: On 05/29/2015 12:07 PM, Lennart Poettering wrote: On Fri, 29.05.15 03:03, Daniel Mack (zon...@kemper.freedesktop.org) wrote: Makefile.am |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) New commits: commit 6096d9ccc3f0b963010a47febce7e44c8632c23b Author: Daniel Mack dan...@zonque.org Date: Fri May 29 12:00:58 2015 +0200 Makefile: make custom-entities.ent depend on Makefile.am When Makefile.am is modified, make sure custom-entities.ent is rebuilt. After all, $(substitutions) is defined there, so changes of that variable must be reflected in the resulting file. Hmm, so we used have a lot of rules like this that mathematically correctly rebuilt really everything touched by a change. However, this resulted in soo much wasted build time, that we removed parts of it again, even if this means that some man pages might be slightly out of date if the Makefile.am changes. hence: what is the impact of this change precisely? does this mean a slight change of the makefile will always result in all man pages to be rebuilt? we don#t do that for the C compilation logic when a Makefile.am changes, so should we do this in this case? This came up during the hackery around the custom entity logic. With changes to what $substitutions in Makefile.am contains, the resulting file man/custom-entities.ent was never rebuilt, and hence went out of date and had to be deleted manually. But yes, that means the man pages will now be rebuilt every time Makefile.am is touched of course. I'd prefer if we would avoid that. The xsltproc stuff already is the slowest part of the build, and I wish touching the makefile would not cause a full rebuild of that. I think it's ok to expect people to run make clean after touching the makefile to get the man pages fixed. Hope that makes sense, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] install: follow symlinks when enabling unit files from /usr/
Right now it is difficult for distros to ship convenience/compat alias for some
service, e.g. mariadb aliased to mysql or nfs-server to nfs. If service which
comes with alias is not enabled by default then user must refer to its new unit
file name when trying to enable the service. Contrary, using alias for
start or stop works fine.
This patch introduces exception to current handling of enable requests. If we
find symlink instead of the unit file under /usr such that it has target in the
same directory, we then assume this is a convenience alias and we will follow
the symlink regardless the value of allow_symlink parameter.
---
Caveat: Patch doesn't cover case when full-path to symlink in /usr is given.
Not sure we want to support this though.
src/shared/install.c | 84 ++--
1 file changed, 82 insertions(+), 2 deletions(-)
diff --git a/src/shared/install.c b/src/shared/install.c
index 6172c42..18cc63e 100644
--- a/src/shared/install.c
+++ b/src/shared/install.c
@@ -824,12 +824,16 @@ static void install_info_free(UnitFileInstallInfo *i) {
static void install_info_hashmap_free(OrderedHashmap *m) {
UnitFileInstallInfo *i;
+char *name;
if (!m)
return;
-while ((i = ordered_hashmap_steal_first(m)))
+while ((name = ordered_hashmap_first_key(m))) {
+i = ordered_hashmap_steal_first(m);
install_info_free(i);
+free(name);
+}
ordered_hashmap_free(m);
}
@@ -849,6 +853,7 @@ static int install_info_add(
const char *path) {
UnitFileInstallInfo *i = NULL;
int r;
+char *n = NULL;
assert(c);
assert(name || path);
@@ -885,7 +890,18 @@ static int install_info_add(
}
}
-r = ordered_hashmap_put(c-will_install, i-name, i);
+n = strdup(name);
+if (!n) {
+r = -ENOMEM;
+goto fail;
+}
+
+/*
+ * There is a possibility that i-name will be changed if we figure
out that we are not
+ * handling unit file but rather symlink to another unit file in
/usr. Thus we can't use
+ * i-name as a key.
+ */
+r = ordered_hashmap_put(c-will_install, n, i);
if (r 0)
goto fail;
@@ -895,6 +911,8 @@ fail:
if (i)
install_info_free(i);
+free(n);
+
return r;
}
@@ -1108,6 +1126,68 @@ static int unit_file_search(
if (!path)
return -ENOMEM;
+if (!path_startswith(path, /etc) !path_startswith(path,
/run)) {
+_cleanup_free_ char *root_target = NULL, *root_path =
NULL;
+
+if (root_dir)
+root_path = path_join(root_dir, path, NULL);
+else
+root_path = strdup(path);
+
+if (!root_path)
+return -ENOMEM;
+
+r = readlink_and_canonicalize(root_path, root_target);
+if (r = 0) {
+_cleanup_free_ char *root_target_prefix= NULL,
*target = NULL;
+
+root_target_prefix = path_join(root_dir, *p,
NULL);
+if (!root_target_prefix)
+return -ENOMEM;
+
+if (path_startswith(root_target, *p) ||
+ path_startswith(root_target,
root_target_prefix)) {
+char *name, *n = NULL;
+
+name = basename(root_target);
+target = path_join(*p, name, NULL);
+if (!target)
+return -ENOMEM;
+
+free(path);
+path = target;
+target = NULL;
+
+if (unit_name_is_valid(info-name,
UNIT_NAME_INSTANCE)) {
+_cleanup_free_ char *instance
= NULL;
+char *at;
+
+at = strchr(info-name, '@');
+
+assert(at);
+
+instance = strdup(++at);
+if (!instance)
+return -ENOMEM;
+
+at = strchr(name, '@');
+if (at) {
+
Re: [systemd-devel] systemctl disable service not working as expected
On Fri, 29.05.15 11:19, Belal, Awais (awais_be...@mentor.com) wrote: Hi, I am working on an x86_64 platform with a yocto based environment. I was trying to disable pulseaudio which is included in the system by default so I did a 'systemctl disable pulseaudio' but when I reboot it seems pulseaudio is still run for a very short period of time and this is messing up some sound controls on my system. Although SYSVINIT capability is enabled but no sysv init style scripts are available on the target. Any pointers will be really helpful. pulseaudio is generally not a system service but a user service. Unless your user session is fully converted to be managed by systemd too (which is unlikely) systemd is hence not involved at all with starting it. PA is usually started from the session setup script or service. In Gnome that's gnome-session, for example. It's also auto-spawned on-demand if the libraries are used and note that it is missing. 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] install: follow symlinks when enabling unit files from /usr/
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1432908009-16682-1-git-send-email-msekleta%40redhat.com -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl as non-root
On Fri, 29.05.15 13:56, Mantas Mikulėnas (graw...@gmail.com) wrote: systemd will always use D-Bus (the protocol) for IPC, that's not optional, and you cannot turn it off neither during build-time nor during runtime. systemd does not use libdbus to implement this however, but instead it uses its own D-Bus client implementation, dubbed sd-bus, which is going to be a public API with the next systemd release. Optional however is whether dbus-daemon (the daemon) is used as for IPC, or if all dbus IPC takes place only between systemd and its clients via direct AF_UNIX connections, without the central bus concept. We support this mode mostly to cover for the early-boot phase where dbus-daemon is not running yet, and hence cannot be used for communication. Running in this mode even during normal operation is supported, but not recommended (which is why the README says: dbus is strictly speaking optional, but recommended). The direct AF_UNIX communication is available exclusively for privileged clients. Normally it's the duty of dbus-daemon to enforce more complex policy on dbus1 systems. If you take dbus-daemon out of the equation however, then this policy component will be missing, and hence systemd refuses to talk to any unprivileged clients. Hmm, in a kdbus world, systemd (the service) itself would be responsible for policy checks anyway, wouldn't it? I mean, it already does the polkit/selinux checks even on dbus1 systems. Correct. However, it does so in cooperation with sd-bus and kdbus. kdbus provides per-method call credentials, which allows us to properly authenticate the individual method call. kdbus also does per-service access control, and sd-bus provides support for defining access control for methods in a static way. All together in systemd on kdbus there are four layers of access checks applied: 1. kdbus own per-service policy 2. sd-bus' static per-method capability based checks, as declared in the object vtables 3. dynamic access control on objects, enforced by systemd itself based on capabalities, uids, and policykit 4. selinux checks based on object and client labels Only if all four layers allow access, access is actually granted. In the long run I hope to add some more helpers to make it easier to implement the schemes of #3 in external services. Currently we have some internal glue that makes invocation of policykit easy, but we should probably provide a public API for that right in sd-bus, too. 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] build-sys: pass originally configured --enable-split-usr to distcheck
Lennart Poettering [2015-05-29 16:28 +0200]: Looks good. Please push. Pushed. Any chance you can connect this thing to #systemd on IRC? Would really love to be notified about failures, but ideall without email-spam... Yes, I'd like that too. I haven't looked at how to create IRC bots, but it shouldn't be too hard, there's plenty of them :-) On my TODO now. 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] cryptsetup: craft a unique ID with the source device
On Fri, 29.05.15 12:17, har...@redhat.com (har...@redhat.com) wrote:
+static char* disk_maj_min(const char *path) {
I'd really not abbreivate things here... call it major and
minor. there's no point in saving two ors...
+struct stat st, st2;
+char *i = NULL;
+int r;
+
+assert(path);
+
+if (stat(path, st) 0)
+return NULL;
+
+if (!S_ISBLK(st.st_mode))
+return NULL;
+
+asprintf(i, /dev/block/%d:%d, major(st.st_rdev),
minor(st.st_rdev));
+
+if (!i)
+return strdup(path);
I'd really prefer if we would propagate errors properly
here. I.e. change the function to:
static int disk_major_minor(const char *path, char **ret);
Then, return proper error codes, and the newly allocated name in *ret.
+
+r = stat(i, st2);
+if ((r 0) || (st.st_rdev != st2.st_rdev)) {
+free(i);
+return strdup(path);
+}
Why the second stat() check? I think we can be reasonably sure that
these device nodes will use the right major/minor...
(Also, the extra () seem unnecessary...)
Otherwise looks fine.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH V2] cryptsetup: craft a unique ID with the source device
From: Harald Hoyer har...@redhat.com
If cryptsetup is called with a source device as argv[3], then craft the
ID for the password agent with a unique device path.
If possible /dev/block/maj:min is used, otherwise the original
argv[3] is used.
This enables password agents like petera [1] to provide a password
according to the source device. The original ID did not carry enough
information and was more targeted for a human readable string, which
is specified in the Message field anyway.
With this patch the ID of the ask.XXX ini file looks like this:
ID=cryptsetup:/dev/block/maj:min
[1] https://github.com/npmccallum/petera
---
V2:
- renamed to disk_major_minor(), return error values
- removed sanity stat() for /dev/block/maj:min
src/cryptsetup/cryptsetup.c | 88 +
1 file changed, 57 insertions(+), 31 deletions(-)
diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
index a5018f1..ff3325c 100644
--- a/src/cryptsetup/cryptsetup.c
+++ b/src/cryptsetup/cryptsetup.c
@@ -238,6 +238,24 @@ static void log_glue(int level, const char *msg, void
*usrptr) {
log_debug(%s, msg);
}
+static int disk_major_minor(const char *path, char **ret) {
+struct stat st;
+
+assert(path);
+
+if (stat(path, st) 0)
+return -errno;
+
+if (!S_ISBLK(st.st_mode))
+return -EINVAL;
+
+if(asprintf(ret, /dev/block/%d:%d, major(st.st_rdev),
minor(st.st_rdev)) 0) {
+return log_oom();
+}
+
+return 0;
+}
+
static char* disk_description(const char *path) {
static const char name_fields[] =
@@ -295,20 +313,54 @@ static char *disk_mount_point(const char *label) {
return NULL;
}
-static int get_password(const char *name, usec_t until, bool accept_cached,
char ***passwords) {
-int r;
+static int get_password(const char *vol, const char *src, usec_t until, bool
accept_cached, char ***passwords) {
+int r = 0;
char **p;
_cleanup_free_ char *text = NULL;
_cleanup_free_ char *escaped_name = NULL;
char *id;
+const char *name = NULL;
+_cleanup_free_ char *description = NULL, *name_buffer = NULL,
+*mount_point = NULL, *maj_min = NULL;
assert(name);
assert(passwords);
+description = disk_description(src);
+mount_point = disk_mount_point(vol);
+
+if (description streq(vol, description)) {
+/* If the description string is simply the
+ * volume name, then let's not show this
+ * twice */
+free(description);
+description = NULL;
+}
+
+if (mount_point description)
+r = asprintf(name_buffer, %s (%s) on %s, description, vol,
mount_point);
+else if (mount_point)
+r = asprintf(name_buffer, %s on %s, vol, mount_point);
+else if (description)
+r = asprintf(name_buffer, %s (%s), description, vol);
+
+if (r 0) {
+log_oom();
+return r;
+}
+name = name_buffer ? name_buffer : vol;
+
if (asprintf(text, Please enter passphrase for disk %s!, name) 0)
return log_oom();
-escaped_name = cescape(name);
+if (src)
+disk_major_minor(src, maj_min);
+
+if (maj_min)
+escaped_name = maj_min;
+else
+escaped_name = cescape(name);
+
if (!escaped_name)
return log_oom();
@@ -552,8 +604,7 @@ int main(int argc, char *argv[]) {
unsigned tries;
usec_t until;
crypt_status_info status;
-const char *key_file = NULL, *name = NULL;
-_cleanup_free_ char *description = NULL, *name_buffer = NULL,
*mount_point = NULL;
+const char *key_file = NULL;
/* Arguments: systemd-cryptsetup attach VOLUME SOURCE-DEVICE
[PASSWORD] [OPTIONS] */
@@ -581,31 +632,6 @@ int main(int argc, char *argv[]) {
/* A delicious drop of snake oil */
mlockall(MCL_FUTURE);
-description = disk_description(argv[3]);
-mount_point = disk_mount_point(argv[2]);
-
-if (description streq(argv[2], description)) {
-/* If the description string is simply the
- * volume name, then let's not show this
- * twice */
-free(description);
-description = NULL;
-}
-
-k = 0;
-if (mount_point description)
-k = asprintf(name_buffer, %s (%s) on %s,
description, argv[2], mount_point);
-else if (mount_point)
-k = asprintf(name_buffer, %s on
Re: [systemd-devel] [PATCH] zsh-completion: a more style/tag aware _systemctl
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1432910411-14517-1-git-send-email-llua%40gmx.com -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2 1/2] path-util: Fix path_is_mount_point for files
Hello,
Lennart Poettering [2015-05-28 19:44 +0200]:
I really think this should work as close as the usual *at() calls
work. i.e. take a dir fd as first argument, and a filename
*within*that*directory* to check. Maybe even give it the _at() suffix:
int fd_is_mount_point_at(int fd, const char *filename, int flags);
int path_is_mount_point(const char *path, int flags);
path_is_mount_point() simply seperates the last part of the path,
opens its parent directory, and then invokes fd_is_mount_point_at()
with the parent dir and the last component...
Done now, this indeed looks much better now, avoids the have parent
or not cases.
This patch keeps the signature of path_is_mount_point(), as that's
being used in a lot of places. For simpler revivewing I'll send that
as a second patch. This updates fd_is_mount_point_at() to behave like
openat() and work for files again, fixing the regression.
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From eb23ac596bd57e10f64dad45e0c98e60ef460359 Mon Sep 17 00:00:00 2001
From: Martin Pitt martin.p...@ubuntu.com
Date: Wed, 27 May 2015 09:56:03 +0200
Subject: [PATCH 1/2] path-util: Fix path_is_mount_point for files
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Commits 27cc6f166 and f25afeb broke path_is_mount_point() for files (such as
/etc/machine-id → /run/machine-id bind mounts) as with the factorization of
fd_is_mount_point() we lost the parent directory. We cannot determine that from
an fd only as openat(fd, ..) only works for directory fds.
Change fd_is_mount_point() to behave like openat(): It now takes a file
descriptor of the containing directory, a file name in it, and flags (which can
be 0 or AT_SYMLINK_FOLLOW). Unlike name_to_handle_at() or openat(), fstatat()
only accepts the inverse flag AT_SYMLINK_NOFOLLOW and complains with EINVAL
about AT_SYMLINK_FOLLOW; so we need to transform the flags for that fallback.
Adjust rm_rf_children() accordingly (only other caller of fd_is_mount_point()
aside from path_is_mount_point()).
Add test cases for files, links, and file bind mounts (the latter will only
work when running as root). Split out a new test_path_is_mount_point() test
case function as it got significantly larger now.
---
src/shared/path-util.c| 31 +--
src/shared/path-util.h| 2 +-
src/shared/rm-rf.c| 2 +-
src/test/test-path-util.c | 76 +++
4 files changed, 87 insertions(+), 24 deletions(-)
diff --git a/src/shared/path-util.c b/src/shared/path-util.c
index 7090989..cf24aa1 100644
--- a/src/shared/path-util.c
+++ b/src/shared/path-util.c
@@ -509,7 +509,7 @@ static int fd_fdinfo_mnt_id(int fd, const char *filename, int flags, int *mnt_id
return safe_atoi(p, mnt_id);
}
-int fd_is_mount_point(int fd) {
+int fd_is_mount_point(int fd, const char *filename, int flags) {
union file_handle_union h = FILE_HANDLE_INIT, h_parent = FILE_HANDLE_INIT;
int mount_id = -1, mount_id_parent = -1;
bool nosupp = false, check_st_dev = true;
@@ -517,6 +517,7 @@ int fd_is_mount_point(int fd) {
int r;
assert(fd = 0);
+assert(filename);
/* First we will try the name_to_handle_at() syscall, which
* tells us the mount id and an opaque file handle. It is
@@ -541,7 +542,7 @@ int fd_is_mount_point(int fd) {
* subvolumes have different st_dev, even though they aren't
* real mounts of their own. */
-r = name_to_handle_at(fd, , h.handle, mount_id, AT_EMPTY_PATH);
+r = name_to_handle_at(fd, filename, h.handle, mount_id, flags);
if (r 0) {
if (errno == ENOSYS)
/* This kernel does not support name_to_handle_at()
@@ -558,7 +559,7 @@ int fd_is_mount_point(int fd) {
return -errno;
}
-r = name_to_handle_at(fd, .., h_parent.handle, mount_id_parent, 0);
+r = name_to_handle_at(fd, , h_parent.handle, mount_id_parent, AT_EMPTY_PATH);
if (r 0) {
if (errno == EOPNOTSUPP) {
if (nosupp)
@@ -593,13 +594,13 @@ int fd_is_mount_point(int fd) {
return mount_id != mount_id_parent;
fallback_fdinfo:
-r = fd_fdinfo_mnt_id(fd, , AT_EMPTY_PATH, mount_id);
+r = fd_fdinfo_mnt_id(fd, filename, flags, mount_id);
if (r == -EOPNOTSUPP)
goto fallback_fstat;
if (r 0)
return r;
-r = fd_fdinfo_mnt_id(fd, .., 0, mount_id_parent);
+r = fd_fdinfo_mnt_id(fd, , AT_EMPTY_PATH, mount_id_parent);
if (r 0)
return r;
@@ -615,10 +616,16 @@ fallback_fdinfo:
check_st_dev = false;
fallback_fstat:
-if (fstatat(fd, , a, AT_EMPTY_PATH) 0)
+/* yay for fstatat() taking a different set of
[systemd-devel] [PATCH V3] cryptsetup: craft a unique ID with the source device
From: Harald Hoyer har...@redhat.com
If cryptsetup is called with a source device as argv[3], then craft the
ID for the password agent with a unique device path.
If possible /dev/block/maj:min is used, otherwise the original
argv[3] is used.
This enables password agents like petera [1] to provide a password
according to the source device. The original ID did not carry enough
information and was more targeted for a human readable string, which
is specified in the Message field anyway.
With this patch the ID of the ask.XXX ini file looks like this:
ID=cryptsetup:/dev/block/maj:min
[1] https://github.com/npmccallum/petera
---
V2:
- renamed to disk_major_minor(), return error values
- removed sanity stat() for /dev/block/maj:min
V3:
- assert() the correct parameters
src/cryptsetup/cryptsetup.c | 91 +
1 file changed, 59 insertions(+), 32 deletions(-)
diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
index a5018f1..5f64ada 100644
--- a/src/cryptsetup/cryptsetup.c
+++ b/src/cryptsetup/cryptsetup.c
@@ -238,6 +238,24 @@ static void log_glue(int level, const char *msg, void
*usrptr) {
log_debug(%s, msg);
}
+static int disk_major_minor(const char *path, char **ret) {
+struct stat st;
+
+assert(path);
+
+if (stat(path, st) 0)
+return -errno;
+
+if (!S_ISBLK(st.st_mode))
+return -EINVAL;
+
+if(asprintf(ret, /dev/block/%d:%d, major(st.st_rdev),
minor(st.st_rdev)) 0) {
+return log_oom();
+}
+
+return 0;
+}
+
static char* disk_description(const char *path) {
static const char name_fields[] =
@@ -295,20 +313,55 @@ static char *disk_mount_point(const char *label) {
return NULL;
}
-static int get_password(const char *name, usec_t until, bool accept_cached,
char ***passwords) {
-int r;
+static int get_password(const char *vol, const char *src, usec_t until, bool
accept_cached, char ***passwords) {
+int r = 0;
char **p;
_cleanup_free_ char *text = NULL;
_cleanup_free_ char *escaped_name = NULL;
char *id;
+const char *name = NULL;
+_cleanup_free_ char *description = NULL, *name_buffer = NULL,
+*mount_point = NULL, *maj_min = NULL;
-assert(name);
+assert(vol);
+assert(src);
assert(passwords);
+description = disk_description(src);
+mount_point = disk_mount_point(vol);
+
+if (description streq(vol, description)) {
+/* If the description string is simply the
+ * volume name, then let's not show this
+ * twice */
+free(description);
+description = NULL;
+}
+
+if (mount_point description)
+r = asprintf(name_buffer, %s (%s) on %s, description, vol,
mount_point);
+else if (mount_point)
+r = asprintf(name_buffer, %s on %s, vol, mount_point);
+else if (description)
+r = asprintf(name_buffer, %s (%s), description, vol);
+
+if (r 0) {
+log_oom();
+return r;
+}
+name = name_buffer ? name_buffer : vol;
+
if (asprintf(text, Please enter passphrase for disk %s!, name) 0)
return log_oom();
-escaped_name = cescape(name);
+if (src)
+disk_major_minor(src, maj_min);
+
+if (maj_min)
+escaped_name = maj_min;
+else
+escaped_name = cescape(name);
+
if (!escaped_name)
return log_oom();
@@ -552,8 +605,7 @@ int main(int argc, char *argv[]) {
unsigned tries;
usec_t until;
crypt_status_info status;
-const char *key_file = NULL, *name = NULL;
-_cleanup_free_ char *description = NULL, *name_buffer = NULL,
*mount_point = NULL;
+const char *key_file = NULL;
/* Arguments: systemd-cryptsetup attach VOLUME SOURCE-DEVICE
[PASSWORD] [OPTIONS] */
@@ -581,31 +633,6 @@ int main(int argc, char *argv[]) {
/* A delicious drop of snake oil */
mlockall(MCL_FUTURE);
-description = disk_description(argv[3]);
-mount_point = disk_mount_point(argv[2]);
-
-if (description streq(argv[2], description)) {
-/* If the description string is simply the
- * volume name, then let's not show this
- * twice */
-free(description);
-description = NULL;
-}
-
-k = 0;
-if (mount_point description)
-k = asprintf(name_buffer, %s (%s) on %s,
description, argv[2], mount_point);
-
[systemd-devel] [PATCH] zsh-completion: a more style/tag aware _systemctl
using _wanted instead of calling compadd directly. this allows the user to
customize
possible matches.
An example being, grouping units by type:
autoload -Uz compinit; compinit
zstyle ':completion:*' menu select
zstyle ':completion:*' group-name ''
zstyle ':completion:*' format 'Completing %d'
zstyle -e ':completion:*:*:systemctl-(((re|)en|dis)able|(*re|)start|reload*):*'
\
tag-order 'local type; for type in service template target socket;
reply+=( systemd-units:-${type}:${type} ); reply=( $reply
systemd-units:-misc:misc )'
zstyle ':completion:*:systemd-units-template' ignored-patterns '^*@'
zstyle ':completion:*:systemd-units-target' ignored-patterns '^*.target'
zstyle ':completion:*:systemd-units-socket' ignored-patterns '^*.socket'
zstyle ':completion:*:systemd-units-service' ignored-patterns '^*.service'
zstyle ':completion:*:systemd-units-misc' ignored-patterns
'*(@|.(service|socket|target))'
also, poke
http://lists.freedesktop.org/archives/systemd-devel/2015-May/032012.html
---
shell-completion/zsh/_systemctl.in | 60 +++---
1 file changed, 37 insertions(+), 23 deletions(-)
diff --git a/shell-completion/zsh/_systemctl.in
b/shell-completion/zsh/_systemctl.in
index db9bdb6..e11671f 100644
--- a/shell-completion/zsh/_systemctl.in
+++ b/shell-completion/zsh/_systemctl.in
@@ -65,7 +65,7 @@
if (( CURRENT == 1 )); then
_describe -t commands 'systemctl command' _systemctl_cmds || compadd $@
else
-local curcontext=$curcontext
+local curcontext=$curcontext expl
cmd=${${_systemctl_cmds[(r)$words[1]:*]%%:*}}
# Deal with any aliases
@@ -172,7 +172,8 @@ for fun in is-active is-failed is-enabled status show cat
mask preset help list-
(( $+functions[_systemctl_$fun] )) || _systemctl_$fun()
{
_systemctl_really_all_units
-compadd $@ -a - _sys_really_all_units
+_wanted systemd-units expl unit \
+ compadd $@ -a - _sys_really_all_units
}
done
@@ -180,34 +181,39 @@ done
(( $+functions[_systemctl_disable] )) || _systemctl_disable()
{
local _sys_unit_state; _systemctl_unit_state
-compadd $@ - ${(k)_sys_unit_state[(R)enabled]}
+_wanted systemd-units expl 'enabled unit' \
+ compadd $@ - ${(k)_sys_unit_state[(R)enabled]}
}
(( $+functions[_systemctl_reenable] )) || _systemctl_reenable()
{
local _sys_unit_state; _systemctl_unit_state
-compadd $@ - ${(k)_sys_unit_state[(R)(enabled|disabled)]}
$(_systemctl_get_template_names)
+_wanted systemd-units expl 'enabled/disabled unit' \
+ compadd $@ - ${(k)_sys_unit_state[(R)(enabled|disabled)]}
$(_systemctl_get_template_names)
}
# Completion functions for DISABLED_UNITS
(( $+functions[_systemctl_enable] )) || _systemctl_enable()
{
local _sys_unit_state; _systemctl_unit_state
- compadd $@ - ${(k)_sys_unit_state[(R)disabled]}
$(_systemctl_get_template_names)
+ _wanted systemd-units expl 'disabled unit' \
+compadd $@ - ${(k)_sys_unit_state[(R)disabled]}
$(_systemctl_get_template_names)
}
# Completion functions for FAILED_UNITS
(( $+functions[_systemctl_reset-failed] )) || _systemctl_reset-failed()
{
local _sys_failed_units; _systemctl_failed_units
- compadd $@ -a - _sys_failed_units || _message no failed unit found
+ _wanted systemd-units expl 'failed unit' \
+compadd $@ -a - _sys_failed_units || _message no failed unit found
}
# Completion functions for STARTABLE_UNITS
(( $+functions[_systemctl_start] )) || _systemctl_start()
{
local _sys_startable_units; _systemctl_startable_units
- compadd $@ - ${_sys_startable_units[*]} $(_systemctl_get_template_names)
+ _wanted systemd-units expl 'startable unit' \
+ compadd $@ - ${_sys_startable_units[*]} $(_systemctl_get_template_names)
}
# Completion functions for STOPPABLE_UNITS
@@ -215,8 +221,9 @@ for fun in stop kill try-restart condrestart ; do
(( $+functions[_systemctl_$fun] )) || _systemctl_$fun()
{
local _sys_active_units; _systemctl_active_units
-compadd $@ - $( _filter_units_by_property CanStop yes \
- ${_sys_active_units[*]} )
+_wanted systemd-units expl 'stoppable unit' \
+ compadd $@ - $( _filter_units_by_property CanStop yes \
+${_sys_active_units[*]} )
}
done
@@ -224,8 +231,9 @@ done
(( $+functions[_systemctl_isolate] )) || _systemctl_isolate()
{
_systemctl_all_units
- compadd $@ - $( _filter_units_by_property AllowIsolate yes \
-${_sys_all_units[*]} )
+ _wanted systemd-units expl 'isolatable unit' \
+compadd $@ - $( _filter_units_by_property AllowIsolate yes \
+ ${_sys_all_units[*]} )
}
# Completion functions for RELOADABLE_UNITS
@@ -233,8 +241,9 @@ for fun in reload reload-or-try-restart force-reload ; do
(( $+functions[_systemctl_$fun] )) || _systemctl_$fun()
{
local _sys_active_units; _systemctl_active_units
-compadd $@ - $( _filter_units_by_property CanReload yes \
- ${_sys_active_units[*]} )
+_wanted systemd-units expl 'reloadable
Re: [systemd-devel] [PATCH v2] cgroup-util: fix is_valid check to pass for unified cgroup hierchy.
On 29 May 2015 at 14:41, Lennart Poettering lenn...@poettering.net wrote: On Fri, 29.05.15 12:42, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: On 29 May 2015 at 11:25, Lennart Poettering lenn...@poettering.net wrote: On Fri, 29.05.15 00:24, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: On 28 May 2015 at 18:08, Lennart Poettering lenn...@poettering.net wrote: On Thu, 28.05.15 16:42, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: It appears in /proc/self/cgroup as `0::/' What precisely does this fix? I mean, we need to do some major rework of things before the unified hierarchy is really supported in systemd, and this one thing won't really get us too much in this regard, does it? I'm starting to explore possibilities to start work towards supporting unified cgroups hierarchy, or at least be able to boot with it. I'll send a larger patch series in one go later than with all the bits that offer something more tangible, albeit disabled by default behind configure options (like kdbus) given that unified hierarchy is still marked experimental in the kernel. Ah, it's actually my big thing to work on for the next weeks too... My current priority is to port at least enough bits to get usable /sys/fs/cgroup/systemd on top of unified cgroups, with immediate benefit of dropping systemd-cgroups-agent and getting release notifications in containers. Not sure about transition / re-exec plan, at the moment I am assuming either/or situation but I guess we'd need to support a dual case, where upon re-exec we might still be in name=systemd rather than in the unified structure. My intention is to make this all work so that we can support both modes for a while, but you have to pick at boot-time which mode you want: the unified hierarchy or the classic one. And if we pick the former you won't get the latter, and if you pick the latter you won't get the former. And yeah, getting proper notifications especially for the container case is the most important thing for me too. Right. I have it as compile option at the moment, and i'm booting fresh VMs with it. I do something rather crazy at the moment - mount /sys/fs/cgroup/systemd as unified hiearchy whilst keeping the old controller mounts where they are. Will add the bits for the inotify watches and then publish an RFC patch set. This way systemd gains the notification benefit straight away, whilst keeping the rest as it was essentially. I take it the unitfied structure is expected to be mounted in /sys/fs/cgroup/ direct, once stable. -- Regards, Dimitri. Pura Vida! https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup: craft a unique ID with the source device
On Fri, 29.05.15 15:45, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: On 29 May 2015 at 11:17, har...@redhat.com wrote: From: Harald Hoyer har...@redhat.com If cryptsetup is called with a source device as argv[3], then craft the ID for the password agent with a unique device path. I'm not sure why this is needed... if the device path is not good enough, there is also luks UUID header. In Ubuntu we display the full cryptsetup UUID in plymouth, but that's fairly cosmetic. If the path is not good enough, maj/min are a bit pointless and you really probably want the luks UUID then. Harald actually convinced me now that this is useful indeed, simply to ensure that if multiple invocations of systemd-cryptsetup using different device aliases actually result in the same id used in the password file. 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 v2] cgroup-util: fix is_valid check to pass for unified cgroup hierchy.
Lennart Poettering [2015-05-29 17:02 +0200]: I'd really just introduce a new kernel cmdline option: systemd.debug-unified-cgroup=1 or so. A simple boolean that gets you either one or the other behaviour. Maybe make the default for this setting configurable with a configure script switch. And I'd include the debug in the name, to indicate that this is just for testing for now, and is an option that will go away eventually. How does that play with containers? Is it just that you can't switch on the unified hierarchy as long as you still have containers with older systemd versions which don't support that yet? That would be a bit ugly, but bearable, I guess, and it'll sort itself out over time. Or are there any worse issues there? 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 v2] cgroup-util: fix is_valid check to pass for unified cgroup hierchy.
On Fri, 29.05.15 17:09, Martin Pitt (martin.p...@ubuntu.com) wrote: Lennart Poettering [2015-05-29 17:02 +0200]: I'd really just introduce a new kernel cmdline option: systemd.debug-unified-cgroup=1 or so. A simple boolean that gets you either one or the other behaviour. Maybe make the default for this setting configurable with a configure script switch. And I'd include the debug in the name, to indicate that this is just for testing for now, and is an option that will go away eventually. How does that play with containers? Is it just that you can't switch on the unified hierarchy as long as you still have containers with older systemd versions which don't support that yet? That would be a bit ugly, but bearable, I guess, and it'll sort itself out over time. IIUC a container manager could actually support old userspace in containers on a system that otherwise uses the unified hierarchy. THis is because even with the unified hierarchy in place you can still set up additional, named hierarchies. You'd hence mount an otherwise empty name=systemd hierarchied in your container manager and pass that to the container, and not mount anything else (especially no controller hierarchies). For the container everything should be as usual. Unfortunately this requires configuration though: you have to tell your container manager how to set things up, this cannot be set up in a way so that that old userspace magically gets the right classic cgroup setup, while new userspace magically gets the new cgroup setip... 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 v2 1/2] path-util: Fix path_is_mount_point for files
Lennart Poettering [2015-05-29 17:31 +0200]: I think this: flags = flags ~AT_SYMLINK_FOLLOW; should better be written like this: flags = ~AT_SYMLINK_FOLLOW; this matches the other if branch better then... Of course, little brainfart.. Looks good otherwise, please push. Pushed with the above change. 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] [systemd-commits] Makefile.am
Hi, I was thinking about this one recently... I really think the correct solution is for man/custom-entities.ent to be generated by configure from a man/custom-entities.ent.in template instead. I haven't really checked if that's viable though, if configure knows about every variable it will need, etc. but I was planning to look into it at some point in the near future. On Fri, May 29, 2015 at 9:39 AM, Michael Biebl mbi...@gmail.com wrote: 2015-05-29 15:56 GMT+02:00 Lennart Poettering lenn...@poettering.net: I think it's ok to expect people to run make clean after touching the makefile to get the man pages fixed. Atm, man/custom-entities.ent is only cleaned up on make distclean. I think we should move that from DISTCLEANFILES to CLEANFILES. Yes I think that's a good start and `make clean` will trigger a rebuild of most of what depends on custom-entities.ent anyways so I wouldn't expect a lot of spurious rebuilds due to that. Cheers, Filipe ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH V3] cryptsetup: craft a unique ID with the source device
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1432916659-16919-1-git-send-email-harald%40redhat.com -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup: craft a unique ID with the source device
Harald Hoyer [2015-05-29 16:50 +0200]: I was more thinking about symlinks pointing to the same device. Naïvely I'd think that resolving symlinks would still be more readable than major/minor numbers; why would that be worse? 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] cryptsetup: craft a unique ID with the source device
On Fri, 29.05.15 17:01, Martin Pitt (martin.p...@ubuntu.com) wrote: Harald Hoyer [2015-05-29 16:50 +0200]: I was more thinking about symlinks pointing to the same device. Naïvely I'd think that resolving symlinks would still be more readable than major/minor numbers; why would that be worse? Well, sure, one can do that too. However, internally in udev we generally identify devices by the major/minor or by their network interface index, since these are not subject to renames ever... And I think this tool should follow what we do in udev in this regard, I guess. 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] cryptsetup: craft a unique ID with the source device
Am 29.05.2015 um 17:04 schrieb Lennart Poettering:
On Fri, 29.05.15 12:17, har...@redhat.com (har...@redhat.com) wrote:
+static char* disk_maj_min(const char *path) {
I'd really not abbreivate things here... call it major and
minor. there's no point in saving two ors...
+struct stat st, st2;
+char *i = NULL;
+int r;
+
+assert(path);
+
+if (stat(path, st) 0)
+return NULL;
+
+if (!S_ISBLK(st.st_mode))
+return NULL;
+
+asprintf(i, /dev/block/%d:%d, major(st.st_rdev),
minor(st.st_rdev));
+
+if (!i)
+return strdup(path);
I'd really prefer if we would propagate errors properly
here. I.e. change the function to:
static int disk_major_minor(const char *path, char **ret);
ret as the last or the first argument?
Then, return proper error codes, and the newly allocated name in *ret.
just copied the scheme of disk_description() and disk_mount_point() :-)
+
+r = stat(i, st2);
+if ((r 0) || (st.st_rdev != st2.st_rdev)) {
+free(i);
+return strdup(path);
+}
Why the second stat() check? I think we can be reasonably sure that
these device nodes will use the right major/minor...
Yes, what if it is missing? Someone removed it or played games :)
Sure, can remove the rdev check.
(Also, the extra () seem unnecessary...)
Otherwise looks fine.
Lennart
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2 1/2] path-util: Fix path_is_mount_point for files
On Fri, 29.05.15 17:22, Martin Pitt (martin.p...@ubuntu.com) wrote: Hello, Lennart Poettering [2015-05-28 19:44 +0200]: I really think this should work as close as the usual *at() calls work. i.e. take a dir fd as first argument, and a filename *within*that*directory* to check. Maybe even give it the _at() suffix: int fd_is_mount_point_at(int fd, const char *filename, int flags); int path_is_mount_point(const char *path, int flags); path_is_mount_point() simply seperates the last part of the path, opens its parent directory, and then invokes fd_is_mount_point_at() with the parent dir and the last component... Done now, this indeed looks much better now, avoids the have parent or not cases. This patch keeps the signature of path_is_mount_point(), as that's being used in a lot of places. For simpler revivewing I'll send that as a second patch. This updates fd_is_mount_point_at() to behave like openat() and work for files again, fixing the regression. One minor nitpick: fallback_fstat: -if (fstatat(fd, , a, AT_EMPTY_PATH) 0) +/* yay for fstatat() taking a different set of flags than the other + * _at() above */ +if (flags AT_SYMLINK_FOLLOW) +flags = flags ~AT_SYMLINK_FOLLOW; +else +flags |= AT_SYMLINK_NOFOLLOW; +if (fstatat(fd, filename, a, flags) 0) return -errno; I think this: flags = flags ~AT_SYMLINK_FOLLOW; should better be written like this: flags = ~AT_SYMLINK_FOLLOW; this matches the other if branch better then... Looks good otherwise, please push. 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 V3] cryptsetup: craft a unique ID with the source device
On Fri, 29.05.15 18:24, har...@redhat.com (har...@redhat.com) wrote:
+static int disk_major_minor(const char *path, char **ret) {
+struct stat st;
+
+assert(path);
+
+if (stat(path, st) 0)
+return -errno;
+
+if (!S_ISBLK(st.st_mode))
+return -EINVAL;
+
+if(asprintf(ret, /dev/block/%d:%d, major(st.st_rdev),
minor(st.st_rdev)) 0) {
+return log_oom();
+}
There's a space missing between if and the opening (...
Also, for single line if blocks we don't put {}, see CODING_STYLE.
Then, we should make sure that each function either logs about all its
errors, or about none and leaves logging to its callers. Currently you log
about OOM but not about the other errors. This means that the caller
will either print duplicate error messages or miss them
entirely... (also see CODING_STYLE)
In this case I think you should just return -ENOMEM, and leave all
logging (or ignoring of any error) to the caller.
Otherwise looks fine.
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] cryptsetup: craft a unique ID with the source device
On 29 May 2015 at 11:17, har...@redhat.com wrote:
From: Harald Hoyer har...@redhat.com
If cryptsetup is called with a source device as argv[3], then craft the
ID for the password agent with a unique device path.
I'm not sure why this is needed... if the device path is not good
enough, there is also luks UUID header. In Ubuntu we display the full
cryptsetup UUID in plymouth, but that's fairly cosmetic.
If the path is not good enough, maj/min are a bit pointless and you
really probably want the luks UUID then.
Regards,
Dimitri.
If possible /dev/block/maj:min is used, otherwise the original
argv[3] is used.
This enables password agents like petera [1] to provide a password
according to the source device. The original ID did not carry enough
information and was more targeted for a human readable string, which
is specified in the Message field anyway.
With this patch the ID of the ask.XXX ini file looks like this:
ID=cryptsetup:/dev/block/maj:min
[1] https://github.com/npmccallum/petera
---
src/cryptsetup/cryptsetup.c | 97
++---
1 file changed, 66 insertions(+), 31 deletions(-)
diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
index a5018f1..130c36e 100644
--- a/src/cryptsetup/cryptsetup.c
+++ b/src/cryptsetup/cryptsetup.c
@@ -238,6 +238,33 @@ static void log_glue(int level, const char *msg, void
*usrptr) {
log_debug(%s, msg);
}
+static char* disk_maj_min(const char *path) {
+struct stat st, st2;
+char *i = NULL;
+int r;
+
+assert(path);
+
+if (stat(path, st) 0)
+return NULL;
+
+if (!S_ISBLK(st.st_mode))
+return NULL;
+
+asprintf(i, /dev/block/%d:%d, major(st.st_rdev),
minor(st.st_rdev));
+
+if (!i)
+return strdup(path);
+
+r = stat(i, st2);
+if ((r 0) || (st.st_rdev != st2.st_rdev)) {
+free(i);
+return strdup(path);
+}
+
+return i;
+}
+
static char* disk_description(const char *path) {
static const char name_fields[] =
@@ -295,20 +322,54 @@ static char *disk_mount_point(const char *label) {
return NULL;
}
-static int get_password(const char *name, usec_t until, bool accept_cached,
char ***passwords) {
-int r;
+static int get_password(const char *vol, const char *src, usec_t until, bool
accept_cached, char ***passwords) {
+int r = 0;
char **p;
_cleanup_free_ char *text = NULL;
_cleanup_free_ char *escaped_name = NULL;
char *id;
+const char *name = NULL;
+_cleanup_free_ char *description = NULL, *name_buffer = NULL,
+*mount_point = NULL, *maj_min = NULL;
assert(name);
assert(passwords);
+description = disk_description(src);
+mount_point = disk_mount_point(vol);
+
+if (description streq(vol, description)) {
+/* If the description string is simply the
+ * volume name, then let's not show this
+ * twice */
+free(description);
+description = NULL;
+}
+
+if (mount_point description)
+r = asprintf(name_buffer, %s (%s) on %s, description,
vol, mount_point);
+else if (mount_point)
+r = asprintf(name_buffer, %s on %s, vol, mount_point);
+else if (description)
+r = asprintf(name_buffer, %s (%s), description, vol);
+
+if (r 0) {
+log_oom();
+return r;
+}
+name = name_buffer ? name_buffer : vol;
+
if (asprintf(text, Please enter passphrase for disk %s!, name)
0)
return log_oom();
-escaped_name = cescape(name);
+if (src)
+maj_min = disk_maj_min(src);
+
+if (maj_min)
+escaped_name = maj_min;
+else
+escaped_name = cescape(name);
+
if (!escaped_name)
return log_oom();
@@ -552,8 +613,7 @@ int main(int argc, char *argv[]) {
unsigned tries;
usec_t until;
crypt_status_info status;
-const char *key_file = NULL, *name = NULL;
-_cleanup_free_ char *description = NULL, *name_buffer =
NULL, *mount_point = NULL;
+const char *key_file;
/* Arguments: systemd-cryptsetup attach VOLUME SOURCE-DEVICE
[PASSWORD] [OPTIONS] */
@@ -581,31 +641,6 @@ int main(int argc, char *argv[]) {
/* A delicious drop of snake oil */
mlockall(MCL_FUTURE);
-description = disk_description(argv[3]);
-mount_point = disk_mount_point(argv[2]);
-
-if (description streq(argv[2],
Re: [systemd-devel] [PATCH] cryptsetup: craft a unique ID with the source device
Am 29.05.2015 um 16:38 schrieb Lennart Poettering: On Fri, 29.05.15 16:30, Harald Hoyer (har...@redhat.com) wrote: Am 29.05.2015 um 16:26 schrieb Lennart Poettering: On Fri, 29.05.15 12:17, har...@redhat.com (har...@redhat.com) wrote: From: Harald Hoyer har...@redhat.com If cryptsetup is called with a source device as argv[3], then craft the ID for the password agent with a unique device path. If possible /dev/block/maj:min is used, otherwise the original argv[3] is used. Why use the major/minor numebrs here? Why isn't the original device name good enough? Don't we want a kind of unique ID? But the original device path is already unique? I mean, it's a path in the file heirarchy, that already makes it unique. Or what do you mean by unique? Lennart I was more thinking about symlinks pointing to the same device. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2 2/2] path-util: Change path_is_mount_point() symlink arg from bool to flags
On Fri, 29.05.15 17:25, Martin Pitt (martin.p...@ubuntu.com) wrote: Hello, and this is the second part which updates the signature of path_is_mount_point() to replace bool allow_symlink to an openat()-like flags. This patch does not change visible behaviour, it's just a stylistic issue. Looks good too. Please push! 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 v2 2/2] path-util: Change path_is_mount_point() symlink arg from bool to flags
Lennart Poettering [2015-05-29 17:50 +0200]: Looks good too. Please push! Pushed. 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] cryptsetup: craft a unique ID with the source device
On Fri, 29.05.15 16:30, Harald Hoyer (har...@redhat.com) wrote: Am 29.05.2015 um 16:26 schrieb Lennart Poettering: On Fri, 29.05.15 12:17, har...@redhat.com (har...@redhat.com) wrote: From: Harald Hoyer har...@redhat.com If cryptsetup is called with a source device as argv[3], then craft the ID for the password agent with a unique device path. If possible /dev/block/maj:min is used, otherwise the original argv[3] is used. Why use the major/minor numebrs here? Why isn't the original device name good enough? Don't we want a kind of unique ID? But the original device path is already unique? I mean, it's a path in the file heirarchy, that already makes it unique. Or what do you mean by unique? 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 v2] cgroup-util: fix is_valid check to pass for unified cgroup hierchy.
On Fri, 29.05.15 15:52, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: And yeah, getting proper notifications especially for the container case is the most important thing for me too. Right. I have it as compile option at the moment, and i'm booting fresh VMs with it. I do something rather crazy at the moment - mount /sys/fs/cgroup/systemd as unified hiearchy whilst keeping the old controller mounts where they are. Will add the bits for the inotify watches and then publish an RFC patch set. This way systemd gains the notification benefit straight away, whilst keeping the rest as it was essentially. I take it the unitfied structure is expected to be mounted in /sys/fs/cgroup/ direct, once stable. I'd rather not support half-way implementations like that. I'd really just introduce a new kernel cmdline option: systemd.debug-unified-cgroup=1 or so. A simple boolean that gets you either one or the other behaviour. Maybe make the default for this setting configurable with a configure script switch. And I'd include the debug in the name, to indicate that this is just for testing for now, and is an option that will go away eventually. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2 2/2] path-util: Change path_is_mount_point() symlink arg from bool to flags
Hello,
and this is the second part which updates the signature of
path_is_mount_point() to replace bool allow_symlink to an
openat()-like flags.
This patch does not change visible behaviour, it's just a stylistic
issue.
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From 5e838c24e0a733834a102658eb742782939d6afb Mon Sep 17 00:00:00 2001
From: Martin Pitt martin.p...@ubuntu.com
Date: Fri, 29 May 2015 17:13:12 +0200
Subject: [PATCH 2/2] path-util: Change path_is_mount_point() symlink arg from
bool to flags
This makes path_is_mount_point() consistent with fd_is_mount_point() wrt.
flags.
---
src/core/automount.c| 2 +-
src/core/machine-id-setup.c | 2 +-
src/core/mount-setup.c | 2 +-
src/efi-boot-generator/efi-boot-generator.c | 2 +-
src/gpt-auto-generator/gpt-auto-generator.c | 2 +-
src/login/logind-user.c | 2 +-
src/nspawn/nspawn.c | 10 -
src/shared/cgroup-util.c| 2 +-
src/shared/condition.c | 2 +-
src/shared/machine-pool.c | 2 +-
src/shared/path-util.c | 5 +++--
src/shared/path-util.h | 2 +-
src/test/test-path-util.c | 32 ++---
13 files changed, 34 insertions(+), 33 deletions(-)
diff --git a/src/core/automount.c b/src/core/automount.c
index 13f80c2..d847dc1 100644
--- a/src/core/automount.c
+++ b/src/core/automount.c
@@ -747,7 +747,7 @@ static int automount_start(Unit *u) {
assert(a);
assert(a-state == AUTOMOUNT_DEAD || a-state == AUTOMOUNT_FAILED);
-if (path_is_mount_point(a-where, false) 0) {
+if (path_is_mount_point(a-where, 0) 0) {
log_unit_error(u, Path %s is already a mount point, refusing start., a-where);
return -EEXIST;
}
diff --git a/src/core/machine-id-setup.c b/src/core/machine-id-setup.c
index e083c5b..b3d2284 100644
--- a/src/core/machine-id-setup.c
+++ b/src/core/machine-id-setup.c
@@ -297,7 +297,7 @@ int machine_id_commit(const char *root) {
etc_machine_id = path_kill_slashes(x);
}
-r = path_is_mount_point(etc_machine_id, false);
+r = path_is_mount_point(etc_machine_id, 0);
if (r 0)
return log_error_errno(r, Failed to determine whether %s is a mount point: %m, etc_machine_id);
if (r == 0) {
diff --git a/src/core/mount-setup.c b/src/core/mount-setup.c
index ba96741..c35248e 100644
--- a/src/core/mount-setup.c
+++ b/src/core/mount-setup.c
@@ -156,7 +156,7 @@ static int mount_one(const MountPoint *p, bool relabel) {
if (relabel)
label_fix(p-where, true, true);
-r = path_is_mount_point(p-where, true);
+r = path_is_mount_point(p-where, AT_SYMLINK_FOLLOW);
if (r 0 r != -ENOENT)
return r;
if (r 0)
diff --git a/src/efi-boot-generator/efi-boot-generator.c b/src/efi-boot-generator/efi-boot-generator.c
index 42b21f5..e6b15c9 100644
--- a/src/efi-boot-generator/efi-boot-generator.c
+++ b/src/efi-boot-generator/efi-boot-generator.c
@@ -68,7 +68,7 @@ int main(int argc, char *argv[]) {
return EXIT_SUCCESS;
}
-r = path_is_mount_point(/boot, true);
+r = path_is_mount_point(/boot, AT_SYMLINK_FOLLOW);
if (r 0) {
log_debug(/boot is already a mount point, exiting.);
return EXIT_SUCCESS;
diff --git a/src/gpt-auto-generator/gpt-auto-generator.c b/src/gpt-auto-generator/gpt-auto-generator.c
index b192526..b46e160 100644
--- a/src/gpt-auto-generator/gpt-auto-generator.c
+++ b/src/gpt-auto-generator/gpt-auto-generator.c
@@ -297,7 +297,7 @@ static int probe_and_add_mount(
assert(where);
assert(description);
-if (path_is_mount_point(where, true) = 0
+if (path_is_mount_point(where, AT_SYMLINK_FOLLOW) = 0
dir_is_empty(where) = 0) {
log_debug(%s already populated, ignoring., where);
return 0;
diff --git a/src/login/logind-user.c b/src/login/logind-user.c
index 71bff96..dc3db9a 100644
--- a/src/login/logind-user.c
+++ b/src/login/logind-user.c
@@ -320,7 +320,7 @@ static int user_mkdir_runtime_path(User *u) {
} else
p = u-runtime_path;
-if (path_is_mount_point(p, false) = 0) {
+if (path_is_mount_point(p, 0) = 0) {
_cleanup_free_ char *t = NULL;
(void) mkdir(p, 0700);
diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index 23bb959..de755ce 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -1099,7 +1099,7 @@ static int mount_all(const char *dest, bool userns) {
if (!where)
return log_oom();
-
Re: [systemd-devel] [PATCH V2] cryptsetup: craft a unique ID with the source device
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1432914850-2569-1-git-send-email-harald%40redhat.com -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl as non-root
I compiled systemd without dbus support (--disable-dbus), and there is no dbus daemon or dbus lib on the system. Is that a requirement to get the functionality I want? I didn't see much need for dbus as the system works quite well without it. Well, except for this of course. systemd will always use D-Bus (the protocol) for IPC, that's not optional, and you cannot turn it off neither during build-time nor during runtime. systemd does not use libdbus to implement this however, but instead it uses its own D-Bus client implementation, dubbed sd-bus, which is going to be a public API with the next systemd release. Optional however is whether dbus-daemon (the daemon) is used as for IPC, or if all dbus IPC takes place only between systemd and its clients via direct AF_UNIX connections, without the central bus concept. We support this mode mostly to cover for the early-boot phase where dbus-daemon is not running yet, and hence cannot be used for communication. Running in this mode even during normal operation is supported, but not recommended (which is why the README says: dbus is strictly speaking optional, but recommended). The direct AF_UNIX communication is available exclusively for privileged clients. Normally it's the duty of dbus-daemon to enforce more complex policy on dbus1 systems. If you take dbus-daemon out of the equation however, then this policy component will be missing, and hence systemd refuses to talk to any unprivileged clients. Long story short: you cannot avoid dbus IPC really. Please use dbus-daemon, it's recommended. If you choose not to anyway, then you will not have access to systemd's APIs from unprivileged APIs. Well, that clears that up. Thanks for the detailed responses. Given my product's embedded nature, I'm trying to run a minimal systemd, as I've mentioned before. This has, of course, caused me to run into lots of issues of my own making. So thanks for bearing with me. I'd like to do without yet another daemon, dbus-daemon, on the system, so I'll work around the non-root systemctl access, which isn't too hard my specific situation. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] Makefile.am
2015-05-29 15:56 GMT+02:00 Lennart Poettering lenn...@poettering.net: I think it's ok to expect people to run make clean after touching the makefile to get the man pages fixed. Atm, man/custom-entities.ent is only cleaned up on make distclean. I think we should move that from DISTCLEANFILES to CLEANFILES. -- 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
Re: [systemd-devel] [systemd-commits] Makefile.am
On Fri, 29.05.15 09:45, Filipe Brandenburger (filbran...@google.com) wrote: Hi, I was thinking about this one recently... I really think the correct solution is for man/custom-entities.ent to be generated by configure from a man/custom-entities.ent.in template instead. I haven't really checked if that's viable though, if configure knows about every variable it will need, etc. but I was planning to look into it at some point in the near future. iirc one should not generate sources with autoconf .in stuff, but always with explicit sed invocations. There was was something avout this in the autoconf docs, don't really remember where. On Fri, May 29, 2015 at 9:39 AM, Michael Biebl mbi...@gmail.com wrote: 2015-05-29 15:56 GMT+02:00 Lennart Poettering lenn...@poettering.net: I think it's ok to expect people to run make clean after touching the makefile to get the man pages fixed. Atm, man/custom-entities.ent is only cleaned up on make distclean. I think we should move that from DISTCLEANFILES to CLEANFILES. Yes I think that's a good start and `make clean` will trigger a rebuild of most of what depends on custom-entities.ent anyways so I wouldn't expect a lot of spurious rebuilds due to that. Yeah, makes sense. Anyone cares to prep a patch for this? 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] cryptsetup: craft a unique ID with the source device
Am 29.05.2015 um 16:45 schrieb Dimitri John Ledkov:
On 29 May 2015 at 11:17, har...@redhat.com wrote:
From: Harald Hoyer har...@redhat.com
If cryptsetup is called with a source device as argv[3], then craft the
ID for the password agent with a unique device path.
I'm not sure why this is needed... if the device path is not good
enough, there is also luks UUID header. In Ubuntu we display the full
cryptsetup UUID in plymouth, but that's fairly cosmetic.
If the path is not good enough, maj/min are a bit pointless and you
really probably want the luks UUID then.
Regards,
Dimitri.
This is the ID=... in the ask-xxx.ini file... The Message field, which is
displayed to the user already contains a verbose description including the luks
uuid.
If possible /dev/block/maj:min is used, otherwise the original
argv[3] is used.
This enables password agents like petera [1] to provide a password
according to the source device. The original ID did not carry enough
information and was more targeted for a human readable string, which
is specified in the Message field anyway.
With this patch the ID of the ask.XXX ini file looks like this:
ID=cryptsetup:/dev/block/maj:min
[1] https://github.com/npmccallum/petera
---
src/cryptsetup/cryptsetup.c | 97
++---
1 file changed, 66 insertions(+), 31 deletions(-)
diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
index a5018f1..130c36e 100644
--- a/src/cryptsetup/cryptsetup.c
+++ b/src/cryptsetup/cryptsetup.c
@@ -238,6 +238,33 @@ static void log_glue(int level, const char *msg, void
*usrptr) {
log_debug(%s, msg);
}
+static char* disk_maj_min(const char *path) {
+struct stat st, st2;
+char *i = NULL;
+int r;
+
+assert(path);
+
+if (stat(path, st) 0)
+return NULL;
+
+if (!S_ISBLK(st.st_mode))
+return NULL;
+
+asprintf(i, /dev/block/%d:%d, major(st.st_rdev),
minor(st.st_rdev));
+
+if (!i)
+return strdup(path);
+
+r = stat(i, st2);
+if ((r 0) || (st.st_rdev != st2.st_rdev)) {
+free(i);
+return strdup(path);
+}
+
+return i;
+}
+
static char* disk_description(const char *path) {
static const char name_fields[] =
@@ -295,20 +322,54 @@ static char *disk_mount_point(const char *label) {
return NULL;
}
-static int get_password(const char *name, usec_t until, bool accept_cached,
char ***passwords) {
-int r;
+static int get_password(const char *vol, const char *src, usec_t until,
bool accept_cached, char ***passwords) {
+int r = 0;
char **p;
_cleanup_free_ char *text = NULL;
_cleanup_free_ char *escaped_name = NULL;
char *id;
+const char *name = NULL;
+_cleanup_free_ char *description = NULL, *name_buffer = NULL,
+*mount_point = NULL, *maj_min = NULL;
assert(name);
assert(passwords);
+description = disk_description(src);
+mount_point = disk_mount_point(vol);
+
+if (description streq(vol, description)) {
+/* If the description string is simply the
+ * volume name, then let's not show this
+ * twice */
+free(description);
+description = NULL;
+}
+
+if (mount_point description)
+r = asprintf(name_buffer, %s (%s) on %s, description,
vol, mount_point);
+else if (mount_point)
+r = asprintf(name_buffer, %s on %s, vol, mount_point);
+else if (description)
+r = asprintf(name_buffer, %s (%s), description, vol);
+
+if (r 0) {
+log_oom();
+return r;
+}
+name = name_buffer ? name_buffer : vol;
+
if (asprintf(text, Please enter passphrase for disk %s!, name)
0)
return log_oom();
-escaped_name = cescape(name);
+if (src)
+maj_min = disk_maj_min(src);
+
+if (maj_min)
+escaped_name = maj_min;
+else
+escaped_name = cescape(name);
+
if (!escaped_name)
return log_oom();
@@ -552,8 +613,7 @@ int main(int argc, char *argv[]) {
unsigned tries;
usec_t until;
crypt_status_info status;
-const char *key_file = NULL, *name = NULL;
-_cleanup_free_ char *description = NULL, *name_buffer =
NULL, *mount_point = NULL;
+const char *key_file;
/* Arguments: systemd-cryptsetup attach VOLUME
SOURCE-DEVICE [PASSWORD] [OPTIONS] */
@@ -581,31 +641,6 @@ int main(int argc, char *argv[]) {
/* A delicious drop of
Re: [systemd-devel] [PATCH] cryptsetup: craft a unique ID with the source device
On Fri, 29.05.15 17:11, Harald Hoyer (har...@redhat.com) wrote:
Am 29.05.2015 um 17:04 schrieb Lennart Poettering:
On Fri, 29.05.15 12:17, har...@redhat.com (har...@redhat.com) wrote:
+static char* disk_maj_min(const char *path) {
I'd really not abbreivate things here... call it major and
minor. there's no point in saving two ors...
+struct stat st, st2;
+char *i = NULL;
+int r;
+
+assert(path);
+
+if (stat(path, st) 0)
+return NULL;
+
+if (!S_ISBLK(st.st_mode))
+return NULL;
+
+asprintf(i, /dev/block/%d:%d, major(st.st_rdev),
minor(st.st_rdev));
+
+if (!i)
+return strdup(path);
I'd really prefer if we would propagate errors properly
here. I.e. change the function to:
static int disk_major_minor(const char *path, char **ret);
ret as the last or the first argument?
Usually we put that last.
(except for object constructors, where we put it first since object
methods always get their object specified as first arg...)
Then, return proper error codes, and the newly allocated name in *ret.
just copied the scheme of disk_description() and disk_mount_point()
:-)
Yeah, I guess that code is just old...
+
+r = stat(i, st2);
+if ((r 0) || (st.st_rdev != st2.st_rdev)) {
+free(i);
+return strdup(path);
+}
Why the second stat() check? I think we can be reasonably sure that
these device nodes will use the right major/minor...
Yes, what if it is missing? Someone removed it or played games :)
Sure, can remove the rdev check.
Well, I#d prefer to avoid additional stat()s unless we have a really
strong reason to have them in place.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [HEADSUP] nspawn/networkd: moving from iptables to nftables
Heya, just a small heads-up: Currently there are two firewall APIs used on Linux: iptables and nftables. iptables is the older one, nftables the new replacement. systemd-nspawn and systemd-networkd currently interface with iptables via the libiptc library: nspawn to implement the --port= switch for opening up container ports on the host, and networkd to implement IPMasquerade=. Generally nftables is the future and iptables is supposed to be phased out sooner or later. Your firewall should either use only iptables or only nftables, but not both. Supporting only iptables in systemd is hence a dead-end: we know already now, that it has no future and we need to rework this sooner or later. The hookup with iptables in nspawn+networkd is very recent only. After discussing this many times internally we now are sure we should better change from iptables to nftables quickly and do that fully and without transition: the rules networkd adds are in a certain way API, since your own iptables/nftables rules need to be ordered against them. And when we establish a new API then we better should make sure to make it a stable, future-proof one. THis will even become more important in the future, should we add further firewalling support to systemd components. Hence: if you currently use networkd's IPMasquerade= or nspawn's --port= support please be aware that the implementation of these switches will change soonishly: and generate nftables rather than iptables rules. Yes, we are aware this is unfortunate, and that many people are still using iptables. For this reason we would like to make the switch quickly to ensure not too many users start using the iptables hook-up before it goes away. Note that this change should not matter to you if you use the switches already, but do not have any other firewall configured. As the effect of the switches should stay the same you shouldn't notice much. Why not support both subsystems in parallel controllable via a runtime or compile-time switch? The reason for this is that the rules nspawn/networkd create *are* API, as mentioned and as such should be the same on all systems, and not be completely different depending on compile-time or runtime options... I hope this makes sense? 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 0/2] Using XML entities for paths in manpages
On Fri, 29.05.15 11:05, Daniel Mack (dan...@zonque.org) wrote: On 05/29/2015 05:18 AM, Michael Biebl wrote: 2015-05-28 19:47 GMT+02:00 Filipe Brandenburger filbran...@google.com: We're actually still missing a small part of it (A sentence like Files in /etc have the highest priority, files in /run take precedence over files with the same name in */usr/lib*. in files like hwdb.xml, the last /usr/lib won't get fixed) but it requires new variables. I'm leaning towards introducing a rootsysconfdir=/etc and rootlibdir=$(rootprefix)/lib (we already have a rootbindir) so I'll follow up with a patch doing that. Though having the first patchset in certainly helps. Indeed. I just ran my small shell script which I used to generate the original diff over current git head. The only occurences which it still replaces can be found at [1]. It's like you said, the override bits which are still missing. Otherwise it looks fine. Could you try the attached patch? I had to introduce a new entity in custom-entites.ent, because with --with-rootprefix=/, rootprefix;/lib resolves to //lib, and with the default behaviour of configure, rootprefix;lib becomes /usrlib. That is solved with a subsitiution in Makefile.am now, which cleans up all double slashes in custom-entites.ent. Patch looks fine to me. Didn't test it though, Michael, Filipe or Martin should probably try that... 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] fsck, /home, btrfs, multiple partitions/drives, boot failure [Ubuntu 15.04]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/28/2015 08:40 PM, Andrei Borzenkov wrote: Try booting with udev.log-priority=debug rd.udev.log-priority=debug, this may give some hint what happens. Wow did that produce a lot of output! No. You can set nofail in which case boot will proceed and you can mount it manually later. I added the nofail flag to /home and mounts below it, along with the udev flags above. Booting at least got me to a login screen instead of the emergency shell. I was then able to login at a virtual console, checked /home was not mounted, and mount -a quite happily mounted it and the system works. I have attached the output of journalctl -b which has all the udev output as well as everything else. That is fulljournal.txt.gz. Separately my laptop has two drives, and I have 3 luks+dmcrypt partitions. One of them is for swap, and two of them are in RAID0 for a single btrfs filesystem that contains / and /home subvolumes. The initrd does the keysetup and decryption, long before systemd is involved. My boot time with systemd has become several minutes, but eventually succeeds. Looking in the log (attached as laptop.txt.gz), it too has messages about waiting for disk devices and eventually timing out, but the system eventually boots compared to the desktop emergency shell. It seems there is something very confused going on between the initrd, udev and systemd, especially noticeable if you have btrfs across multiple partitions and the same partitions are already mounted for root by initrd. Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlVoqb0ACgkQmOOfHg372QRi4QCgp1GNeKJ4UIPqAVtI7vkGzpwE u7cAn1aAiBolnDd4xBIlQETTR+0nmUji =0DRw -END PGP SIGNATURE- fulljournal.txt.gz Description: application/gzip laptop.txt.gz Description: application/gzip ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 0/2] Using XML entities for paths in manpages
Hi Daniel, I haven't tested it, but I do have a few comments. First, why not use rootlibdir instead of rootprefixlibdir? There's already similar rootbindir and rootlibexecdir defined there, so I think we could stick to the same convention. From a few lines down in Makefile.am: # And these are the special ones for / rootprefix=@rootprefix@ rootbindir=$(rootprefix)/bin rootlibexecdir=$(rootprefix)/lib/systemd On Fri, May 29, 2015 at 2:05 AM, Daniel Mack dan...@zonque.org wrote: I had to introduce a new entity in custom-entites.ent, because with --with-rootprefix=/, rootprefix;/lib resolves to //lib, and with the default behaviour of configure, rootprefix;lib becomes /usrlib. Debian is already using --with-rootprefix= (an empty string) exactly for that reason. http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/rules#n16 If rootprefix=/, there would be also problems with rootbindir=//bin and other such definitions getting double slashes. Having said that, I do agree that it would be nice to handle --with-rootprefix=/ correctly without creating double slashes, but I think it would be preferrable to handle that in general and not for the specific case of /lib. Perhaps just remove any trailing slashes from rootprefix in configure.ac instead before generating the Makefile? That would also handle cases like --with-rootprefix=/usr/ to still generate /usr/bin and /usr/lib correctly. In any case, handling trailing slashes/double slashes could come on a separate patch. As pointed out, the problem with it already exists and Debian is working around it by setting rootprefix to an empty string, so it's not really strictly required for the rootlibdir patch itself. I'd be glad to test a new patchset that addresses these suggestions. Cheers, Filipe ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] configure.ac: strip off trailing slashed from $rootprefix
2015-05-30 2:24 GMT+02:00 Daniel Mack dan...@zonque.org:
Fine for me, just go ahead if you have an implementation in mind :)
I was lazy and just copied
ftp://ftp.tu-clausthal.de/pub/mirror/gnu/www/software/ac-archive/normpath.html
The resulting diff would look something like
diff --git a/configure.ac b/configure.ac
index 92654a6..815c8af 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1397,11 +1397,13 @@ AC_ARG_WITH([zshcompletiondir],
AC_ARG_WITH([rootprefix],
AS_HELP_STRING([--with-rootprefix=DIR], [rootfs directory
prefix for config files and kernel modules]),
[], [with_rootprefix=${ac_default_prefix}])
+adl_NORMALIZE_PATH([with_rootprefix])
AC_ARG_WITH([rootlibdir],
AS_HELP_STRING([--with-rootlibdir=DIR], [Root directory for
libraries necessary for boot]),
[],
[with_rootlibdir=${libdir}])
+adl_NORMALIZE_PATH([with_rootlibdir])
AC_ARG_WITH([pamlibdir],
AS_HELP_STRING([--with-pamlibdir=DIR], [Directory for PAM modules]),
diff --git a/m4/normpath.m4 b/m4/normpath.m4
new file mode 100644
index 000..5b29488
--- /dev/null
+++ b/m4/normpath.m4
@@ -0,0 +1,15 @@
+AC_DEFUN([adl_NORMALIZE_PATH],
+[case :[$]$1: in
+# change empty paths to '.'
+ ::) $1='.' ;;
+# strip trailing slashes
+ :*[[\\/]]:) $1=`echo [$]$1 | sed 's,[[\\/]]*[$],,'` ;;
+ :*:) ;;
+esac
+# squeze repeated slashes
+case ifelse($2,,[$]$1,$2) in
+# if the path contains any backslashes, turn slashes into backslashes
+ *\\*) $1=`echo [$]$1 | sed 's,\(.\)[[\\/]][[\\/]]*,\1,g'` ;;
+# if the path contains slashes, also turn backslashes into slashes
+ *) $1=`echo [$]$1 | sed 's,\(.\)[[\\/]][[\\/]]*,\1/,g'` ;;
+esac])
This would need to be extended all remaining dirs.
--
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
Re: [systemd-devel] [PATCH 1/2] configure.ac: strip off trailing slashed from $rootprefix
On Fri, May 29, 2015 at 5:21 PM, Michael Biebl mbi...@gmail.com wrote: autoconf already strips trailing slashes for all default directory variables [1]. How does it handle --prefix=/ though? Does it turn it into an empty string? I think we should do the same for *all* our custom --with-$foo-dir variables, not just rootlibdir. Agreed. I think we can go ahead with patch #2 (man: replace hard-coded /usr/lib) since it works for both the --with-rootprefix=/usr (default) case and the --with-rootprefix= (empty) case used by Debian. Cheers, Filipe ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] configure.ac: strip off trailing slashed from $rootprefix
2015-05-30 2:53 GMT+02:00 Michael Biebl mbi...@gmail.com:
2015-05-30 2:50 GMT+02:00 Michael Biebl mbi...@gmail.com:
2015-05-30 2:24 GMT+02:00 Daniel Mack dan...@zonque.org:
Fine for me, just go ahead if you have an implementation in mind :)
I was lazy and just copied
ftp://ftp.tu-clausthal.de/pub/mirror/gnu/www/software/ac-archive/normpath.html
Oh, I just noticed there is a sort-of official macro for that, already
provided in Debian as
/usr/share/aclocal/ax_normalize_path.m4
It's shipped as part of autoconf-archive.
I we assume, autconf-archive is installed, the resulting patch would
look like the attached diff.
For convenience sake, we could also ship a copy of
/usr/share/aclocal/ax_normalize_path.m4 in our m4/ directory.
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
diff --git a/configure.ac b/configure.ac
index 92654a6..78d52e4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1370,16 +1370,19 @@ AC_ARG_WITH([dbuspolicydir],
AS_HELP_STRING([--with-dbuspolicydir=DIR], [D-Bus policy directory]),
[],
[with_dbuspolicydir=${sysconfdir}/dbus-1/system.d])
+AX_NORMALIZE_PATH([with_dbuspolicydir])
AC_ARG_WITH([dbussessionservicedir],
AS_HELP_STRING([--with-dbussessionservicedir=DIR], [D-Bus session
service directory]),
[],
[with_dbussessionservicedir=${datadir}/dbus-1/services])
+AX_NORMALIZE_PATH([with_dbussessionservicedir])
AC_ARG_WITH([dbussystemservicedir],
AS_HELP_STRING([--with-dbussystemservicedir=DIR], [D-Bus system
service directory]),
[],
[with_dbussystemservicedir=${datadir}/dbus-1/system-services])
+AX_NORMALIZE_PATH([with_dbussystemservicedir])
AC_ARG_WITH([bashcompletiondir],
AS_HELP_STRING([--with-bashcompletiondir=DIR], [Bash completions
directory]),
@@ -1389,29 +1392,35 @@ AC_ARG_WITH([bashcompletiondir],
] , [
with_bashcompletiondir=${datadir}/bash-completion/completions
])])
+AX_NORMALIZE_PATH([with_bashcompletiondir])
AC_ARG_WITH([zshcompletiondir],
AS_HELP_STRING([--with-zshcompletiondir=DIR], [Zsh completions
directory]),
[], [with_zshcompletiondir=${datadir}/zsh/site-functions])
+AX_NORMALIZE_PATH([with_zshcompletiondir])
AC_ARG_WITH([rootprefix],
AS_HELP_STRING([--with-rootprefix=DIR], [rootfs directory prefix for
config files and kernel modules]),
[], [with_rootprefix=${ac_default_prefix}])
+AX_NORMALIZE_PATH([with_rootprefix])
AC_ARG_WITH([rootlibdir],
AS_HELP_STRING([--with-rootlibdir=DIR], [Root directory for libraries
necessary for boot]),
[],
[with_rootlibdir=${libdir}])
+AX_NORMALIZE_PATH([with_rootlibdir])
AC_ARG_WITH([pamlibdir],
AS_HELP_STRING([--with-pamlibdir=DIR], [Directory for PAM modules]),
[],
[with_pamlibdir=${with_rootlibdir}/security])
+AX_NORMALIZE_PATH([with_pamlibdir])
AC_ARG_WITH([pamconfdir],
AS_HELP_STRING([--with-pamconfdir=DIR], [Directory for PAM
configuration]),
[],
[with_pamconfdir=${sysconfdir}/pam.d])
+AX_NORMALIZE_PATH([with_pamconfdir])
AC_ARG_ENABLE([split-usr],
AS_HELP_STRING([--enable-split-usr], [Assume that /bin, /sbin aren\'t
symlinks into /usr]),
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 0/2] Using XML entities for paths in manpages
On 05/29/2015 07:37 PM, Filipe Brandenburger wrote: I haven't tested it, but I do have a few comments. First, why not use rootlibdir instead of rootprefixlibdir? Because $(rootlibdir) resolves to /usr/lib64 on my system. [...] On Fri, May 29, 2015 at 2:05 AM, Daniel Mack dan...@zonque.org wrote: I had to introduce a new entity in custom-entites.ent, because with --with-rootprefix=/, rootprefix;/lib resolves to //lib, and with the default behaviour of configure, rootprefix;lib becomes /usrlib. Debian is already using --with-rootprefix= (an empty string) exactly for that reason. http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/rules#n16 Interesting, thanks for the pointer. If rootprefix=/, there would be also problems with rootbindir=//bin and other such definitions getting double slashes. Having said that, I do agree that it would be nice to handle --with-rootprefix=/ correctly without creating double slashes, but I think it would be preferrable to handle that in general and not for the specific case of /lib. Yes, the subst logic I added replaces _all_ leading double slashes, and hence avoids touching URLs with http://;. Perhaps just remove any trailing slashes from rootprefix in configure.ac instead before generating the Makefile? That would also handle cases like --with-rootprefix=/usr/ to still generate /usr/bin and /usr/lib correctly. Yes, that's actually better, you're right. I'll post a patch for this. Thanks, Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] configure.ac: strip off trailing slashed from $rootprefix
2015-05-30 2:05 GMT+02:00 Daniel Mack dan...@zonque.org:
Make sure the variable set via --with-rootprefix= does not contain a
trailing slash, so man pages can use entities like rootprefix;/lib
without ending up having double slashes.
---
configure.ac | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 92654a6..55b73de 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1396,7 +1396,8 @@ AC_ARG_WITH([zshcompletiondir],
AC_ARG_WITH([rootprefix],
AS_HELP_STRING([--with-rootprefix=DIR], [rootfs directory prefix for
config files and kernel modules]),
-[], [with_rootprefix=${ac_default_prefix}])
+[with_rootprefix=`echo ${withval} | sed -e s,/*$,,`],
+[with_rootprefix=${ac_default_prefix}])
AC_ARG_WITH([rootlibdir],
AS_HELP_STRING([--with-rootlibdir=DIR], [Root directory for
libraries necessary for boot]),
autoconf already strips trailing slashes for all default directory
variables [1].
I think we should do the same for *all* our custom --with-$foo-dir
variables, not just rootlibdir.
Maybe provide a custom macro for that and apply that to
--with-html-dir=PATHpath to installed docs
--with-efi-libdir=PATH Path to EFI lib directory
--with-efi-ldsdir=PATH Path to EFI lds directory
--with-efi-includedir=PATH
--with-dbuspolicydir=DIR
--with-dbussessionservicedir=DIR
--with-dbussystemservicedir=DIR
--with-bashcompletiondir=DIR
--with-zshcompletiondir=DIR
--with-rootprefix=DIR rootfs directory prefix for config files and kernel
--with-rootlibdir=DIR Root directory for libraries necessary for boot
--with-pamlibdir=DIRDirectory for PAM modules
--with-pamconfdir=DIR Directory for PAM configuration
WDYT?
[1] http://comments.gmane.org/gmane.comp.sysutils.autoconf.bugs/5747
--
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
Re: [systemd-devel] [PATCH 1/2] configure.ac: strip off trailing slashed from $rootprefix
2015-05-30 2:50 GMT+02:00 Michael Biebl mbi...@gmail.com: 2015-05-30 2:24 GMT+02:00 Daniel Mack dan...@zonque.org: Fine for me, just go ahead if you have an implementation in mind :) I was lazy and just copied ftp://ftp.tu-clausthal.de/pub/mirror/gnu/www/software/ac-archive/normpath.html Oh, I just noticed there is a sort-of official macro for that, already provided in Debian as /usr/share/aclocal/ax_normalize_path.m4 It's shipped as part of autoconf-archive. -- 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
Re: [systemd-devel] [PATCH 2/2] man: replace hard-coded /usr/lib
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1432944333-3566-2-git-send-email-daniel%40zonque.org -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] man: replace hard-coded /usr/lib
Replace some /usr/lib occurences in man/ with rootprefix;/lib. --- man/hwdb.xml| 4 ++-- man/systemd.link.xml| 4 ++-- man/systemd.netdev.xml | 4 ++-- man/systemd.network.xml | 4 ++-- man/udev.xml| 4 ++-- 5 files changed, 10 insertions(+), 10 deletions(-) diff --git a/man/hwdb.xml b/man/hwdb.xml index b3602ac..e6215df 100644 --- a/man/hwdb.xml +++ b/man/hwdb.xml @@ -50,10 +50,10 @@ regardless of the directories in which they live. However, files with identical filenames replace each other. Files in filename/etc/filename have the highest priority, files in filename/run/filename take precedence - over files with the same name in filename/usr/lib/filename. This can be + over files with the same name in filenamerootprefix;/lib/filename. This can be used to override a system-supplied hwdb file with a local file if needed; a symlink in filename/etc/filename with the same name as a hwdb file in - filename/usr/lib/filename, pointing to filename/dev/null/filename, + filenamerootprefix;/lib/filename, pointing to filename/dev/null/filename, disables the hwdb file entirely. hwdb files must have the extension filename.hwdb/filename; other extensions are ignored./para diff --git a/man/systemd.link.xml b/man/systemd.link.xml index 75cf6e1..5db0684 100644 --- a/man/systemd.link.xml +++ b/man/systemd.link.xml @@ -70,10 +70,10 @@ However, files with identical filenames replace each other. Files in filename/etc/filename have the highest priority, files in filename/run/filename take precedence over files with the same -name in filename/usr/lib/filename. This can be used to +name in filenamerootprefix;/lib/filename. This can be used to override a system-supplied link file with a local file if needed; a symlink in filename/etc/filename with the same name as a -link file in filename/usr/lib/filename, pointing to +link file in filenamerootprefix;/lib/filename, pointing to filename/dev/null/filename, disables the link file entirely./para diff --git a/man/systemd.netdev.xml b/man/systemd.netdev.xml index 6cd77ab..786c7d4 100644 --- a/man/systemd.netdev.xml +++ b/man/systemd.netdev.xml @@ -81,10 +81,10 @@ identical filenames replace each other. Files in filename/etc/filename have the highest priority, files in filename/run/filename take precedence over files with the same -name in filename/usr/lib/filename. This can be used to +name in filenamerootprefix;/lib/filename. This can be used to override a system-supplied configuration file with a local file if needed; a symlink in filename/etc/filename with the same name -as a configuration file in filename/usr/lib/filename, pointing +as a configuration file in filenamerootprefix;/lib/filename, pointing to filename/dev/null/filename, disables the configuration file entirely./para diff --git a/man/systemd.network.xml b/man/systemd.network.xml index 0b9781f..bd061c2 100644 --- a/man/systemd.network.xml +++ b/man/systemd.network.xml @@ -77,10 +77,10 @@ identical filenames replace each other. Files in filename/etc/filename have the highest priority, files in filename/run/filename take precedence over files with the same -name in filename/usr/lib/filename. This can be used to +name in filenamerootprefix;/lib/filename. This can be used to override a system-supplied configuration file with a local file if needed; a symlink in filename/etc/filename with the same name -as a configuration file in filename/usr/lib/filename, pointing +as a configuration file in filenamerootprefix;/lib/filename, pointing to filename/dev/null/filename, disables the configuration file entirely./para diff --git a/man/udev.xml b/man/udev.xml index f7ebaad..d5d8a17 100644 --- a/man/udev.xml +++ b/man/udev.xml @@ -65,10 +65,10 @@ regardless of the directories in which they live. However, files with identical filenames replace each other. Files in filename/etc/filename have the highest priority, files in filename/run/filename take precedence - over files with the same name in filename/usr/lib/filename. This can be + over files with the same name in filenamerootprefix;/lib/filename. This can be used to override a system-supplied rules file with a local file if needed; a symlink in filename/etc/filename with the same name as a rules file in - filename/usr/lib/filename, pointing to filename/dev/null/filename, + filenamerootprefix;/lib/filename, pointing to filename/dev/null/filename, disables the rules file entirely. Rule files must have the extension filename.rules/filename; other extensions are ignored./para -- 2.4.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org
[systemd-devel] [PATCH 1/2] configure.ac: strip off trailing slashed from $rootprefix
Make sure the variable set via --with-rootprefix= does not contain a
trailing slash, so man pages can use entities like rootprefix;/lib
without ending up having double slashes.
---
configure.ac | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 92654a6..55b73de 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1396,7 +1396,8 @@ AC_ARG_WITH([zshcompletiondir],
AC_ARG_WITH([rootprefix],
AS_HELP_STRING([--with-rootprefix=DIR], [rootfs directory prefix for
config files and kernel modules]),
-[], [with_rootprefix=${ac_default_prefix}])
+[with_rootprefix=`echo ${withval} | sed -e s,/*$,,`],
+[with_rootprefix=${ac_default_prefix}])
AC_ARG_WITH([rootlibdir],
AS_HELP_STRING([--with-rootlibdir=DIR], [Root directory for libraries
necessary for boot]),
--
2.4.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] configure.ac: strip off trailing slashed from $rootprefix
2015-05-30 2:30 GMT+02:00 Filipe Brandenburger filbran...@google.com: On Fri, May 29, 2015 at 5:21 PM, Michael Biebl mbi...@gmail.com wrote: autoconf already strips trailing slashes for all default directory variables [1]. How does it handle --prefix=/ though? Does it turn it into an empty string? Hm, no, apparently it doesn't. It only strips the trailing '/' when you use something like --prefix=/usr/ -- 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
Re: [systemd-devel] [systemd-commits] Makefile.am
On 05/29/2015 06:53 PM, Lennart Poettering wrote: On Fri, 29.05.15 09:45, Filipe Brandenburger (filbran...@google.com) wrote: Atm, man/custom-entities.ent is only cleaned up on make distclean. I think we should move that from DISTCLEANFILES to CLEANFILES. Yes I think that's a good start and `make clean` will trigger a rebuild of most of what depends on custom-entities.ent anyways so I wouldn't expect a lot of spurious rebuilds due to that. Yeah, makes sense. Anyone cares to prep a patch for this? Pushed now. I reverted the Makefile.am dependency again and move custom-entities.ent from DISTCLEANFILES to CLEANFILES. Thanks, Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] configure.ac: strip off trailing slashed from $rootprefix
On 05/30/2015 02:21 AM, Michael Biebl wrote:
2015-05-30 2:05 GMT+02:00 Daniel Mack dan...@zonque.org:
Make sure the variable set via --with-rootprefix= does not contain a
trailing slash, so man pages can use entities like rootprefix;/lib
without ending up having double slashes.
---
configure.ac | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 92654a6..55b73de 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1396,7 +1396,8 @@ AC_ARG_WITH([zshcompletiondir],
AC_ARG_WITH([rootprefix],
AS_HELP_STRING([--with-rootprefix=DIR], [rootfs directory prefix
for config files and kernel modules]),
-[], [with_rootprefix=${ac_default_prefix}])
+[with_rootprefix=`echo ${withval} | sed -e s,/*$,,`],
+[with_rootprefix=${ac_default_prefix}])
AC_ARG_WITH([rootlibdir],
AS_HELP_STRING([--with-rootlibdir=DIR], [Root directory for
libraries necessary for boot]),
autoconf already strips trailing slashes for all default directory
variables [1].
I think we should do the same for *all* our custom --with-$foo-dir
variables, not just rootlibdir.
Maybe provide a custom macro for that and apply that to
--with-html-dir=PATHpath to installed docs
--with-efi-libdir=PATH Path to EFI lib directory
--with-efi-ldsdir=PATH Path to EFI lds directory
--with-efi-includedir=PATH
--with-dbuspolicydir=DIR
--with-dbussessionservicedir=DIR
--with-dbussystemservicedir=DIR
--with-bashcompletiondir=DIR
--with-zshcompletiondir=DIR
--with-rootprefix=DIR rootfs directory prefix for config files and kernel
--with-rootlibdir=DIR Root directory for libraries necessary for boot
--with-pamlibdir=DIRDirectory for PAM modules
--with-pamconfdir=DIR Directory for PAM configuration
WDYT?
Fine for me, just go ahead if you have an implementation in mind :)
Thanks,
Daniel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2 5/5] core/cgroup: Add cgroup.populated inotify watches, when available.
---
src/core/cgroup.c| 81 ++--
src/core/manager.c | 7 -
src/core/manager.h | 3 ++
src/core/service.c | 2 +-
src/shared/cgroup-util.c | 28 +
src/shared/cgroup-util.h | 6 ++--
src/test/test-cgroup.c | 12 +++
7 files changed, 120 insertions(+), 19 deletions(-)
diff --git a/src/core/cgroup.c b/src/core/cgroup.c
index 6474e08..a1d7d93 100644
--- a/src/core/cgroup.c
+++ b/src/core/cgroup.c
@@ -30,6 +30,8 @@
#define CGROUP_CPU_QUOTA_PERIOD_USEC ((usec_t) 100 * USEC_PER_MSEC)
+static int cgroup_populated_dispatch_io(sd_event_source *source, int fd,
uint32_t revents, void *userdata);
+
void cgroup_context_init(CGroupContext *c) {
assert(c);
@@ -629,6 +631,7 @@ static const char *migrate_callback(CGroupControllerMask
mask, void *userdata) {
static int unit_create_cgroups(Unit *u, CGroupControllerMask mask) {
CGroupContext *c;
int r;
+int wd = -1;
assert(u);
@@ -655,10 +658,13 @@ static int unit_create_cgroups(Unit *u,
CGroupControllerMask mask) {
}
/* First, create our own group */
-r = cg_create_everywhere(u-manager-cgroup_supported, mask,
u-cgroup_path);
+r = cg_create_everywhere(u-manager-cgroup_supported, mask,
u-cgroup_path, u-manager-cgroup_populated_inotify_fd, wd);
if (r 0)
return log_error_errno(r, Failed to create cgroup %s: %m,
u-cgroup_path);
+if (wd 0 hashmap_put(u-manager-cgroup_populated_by_wd,
INT_TO_PTR(wd), u-cgroup_path) 0)
+inotify_rm_watch(u-manager-cgroup_populated_inotify_fd, wd);
+
/* Keep track that this is now realized */
u-cgroup_realized = true;
u-cgroup_realized_mask = mask;
@@ -893,6 +899,7 @@ pid_t unit_search_main_pid(Unit *u) {
int manager_setup_cgroup(Manager *m) {
_cleanup_free_ char *path = NULL;
+_cleanup_free_ char *sane_behavior = NULL;
int r;
assert(m);
@@ -944,7 +951,7 @@ int manager_setup_cgroup(Manager *m) {
}
/* 4. Make sure we are in the root cgroup */
-r = cg_create_and_attach(SYSTEMD_CGROUP_CONTROLLER,
m-cgroup_root, 0);
+r = cg_create_and_attach(SYSTEMD_CGROUP_CONTROLLER,
m-cgroup_root, 0, -1, NULL);
if (r 0)
return log_error_errno(r, Failed to create root
cgroup hierarchy: %m);
@@ -957,6 +964,23 @@ int manager_setup_cgroup(Manager *m) {
/* 6. Always enable hierarchical support if it exists... */
cg_set_attribute(memory, /, memory.use_hierarchy, 1);
+
+/* 7. Create inotify fd for cgroup.populated files, if
+ * supported on unified cgroups. Insane ones have
+ * cgroup.sane_behavior set to 0.*/
+r = cg_get_attribute(SYSTEMD_CGROUP_CONTROLLER,
m-cgroup_root, cgroup.sane_behavior, sane_behavior);
+if (r == -ENOENT) {
+m-cgroup_populated_inotify_fd =
inotify_init1(IN_NONBLOCK|IN_CLOEXEC);
+if (m-cgroup_populated_inotify_fd 0)
+return log_error_errno(errno, inotify_init1()
failed: %m);
+
+r = sd_event_add_io(m-event,
m-cgroup_populated_event_source, m-cgroup_populated_inotify_fd, EPOLLIN,
cgroup_populated_dispatch_io, m);
+if (r 0)
+return log_error_errno(errno, Failed to
create inotify event source: %m);
+/* TODO what priority to set? */
+(void)
sd_event_source_set_description(m-cgroup_populated_event_source,
cgroup-populated);
+}
+
}
/* 7. Figure out which controllers are supported */
@@ -975,10 +999,63 @@ void manager_shutdown_cgroup(Manager *m, bool delete) {
m-pin_cgroupfs_fd = safe_close(m-pin_cgroupfs_fd);
+m-cgroup_populated_inotify_fd =
safe_close(m-cgroup_populated_inotify_fd);
+hashmap_free(m-cgroup_populated_by_wd);
+
free(m-cgroup_root);
m-cgroup_root = NULL;
}
+static int cgroup_populated_dispatch_io(sd_event_source *source, int fd,
uint32_t revents, void *userdata) {
+char *path;
+_cleanup_free_ char *v = NULL;
+Manager *m = userdata;
+int r;
+int populated = -1;
+
+assert(m);
+assert(revents (EPOLLPRI | EPOLLIN));
+
+if (fd != m-cgroup_populated_inotify_fd)
+return 0;
+
+for (;;) {
+union inotify_event_buffer buffer;
+struct inotify_event *e;
+ssize_t l;
+
+l = read(fd, buffer, sizeof(buffer));
+if (l 0) {
+if (errno == EAGAIN || errno == EINTR)
+break;
+
+
[systemd-devel] [PATCH v2 4/5] unified-cgroup: fix cg_pid_get_path() and cg_get_path().
---
src/shared/cgroup-util.c| 8
src/test/test-cgroup-util.c | 18 ++
2 files changed, 26 insertions(+)
diff --git a/src/shared/cgroup-util.c b/src/shared/cgroup-util.c
index 2bca32a..eae9f5d 100644
--- a/src/shared/cgroup-util.c
+++ b/src/shared/cgroup-util.c
@@ -749,6 +749,11 @@ int cg_pid_get_path(const char *controller, pid_t pid,
char **path) {
} else
controller = SYSTEMD_CGROUP_CONTROLLER;
+#ifdef HAVE_UNIFIED_CGROUP
+if (!strcmp(systemd, controller))
+controller = ;
+#endif
+
fs = procfs_file_alloca(pid, cgroup);
f = fopen(fs, re);
@@ -774,6 +779,9 @@ int cg_pid_get_path(const char *controller, pid_t pid, char
**path) {
if (!e)
continue;
+if (cs == 0 e == l)
+found = true;
+
*e = 0;
FOREACH_WORD_SEPARATOR(word, k, l, ,, state) {
diff --git a/src/test/test-cgroup-util.c b/src/test/test-cgroup-util.c
index 015d3d7..59e2c7f 100644
--- a/src/test/test-cgroup-util.c
+++ b/src/test/test-cgroup-util.c
@@ -219,6 +219,22 @@ static void test_proc(void) {
}
}
+static void test_cg_pid_get_path(void) {
+_cleanup_free_ char *path = NULL;
+
+assert_se(cg_pid_get_path(SYSTEMD_CGROUP_CONTROLLER, 0, path) == 0);
+
+assert_se(cg_pid_get_path(, 0, path) == 0);
+
+assert_se(cg_pid_get_path(NULL, 0, path) == 0);
+}
+
+static void test_cg_get_path(void) {
+_cleanup_free_ char *path = NULL;
+
+assert_se(cg_get_path(SYSTEMD_CGROUP_CONTROLLER, , , path) == 0);
+}
+
static void test_escape_one(const char *s, const char *r) {
_cleanup_free_ char *b;
@@ -306,6 +322,8 @@ int main(void) {
test_path_get_user_slice();
TEST_REQ_RUNNING_SYSTEMD(test_get_paths());
test_proc();
+test_cg_pid_get_path();
+test_cg_get_path();
TEST_REQ_RUNNING_SYSTEMD(test_escape());
test_controller_is_valid();
test_slice_to_path();
--
2.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2 1/5] cgroup-util: fix is_valid check to pass for unified cgroup hierchy.
It appears in /proc/self/cgroup as `0::/'
---
src/shared/cgroup-util.c| 4
src/test/test-cgroup-util.c | 3 ++-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/shared/cgroup-util.c b/src/shared/cgroup-util.c
index 9988e5c..2bca32a 100644
--- a/src/shared/cgroup-util.c
+++ b/src/shared/cgroup-util.c
@@ -1616,6 +1616,10 @@ bool cg_controller_is_valid(const char *p, bool
allow_named) {
if (!p)
return false;
+/* Unified cgroup */
+if (*p == 0)
+return true;
+
if (allow_named) {
s = startswith(p, name=);
if (s)
diff --git a/src/test/test-cgroup-util.c b/src/test/test-cgroup-util.c
index 4a89f64..015d3d7 100644
--- a/src/test/test-cgroup-util.c
+++ b/src/test/test-cgroup-util.c
@@ -247,7 +247,8 @@ static void test_controller_is_valid(void) {
assert_se(cg_controller_is_valid(foobar, false));
assert_se(cg_controller_is_valid(foo_bar, false));
assert_se(cg_controller_is_valid(name=foo, true));
-assert_se(!cg_controller_is_valid(, false));
+assert_se(cg_controller_is_valid(, true));
+assert_se(cg_controller_is_valid(, false));
assert_se(!cg_controller_is_valid(name=, true));
assert_se(!cg_controller_is_valid(=, false));
assert_se(!cg_controller_is_valid(cpu,cpuacct, false));
--
2.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
