[systemd-devel] I am adding RegisterMachine to docker.
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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemctl as non-root
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
Re: [systemd-devel] Alienware graphics amplifier scancodes
On Thu, May 28, 2015 at 01:53:57PM -0500, Mario Limonciello 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. True. 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.. And how does other operating systems handle this? Hint, I don't imagine they reboot the box... greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] disabling ctrl+alt+del
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello. What is the most correct way to disable ctrl+alt+delete keys? I mean disable, not redefine. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVZ4cVAAoJEHb1CzgxXKwY2n0QAKQ+xDNG+t0NgOCiBhSEWF1s UmgeDXqa38/9m3qHMYfQXvssrp9ytsInuHq0reex8HZ8l6swx0BNQqvq1vx2UW9U BEQZ8YOUFshWaM3QQk7l27WwSnDuE9BUqVJrabXH1hEIzwSrkq3Czag9xRlZHSbo bynb9PI9Ru6qYn4EOFjod78UU5myo43SdCVoH4T5t0apNutEl4OXjlzds8x8yjtn t4QhatVaZp7BqJgcGuBvkRQtAmggTWVp5PwOlDLsn8RXcqtB/1Ttz84t51YDnOto 0a9Js9R3UBEB/SQTsHdNt6JMqbgaqAF0aOu8dQSQRaHbsgYWLAfR83cFM0esXcwV kX6NMDj8AZSn+oprsMSIQ9dNV2hp/8U/1jb1axFyczS1h6kgKcGqG4Jxd1YXrJs2 60s045gCRW0hW3ZNcSQB/J4KzO5Xdc9ZgCl5xkL4EEND8iJkfMln8w4PnAp1L17Y nm9CO21kkT4q6hRvA9XFjbXgTEtP7vGefnWm7znTxmnD3NdECL/N2eXFEfjn4H7R wYlVxNx+1s8a6ZTwFdfjEiHWVpW3BU47YTzzOHcUyUA+hIosySSm3V6kU1pUJrIo +7+Fs4xwjAeAjsyzo9sbJX2AF9ZkZY9vmhOCVqIAuy/IEPDhcj9dcOUzZupKNOEW 5ycGteEcQy/VeKO2faCV =ZSeP -END PGP SIGNATURE- ___ 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, 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. Though having the first patchset in certainly helps. Cheers! Filipe ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] systemctl: Don't skip SysV init.d scripts when enabling/disabling units
On Thu, 28.05.15 15:10, Martin Pitt (martin.p...@ubuntu.com) wrote:
Hello again,
Lennart Poettering [2015-05-28 13:31 +0200]:
Hmm? THis sounds the wrong way round. What currently happens should be
this: if both are available systemd ignores the sysv script, and only
considers the native unit. Is that what you are trying to say?
Err yes, sorry. Adjusted the patch description.
And you now want everything to be applied to both the sysv script and
the native unit?
Right, so that you keep the sysv init script and unit in sync, instead
of enabling one and disabling the other.
What happens if we query the state of things with is-enabled, then?
Good point, thanks for spotting; fixed. We didn't have that problem in
our original patch as is-enabled didn't work; curiously, with the new
systemd-sysv-install wrapper we can now implement is-enabled trivially
:-) ).
Looks good. Please push.
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From 528c97ef47c59ea65c897eacd04b39a12d2113ae Mon Sep 17 00:00:00 2001
From: Martin Pitt martin.p...@ubuntu.com
Date: Wed, 27 May 2015 14:52:17 +0200
Subject: [PATCH 2/2] systemctl: Don't skip SysV init.d scripts when
enabling/disabling units
If there is both a SysV init.d script and a systemd unit for a given name, we
want to do the same enable/disable operation for both, instead of just on the
systemd unit. This keeps the enablement status in sync so that switching init
systems behaves as expected.
---
src/systemctl/systemctl.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index f0ba83d..897248a 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -5149,7 +5149,10 @@ static int enable_sysv_units(const char *verb, char
**args) {
break;
}
-if (found_native)
+/* If we have both a native unit and a SysV script,
+ * enable/disable them both (below); for is-enabled, prefer
the
+ * native unit */
+if (found_native streq(verb, is-enabled))
continue;
p = path_join(arg_root, SYSTEM_SYSVINIT_PATH, name);
@@ -5161,7 +5164,10 @@ static int enable_sysv_units(const char *verb, char
**args) {
if (!found_sysv)
continue;
-log_info(%s is not a native service, redirecting to
systemd-sysv-install, name);
+if (found_native)
+log_info(Synchronizing state of %s with SysV init
with %s..., name, argv[0]);
+else
+log_info(%s is not a native service, redirecting to
systemd-sysv-install, name);
if (!isempty(arg_root))
argv[c++] = q = strappend(--root=, arg_root);
@@ -5209,6 +5215,9 @@ static int enable_sysv_units(const char *verb, char
**args) {
} else
return -EPROTO;
+if (found_native)
+continue;
+
/* Remove this entry, so that we don't try enabling it as
native unit */
assert(f 0);
f--;
--
2.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 Wed, 27.05.15 02:38, Filipe Brandenburger (filbran...@google.com) wrote:
As suggested by Martin Pitt, for better support of distros with non-merged
/usr.
This doesn't get us 100% there but I'd say it gets us much closer.
I think we still need a new variable for /etc/udev (similar to pkgsysconfdir;
which is /etc/systemd) though that is not really critical for non-merged /usr.
There are also some general explanations (in files man/hwdb.xml, man/udev.xml
and man/systemd.{link,netdev,network}.xml) which talk of how files in /etc
override those in /usr/lib but we don't really have a great variable for
/usr/lib or /lib vs. /etc, so I'd like to think a little further on how to
solve that particular one...
I hope that's helpful!
Applied both!
Thanks!
Cheers,
Filipe
Filipe Brandenburger (2):
man: generate configured paths in manpages
man: use configured path for mount and umount binaries in manpages
Makefile.am | 2 ++
man/binfmt.d.xml | 5 -
man/bootchart.conf.xml | 17 +---
man/bootctl.xml | 5 -
man/bootup.xml | 5 -
man/busctl.xml | 5 -
man/coredump.conf.xml| 11 ++
man/coredumpctl.xml | 5 -
man/crypttab.xml | 5 -
man/daemon.xml | 5 -
man/file-hierarchy.xml | 5 -
man/halt.xml | 5 -
man/hostname.xml | 5 -
man/hostnamectl.xml | 5 -
man/hwdb.xml | 9 ++---
man/journal-remote.conf.xml | 11 ++
man/journalctl.xml | 5 -
man/journald.conf.xml| 11 ++
man/kernel-command-line.xml | 5 -
man/kernel-install.xml | 5 -
man/less-variables.xml | 5 -
man/libsystemd-pkgconfig.xml | 5 -
man/locale.conf.xml | 5 -
man/localectl.xml| 5 -
man/localtime.xml| 5 -
man/loginctl.xml | 5 -
man/logind.conf.xml | 11 ++
man/machine-id.xml | 5 -
man/machine-info.xml | 5 -
man/machinectl.xml | 9 ++---
man/modules-load.d.xml | 5 -
man/networkctl.xml | 5 -
man/nss-myhostname.xml | 5 -
man/nss-mymachines.xml | 5 -
man/os-release.xml | 5 -
man/pam_systemd.xml | 5 -
man/resolved.conf.xml| 11 ++
man/runlevel.xml | 5 -
man/sd-daemon.xml| 5 -
man/sd-id128.xml | 5 -
man/sd-journal.xml | 5 -
man/sd-login.xml | 5 -
man/sd_booted.xml| 5 -
man/sd_bus_creds_get_pid.xml | 5 -
man/sd_bus_creds_new_from_pid.xml| 5 -
man/sd_bus_default.xml | 5 -
man/sd_bus_error.xml | 5 -
man/sd_bus_message_append.xml| 5 -
man/sd_bus_message_append_array.xml | 5 -
man/sd_bus_message_append_basic.xml | 5 -
man/sd_bus_message_append_string_memfd.xml | 5 -
man/sd_bus_message_append_strv.xml | 5 -
man/sd_bus_message_get_cookie.xml| 5 -
man/sd_bus_message_get_monotonic_usec.xml| 5 -
man/sd_bus_negotiate_fds.xml | 5 -
man/sd_bus_new.xml | 5 -
man/sd_bus_path_encode.xml | 5 -
man/sd_bus_request_name.xml | 5 -
man/sd_event_add_child.xml | 5 -
man/sd_event_add_defer.xml | 5 -
man/sd_event_add_signal.xml | 5 -
man/sd_event_add_time.xml| 5 -
man/sd_event_get_fd.xml | 5 -
man/sd_event_new.xml | 5 -
man/sd_event_run.xml | 5 -
man/sd_event_set_name.xml| 5 -
man/sd_event_wait.xml| 5 -
man/sd_get_seats.xml | 5 -
man/sd_id128_get_machine.xml | 5 -
Re: [systemd-devel] fsck, /home, btrfs, multiple partitions/drives, boot failure [Ubuntu 15.04]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/28/2015 02:37 AM, Andrei Borzenkov wrote: I was wrong here, device is opened by btrfs driver so there should be no collision here. Still obviously scanning fails (and it fails actively, setting ID_BTRFS_READY). This needs some debugging on udev side. I just tried booting with fsck.mode=skip and that didn't make any difference, seemingly supporting your diagnosis (it being the device stage rather than fsck stage where the problem lies). Note that this problem is very silly. The systemd binary is running from the very devices it claims aren't ready! If it actually tried to mount /home then it would succeed every time. Prior to Ubuntu 15.04/systemd, I had my drives in a different configuration. My motherboard has two SATA controllers, each with 4 ports (one is Intel, one is ASMedia). I had the two drives making up / and /home on different controllers, and everything worked fine. My hypothesis is that the boot sequence looked like this: 1. Wait for all storage controllers and all devices on them to be enumerated 2. Run btrfs device scan 3. Mount root and pivot 4. Within new root, attempt to mount everything in /etc/fstab without any detection of availability etc With 15.04 (both upstart and systemd, hence blame likely lying with initrd+udev), things look concurrent: 1. Enumerate storage controllers and all devices on them 1. Simultaneously run btrfs device scan each time a new device is found 1. Simultaneously, the moment /dev/disk/by-uuid/ROOTUUID shows up, attempt to mount root filesystem With the two halves of the btrfs filesystem on different controllers, mounting of root failed. Doing so at the emergency root shell worked just fine. I had to rewire my drives so they were on the same controller which fixed this issue. Is there any more information I can gather to make progress on this issue? Does systemd support any flags in /etc/fstab where I can tell it just go ahead and mount instead of waiting for devices? Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlVnYVMACgkQmOOfHg372QTLMwCfRUnluXxvRsRvFTULJ0Y1ORZO 5SkAnR8rM6++4yePhel+nfPlUNh/iRfN =UF1T -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] systemctl: drop hardcoded chkconfig invocation
On Thu, 28.05.15 15:02, Martin Pitt (martin.p...@ubuntu.com) wrote:
Lennart Poettering [2015-05-28 13:05 +0200]:
Nah, please remove this part. We should not ship that upstream. THis
is something that Fedora's initscripts.rpm should provide eventually,
and should be neither shipped with systemd upstream nor systemd.rpm in
Fedora.
OK, done. I changed it to be an example .SKELETON script in the
source/tarball now, but it's not installed. (Makes it easier for
packagers to adjust).
Also added README/NEWS now.
Looks good. Please push!
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From a23a4b6c0e2b156b8902b56eab65eb87c239a073 Mon Sep 17 00:00:00 2001
From: Martin Pitt martin.p...@ubuntu.com
Date: Wed, 27 May 2015 17:04:49 +0200
Subject: [PATCH] systemctl: drop hardcoded chkconfig invocation
Introduce /usr/lib/systemd/systemd-sysv-install [--root=] action name
abstraction, replacing the direct calling of chkconfig. This allows
distributions to call their specific tools like update-rc.d without patching
systemd.
Ship systemd-sysv-install.SKELETON as an example for packagers how to
implement
this.
Drop the --enable-chkconfig configure option.
Document this in README and point to it in NEWS.
---
Makefile.am | 1 +
NEWS| 11 +++
README | 11 +++
configure.ac| 20
src/systemctl/systemctl.c | 11 +++
src/systemctl/systemd-sysv-install.SKELETON | 47
+
6 files changed, 75 insertions(+), 26 deletions(-)
create mode 100755 src/systemctl/systemd-sysv-install.SKELETON
diff --git a/Makefile.am b/Makefile.am
index d6010c5..b7d0add 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -627,6 +627,7 @@ systemgenerator_PROGRAMS += \
endif
EXTRA_DIST += \
+ src/systemctl/systemd-sysv-install.SKELETON \
units/rc-local.service.in \
units/halt-local.service.in
diff --git a/NEWS b/NEWS
index ee533b4..2e2d1ce 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,16 @@
systemd System and Service Manager
+CHANGES WITH 221:
+
+* Support for chkconfig (--enable-chkconfig) was removed in favour of
+ calling an abstraction /lib/systemd/systemd-sysv-install. This
needs
+ to be implemented for your distribution. See SYSV INIT.D SCRIPTS
in
+ README for details.
+
+Contributions from: ...
+
+-- Berlin, UNRELEASED
+
CHANGES WITH 220:
* The gudev library has been extracted into a separate repository
diff --git a/README b/README
index 2b8c68e..2be3972 100644
--- a/README
+++ b/README
@@ -222,6 +222,17 @@ NSS:
hosts: files mymachines resolve myhostname
+SYSV INIT.D SCRIPTS:
+When calling systemctl enable/disable/is-enabled on a unit which
is a
+SysV init.d script, it calls /usr/lib/systemd/systemd-sysv-install;
+this needs to translate the action into the distribution specific
+mechanism such as chkconfig or update-rc.d. Packagers need to provide
+this script if you need this functionality (you don't if you disabled
+SysV init support).
+
+Please see src/systemctl/systemd-sysv-install.SKELETON for how this
+needs to look like, and provide an implementation at the marked
places.
+
WARNINGS:
systemd will warn you during boot if /etc/mtab is not a
symlink to /proc/mounts. Please ensure that /etc/mtab is a
diff --git a/configure.ac b/configure.ac
index 0818dd8..e46ca45 100644
--- a/configure.ac
+++ b/configure.ac
@@ -491,25 +491,6 @@ if test x${have_ima} != xno ; then
fi
#
--
-have_chkconfig=yes
-AC_ARG_ENABLE([chkconfig], AS_HELP_STRING([--disable-chkconfig],[Disable
optional chkconfig support]),
-[case ${enableval} in
-yes) have_chkconfig=yes ;;
-no) have_chkconfig=no ;;
-*) AC_MSG_ERROR(bad value ${enableval} for
--disable-chkconfig) ;;
-esac],
-[AC_PATH_PROG(CHKCONFIG, chkconfig)
-if test -z $CHKCONFIG; then
-have_chkconfig=no
-else
-have_chkconfig=yes
-fi])
-
-if test x${have_chkconfig} != xno ; then
-AC_DEFINE(HAVE_CHKCONFIG, 1, [Define if CHKCONFIG is available])
-fi
-
-#
--
have_selinux=no
AC_ARG_ENABLE(selinux, AS_HELP_STRING([--disable-selinux], [Disable optional
SELINUX support]))
if test x$enable_selinux != xno; then
@@ -1541,7
Re: [systemd-devel] [PATCH] path-util: Fix path_is_mount_point for files
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).
I'll look into making these more like open*_at() tomorrow.
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] Fix systemd.resource-control(5) volume number.
On Thu, 28.05.15 09:24, Patrick Donnelly (batr...@batbytes.com) wrote: On Wed, May 27, 2015 at 5:38 PM, Tom Gundersen t...@jklm.no wrote: On Wed, May 27, 2015 at 9:47 PM, Patrick Donnelly batr...@batbytes.com wrote: Signed-off-by: Patrick Donnelly batr...@batbytes.com We don't use s-o-b in systemd, so dropped this when applying. Also adjusted the subject line a bit (for future reference). Thanks for the patch! Pushed. I looked around on the website/repo and didn't see a document on submitting patches and/or commit message styling. Did I miss it or perhaps it should be written? Yeah, we don't really have that right now. Also, it's going to change shortly anyway, since we intend to move the core repo to github, at which point we will start accepting patches both traditionally via the mailing list and as github merge requests... I figure before documenting this we should have completed that switch so that we don't document something that's already out-of-date. 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 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...
Or am I missing something?
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;
@@ -558,7 +558,11 @@ int fd_is_mount_point(int fd) {
return -errno;
}
-r = name_to_handle_at(fd, .., h_parent.handle, mount_id_parent,
0);
+if (parent)
+r = name_to_handle_at(AT_FDCWD, parent, h_parent.handle,
mount_id_parent, 0);
+else
+/* this only works for directories */
+r = name_to_handle_at(fd, .., h_parent.handle,
mount_id_parent, 0);
if (r 0) {
if (errno == EOPNOTSUPP) {
if (nosupp)
@@ -599,7 +603,11 @@ fallback_fdinfo:
if (r 0)
return r;
-r = fd_fdinfo_mnt_id(fd, .., 0, mount_id_parent);
+if (parent)
+r = fd_fdinfo_mnt_id(AT_FDCWD, parent, 0, mount_id_parent);
+else
+/* this only works for directories */
+r = fd_fdinfo_mnt_id(fd, .., 0, mount_id_parent);
if (r 0)
return r;
@@ -618,7 +626,11 @@ fallback_fstat:
if (fstatat(fd, , a, AT_EMPTY_PATH) 0)
return -errno;
-if (fstatat(fd, .., b, 0) 0)
+if (parent)
+r = fstatat(AT_FDCWD, parent, b, 0);
+else
+r = fstatat(fd, .., b, 0);
+if (r 0)
return -errno;
/* A directory with same device and inode as its parent? Must
@@ -632,17 +644,23 @@ fallback_fstat:
int path_is_mount_point(const char *t, bool allow_symlink) {
_cleanup_close_ int fd = -1;
+_cleanup_free_ char *parent = NULL;
+int r;
assert(t);
if (path_equal(t, /))
return 1;
-fd = openat(AT_FDCWD, t,
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC|(allow_symlink ? 0 : O_PATH));
+r = path_get_parent(t, parent);
+if (r 0)
+return r;
+
+fd = openat(AT_FDCWD, t,
O_RDONLY|O_NONBLOCK|O_CLOEXEC|(allow_symlink ? 0 : O_PATH|O_NOFOLLOW));
if (fd 0)
return -errno;
-return fd_is_mount_point(fd);
+return fd_is_mount_point(fd, parent);
}
int path_is_read_only_fs(const char *path) {
diff --git a/src/shared/path-util.h b/src/shared/path-util.h
index 4f45cfd..cf5143f 100644
--- a/src/shared/path-util.h
+++ b/src/shared/path-util.h
@@ -53,7 +53,7 @@ char** path_strv_make_absolute_cwd(char **l);
char** path_strv_resolve(char **l, const char *prefix);
char** path_strv_resolve_uniq(char **l, const char *prefix);
-int fd_is_mount_point(int fd);
+int fd_is_mount_point(int fd, const char *parent);
int path_is_mount_point(const char *path, bool allow_symlink);
int path_is_read_only_fs(const char *path);
int path_is_os_tree(const char *path);
diff --git a/src/shared/rm-rf.c b/src/shared/rm-rf.c
index a89e8af..e84bb10 100644
--- a/src/shared/rm-rf.c
+++ b/src/shared/rm-rf.c
@@ -102,8 +102,8 @@ int rm_rf_children(int fd, RemoveFlags flags, struct stat
*root_dev) {
continue;
}
-/* Stop at mount points */
-r = fd_is_mount_point(subdir_fd);
+/* Stop at directory mount points */
+r = fd_is_mount_point(subdir_fd, NULL);
if (r 0) {
if (ret == 0 r != -ENOENT)
ret = r;
diff --git a/src/test/test-path-util.c b/src/test/test-path-util.c
index 09f0f2f..0a03941 100644
--- a/src/test/test-path-util.c
+++ b/src/test/test-path-util.c
@@ -21,6 +21,7 @@
#include stdio.h
#include unistd.h
+#include sys/mount.h
#include path-util.h
#include util.h
@@ -88,21 +89,9 @@ static void test_path(void) {
test_parent(/aa///file..., /aa///);
test_parent(file.../, NULL);
-assert_se(path_is_mount_point(/, true) 0);
-assert_se(path_is_mount_point(/, false) 0);
-
fd
Re: [systemd-devel] [PATCH v2] cgroup-util: fix is_valid check to pass for unified cgroup hierchy.
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?
---
v2 change: Test for unified cgroup should pass irrespective of
whether allow_named is set.
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 c0b0ca4..eda7523 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
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
2015-05-28 19:41 GMT+02:00 Martin Pitt martin.p...@ubuntu.com: I hope that's helpful! Applied both! \o/ Many thanks Filipe, that's great! Biggest patch gone :) A huge thanks from me as well to everyone involved! -- 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 v3] systemctl: Don't skip SysV init.d scripts when enabling/disabling units
Lennart Poettering [2015-05-28 19:23 +0200]: Looks good. Please push. For the archives: 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] Alienware graphics amplifier scancodes
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.. ___ 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
Hey Filipe,
Lennart Poettering [2015-05-28 19:35 +0200]:
On Wed, 27.05.15 02:38, Filipe Brandenburger (filbran...@google.com) wrote:
As suggested by Martin Pitt, for better support of distros with non-merged
/usr.
This doesn't get us 100% there but I'd say it gets us much closer.
I think we still need a new variable for /etc/udev (similar to
pkgsysconfdir;
which is /etc/systemd) though that is not really critical for non-merged
/usr.
There are also some general explanations (in files man/hwdb.xml,
man/udev.xml
and man/systemd.{link,netdev,network}.xml) which talk of how files in /etc
override those in /usr/lib but we don't really have a great variable for
/usr/lib or /lib vs. /etc, so I'd like to think a little further on how to
solve that particular one...
I hope that's helpful!
Applied both!
\o/ Many thanks Filipe, that's great! Biggest patch gone :)
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] Alienware graphics amplifier scancodes
On Thu, May 28, 2015 at 06:48:49PM +0200, Lennart Poettering wrote: On Wed, 27.05.15 15:59, Mario Limonciello (mario_limoncie...@dell.com) wrote: Hi, Some Alienware notebooks and desktops support an external graphics housing called the Alienware Graphics Amplifier. It allows the usage of a larger or more modern graphics card than your gaming PC would already support. In order to provide a good experience, systems that support it can provide notification to the OS via the scancodes on the the keyboard controller of events related to the cable. The following 4 events are supported (and the presumed OS response): * Cable plugged in (An app on the existing display or terminal would tell the user to reboot the system to activate) * Undock cable pressed (An app would let the user know to reboot the system to complete undock process; also when supported by GFX driver, driver can clean up and work without a reboot) * Undock hotkey pressed (Same result as undock cable expected) * Surprise removal of cable (System immediately reboots). The first three events I think it would make sense to assign to a keycode that a userspace application in X land can pickup and recognize, but I'm at a loss what makes most sense (prog1, prog2, prog3 maybe?). This userspace application hasn't yet been made or decided, I just want to pave the path for it first. The fourth event I'm submitting a kernel patch (https://lkml.org/lkml/2015/5/27/817) so that the kernel would issue a reboot when this was detected, so I believe it would make sense to mark it 'unknown' in systemd. Also, these don't show up in xev output, but they do show up in evtest. Can I get some advice on these? I'll gladly submit a bug with a patch afterward. 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? We are not happy with such a thing at all, I'll go respond to that kernel patch now, this is not an acceptable solution in any way. greg k-h ___ 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 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? 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. If it ends up in the kernel to reboot when the cable is unplugged, I don't really care if the event that the cable was unplugged gets relayed up to userspace, I was just looking to avoid the unknown keys message in dmesg. It can be mapped to 'unknown' in this scenario. As for the other two events (cable connect and disconnect button notification), these are supposed to be delivered to userspace for that app to notify the user what to do to make their hardware work depending on what they did. This might be restarting the graphics server, might be installing a new driver from a graphics vendor, might be rebooting. It's something that userspace needs to tell someone to do. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Alienware graphics amplifier scancodes
28.05.2015 01:59, Mario Limonciello wrote: Hi, Some Alienware notebooks and desktops support an external graphics housing called the Alienware Graphics Amplifier. It allows the usage of a larger or more modern graphics card than your gaming PC would already support. In order to provide a good experience, systems that support it can provide notification to the OS via the scancodes on the the keyboard controller of events related to the cable. The following 4 events are supported (and the presumed OS response): * Cable plugged in (An app on the existing display or terminal would tell the user to reboot the system to activate) * Undock cable pressed (An app would let the user know to reboot the system to complete undock process; also when supported by GFX driver, driver can clean up and work without a reboot) * Undock hotkey pressed (Same result as undock cable expected) * Surprise removal of cable (System immediately reboots). OK, so you have described GPU hotplug in detail. Please note that Alienware is not the only system that has a hot-pluggable GPU. My laptop, Sony VAIO VPC-Z23A4R, manufactured in 2012, also has a similar facility (the AMD GPU, including two additional outputs, is in the docking station), but AFAIK it is not based on scancodes. So maybe it makes sense to unify handling of the Undock buttons on these devices. Feel free to contact me via email or XMPP (same address) so that we can figure out how to make this possible. P.S. Under Windows 7, if the dock station is configured to be used for additional outputs only, it handles both docking and undocking without a reboot. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] systemctl: drop hardcoded chkconfig invocation
Lennart Poettering [2015-05-28 19:22 +0200]: Looks good. Please push! For the archives: 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] Alienware graphics amplifier scancodes
On Thu, May 28, 2015 at 01:25:58PM -0500, Mario Limonciello wrote: 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? Fix the drivers. 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? It means it gets fixed. Why should your hardware be immune from this? I have hardware right here that does this properly, it's been working for many many years, this isn't new at all. You can't guarantee that there is another GPU to display things on. Yes you can. X's architecture isn't cut out for GPU's disappearing and reappearing. Yes it is, this does work. Please fix the drivers, that's the solution. greg k-h ___ 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 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.
Regards,
Dimitri.
---
v2 change: Test for unified cgroup should pass irrespective of
whether allow_named is set.
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 c0b0ca4..eda7523 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
Lennart
--
Lennart Poettering, Red Hat
--
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
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. 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
Re: [systemd-devel] [PATCH v2] udev: input_id: fix detection of various touchscreens
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.
libinput would not treat those as input devices. Additionally there
is an 'IS_DIRECT' property exposed by most touch screens, that would
otherwise be detected as touch pads.
---
src/udev/udev-builtin-input_id.c | 145
+--
1 file changed, 80 insertions(+), 65 deletions(-)
diff --git a/src/udev/udev-builtin-input_id.c
b/src/udev/udev-builtin-input_id.c
index b14190e..a4cafa0 100644
--- a/src/udev/udev-builtin-input_id.c
+++ b/src/udev/udev-builtin-input_id.c
@@ -133,79 +133,94 @@ 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)) {
-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)) {
+bool is_mouse = false;
+bool is_touchpad = false;
+bool is_direct = false;
+bool has_coordinates = false;
+bool has_mt_coordinates = false;
+bool has_joystick_axes_or_buttons = false;
+bool has_touch = false;
+bool stylus_or_pen = false;
+bool finger_but_no_pen = false;
+bool has_mouse = false;
s/has_mouse/has_mouse_button/ or better has_button_left
+bool is_touchscreen = false;
+bool is_tablet = false;
+bool is_joystick = false;
+bool is_accelerometer = false;
+bool is_pointing_stick= false;
+bool has_3d_coordinates = false;
+bool has_keys = false;
+
+has_keys = test_bit(EV_KEY, bitmask_ev);
+has_touch = test_bit(BTN_TOUCH, bitmask_key);
+has_mouse = test_bit(BTN_MOUSE, bitmask_key);
I'd prefer BTN_LEFT here, they're aliases anyway and LEFT is more
expressive.
+has_coordinates = test_bit(ABS_X, bitmask_abs) test_bit(ABS_Y,
bitmask_abs);
s/has_abs_coordinates/
+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.
+is_direct = test_bit(INPUT_PROP_DIRECT, bitmask_props);
+is_accelerometer = test_bit(INPUT_PROP_ACCELEROMETER, bitmask_props);
+is_pointing_stick = test_bit(INPUT_PROP_POINTING_STICK,
bitmask_props);
+stylus_or_pen = test_bit(BTN_STYLUS, bitmask_key) ||
+test_bit(BTN_STYLUS2, 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);
+/* joysticks don't necessarily have to have buttons; e. g.
s/have to have/have/
+ * 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) ||
+
Re: [systemd-devel] fsck, /home, btrfs, multiple partitions/drives, boot failure [Ubuntu 15.04]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 В Thu, 28 May 2015 11:41:27 -0700 Roger Binns rog...@rogerbinns.com пишет: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/28/2015 02:37 AM, Andrei Borzenkov wrote: I was wrong here, device is opened by btrfs driver so there should be no collision here. Still obviously scanning fails (and it fails actively, setting ID_BTRFS_READY). This needs some debugging on udev side. I just tried booting with fsck.mode=skip and that didn't make any difference, seemingly supporting your diagnosis (it being the device stage rather than fsck stage where the problem lies). ... Is there any more information I can gather to make progress on this issue? Try booting with udev.log-priority=debug rd.udev.log-priority=debug, this may give some hint what happens. You can also try to enable debug logging after boot (udevadm control - -l debug) and trigger event by issuing echo add /sys/block/sda/sda1/uevent Does systemd support any flags in /etc/fstab where I can tell it just go ahead and mount instead of waiting for devices? No. You can set nofail in which case boot will proceed and you can mount it manually later. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlVn36QACgkQR6LMutpd94yO0QCfbuLIGqrGv0Bmv5diFwBMJCs9 phcAnivLXey85bM4XkuBbIHhS7k2lDO0 =+WoA -END PGP SIGNATURE- ___ 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 Thu, May 28, 2015 at 9:21 PM, 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. That's not what --disable-dbus means..please read the configure description.. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] disabling ctrl+alt+del
Michał Zegan [2015-05-28 23:22 +0200]: What is the most correct way to disable ctrl+alt+delete keys? I mean disable, not redefine. As a first iteration I'd recommend systemctl mask ctrl-alt-del.target. After that, pressing it will cause an error message in the journal, though (Failed to enqueue ctrl-alt-del.target job). If that's bothering, you, create an /etc/systemd/system/ctrl-alt-del.target with just [Unit] and a Description= and nothing else, then you don't get an error message any more. This will also override the builtin Alias= in reboot.target. 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 as non-root
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. 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 ___ 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
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. Michael [1] http://paste.debian.net/186665/ -- 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] systemctl as non-root
В Thu, 28 May 2015 17:21:14 -0700 aaron_wri...@selinc.com пишет: 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. 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 wonder how access control is implemented in kdbus case. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] build-sys: pass originally configured --enable-split-usr to distcheck
Hello all,
this is a little patch which fixes make distcheck on split-/usr
systems. That together with the previous Stop depending on current
configure options for EXTRA_DIST now makes check, distcheck, etc.
completely work on Debian/Ubuntu.
As discussed, I now set up daily upstream make/make check/make
distcheck builds on
https://code.launchpad.net/~pitti/+recipe/upstream-distcheck so that I
get notified whenever distcheck starts failing again. This still fails
due to these two issues. The build recipe also had a bug which showed
the wrong test logs on distcheck failures, but that'll be fixed in the
next run. Next step ist to build actually useful packages out of that
which we can then feed to our rather extensive system integration tests.
That'll be some more work, but it's absolutely worth doing it for both
CI as well as giving people a way to test the latest changes easily.
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From 00bed6f7a42f5bb8479f415f61349a63a8d6dba0 Mon Sep 17 00:00:00 2001
From: Martin Pitt martin.p...@ubuntu.com
Date: Fri, 29 May 2015 07:39:53 +0200
Subject: [PATCH] build-sys: pass originally configured --enable-split-usr to
distcheck
Previously we always ran distcheck with --disable-split-usr. This caused
test-path-util to fail with
Assertion 'fsck_exists(minix) == 0' failed at ../src/test/test-path-util.c:224, function test_fsck_exists(). Aborting.
as looking up fsck.minix would only look into DEFAULT_PATH_NORMAL, but on these
systems fsck is in /sbin/.
---
Makefile.am | 9 -
configure.ac | 1 +
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/Makefile.am b/Makefile.am
index d3ab8d2..7703cda 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -6799,7 +6799,6 @@ DISTCHECK_CONFIGURE_FLAGS = \
--with-pamlibdir=$$dc_install_base/$(pamlibdir) \
--with-pamconfdir=$$dc_install_base/$(pamconfdir) \
--with-rootprefix=$$dc_install_base \
- --disable-split-usr \
--enable-kdbus \
--enable-compat-libs
@@ -6823,6 +6822,14 @@ DISTCHECK_CONFIGURE_FLAGS += \
--enable-gtk-doc
endif
+if ENABLE_SPLIT_USR
+DISTCHECK_CONFIGURE_FLAGS += \
+ --enable-split-usr
+else
+DISTCHECK_CONFIGURE_FLAGS += \
+ --disable-split-usr
+endif
+
#
# Require python when making dist
#
diff --git a/configure.ac b/configure.ac
index e46ca45..92654a6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1433,6 +1433,7 @@ AC_SUBST(DEFAULT_DKR_INDEX_URL)
AS_IF([test x${enable_split_usr} = xyes], [
AC_DEFINE(HAVE_SPLIT_USR, 1, [Define if /bin, /sbin aren't symlinks into /usr])
])
+AM_CONDITIONAL(ENABLE_SPLIT_USR, [test x${enable_split_usr} = xyes])
# Work around intltoolize and gtk-doc problems in VPATH builds
AM_CONDITIONAL([ENABLE_GTK_DOC_TESTS], [test x$0 = x./configure],
--
2.1.4
signature.asc
Description: Digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fsck, /home, btrfs, multiple partitions/drives, boot failure [Ubuntu 15.04]
Am 28.05.2015 um 07:24 schrieb Martin Pitt: Reindl Harald [2015-05-28 1:00 +0200]: Am 27.05.2015 um 23:03 schrieb Roger Binns: My immediate problem is a boot failure with systemd on Ubuntu 15.04 because of fsck issues (systemd timing out fscking something it shouldn't) sounds like https://bugzilla.redhat.com/show_bug.cgi?id=1217969 Out of interest, why does it sound the same? Roger's specific situation is that he has a btrfs device which is spread over multiple partitions, and all these partitions have the exact same UUID. Do you actually have that as well? The bug report doesn't mention that, or a blkid output etc.; I'd say that this kind of striped btrfs is a special case enough to at least be worth mentioning it sounds similar because something is running in a timeout and break boot instead wait for the fsck to finish, in my case it's a at that time slow host system a fsck should not timeout and lead in an emergency shell because when you imagine a really large volume with multible TB it may take a long time signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Starting units when a port is available for connections
On 27 May 2015, at 8:40 pm, Andrei Borzenkov arvidj...@gmail.com wrote: Hmm ... this sounds suspiciously like what D-Bus does. Did you consider using D-Bus in your application? But for now there is no way to express such dependency in systemd; D-Bus being exception, you can make services dependent on D-Bus end points. I’ve considered it now :) I communicate with systemd via D-Bus for starting stopping services. How does one write a service unit that depends on a D-Bus endpoint? Is this supported by systemd, or is this an application level thing? I’m unable to find anything in the systemd docs about creating dependencies on D-Bus endpoints. I wonder - can your master service trigger startup of clients when it is ready? Note that it can be done in completely generic way - it can simply run something like cassandra.target and you can plug in any client into this target. This is another option that I’ll play with. Thanks, Adam ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] 220 udev boot regression: timeout, giving up waiting for workers to finish
On Wed, May 27, 2015 at 07:08:41PM +0200, Tom Gundersen wrote: This should be fixed by 86c3bece38bcf55da6387d20c6f01da9ad0284dc. Thanks for the help in debugging this, and sorry for the inconvenience. Also this fixes a bug where 'udevadm settle' would go into a loop for a few minutes after you create a new partition (RHBZ#1225641). Thanks, Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] udev: input_id: fix detection of various touchscreens
There are touch screens that do not provide 'BTN_TOUCH' and hence no
'EV_KEY'. Previously those would not get any properties assigned and
libinput would not treat those as input devices. Additionally there
is an 'IS_DIRECT' property exposed by most touch screens, that would
otherwise be detected as touch pads.
---
src/udev/udev-builtin-input_id.c | 134 +--
1 file changed, 74 insertions(+), 60 deletions(-)
diff --git a/src/udev/udev-builtin-input_id.c b/src/udev/udev-builtin-input_id.c
index b14190e..8b08742 100644
--- a/src/udev/udev-builtin-input_id.c
+++ b/src/udev/udev-builtin-input_id.c
@@ -135,77 +135,91 @@ static bool test_pointers(struct udev_device *dev,
bool test) {
int is_mouse = 0;
int is_touchpad = 0;
-bool ret = false;
-
-if (test_bit(INPUT_PROP_ACCELEROMETER, bitmask_props)) {
-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)) {
+int is_direct = 0;
+int has_coordinates = 0;
+int has_mt_coordinates = 0;
+int has_joystick_axes_or_buttons = 0;
+int has_touch = 0;
+int stylus_or_pen = 0;
+int finger_but_no_pen = 0;
+int has_mouse = 0;
+int is_touchscreen = 0;
+int is_tablet = 0;
+int is_joystick = 0;
+int is_accelerometer = 0;
+int is_pointing_stick= 0;
+int has_3d_coordinates = 0;
+int has_keys = 0;
+
+has_keys = test_bit (EV_KEY, bitmask_ev);
+has_touch = test_bit (BTN_TOUCH, bitmask_key);
+has_mouse = test_bit (BTN_MOUSE, bitmask_key);
+has_coordinates = test_bit (ABS_X, bitmask_abs) test_bit (ABS_Y,
bitmask_abs);
+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);
+is_direct = test_bit (INPUT_PROP_DIRECT, bitmask_props);
+is_accelerometer = test_bit (INPUT_PROP_ACCELEROMETER, bitmask_props);
+is_pointing_stick = test_bit(INPUT_PROP_POINTING_STICK, bitmask_props);
+stylus_or_pen = test_bit (BTN_STYLUS, bitmask_key) ||
+test_bit (BTN_STYLUS2, 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);
+/* joysticks don't necessarily have to 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_coordinates) {
+if (stylus_or_pen)
+is_tablet = 1;
+else if (!is_direct finger_but_no_pen)
is_touchpad = 1;
-} else if (test_bit(BTN_MOUSE, bitmask_key)) {
+else if (has_mouse)
/* This path is taken by VMware's USB mouse, which has
* absolute axes, but no touch/pressure button. */
is_mouse = 1;
-} else if (test_bit(BTN_TOUCH, bitmask_key)) {
-udev_builtin_add_property(dev, test,
ID_INPUT_TOUCHSCREEN, 1);
-ret = true;
-/* joysticks don't necessarily have to have buttons; e. g.
- * rudders/pedals are
Re: [systemd-devel] 'udevadm settle' brakes lvm on top of imsm raid
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] build-sys: Stop depending on current configure options for EXTRA_DIST
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:20150528101607.GH3335%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 1/2] systemctl: drop hardcoded chkconfig invocation
Lennart Poettering píše v Čt 28. 05. 2015 v 13:05 +0200: On Wed, 27.05.15 18:08, Martin Pitt (martin.p...@ubuntu.com) wrote: Hello again, as discussed previously this second variant of un-hardcoding chkconfig now uses the proposed /usr/lib/systemd/systemd-sysv-install abstraction. I also added a reference implementation for chkconfig which gets installed with --enable-chkconfig, so on Fedora this should be no net change. Nah, please remove this part. We should not ship that upstream. THis is something that Fedora's initscripts.rpm should provide eventually, and should be neither shipped with systemd upstream nor systemd.rpm in Fedora. +1 I will patch chkconfig to handle this similarly as the install_initd. This doesn't have a manpage yet (as it's not an user-callable program); where should this be documented? Just adding to README? Well, you could put it on some fdo wiki page maybe and link this up from the source and from NEWS. Doesn't have to be too formal... Patch looks fine otherwise: just remove any trace of chkconfig. Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] systemctl: Don't skip native units when enabling/disabling SysV init.d scripts
On 28 May 2015 at 12:31, Lennart Poettering lenn...@poettering.net wrote:
On Wed, 27.05.15 15:13, Martin Pitt (martin.p...@ubuntu.com) wrote:
Hello,
if you have both a systemd unit and a SysV init script with the same
name, systemctl {en,dis}able currently diverts to chkconfig and
friends *only*, without actually enabling/disabling the native unit.
This is a non-issue for Fedora packages which eliminated init.d
scripts, but still an issue for e. g. Debian or third-party packages
which want to support multiple init systems.
Hmm? THis sounds the wrong way round. What currently happens should be
this: if both are available systemd ignores the sysv script, and only
considers the native unit. Is that what you are trying to say?
And you now want everything to be applied to both the sysv script and
the native unit?
What happens if we query the state of things with is-enabled, then?
Debian supports rebooting with either sysv-init or systemd hence
the key point here multiple init systems, simultaneously within single
install.
--
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] journal, coredump: allow relative values in some configuration options
Lennart Poettering lenn...@poettering.net writes:
Hmm, this doesn't look right. here we choose the hash table sizes to
use for a file, and I doubt we should base this on the currently
available disk space, since sizing the hashtable will have an effect
on the entire lifetime of the file, during which the available disk
space might change wildly.
I think it would be best not to do relative sizes for the journal file
max size at all, and continue to only support and absolute value for
that.
+
+uint64_t size_parameter_evaluate(const SizeParameter *sp, uint64_t
available) {
+if (sp-value == (uint64_t) -1)
+return (uint64_t) -1;
+
+if (sp-relative)
+return sp-value * 0.01 * available;
Hmm, so this implements this as percentage after all. as mentioned in
my earlier mail, I think this should be normalized to 2^32 instead, so
that 2^32 maps to 100%...
I realized that I got the patch wrong. What I really wanted was to take
percentage values of *disk size*, not available space. Using disk size
would make it constant. Having said that, is it ok to change even the
options that you said were the bad idea? Also, does it really make sense
to implement the relative values as a mapping as you have suggested? To
me it really doesn't, since you can't take more than 100% of disk space
is not possible (I don't really count thin LVs), and mapping to a
huge interval is just not as readable as using percentage. What is the
advantage of the mapping again? Sorry if I'm being thick.
Cheers,
--
Jan Synacek
Software Engineer, Red Hat
signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journal, coredump: allow relative values in some configuration options
On Thu, 28.05.15 11:49, Jan Synacek (jsyna...@redhat.com) wrote:
Lennart Poettering lenn...@poettering.net writes:
Hmm, this doesn't look right. here we choose the hash table sizes to
use for a file, and I doubt we should base this on the currently
available disk space, since sizing the hashtable will have an effect
on the entire lifetime of the file, during which the available disk
space might change wildly.
I think it would be best not to do relative sizes for the journal file
max size at all, and continue to only support and absolute value for
that.
+
+uint64_t size_parameter_evaluate(const SizeParameter *sp, uint64_t
available) {
+if (sp-value == (uint64_t) -1)
+return (uint64_t) -1;
+
+if (sp-relative)
+return sp-value * 0.01 * available;
Hmm, so this implements this as percentage after all. as mentioned in
my earlier mail, I think this should be normalized to 2^32 instead, so
that 2^32 maps to 100%...
I realized that I got the patch wrong. What I really wanted was to take
percentage values of *disk size*, not available space. Using disk size
would make it constant.
Not really. On btrfs and suchlike you can easily add/remove a new disk
during runtime, making this dynamic...
Having said that, is it ok to change even the options that you said
were the bad idea?
Well, for some of them you need to to an extra statfs() which we
better avoid if we don't have to, since it was in a relatively inner
loop. I'd hence rather avoid this...
Also, does it really make sense to implement the relative values as
a mapping as you have suggested? To me it really doesn't, since you
can't take more than 100% of disk space is not possible (I don't
really count thin LVs), and mapping to a huge interval is just not
as readable as using percentage. What is the advantage of the
mapping again? Sorry if I'm being thick.
Well, storing them as fixed-point factor with 32bit before and 32bit
after the radix point rather than as percentage is mostly just a
question of accuracy and of being generic or not...
I'd always keep our basic structures as generic as possible, and as
close to the way CPUs work. Hence: store things as fixed-point
32bit/32bit internally, but make it configurable in percent as
user-pointing UI.
Sure, actually using factors 1.0 (or 100%) doesn't make much sense,
but I'd still allow them to be encoded, simply to have the basic types
as generic as possible...
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 2/2] systemctl: Don't skip native units when enabling/disabling SysV init.d scripts
On Wed, 27.05.15 15:13, Martin Pitt (martin.p...@ubuntu.com) wrote:
Hello,
if you have both a systemd unit and a SysV init script with the same
name, systemctl {en,dis}able currently diverts to chkconfig and
friends *only*, without actually enabling/disabling the native unit.
This is a non-issue for Fedora packages which eliminated init.d
scripts, but still an issue for e. g. Debian or third-party packages
which want to support multiple init systems.
Hmm? THis sounds the wrong way round. What currently happens should be
this: if both are available systemd ignores the sysv script, and only
considers the native unit. Is that what you are trying to say?
And you now want everything to be applied to both the sysv script and
the native unit?
What happens if we query the state of things with is-enabled, then?
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]
On Thu, May 28, 2015 at 8:46 AM, Andrei Borzenkov arvidj...@gmail.com wrote: Apr 24 14:18:41 workstation systemd[1]: Job dev-disk-by\x2duuid-3ff68715\x2d0daa\x2d4e44\x2d8de2\x2d0997f36d8ab6.device/start timed out. systemd times out waiting for UUID alias. Neither sda1 nor sdb1 are present in list of active device units. Please show udevadm info -q all -n sda1 and udevadm info -q all -n sdb1 after boot. OK, found them in bug report. As expected P: /devices/pci:00/:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1 E: ID_BTRFS_READY=0 E: SYSTEMD_READY=0 P: /devices/pci:00/:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sdb/sdb1 E: ID_BTRFS_READY=0 E: SYSTEMD_READY=0 Something is wrong with scanning for btrfs either in initrd or in running system. Hmm ... looking in kernel, btrfs_scan_one_device tries to open device exclusively. If device is already mounted, it will likely fail. I was wrong here, device is opened by btrfs driver so there should be no collision here. Still obviously scanning fails (and it fails actively, setting ID_BTRFS_READY). This needs some debugging on udev side. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: input_id: fix detection of various touchscreens
On Thu, 28.05.15 11:59, Andreas Pokorny (andreas.poko...@canonical.com) 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
libinput would not treat those as input devices. Additionally there
is an 'IS_DIRECT' property exposed by most touch screens, that would
otherwise be detected as touch pads.
I didn't check what the patch actually precisely does, and I am not
sure if it's something to merge (that's probably something Peter
Hutterer has to decide).
However: please check CODING_STYLE when prepping patches. For new
code, please use bools rather than ints to encode booleans. It appears
that has_coordinates and the other variables should really be
bools.
Also, please write test_bit(...) rather than test_bit (...).
src/udev/udev-builtin-input_id.c | 134
+--
1 file changed, 74 insertions(+), 60 deletions(-)
diff --git a/src/udev/udev-builtin-input_id.c
b/src/udev/udev-builtin-input_id.c
index b14190e..8b08742 100644
--- a/src/udev/udev-builtin-input_id.c
+++ b/src/udev/udev-builtin-input_id.c
@@ -135,77 +135,91 @@ static bool test_pointers(struct udev_device *dev,
bool test) {
int is_mouse = 0;
int is_touchpad = 0;
-bool ret = false;
-
-if (test_bit(INPUT_PROP_ACCELEROMETER, bitmask_props)) {
-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)) {
+int is_direct = 0;
+int has_coordinates = 0;
+int has_mt_coordinates = 0;
+int has_joystick_axes_or_buttons = 0;
+int has_touch = 0;
+int stylus_or_pen = 0;
+int finger_but_no_pen = 0;
+int has_mouse = 0;
+int is_touchscreen = 0;
+int is_tablet = 0;
+int is_joystick = 0;
+int is_accelerometer = 0;
+int is_pointing_stick= 0;
+int has_3d_coordinates = 0;
+int has_keys = 0;
+
+has_keys = test_bit (EV_KEY, bitmask_ev);
+has_touch = test_bit (BTN_TOUCH, bitmask_key);
+has_mouse = test_bit (BTN_MOUSE, bitmask_key);
+has_coordinates = test_bit (ABS_X, bitmask_abs) test_bit (ABS_Y,
bitmask_abs);
+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);
+is_direct = test_bit (INPUT_PROP_DIRECT, bitmask_props);
+is_accelerometer = test_bit (INPUT_PROP_ACCELEROMETER,
bitmask_props);
+is_pointing_stick = test_bit(INPUT_PROP_POINTING_STICK,
bitmask_props);
+stylus_or_pen = test_bit (BTN_STYLUS, bitmask_key) ||
+test_bit (BTN_STYLUS2, 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);
+/* joysticks don't necessarily have to 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_coordinates) {
+if (stylus_or_pen)
+is_tablet = 1;
+else if (!is_direct finger_but_no_pen)
is_touchpad = 1;
Re: [systemd-devel] [PATCH v2 1/2] systemctl: drop hardcoded chkconfig invocation
On Wed, 27.05.15 18:08, Martin Pitt (martin.p...@ubuntu.com) wrote: Hello again, as discussed previously this second variant of un-hardcoding chkconfig now uses the proposed /usr/lib/systemd/systemd-sysv-install abstraction. I also added a reference implementation for chkconfig which gets installed with --enable-chkconfig, so on Fedora this should be no net change. Nah, please remove this part. We should not ship that upstream. THis is something that Fedora's initscripts.rpm should provide eventually, and should be neither shipped with systemd upstream nor systemd.rpm in Fedora. This doesn't have a manpage yet (as it's not an user-callable program); where should this be documented? Just adding to README? Well, you could put it on some fdo wiki page maybe and link this up from the source and from NEWS. Doesn't have to be too formal... Patch looks fine otherwise: just remove any trace of chkconfig. 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] udev: input_id: fix detection of various touchscreens
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1432807197-32739-1-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] ExecStart vs ExecStartPre
On Tue, 26.05.15 14:12, Steven Noonan (ste...@uplinklabs.net) wrote: Hi there, I'm wondering what the functional difference is between doing: ExecStartPre=/bin/foo ExecStart=/bin/bar and ExecStart=/bin/foo ExecStart=/bin/bar As mentioned in Christian's reply: multiple ExecStart= lines are only available for Type=oneshot services. Other service types do not support that. From my read of the systemd.service man page, they appear to have the same behavior in the common use case. For services that do not have Type=oneshot it is the ExecStart= process that defines the runtime of the service unit. Only when it signalled that its initialization is complete systemd considers the service fully up, and when it dies it takes that as indication that the service is terminating now. Also, each time an ExecStartPre= service dies systemd will kill all remaining processes in the cgroup. However, especially for Type=forking services this is different for ExecStart=. Then, among other things, while the process invoked with ExecStart= is up things like watchdog support and so on are active, while on ExecStartPre= and so on a timeout is applied. The only difference I can see is that groups of ExecStartPre and ExecStart groups can be rearranged. That is, you could have an ExecStartPre line *after* the ExecStart line in the file, and the ExecStartPre would still be executed first. But the ordering of multiple ExecStart (or ExecStartPre) lines in a single systemd.service file matters, because it has explicit ordering as written in the file. Why would someone choose one over the other? What differences am I missing? ExecStart= should be the main process of a daemon. Defining its life-time, be long-lived. ExecStartPre= however should only be short-lived, preparatory processes. 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] Vendor default masked service
On Wed, 27.05.15 13:05, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: On Tue, May 26, 2015 at 4:14 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 26.05.15 11:53, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: Hi, I was wondering if we have a way to provide vendor default masked service? Well, so far our thinking was that if the vendor wants to make a unit completely unavailable he should simply not ship it in the first place. What's the usecase for a vendor masking a unit, but installing it? Why not remove it in the first place entirely? If we ship a product without the service, we don't have a way of installing it again once the product is deployed. Use case would be: We use one software for a video encoder blade with multiple CPUs. Every CPU runs the same software. We have a special service which should only run on the first CPU. A generator installs the .wants link for the service on first CPU. Another service could try to talk to the special service over dbus causing it to be dbus activated (where special service is only allowed to be up on first CPU). We could install the dbus activation files with generator but it gets messy to offload this logic to a generator. Also, special service can be activated by using systemd's dbus interface. My recommendation would be to ship the dbus service file always, but make it direct to SystemdService=dbus-com.axis.foobar.waldi.service, and then manage dbus-com.axis.foobar.waldi.service as a symlink alias to the real bus service. All you do in your generator now is create the symlink or not create it... Wouldn't that work? 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] Vendor default masked service
On Thu, May 28, 2015 at 1:17 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 27.05.15 13:05, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: On Tue, May 26, 2015 at 4:14 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 26.05.15 11:53, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: Hi, I was wondering if we have a way to provide vendor default masked service? Well, so far our thinking was that if the vendor wants to make a unit completely unavailable he should simply not ship it in the first place. What's the usecase for a vendor masking a unit, but installing it? Why not remove it in the first place entirely? If we ship a product without the service, we don't have a way of installing it again once the product is deployed. Use case would be: We use one software for a video encoder blade with multiple CPUs. Every CPU runs the same software. We have a special service which should only run on the first CPU. A generator installs the .wants link for the service on first CPU. Another service could try to talk to the special service over dbus causing it to be dbus activated (where special service is only allowed to be up on first CPU). We could install the dbus activation files with generator but it gets messy to offload this logic to a generator. Also, special service can be activated by using systemd's dbus interface. My recommendation would be to ship the dbus service file always, but make it direct to SystemdService=dbus-com.axis.foobar.waldi.service, and then manage dbus-com.axis.foobar.waldi.service as a symlink alias to the real bus service. All you do in your generator now is create the symlink or not create it... Wouldn't that work? For dbus activation it would work but other services can still activate the service through systemd. Umut 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] build-sys: Stop depending on current configure options for EXTRA_DIST
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. 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 += \ - units/systemd-hwdb-update.service.in \ - hwdb/ids-update.pl \ - hwdb/sdio.ids - SYSINIT_TARGET_WANTS += \ systemd-hwdb-update.service @@ -3972,6 +3967,11 @@ hwdb-remove-hook: -test -n $(DESTDIR) || rm -f /etc/udev/hwdb.bin endif +EXTRA_DIST += \ + units/systemd-hwdb-update.service.in \ + hwdb/ids-update.pl \ + hwdb/sdio.ids + # -- TESTS += \ test/udev-test.pl \ @@ -4369,9 +4369,6 @@
Re: [systemd-devel] 219/Fedora22: NFS mounts do not set SELINUX label to nfs_t: errno=-22
On 05/26/2015 09:46 AM, Lennart Poettering wrote: On Sun, 24.05.15 15:01, Anthony Alba (ascanio.al...@gmail.com) wrote: Hi, On Fedora 22, systemd 219, NFS mounts no longer acquire a default label nfs_t. mount 192.168.1.6:/var/exports/1 1 -orootcontext=system_u:object_r:nfs_t mount.nfs: an incorrect mount option was specified [ 8316.276744] SELinux: security_context_to_sid(system_u:object_r:nfs_t) failed for (dev 0:51, type nfs4) errno=-22 To my surprise, it seems to acquire labels from the NFS server (Fedora 22/nfs4) - how is this possible? But..it breaks libvirtd/kvm: it sees the right label if this were a local filesystem but audit2allow complains: ls -lZ guestfs/centos7.img -rw-r--r--. 1 qemu qemu system_u:object_r:virt_image_t:s0 22987538432 May 24 14:56 guestfs/centos7.img ## for a image in /var/lib/libvirt this is the correct label. ## I do not know how it figured that from the NFS server SELinux is preventing qemu-system-x86 from read access on the file centos7.img (on NFS share). On Fedora 21, the files acquire the label nfs_t and setsebool -P virt_use_nfs=on This is unlikely to be related to systemd, we don't really do anything special with NFS and especially not its selinux support. We simply invoke util-linux' mount command, which in turn calls mount.nfs of the nfs-utils package. Please contact the nfs-utils guys, thank you, Lennart nfs_t should be by default for labels. The example you have was not using a complete label. mount 192.168.1.6:/var/exports/1 1 -orootcontext=system_u:object_r:nfs_t mount.nfs: an incorrect mount option was specified [ 8316.276744] SELinux: security_context_to_sid(system_u:object_r:nfs_t) failed for (dev 0:51, type nfs4) errno=-22 The label should be system_u:object_r:nfs_t:s0 not system_u:object_r:nfs_t Nfs does now support labeling if you use a RHEL7 or Fedora based server and client. But it should still default to nfs_t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Vendor default masked service
On Thu, May 28, 2015 at 2:15 PM, Dimitri John Ledkov dimitri.j.led...@intel.com wrote: On 28 May 2015 at 12:56, Umut Tezduyar Lindskog u...@tezduyar.com wrote: On Thu, May 28, 2015 at 1:17 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 27.05.15 13:05, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: On Tue, May 26, 2015 at 4:14 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 26.05.15 11:53, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: Hi, I was wondering if we have a way to provide vendor default masked service? Well, so far our thinking was that if the vendor wants to make a unit completely unavailable he should simply not ship it in the first place. What's the usecase for a vendor masking a unit, but installing it? Why not remove it in the first place entirely? If we ship a product without the service, we don't have a way of installing it again once the product is deployed. Use case would be: We use one software for a video encoder blade with multiple CPUs. Every CPU runs the same software. We have a special service which should only run on the first CPU. A generator installs the .wants link for the service on first CPU. Another service could try to talk to the special service over dbus causing it to be dbus activated (where special service is only allowed to be up on first CPU). We could install the dbus activation files with generator but it gets messy to offload this logic to a generator. Also, special service can be activated by using systemd's dbus interface. My recommendation would be to ship the dbus service file always, but make it direct to SystemdService=dbus-com.axis.foobar.waldi.service, and then manage dbus-com.axis.foobar.waldi.service as a symlink alias to the real bus service. All you do in your generator now is create the symlink or not create it... Wouldn't that work? For dbus activation it would work but other services can still activate the service through systemd. it will attempt to dbus activate non-existing service file since there wouldn't be a symlink with a name dbus-com.axis.foobar.waldi.service pointing to anything real, and thus effectively masked, no?! Nope. They can call StartUnit (org.freedesktop.systemd1, /org/freedesktop/systemd1) or systemctl start. Umut -- 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 v3] systemctl: drop hardcoded chkconfig invocation
Lennart Poettering [2015-05-28 13:05 +0200]:
Nah, please remove this part. We should not ship that upstream. THis
is something that Fedora's initscripts.rpm should provide eventually,
and should be neither shipped with systemd upstream nor systemd.rpm in
Fedora.
OK, done. I changed it to be an example .SKELETON script in the
source/tarball now, but it's not installed. (Makes it easier for
packagers to adjust).
Also added README/NEWS now.
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From a23a4b6c0e2b156b8902b56eab65eb87c239a073 Mon Sep 17 00:00:00 2001
From: Martin Pitt martin.p...@ubuntu.com
Date: Wed, 27 May 2015 17:04:49 +0200
Subject: [PATCH] systemctl: drop hardcoded chkconfig invocation
Introduce /usr/lib/systemd/systemd-sysv-install [--root=] action name
abstraction, replacing the direct calling of chkconfig. This allows
distributions to call their specific tools like update-rc.d without patching
systemd.
Ship systemd-sysv-install.SKELETON as an example for packagers how to implement
this.
Drop the --enable-chkconfig configure option.
Document this in README and point to it in NEWS.
---
Makefile.am | 1 +
NEWS| 11 +++
README | 11 +++
configure.ac| 20
src/systemctl/systemctl.c | 11 +++
src/systemctl/systemd-sysv-install.SKELETON | 47 +
6 files changed, 75 insertions(+), 26 deletions(-)
create mode 100755 src/systemctl/systemd-sysv-install.SKELETON
diff --git a/Makefile.am b/Makefile.am
index d6010c5..b7d0add 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -627,6 +627,7 @@ systemgenerator_PROGRAMS += \
endif
EXTRA_DIST += \
+ src/systemctl/systemd-sysv-install.SKELETON \
units/rc-local.service.in \
units/halt-local.service.in
diff --git a/NEWS b/NEWS
index ee533b4..2e2d1ce 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,16 @@
systemd System and Service Manager
+CHANGES WITH 221:
+
+* Support for chkconfig (--enable-chkconfig) was removed in favour of
+ calling an abstraction /lib/systemd/systemd-sysv-install. This needs
+ to be implemented for your distribution. See SYSV INIT.D SCRIPTS in
+ README for details.
+
+Contributions from: ...
+
+-- Berlin, UNRELEASED
+
CHANGES WITH 220:
* The gudev library has been extracted into a separate repository
diff --git a/README b/README
index 2b8c68e..2be3972 100644
--- a/README
+++ b/README
@@ -222,6 +222,17 @@ NSS:
hosts: files mymachines resolve myhostname
+SYSV INIT.D SCRIPTS:
+When calling systemctl enable/disable/is-enabled on a unit which is a
+SysV init.d script, it calls /usr/lib/systemd/systemd-sysv-install;
+this needs to translate the action into the distribution specific
+mechanism such as chkconfig or update-rc.d. Packagers need to provide
+this script if you need this functionality (you don't if you disabled
+SysV init support).
+
+Please see src/systemctl/systemd-sysv-install.SKELETON for how this
+needs to look like, and provide an implementation at the marked places.
+
WARNINGS:
systemd will warn you during boot if /etc/mtab is not a
symlink to /proc/mounts. Please ensure that /etc/mtab is a
diff --git a/configure.ac b/configure.ac
index 0818dd8..e46ca45 100644
--- a/configure.ac
+++ b/configure.ac
@@ -491,25 +491,6 @@ if test x${have_ima} != xno ; then
fi
# --
-have_chkconfig=yes
-AC_ARG_ENABLE([chkconfig], AS_HELP_STRING([--disable-chkconfig],[Disable optional chkconfig support]),
-[case ${enableval} in
-yes) have_chkconfig=yes ;;
-no) have_chkconfig=no ;;
-*) AC_MSG_ERROR(bad value ${enableval} for --disable-chkconfig) ;;
-esac],
-[AC_PATH_PROG(CHKCONFIG, chkconfig)
-if test -z $CHKCONFIG; then
-have_chkconfig=no
-else
-have_chkconfig=yes
-fi])
-
-if test x${have_chkconfig} != xno ; then
-AC_DEFINE(HAVE_CHKCONFIG, 1, [Define if CHKCONFIG is available])
-fi
-
-# --
have_selinux=no
AC_ARG_ENABLE(selinux, AS_HELP_STRING([--disable-selinux], [Disable optional SELINUX support]))
if test x$enable_selinux != xno; then
@@ -1541,7 +1522,6 @@ AC_MSG_RESULT([
GCRYPT: ${have_gcrypt}
QRENCODE:${have_qrencode}
MICROHTTPD: ${have_microhttpd}
-CHKCONFIG: ${have_chkconfig}
GNUTLS:
[systemd-devel] [PATCH v2] udev: input_id: fix detection of various touchscreens
There are touch screens that do not provide 'BTN_TOUCH' and hence no
'EV_KEY'. Previously those would not get any properties assigned and
libinput would not treat those as input devices. Additionally there
is an 'IS_DIRECT' property exposed by most touch screens, that would
otherwise be detected as touch pads.
---
src/udev/udev-builtin-input_id.c | 145 +--
1 file changed, 80 insertions(+), 65 deletions(-)
diff --git a/src/udev/udev-builtin-input_id.c b/src/udev/udev-builtin-input_id.c
index b14190e..a4cafa0 100644
--- a/src/udev/udev-builtin-input_id.c
+++ b/src/udev/udev-builtin-input_id.c
@@ -133,79 +133,94 @@ 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)) {
-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)) {
+bool is_mouse = false;
+bool is_touchpad = false;
+bool is_direct = false;
+bool has_coordinates = false;
+bool has_mt_coordinates = false;
+bool has_joystick_axes_or_buttons = false;
+bool has_touch = false;
+bool stylus_or_pen = false;
+bool finger_but_no_pen = false;
+bool has_mouse = false;
+bool is_touchscreen = false;
+bool is_tablet = false;
+bool is_joystick = false;
+bool is_accelerometer = false;
+bool is_pointing_stick= false;
+bool has_3d_coordinates = false;
+bool has_keys = false;
+
+has_keys = test_bit(EV_KEY, bitmask_ev);
+has_touch = test_bit(BTN_TOUCH, bitmask_key);
+has_mouse = test_bit(BTN_MOUSE, bitmask_key);
+has_coordinates = test_bit(ABS_X, bitmask_abs) test_bit(ABS_Y,
bitmask_abs);
+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);
+is_direct = test_bit(INPUT_PROP_DIRECT, bitmask_props);
+is_accelerometer = test_bit(INPUT_PROP_ACCELEROMETER, bitmask_props);
+is_pointing_stick = test_bit(INPUT_PROP_POINTING_STICK, bitmask_props);
+stylus_or_pen = test_bit(BTN_STYLUS, bitmask_key) ||
+test_bit(BTN_STYLUS2, 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);
+/* joysticks don't necessarily have to 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_coordinates) {
+if (stylus_or_pen)
+is_tablet = true;
+else if (!is_direct finger_but_no_pen)
+is_touchpad = true;
+else if (has_mouse)
/* This path is taken by VMware's USB mouse, which has
* absolute axes, but no touch/pressure button. */
-is_mouse = 1;
-} else if
Re: [systemd-devel] [PATCH 9/9] man: Document \: escapes in nspawn's --overlay option
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1432814535-9841-10-git-send-email-richard.maw%40codethink.co.uk -- 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] udev: input_id: fix detection of various touchscreens
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1432817255-9423-1-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] [PATCH v3] systemctl: drop hardcoded chkconfig invocation
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:20150528130208.GJ3335%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
[systemd-devel] [PATCH 1/9] util: Add unescape_first_word()
This is a superset of the functionality of unquote_first_word, allowing
non-whitespace separators, and doesn't interpret quotes unless
UNQUOTE_QUOTES is included in flags.
This also adds UNQUOTE_SEPARATOR_SPLIT, which has it return multiple
empty strings when there is a span of separator characters.
---
src/shared/util.c | 35 +--
src/shared/util.h | 7 +--
2 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/src/shared/util.c b/src/shared/util.c
index 74a2190..468b5ab 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -5344,7 +5344,7 @@ int is_device_node(const char *path) {
return !!(S_ISBLK(info.st_mode) || S_ISCHR(info.st_mode));
}
-int unquote_first_word(const char **p, char **ret, UnquoteFlags flags) {
+int unescape_first_word(const char **p, char **ret, const char *separators,
UnquoteFlags flags) {
_cleanup_free_ char *s = NULL;
size_t allocated = 0, sz = 0;
int r;
@@ -5357,7 +5357,7 @@ int unquote_first_word(const char **p, char **ret,
UnquoteFlags flags) {
SINGLE_QUOTE_ESCAPE,
DOUBLE_QUOTE,
DOUBLE_QUOTE_ESCAPE,
-SPACE,
+SEPARATOR,
} state = START;
assert(p);
@@ -5377,8 +5377,14 @@ int unquote_first_word(const char **p, char **ret,
UnquoteFlags flags) {
case START:
if (c == 0)
goto finish;
-else if (strchr(WHITESPACE, c))
+else if (strchr(separators, c)) {
+if (!(flags UNQUOTE_SEPARATOR_SPLIT))
+break;
+if (!GREEDY_REALLOC(s, allocated, sz+1))
+return -ENOMEM;
+state = SEPARATOR;
break;
+}
state = VALUE;
/* fallthrough */
@@ -5386,14 +5392,14 @@ int unquote_first_word(const char **p, char **ret,
UnquoteFlags flags) {
case VALUE:
if (c == 0)
goto finish;
-else if (c == '\'')
+else if (c == '\'' (flags UNQUOTE_QUOTES))
state = SINGLE_QUOTE;
else if (c == '\\')
state = VALUE_ESCAPE;
-else if (c == '\')
+else if (c == '\' (flags UNQUOTE_QUOTES))
state = DOUBLE_QUOTE;
-else if (strchr(WHITESPACE, c))
-state = SPACE;
+else if (strchr(separators, c))
+state = SEPARATOR;
else {
if (!GREEDY_REALLOC(s, allocated, sz+2))
return -ENOMEM;
@@ -5524,12 +5530,17 @@ int unquote_first_word(const char **p, char **ret,
UnquoteFlags flags) {
state = DOUBLE_QUOTE;
break;
-case SPACE:
+case SEPARATOR:
if (c == 0)
goto finish;
-if (!strchr(WHITESPACE, c))
+if (flags UNQUOTE_SEPARATOR_SPLIT) {
+/* Ensure we allocated */
+if (!GREEDY_REALLOC(s, allocated, sz+1))
+return -ENOMEM;
+goto finish;
+}
+if (!strchr(separators, c))
goto finish;
-
break;
}
@@ -5549,6 +5560,10 @@ finish:
return 1;
}
+int unquote_first_word(const char **p, char **ret, UnquoteFlags flags) {
+return unescape_first_word(p, ret, WHITESPACE, flags|UNQUOTE_QUOTES);
+}
+
int unquote_many_words(const char **p, UnquoteFlags flags, ...) {
va_list ap;
char **l;
diff --git a/src/shared/util.h b/src/shared/util.h
index eb35952..dd86ddc 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -855,10 +855,13 @@ int is_dir(const char *path, bool follow);
int is_device_node(const char *path);
typedef enum UnquoteFlags {
-UNQUOTE_RELAX = 1,
-UNQUOTE_CUNESCAPE = 2,
+UNQUOTE_RELAX = 1,
+UNQUOTE_CUNESCAPE = 2,
+UNQUOTE_QUOTES = 3,
+UNQUOTE_SEPARATOR_SPLIT = 4,
} UnquoteFlags;
+int unescape_first_word(const char **p, char **ret, const char *separators,
UnquoteFlags flags);
int unquote_first_word(const char **p, char **ret, UnquoteFlags flags);
int unquote_many_words(const char **p, UnquoteFlags flags, ...) _sentinel_;
[systemd-devel] [PATCH 7/9] nspawn: escape paths in overlay mount options
Overlayfs uses , as an option separator and : as a list separator. These
characters are both valid in file paths, so overlayfs allows file paths
which contain these characters to backslash escape these values.
---
src/nspawn/nspawn.c | 63 +++--
1 file changed, 56 insertions(+), 7 deletions(-)
diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index c40d50f..f7580f9 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -1237,6 +1237,42 @@ static int mount_tmpfs(const char *dest, CustomMount *m)
{
return 0;
}
+static char *escaped_overlay_path(const char *path) {
+_cleanup_free_ char *colon_escaped = NULL;
+char *comma_escaped = NULL;
+
+colon_escaped = strreplace(path, :, \\:);
+if (!colon_escaped)
+return NULL;
+
+comma_escaped = strreplace(colon_escaped, ,, \\,);
+
+return comma_escaped;
+}
+
+static char *joined_and_escaped_lower_dirs(char * const *lower) {
+_cleanup_free_ char *s = NULL;
+char *ret = NULL;
+char * const *path;
+bool first = true;
+
+STRV_FOREACH_BACKWARDS(path, lower) {
+_cleanup_free_ char *escaped_path = NULL;
+escaped_path = escaped_overlay_path(*path);
+if (first) {
+if (!strextend(s, escaped_path, NULL))
+return NULL;
+first = false;
+} else
+if (!strextend(s, :, escaped_path, NULL))
+return NULL;
+}
+
+ret = s;
+s = NULL;
+return ret;
+}
+
static int mount_overlay(const char *dest, CustomMount *m) {
_cleanup_free_ char *lower = NULL;
const char *where, *options;
@@ -1253,19 +1289,32 @@ static int mount_overlay(const char *dest, CustomMount
*m) {
(void) mkdir_p_label(m-source, 0755);
-strv_reverse(m-lower);
-lower = strv_join(m-lower, :);
-strv_reverse(m-lower);
+lower = joined_and_escaped_lower_dirs(m-lower);
if (!lower)
return log_oom();
-if (m-read_only)
-options = strjoina(lowerdir=, m-source, :, lower);
-else {
+if (m-read_only) {
+_cleanup_free_ char *escaped_source = NULL;
+
+escaped_source = escaped_overlay_path(m-source);
+if (!escaped_source)
+return log_oom();
+
+options = strjoina(lowerdir=, escaped_source, :, lower);
+} else {
+_cleanup_free_ char *escaped_source = NULL, *escaped_work_dir
= NULL;
+
assert(m-work_dir);
(void) mkdir_label(m-work_dir, 0700);
-options = strjoina(lowerdir=, lower, ,upperdir=,
m-source, ,workdir=, m-work_dir);
+escaped_source = escaped_overlay_path(m-source);
+if (!escaped_source)
+return log_oom();
+escaped_work_dir = escaped_overlay_path(m-work_dir);
+if (!escaped_work_dir)
+return log_oom();
+
+options = strjoina(lowerdir=, lower, ,upperdir=,
escaped_source, ,workdir=, escaped_work_dir);
}
if (mount(overlay, where, overlay, m-read_only ? MS_RDONLY : 0,
options) 0)
--
1.9.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 4/9] strv: Add strv_split_escaped
This is to strv_split_quoted as unescape_first_word is to
unquote_first_word.
---
src/shared/strv.c | 8 ++--
src/shared/strv.h | 1 +
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/shared/strv.c b/src/shared/strv.c
index d44a72f..a6c42d4 100644
--- a/src/shared/strv.c
+++ b/src/shared/strv.c
@@ -278,7 +278,7 @@ char **strv_split_newlines(const char *s) {
return l;
}
-int strv_split_quoted(char ***t, const char *s, UnquoteFlags flags) {
+int strv_split_escaped(char ***t, const char *s, const char *separators,
UnquoteFlags flags) {
size_t n = 0, allocated = 0;
_cleanup_strv_free_ char **l = NULL;
int r;
@@ -289,7 +289,7 @@ int strv_split_quoted(char ***t, const char *s,
UnquoteFlags flags) {
for (;;) {
_cleanup_free_ char *word = NULL;
-r = unquote_first_word(s, word, flags);
+r = unescape_first_word(s, word, separators, flags);
if (r 0)
return r;
if (r == 0)
@@ -313,6 +313,10 @@ int strv_split_quoted(char ***t, const char *s,
UnquoteFlags flags) {
return 0;
}
+int strv_split_quoted(char ***t, const char *s, UnquoteFlags flags) {
+return strv_split_escaped(t, s, WHITESPACE, flags|UNQUOTE_QUOTES);
+}
+
char *strv_join(char **l, const char *separator) {
char *r, *e;
char **s;
diff --git a/src/shared/strv.h b/src/shared/strv.h
index 22f8f98..edde2e4 100644
--- a/src/shared/strv.h
+++ b/src/shared/strv.h
@@ -73,6 +73,7 @@ static inline bool strv_isempty(char * const *l) {
char **strv_split(const char *s, const char *separator);
char **strv_split_newlines(const char *s);
+int strv_split_escaped(char ***t, const char *s, const char *separators,
UnquoteFlags flags);
int strv_split_quoted(char ***t, const char *s, UnquoteFlags flags);
char *strv_join(char **l, const char *separator);
--
1.9.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 3/9] man: Document \: escapes in nspawn's --tmpfs option
From: Richard Maw richard@gmail.com --- man/systemd-nspawn.xml | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/man/systemd-nspawn.xml b/man/systemd-nspawn.xml index 06285ed..49f3e13 100644 --- a/man/systemd-nspawn.xml +++ b/man/systemd-nspawn.xml @@ -597,7 +597,10 @@ otherwise specified). This option is particularly useful for mounting directories such as filename/var/filename as tmpfs, to allow state-less systems, in particular when -combined with option--read-only/option./para/listitem +combined with option--read-only/option. +Backslash escapes are interpreted in the path so +literal\:/literal may be used to embed colons in the path. +/para/listitem /varlistentry varlistentry -- 1.9.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 6/9] man: Document \: escapes in nspawn's --bind option
From: Richard Maw richard@gmail.com --- man/systemd-nspawn.xml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/man/systemd-nspawn.xml b/man/systemd-nspawn.xml index 49f3e13..ffb513d 100644 --- a/man/systemd-nspawn.xml +++ b/man/systemd-nspawn.xml @@ -578,7 +578,9 @@ same path in the container --, or a colon-separated pair of paths -- in which case the first specified path is the source in the host, and the second path is the destination in the -container. This option may be specified multiple times for +container. Backslash escapes are interpreted so +literal\:/literal may be used to embed colons in either path. +This option may be specified multiple times for creating multiple independent bind mount points. The option--bind-ro=/option option creates read-only bind mounts./para/listitem -- 1.9.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 0/9] Allow \: escapes in nspawn command line
File paths may contain : characters, and the nspawn command-line argument parser had no way of being able to tell which were part of the paths, or used to separate paths. This is fixable by introducing an escaping mechanism. The --overlay option had a related problem, as it would still fail if the paths contained : characters or , characters, as they are used as path separators for the lowerdir union, and as the option separator. In this case overlayfs has an escaping mechanism, so we just needed to escape the paths correctly. This re-uses the existing escaping and parsing logic as much as possible. I couldn't find anything that was an exact fit, but unquote_first_word was the closest, so I extended the flags a bit and added a variant that accepted a set of separator characters, rather than always using whitespace. I've been running these patches on my system for a day, and tested that I could nspawn a system using the changed arguments, but I couldn't get the test suite to run, so I may have missed something. Richard Maw (9): util: Add unescape_first_word() nspawn: Allow : characters in --tmpfs path man: Document \: escapes in nspawn's --tmpfs option strv: Add strv_split_escaped nspawn: Allow : characters in nspawn --bind paths man: Document \: escapes in nspawn's --bind option nspawn: escape paths in overlay mount options nspawn: Allow : characters in overlay paths man: Document \: escapes in nspawn's --overlay option man/systemd-nspawn.xml | 13 +- src/nspawn/nspawn.c| 119 ++--- src/shared/strv.c | 8 +++- src/shared/strv.h | 1 + src/shared/util.c | 35 ++- src/shared/util.h | 7 ++- 6 files changed, 142 insertions(+), 41 deletions(-) -- 1.9.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/9] nspawn: Allow : characters in --tmpfs path
This now accepts : characters with the \: escape sequence.
Other escape sequences are also interpreted, but having a \ in your file
path is less likely than :, so this shouldn't break anyone's existing
tools.
---
src/nspawn/nspawn.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index 23bb959..97f980f 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -687,18 +687,21 @@ static int parse_argv(int argc, char *argv[]) {
}
case ARG_TMPFS: {
+const char *current = optarg;
_cleanup_free_ char *path = NULL, *opts = NULL;
CustomMount *m;
-char *e;
-e = strchr(optarg, ':');
-if (e) {
-path = strndup(optarg, e - optarg);
-opts = strdup(e + 1);
-} else {
-path = strdup(optarg);
-opts = strdup(mode=0755);
+r = unescape_first_word(current, path, :,
UNQUOTE_SEPARATOR_SPLIT);
+if (r == -ENOMEM)
+return log_oom();
+else if (r 0) {
+log_error(Invalid tmpfs specification: %s,
optarg);
+return r;
}
+if (r)
+opts = strdup(current);
+else
+opts = strdup(mode=0755);
if (!path || !opts)
return log_oom();
--
1.9.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 9/9] man: Document \: escapes in nspawn's --overlay option
From: Richard Maw richard@gmail.com --- man/systemd-nspawn.xml | 4 1 file changed, 4 insertions(+) diff --git a/man/systemd-nspawn.xml b/man/systemd-nspawn.xml index ffb513d..4e2e582 100644 --- a/man/systemd-nspawn.xml +++ b/man/systemd-nspawn.xml @@ -614,6 +614,10 @@ list of colon-separated paths to the directory trees to combine and the destination mount point./para +paraBackslash escapes are interpreted in the paths, so +literal\:/literal may be used to embed colons in the paths. +/para + paraIf three or more paths are specified, then the last specified path is the destination mount point in the container, all paths specified before refer to directory trees -- 1.9.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 8/9] nspawn: Allow : characters in overlay paths
: characters can be entered with the \: escape sequence.
---
src/nspawn/nspawn.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index f7580f9..bace72e 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -744,9 +744,13 @@ static int parse_argv(int argc, char *argv[]) {
unsigned n = 0;
char **i;
-lower = strv_split(optarg, :);
-if (!lower)
+r = strv_split_escaped(lower, optarg, :,
UNQUOTE_SEPARATOR_SPLIT);
+if (r == -ENOMEM)
return log_oom();
+else if (r 0) {
+log_error(Invalid overlay specification: %s,
optarg);
+return r;
+}
STRV_FOREACH(i, lower) {
if (!path_is_absolute(*i)) {
--
1.9.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 0/9] Allow \: escapes in nspawn command line
On Thu, May 28, 2015 at 2:02 PM, Richard Maw richard@codethink.co.uk wrote: File paths may contain : characters, and the nspawn command-line argument parser had no way of being able to tell which were part of the paths, or used to separate paths. This is fixable by introducing an escaping mechanism. The --overlay option had a related problem, as it would still fail if the paths contained : characters or , characters, as they are used as path separators for the lowerdir union, and as the option separator. In this case overlayfs has an escaping mechanism, so we just needed to escape the paths correctly. This re-uses the existing escaping and parsing logic as much as possible. I couldn't find anything that was an exact fit, but unquote_first_word was the closest, so I extended the flags a bit and added a variant that accepted a set of separator characters, rather than always using whitespace. I've been running these patches on my system for a day, and tested that I could nspawn a system using the changed arguments, but I couldn't get the test suite to run, so I may have missed something. Hi, Apart from the test suite there is also all the unit tests, it would be great if you could add unit tests for unescape_first_word and strv_split_escaped functions (src/test/test-unit.c and src/test/test-strv.c). Thanks Richard Maw (9): util: Add unescape_first_word() nspawn: Allow : characters in --tmpfs path man: Document \: escapes in nspawn's --tmpfs option strv: Add strv_split_escaped nspawn: Allow : characters in nspawn --bind paths man: Document \: escapes in nspawn's --bind option nspawn: escape paths in overlay mount options nspawn: Allow : characters in overlay paths man: Document \: escapes in nspawn's --overlay option man/systemd-nspawn.xml | 13 +- src/nspawn/nspawn.c| 119 ++--- src/shared/strv.c | 8 +++- src/shared/strv.h | 1 + src/shared/util.c | 35 ++- src/shared/util.h | 7 ++- 6 files changed, 142 insertions(+), 41 deletions(-) -- 1.9.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v3] systemctl: Don't skip SysV init.d scripts when enabling/disabling units
Hello again,
Lennart Poettering [2015-05-28 13:31 +0200]:
Hmm? THis sounds the wrong way round. What currently happens should be
this: if both are available systemd ignores the sysv script, and only
considers the native unit. Is that what you are trying to say?
Err yes, sorry. Adjusted the patch description.
And you now want everything to be applied to both the sysv script and
the native unit?
Right, so that you keep the sysv init script and unit in sync, instead
of enabling one and disabling the other.
What happens if we query the state of things with is-enabled, then?
Good point, thanks for spotting; fixed. We didn't have that problem in
our original patch as is-enabled didn't work; curiously, with the new
systemd-sysv-install wrapper we can now implement is-enabled trivially
:-) ).
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From 528c97ef47c59ea65c897eacd04b39a12d2113ae Mon Sep 17 00:00:00 2001
From: Martin Pitt martin.p...@ubuntu.com
Date: Wed, 27 May 2015 14:52:17 +0200
Subject: [PATCH 2/2] systemctl: Don't skip SysV init.d scripts when
enabling/disabling units
If there is both a SysV init.d script and a systemd unit for a given name, we
want to do the same enable/disable operation for both, instead of just on the
systemd unit. This keeps the enablement status in sync so that switching init
systems behaves as expected.
---
src/systemctl/systemctl.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index f0ba83d..897248a 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -5149,7 +5149,10 @@ static int enable_sysv_units(const char *verb, char **args) {
break;
}
-if (found_native)
+/* If we have both a native unit and a SysV script,
+ * enable/disable them both (below); for is-enabled, prefer the
+ * native unit */
+if (found_native streq(verb, is-enabled))
continue;
p = path_join(arg_root, SYSTEM_SYSVINIT_PATH, name);
@@ -5161,7 +5164,10 @@ static int enable_sysv_units(const char *verb, char **args) {
if (!found_sysv)
continue;
-log_info(%s is not a native service, redirecting to systemd-sysv-install, name);
+if (found_native)
+log_info(Synchronizing state of %s with SysV init with %s..., name, argv[0]);
+else
+log_info(%s is not a native service, redirecting to systemd-sysv-install, name);
if (!isempty(arg_root))
argv[c++] = q = strappend(--root=, arg_root);
@@ -5209,6 +5215,9 @@ static int enable_sysv_units(const char *verb, char **args) {
} else
return -EPROTO;
+if (found_native)
+continue;
+
/* Remove this entry, so that we don't try enabling it as native unit */
assert(f 0);
f--;
--
2.1.4
signature.asc
Description: Digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix systemd.resource-control(5) volume number.
On Wed, May 27, 2015 at 5:38 PM, Tom Gundersen t...@jklm.no wrote: On Wed, May 27, 2015 at 9:47 PM, Patrick Donnelly batr...@batbytes.com wrote: Signed-off-by: Patrick Donnelly batr...@batbytes.com We don't use s-o-b in systemd, so dropped this when applying. Also adjusted the subject line a bit (for future reference). Thanks for the patch! Pushed. I looked around on the website/repo and didn't see a document on submitting patches and/or commit message styling. Did I miss it or perhaps it should be written? -- Patrick Donnelly ___ 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 Thu, May 28, 2015 at 10:10 AM, 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. I've created a bug https://bugzilla.redhat.com/show_bug.cgi?id=1178181 on this issue. After some discovering I found that the reason of this issue is that anaconda brakes lvm: before launching anaconda pvdisplay reports there are two physical volumes /dev/md126p2 and /dev/sdc2 (/dev/sdc is an SSD that does not belong any raid and contains a separate lvm volume group) after launching anaconda pvdisplay reports another two physical volumes /dev/sdb2 and /dev/sdc2, that is wrong, because /dev/sdb is a part of /dev/md126 raid. journalctl shows: May 28 02:44:08 localhost systemd[1]: Stopping LVM2 PV scan on device 259:1... May 28 02:44:08 localhost systemd[1]: Stopped LVM2 PV scan on device 259:1. May 28 02:44:08 localhost audit[1]: audit-1131 pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=lvm2-pvscan@259:1 comm=systemd exe=/usr/lib/systemd/systemd hostname=? addr=? terminal=? res=success' May 28 02:44:09 localhost kernel: sde: May 28 02:44:09 localhost kernel: sda: sda1 sda2 May 28 02:44:09 localhost systemd[1]: Starting LVM2 PV scan on device 8:2... May 28 02:44:09 localhost kernel: sdb: sdb1 sdb2 Seems lvm stops using /dev/md126p2 and starts using /dev/sdb2 at this moment I can see in anaconda program.log that it ran 'udevadm settle' at this moment: 02:44:07,141 INFO program: ...done [9] (exit code: 0) 02:44:09,290 INFO program: Running... udevadm settle --timeout=300 02:44:09,305 DEBUG program: Return code: 0 02:44:09,306 INFO program: Running... udevadm settle --timeout=300 02:44:09,315 DEBUG program: Return code: 0 So 'udevadm settle' breaks lvm from using '/dev/md126p2'. Futher lvm rescans force it to use /dev/sdb2 instead. The attached storage.log contains a trace of udev events of this. All other logs are available in https://bugzilla.redhat.com/show_bug.cgi?id=1178181 What is wrong? How to force lvm to use /dev/md126p2 instead of /dev/sdb2 after starting anaconda? This seems unlikely to be udevadm settle's fault. All it does is wait for udev to process events, you may think of it as sleep 5 or something like that. It can obviously affect the timing of things, but as Lennart said the underlying problem is surely elsewhere... Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] systemctl: Don't skip native units when enabling/disabling SysV init.d scripts
On 05/27/2015 04:00 PM, Lennart Poettering wrote: On Wed, 27.05.15 13:39, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 05/27/2015 01:07 PM, Martin Pitt wrote: Hello, as discussed in the get some distro patches upstream thread, this is the generalization for supporting different chkconfig/update-rc.d/whatnot distro implementations of enabling init.d scripts, as per LSB specification. Is this not something that downstream should be carrying tailored to what init implementation what was used in the past and or is shipped in the present, ( Debian for example ships/supports multiple init systems ) and the support for this dropped upstream? Well, I think it's too early for that. 3rd party software tends to be written for LSB. Also, Debian/Ubuntu only very recently switched to sytemd. Out of fairness we owe them to support the old stuff natively for a while, the same way we benefitted from that during the fedora transition. Last time I checked Debian shipped the most initscripts of the distributions roughly half more then we do in Fedora ( ca 1200 components ). Now if we put aside Debians support for multiple initsystem which makes it more likely that they prefer using generators instead of actually migrate components and we subtract the collaborated migration effort done by us systemd integrators that resided in distributions community that we did together for what past 4 or five years, it will leave ca 600 components for Debian to migrate and they will do so in roughly the same time frame as we all did collectively I would expect. Add to that the long discussion, approval period in Debian's community before that work would actually start to happen, we are talking about supporting this for 5 - 7 years more ( unless something is done here , upstream to nudge it's completion sooner ). 3rd party software will not migrate until they have to that is a fact ( and distributions and upstream cannot wait for something they have absolutely no control over which is another fact ). Also, there are still ~100 sysv scripts in fedora too... I'm perfectly aware the status on unmigrated components along with other systemd integration and cleanup work has not progressed since I stopped leading and doing that in Fedora and now that has started to hinder other work ( as I had expected would happen ) but this is what some of your coworkers wanted and this is precisely what they got with the associated cost of their behavior and decision(s) which ultimately will cost Red Hat more in work,money and delays of it's upcoming RHEL release(s) There was an FESCo discussion dropping all the 100 - 150 components that had not been migrated in F23 with Adam Jackson valiantly assigning an task to himself and trying migrated what he could up to that point ( kudos to him for that. I have not seen that spirit in FESCo member since what FC5/6 ) I just dont think he realized how much amount of work that was nor how distracting it would become from his other work/upstream obligations not that I have checked but I expect that he has abandoned that work by now or it's progressing very very slowly. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Vendor default masked service
On Thu, 28.05.15 13:56, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: On Thu, May 28, 2015 at 1:17 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 27.05.15 13:05, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: On Tue, May 26, 2015 at 4:14 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 26.05.15 11:53, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: Hi, I was wondering if we have a way to provide vendor default masked service? Well, so far our thinking was that if the vendor wants to make a unit completely unavailable he should simply not ship it in the first place. What's the usecase for a vendor masking a unit, but installing it? Why not remove it in the first place entirely? If we ship a product without the service, we don't have a way of installing it again once the product is deployed. Use case would be: We use one software for a video encoder blade with multiple CPUs. Every CPU runs the same software. We have a special service which should only run on the first CPU. A generator installs the .wants link for the service on first CPU. Another service could try to talk to the special service over dbus causing it to be dbus activated (where special service is only allowed to be up on first CPU). We could install the dbus activation files with generator but it gets messy to offload this logic to a generator. Also, special service can be activated by using systemd's dbus interface. My recommendation would be to ship the dbus service file always, but make it direct to SystemdService=dbus-com.axis.foobar.waldi.service, and then manage dbus-com.axis.foobar.waldi.service as a symlink alias to the real bus service. All you do in your generator now is create the symlink or not create it... Wouldn't that work? For dbus activation it would work but other services can still activate the service through systemd. But why is that a problem? If daemons explicitly request another service by invoking StartUnit() via the bus, why block this off in your usecase? I can understand you don't want implicit activation via socket, boot, bus but that's all easily managable via systemctl disable and systemctl enable. What am I 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] systemd-networkd and openvswitch?
Hi Richard, thanks for your insights. In the mean time, I was successful in bridging an VLAN trunk to a VM with the native linux bridge, and thus do not need Openvswich in my project any more. Your mail will be helpful to others in the future. ftr, one needs to define the VLANs on the hosts as well, and the VLAN definition needs to be on the _bridge_, not the ethernet. I guess that the Linux bridge code uses the VLANs defined on the bridge as kind of VLAN filter for the poor. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ 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.
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1432827774-10868-1-git-send-email-dimitri.j.ledkov%40intel.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] cgroup-util: fix is_valid check to pass for unified cgroup hierchy.
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1432827559-10445-1-git-send-email-dimitri.j.ledkov%40intel.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] 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 | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/shared/cgroup-util.c b/src/shared/cgroup-util.c
index c0b0ca4..eda7523 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..e4c3432 100644
--- a/src/test/test-cgroup-util.c
+++ b/src/test/test-cgroup-util.c
@@ -247,7 +247,7 @@ 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(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
[systemd-devel] [PATCH v2] cgroup-util: fix is_valid check to pass for unified cgroup hierchy.
It appears in /proc/self/cgroup as `0::/'
---
v2 change: Test for unified cgroup should pass irrespective of
whether allow_named is set.
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 c0b0ca4..eda7523 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
Re: [systemd-devel] [PATCH 1/9] util: Add unescape_first_word()
On Thu, May 28, 2015 at 01:02:07PM +0100, Richard Maw wrote:
diff --git a/src/shared/util.h b/src/shared/util.h
index eb35952..dd86ddc 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -855,10 +855,13 @@ int is_dir(const char *path, bool follow);
int is_device_node(const char *path);
typedef enum UnquoteFlags {
-UNQUOTE_RELAX = 1,
-UNQUOTE_CUNESCAPE = 2,
+UNQUOTE_RELAX = 1,
+UNQUOTE_CUNESCAPE = 2,
+UNQUOTE_QUOTES = 3,
+UNQUOTE_SEPARATOR_SPLIT = 4,
} UnquoteFlags;
Thanks to Ronny pointing out how to run the test suite, I have determined that
this causes every use of unquote to attempt to unescape and relax the rules for
unpaired quotes.
I'll fix this up and extend the test suite with the new features.
___
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 Wed, 27.05.15 15:59, Mario Limonciello (mario_limoncie...@dell.com) wrote: Hi, Some Alienware notebooks and desktops support an external graphics housing called the Alienware Graphics Amplifier. It allows the usage of a larger or more modern graphics card than your gaming PC would already support. In order to provide a good experience, systems that support it can provide notification to the OS via the scancodes on the the keyboard controller of events related to the cable. The following 4 events are supported (and the presumed OS response): * Cable plugged in (An app on the existing display or terminal would tell the user to reboot the system to activate) * Undock cable pressed (An app would let the user know to reboot the system to complete undock process; also when supported by GFX driver, driver can clean up and work without a reboot) * Undock hotkey pressed (Same result as undock cable expected) * Surprise removal of cable (System immediately reboots). The first three events I think it would make sense to assign to a keycode that a userspace application in X land can pickup and recognize, but I'm at a loss what makes most sense (prog1, prog2, prog3 maybe?). This userspace application hasn't yet been made or decided, I just want to pave the path for it first. The fourth event I'm submitting a kernel patch (https://lkml.org/lkml/2015/5/27/817) so that the kernel would issue a reboot when this was detected, so I believe it would make sense to mark it 'unknown' in systemd. Also, these don't show up in xev output, but they do show up in evtest. Can I get some advice on these? I'll gladly submit a bug with a patch afterward. 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 -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
