Re: [systemd-devel] Udev rules hardware database
On Fri, 2014-11-07 at 08:26 +0100, Martin Pitt wrote:
Patrick Häcker [2014-11-05 16:55 +0100]:
I you want to have permanent power saving activated for your devices, the
recommended way is to use udev (e.g.
https://wiki.archlinux.org/index.php/Power_saving#USB_autosuspend). Some
[...]
- Is there already something like this?
By coincidence I recently noticed something interesting in sysfs: My
USB devices seem to have an attribute supports_autosuspend. These
They are from the kernel and tell you that the drivers for the devices
support autosuspend. It says nothing about the device itself.
are all 1 except for my USB webcam [1] where it is 0. This sounds very
promising indeed! So apparently the kernel now already grew either a
heuristics or some black/whitelists?
Nothing of this sort. It is a pure driver thing and only the negative
is to be taken at face value.
At least the current state how Linux (3.16.0) and udev (215) configure
autosuspend seems a bit weird:
- Some of my USB devices have power/autosuspend == 2: internal
laptop webcam, USB webcam ([1] again), USB Keyboard, USB mouse.
2 is the kernel's default for the general case.
All others have 0. There is no udev rule or other thing on my
system to set those, so unless it's udev or systemd itself I guess
it's from the kernel.
Drivers in the kernel can change it with
pm_runtime_set_autosuspend_delay()
- Most of my USB devices have power/level==auto (i. e. suspend
enabled), only some of them are on (i. e. suspend disabled).
Curiously those which are on are three of above devices where
autosuspend==2: USB webcam, USB Keyboard, USB mouse.
Again drivers can enable it with usb_enable_autosuspend()
This can not be done for HID devices, because for most mice
remote wakeup isn't usable in the generic case.
- The only udev rule which I'm aware of that does autosuspend is
42-usb-hid-pm.rules:
ACTION==add, SUBSYSTEM==usb, ATTR{bInterfaceClass}==03,
ATTRS{removable}==fixed, TEST==../power/control,
ATTR{../power/control}=auto
So it does not seem to be the case that we don't currently enable
autosuspend at all, but it's currently highly inconsistant and
confusing.
It is inconsistent. That is at least partially to the inability to find
general rules.
Regards
Oliver
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] remote-fs ordering, iSCSI and _netdev
On Thu, Nov 06, 2014 at 09:10:51PM -0800, Chris Leech wrote: Not sure, maybe it's possible to detect this by scsi info in /sys. I took a look at what lsscsi is doing to guess at transport type. iSCSI is kind of ugly, FCoE is really ugly, and for both of those there exists a variety of drivers with varying levels of dependence on the networking layer. It would be nice to work on getting some of the more common works working automatically, but _netdev seems like a nice failsafe. BTW, in lsblk(8) we have TRANS column (lsblk -S, function get_transport()) to report scsi transport type and it uses /sys, but I have no clue how reliable it's. Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shared/install: don't report 'static' when unit contains only Also=
Lennart Poettering lenn...@poettering.net writes: On Thu, 06.11.14 10:49, Jan Synacek (jsyna...@redhat.com) wrote: I think that this patch might be a bit ineffective, as it calls unit_file_load() again just to get an InstallContext. I wasn't sure how to get Also= targets in any other way. If such change makes sense, this patch should probably be considered a preview rather than something to be committed right away. Hmm, wouldn't it be nicer to introduce a new UnitFileState enum value for this? Maybe UNIT_FILE_ALSO or so? I am not sure I like the idea of implicitly following the Also= setting here, due to the awkwarndess if multiple units are listed and how to map exotic states of that other unit back to ours... Would that make sense? Lennart Yes, that makes sense. What should a string representation of UNIT_FILE_ALSO be? I don't think that reporting 'also' would feel right. Also, is there a better way to find out if unit has any Also= targets than how I did it? 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
[systemd-devel] Unexpecte behavior for timer with OnActiveSec
Hi, We need to switch to a different target after 30 min of starting that target. Switching happens with isolate. So we have a timer with OnActiveSec=30min witch starts a service that calls systemctl isolate other.target This works like a charm... the first time the target is activated. The second time we start that target nothing happens after 30 min. After some manual testing I can conclude that a timer with OnActiveSec set will stay in elapsed state even after the timer has been restarted or stopped and then started. This is not what I expect. Also there seems to be no way to reset it to the waiting/running state except for the following procedure: systemctl daemon-reload systemctl restart timer.timer Is this expected behavior or a bug? Best regards, Hiram van Paassen Power Products, LLC Email Notice This message is intended only for the use of the Addressee and may contain information that is PRIVILEGED and/or CONFIDENTIAL. This email is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this email is not an intended recipient, you have received this email in error and any review, dissemination, distribution or copying is strictly prohibited. If you have received this email in error, please notify the sender immediately by return mail and permanently delete the copy you received. Thank you. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] manager: Ensure user's systemd runtime directory exists.
Lennart Poettering wrote on 07/11/14 01:06: On Wed, 05.11.14 14:51, Colin Guthrie (gm...@colin.guthr.ie) wrote: Colin Guthrie wrote on 03/11/14 08:02: Zbigniew Jędrzejewski-Szmek wrote on 02/11/14 18:18: On Sun, Nov 02, 2014 at 02:04:20PM +, Colin Guthrie wrote: This mirrors code in dbus.c when creating the private socket and avoids error messages like: systemd[1353]: bind(/run/user/603/systemd/notify) failed: No such file or directory systemd[1353]: Failed to fully start up daemon: No such file or directory Seems reasonable. But why not move the mkdir_parent_label() to the shared code path? Even if the dir is created elsewhere, it seems cleaner to ensure here that it is available. Well, to be honest, I just copied the structure from dbus.c. I can easily do as you suggest in both places if you think it's nicer. I guess this would add two unnecessary stat()s (at least - not looked at the mkdir... implementation!) on boot however, so might just be better leaving it as is (not that that is a real problem practically speaking, especially in tmpfs!). Just pushed as is for now. I'm sure any moving of mkdir*() to common code path can come later (both here and in dbus.c) if it's deemed more readable and doesn't have a negative impact on performance (I'd expect it to be negligible, but I'm not an embedded guy) It's not an inner loop. We it is usually called exactly once. We do not optimize such cases for individual syscalls. Stuff that ends up in inner loops is something to optimize, possibly. Anyway, I moved the mkdir now to the common path. Not that it really matters, but more because I wanted to cast the result to (void), in order to make sure Coverity doesn't trip up over us ignoring the return value from mkdir(). And while I was at it... Cool, as I mentioned in the thread, you likely want to make a similar change in src/core/dbus.c too when creating the private socket (and the dir to hold it). If nothing else you'll want the (void) cast on mkdir call. There may be other reasons to leave it as it is tho', so I don't want to assume too much and make the change myself in case there are subtleties that are beyond me this early in the morning! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Shutdown problems
Am 2014-11-07 04:07, schrieb Nikolaus Rath: $ cat /lib/systemd/system-shutdown/debug.sh #!/bin/sh exec /shutdown.log exec 21 mount -o remount,rw / Well, you need to mount / rewrite *before* redirecting output into a file. Try putting the 'mount -o remount,rw /' line to the top of the script and try again. Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd user service when x is started
I am starting my user services with systemctl --user as possible as I can. I log in my session on VT with startx. I thus defined a first target, called console.target, for services than do not need X (dbus,urxvtd, ssh-agent, gpg-agent, tmux). The default.target is symlinked to it. Unfortunately, I am unable to start my X session with a systemd service file, see [1] My plan is to use after X is started a second target, let's call it wm.target, with all services relevant to the X session. For now, I have no idea how to define After= It can't be right after the console.target as X need to be started first. Until I solve the start of X with a service file, I am looking for a solution to be able to use the wm.target even if there is no any xorg.target after first one (console.target). Thank you for any suggestion [1]http://lists.freedesktop.org/archives/systemd-devel/2014-November/024862.html -- google.com/+arnaudgabourygabx ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Expected behavior when systemd cannot load SELinux policy
Hello, currently, when SELINUX=enforcing and SELINUXTYPE=invalid value are set in /etc/selinux/config, systemd refuses to boot with Failed to load SELinux policy. Freezing. Is this really what should happen? If SELINUX is set to permissive or disabled, though, systemd happily continues booting. I think that that's what should happen when SELINUX is set to enforcing as well. Plus a big warning in the log, or maybe even on the console, of course. What do you think? 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
[systemd-devel] [PATCH 1/3] cryptsetup-generator: Split main() into more functions and use hasmaps
---
man/systemd-cryptsetup-generator.xml | 9 +-
src/cryptsetup/cryptsetup-generator.c | 380 +-
2 files changed, 199 insertions(+), 190 deletions(-)
diff --git a/man/systemd-cryptsetup-generator.xml
b/man/systemd-cryptsetup-generator.xml
index 3abb39d..ff94e88 100644
--- a/man/systemd-cryptsetup-generator.xml
+++ b/man/systemd-cryptsetup-generator.xml
@@ -120,7 +120,7 @@
activate the specified device as part
of the boot process as if it was
listed in
-filename/etc/fstab/filename. This
+filename/etc/crypttab/filename. This
option may be specified more than once
in order to set up multiple
devices. varnamerd.luks.uuid=/varname
@@ -130,9 +130,10 @@
honored by both the main system and
the initrd./para
paraIf /etc/crypttab contains entries with
-the same UUID, then the options for this entry
-will be used./para
-paraIf /etc/crypttab exists, only those UUID
+the same UUID, then the name, keyfile and
options
+specified there will be used. Otherwise the
device
+will have the name
literalluks-UUID/literal./para
+paraIf /etc/crypttab exists, only those UUIDs
specified on the kernel command line
will be activated in the initrd or the real
root./para
/listitem
diff --git a/src/cryptsetup/cryptsetup-generator.c
b/src/cryptsetup/cryptsetup-generator.c
index 7c79ca3..185c03c 100644
--- a/src/cryptsetup/cryptsetup-generator.c
+++ b/src/cryptsetup/cryptsetup-generator.c
@@ -19,26 +19,34 @@
along with systemd; If not, see http://www.gnu.org/licenses/.
***/
-#include string.h
#include errno.h
+#include string.h
#include unistd.h
+#include dropin.h
+#include fileio.h
+#include generator.h
+#include hashmap.h
#include log.h
-#include util.h
-#include unit-name.h
#include mkdir.h
-#include strv.h
-#include fileio.h
#include path-util.h
-#include dropin.h
-#include generator.h
+#include strv.h
+#include unit-name.h
+#include util.h
+
+typedef struct crypto_device {
+char *uuid;
+char *options;
+bool create;
+} crypto_device;
static const char *arg_dest = /tmp;
static bool arg_enabled = true;
static bool arg_read_crypttab = true;
-static char **arg_disks = NULL;
-static char **arg_options = NULL;
-static char *arg_keyfile = NULL;
+static bool arg_whitelist = false;
+static Hashmap *arg_disks = NULL;
+static char *arg_default_options = NULL;
+static char *arg_default_keyfile = NULL;
static bool has_option(const char *haystack, const char *needle) {
const char *f = haystack;
@@ -263,8 +271,54 @@ static int create_disk(
return 0;
}
+static void free_arg_disks(void) {
+crypto_device *d;
+
+while ((d = hashmap_steal_first(arg_disks))) {
+free(d-uuid);
+free(d-options);
+free(d);
+}
+
+hashmap_free(arg_disks);
+}
+
+static crypto_device *get_crypto_device(const char *uuid) {
+int r;
+crypto_device *d;
+
+assert(uuid);
+
+d = hashmap_get(arg_disks, uuid);
+if (!d) {
+d = new0(struct crypto_device, 1);
+if (!d)
+return NULL;
+
+d-create = false;
+d-options = NULL;
+
+d-uuid = strdup(uuid);
+if (!d-uuid) {
+free(d);
+return NULL;
+}
+
+r = hashmap_put(arg_disks, d-uuid, d);
+if (r 0) {
+free(d-uuid);
+free(d);
+return NULL;
+}
+}
+
+return d;
+}
+
static int parse_proc_cmdline_item(const char *key, const char *value) {
int r;
+crypto_device *d;
+_cleanup_free_ char *uuid = NULL, *uuid_value = NULL;
if (STR_IN_SET(key, luks, rd.luks) value) {
@@ -284,19 +338,29 @@ static int parse_proc_cmdline_item(const char *key, const
char *value) {
} else if (STR_IN_SET(key, luks.uuid, rd.luks.uuid) value) {
-if (strv_extend(arg_disks, value) 0)
+d = get_crypto_device(startswith(value, luks-) ? value+5 :
value);
+if (!d)
return log_oom();
+d-create = arg_whitelist = true;
+
} else if
[systemd-devel] [PATCH 3/3] cryptsetup-generator: Add support for naming luks devices on kernel cmdline
---
man/kernel-command-line.xml | 2 ++
man/systemd-cryptsetup-generator.xml | 19 +++
src/cryptsetup/cryptsetup-generator.c | 32 ++--
3 files changed, 47 insertions(+), 6 deletions(-)
diff --git a/man/kernel-command-line.xml b/man/kernel-command-line.xml
index 68460ac..e32ed19 100644
--- a/man/kernel-command-line.xml
+++ b/man/kernel-command-line.xml
@@ -283,6 +283,8 @@
termvarnamerd.luks=/varname/term
termvarnameluks.crypttab=/varname/term
termvarnamerd.luks.crypttab=/varname/term
+termvarnameluks.name=/varname/term
+termvarnamerd.luks.name=/varname/term
termvarnameluks.uuid=/varname/term
termvarnamerd.luks.uuid=/varname/term
termvarnameluks.options=/varname/term
diff --git a/man/systemd-cryptsetup-generator.xml
b/man/systemd-cryptsetup-generator.xml
index d4a9cc7..c8753ce 100644
--- a/man/systemd-cryptsetup-generator.xml
+++ b/man/systemd-cryptsetup-generator.xml
@@ -140,6 +140,25 @@
/varlistentry
varlistentry
+termvarnameluks.name=/varname/term
+termvarnamerd.luks.name=/varname/term
+
+listitemparaTakes a LUKS super
+block UUID followed by an '=' and a name. This
implies
+varnamerd.luks.uuid=/varname or
varnameluks.uuid=/varname
+and will additionally make the LUKS device
given by
+the UUID appear under the provided name./para
+
+paravarnamerd.luks.name=/varname
+is honored only by initial RAM disk
+(initrd) while
+varnameluks.name=/varname is
+honored by both the main system and
+the initrd./para
+/listitem
+/varlistentry
+
+varlistentry
termvarnameluks.options=/varname/term
termvarnamerd.luks.options=/varname/term
diff --git a/src/cryptsetup/cryptsetup-generator.c
b/src/cryptsetup/cryptsetup-generator.c
index 09374c2..faf6caf 100644
--- a/src/cryptsetup/cryptsetup-generator.c
+++ b/src/cryptsetup/cryptsetup-generator.c
@@ -37,6 +37,7 @@
typedef struct crypto_device {
char *uuid;
char *keyfile;
+char *name;
char *options;
bool create;
} crypto_device;
@@ -278,6 +279,7 @@ static void free_arg_disks(void) {
while ((d = hashmap_steal_first(arg_disks))) {
free(d-uuid);
free(d-keyfile);
+free(d-name);
free(d-options);
free(d);
}
@@ -298,7 +300,7 @@ static crypto_device *get_crypto_device(const char *uuid) {
return NULL;
d-create = false;
-d-keyfile = d-options = NULL;
+d-keyfile = d-options = d-name = NULL;
d-uuid = strdup(uuid);
if (!d-uuid) {
@@ -374,6 +376,22 @@ static int parse_proc_cmdline_item(const char *key, const
char *value) {
} else if (free_and_strdup(arg_default_keyfile, value))
return log_oom();
+} else if (STR_IN_SET(key, luks.name, rd.luks.name) value) {
+
+r = sscanf(value, %m[0-9a-fA-F-]=%ms, uuid, uuid_value);
+if (r == 2) {
+d = get_crypto_device(uuid);
+if (!d)
+return log_oom();
+
+d-create = arg_whitelist = true;
+
+free(d-name);
+d-name = uuid_value;
+uuid_value = NULL;
+} else
+log_warning(Failed to parse luks name switch %s.
Ignoring., value);
+
}
return 0;
@@ -458,14 +476,16 @@ static int add_proc_cmdline_devices(void) {
HASHMAP_FOREACH(d, arg_disks, i) {
const char *options;
-_cleanup_free_ char *name = NULL, *device = NULL;
+_cleanup_free_ char *device = NULL;
if (!d-create)
continue;
-name = strappend(luks-, d-uuid);
-if (!name)
-return log_oom();
+if (!d-name) {
+d-name = strappend(luks-, d-uuid);
+if (!d-name)
+return
[systemd-devel] [PATCH 2/3] cryptsetup-generator: Add support for UUID-specific key files on kernel command line
---
man/systemd-cryptsetup-generator.xml | 11 ---
src/cryptsetup/cryptsetup-generator.c | 17 ++---
2 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/man/systemd-cryptsetup-generator.xml
b/man/systemd-cryptsetup-generator.xml
index ff94e88..d4a9cc7 100644
--- a/man/systemd-cryptsetup-generator.xml
+++ b/man/systemd-cryptsetup-generator.xml
@@ -165,11 +165,16 @@
termvarnameluks.key=/varname/term
termvarnamerd.luks.key=/varname/term
-listitemparaTakes a password file as
argument./para
+listitemparaTakes a password file name as
argument or
+a LUKS super block UUID followed by a '=' and
a password
+file name./para
+
paraFor those entries specified with
varnamerd.luks.uuid=/varname or
varnameluks.uuid=/varname,
-the password file will be set to the password
file specified by
-varnamerd.luks.key=/varname or
varnameluks.key/varname/para
+the password file will be set to the one
specified by
+varnamerd.luks.key=/varname or
varnameluks.key=/varname
+of the corresponding UUID, or the password
file that was specified
+without a UUID./para
paravarnamerd.luks.key=/varname
is honored only by initial RAM disk
(initrd) while
diff --git a/src/cryptsetup/cryptsetup-generator.c
b/src/cryptsetup/cryptsetup-generator.c
index 185c03c..09374c2 100644
--- a/src/cryptsetup/cryptsetup-generator.c
+++ b/src/cryptsetup/cryptsetup-generator.c
@@ -36,6 +36,7 @@
typedef struct crypto_device {
char *uuid;
+char *keyfile;
char *options;
bool create;
} crypto_device;
@@ -276,6 +277,7 @@ static void free_arg_disks(void) {
while ((d = hashmap_steal_first(arg_disks))) {
free(d-uuid);
+free(d-keyfile);
free(d-options);
free(d);
}
@@ -296,7 +298,7 @@ static crypto_device *get_crypto_device(const char *uuid) {
return NULL;
d-create = false;
-d-options = NULL;
+d-keyfile = d-options = NULL;
d-uuid = strdup(uuid);
if (!d-uuid) {
@@ -360,7 +362,16 @@ static int parse_proc_cmdline_item(const char *key, const
char *value) {
} else if (STR_IN_SET(key, luks.key, rd.luks.key) value) {
-if (free_and_strdup(arg_default_keyfile, value))
+r = sscanf(value, %m[0-9a-fA-F-]=%ms, uuid, uuid_value);
+if (r == 2) {
+d = get_crypto_device(uuid);
+if (!d)
+return log_oom();
+
+free(d-keyfile);
+d-keyfile = uuid_value;
+uuid_value = NULL;
+} else if (free_and_strdup(arg_default_keyfile, value))
return log_oom();
}
@@ -467,7 +478,7 @@ static int add_proc_cmdline_devices(void) {
else
options = timeout=0;
-r = create_disk(name, device, arg_default_keyfile, options);
+r = create_disk(name, device, d-keyfile ?:
arg_default_keyfile, options);
if (r 0)
return r;
}
--
2.1.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Udev rules hardware database
On Fri, 07.11.14 09:23, Oliver Neukum (oneu...@suse.de) wrote:
By coincidence I recently noticed something interesting in sysfs: My
USB devices seem to have an attribute supports_autosuspend. These
They are from the kernel and tell you that the drivers for the devices
support autosuspend. It says nothing about the device itself.
are all 1 except for my USB webcam [1] where it is 0. This sounds very
promising indeed! So apparently the kernel now already grew either a
heuristics or some black/whitelists?
Nothing of this sort. It is a pure driver thing and only the negative
is to be taken at face value.
At least the current state how Linux (3.16.0) and udev (215) configure
autosuspend seems a bit weird:
- Some of my USB devices have power/autosuspend == 2: internal
laptop webcam, USB webcam ([1] again), USB Keyboard, USB mouse.
2 is the kernel's default for the general case.
All others have 0. There is no udev rule or other thing on my
system to set those, so unless it's udev or systemd itself I guess
it's from the kernel.
Drivers in the kernel can change it with
pm_runtime_set_autosuspend_delay()
- Most of my USB devices have power/level==auto (i. e. suspend
enabled), only some of them are on (i. e. suspend disabled).
Curiously those which are on are three of above devices where
autosuspend==2: USB webcam, USB Keyboard, USB mouse.
Again drivers can enable it with usb_enable_autosuspend()
This can not be done for HID devices, because for most mice
remote wakeup isn't usable in the generic case.
- The only udev rule which I'm aware of that does autosuspend is
42-usb-hid-pm.rules:
ACTION==add, SUBSYSTEM==usb, ATTR{bInterfaceClass}==03,
ATTRS{removable}==fixed, TEST==../power/control,
ATTR{../power/control}=auto
So it does not seem to be the case that we don't currently enable
autosuspend at all, but it's currently highly inconsistant and
confusing.
It is inconsistent. That is at least partially to the inability to find
general rules.
So what would you recommend we do?
Experiment with turning auto-suspend on by default and then start
building a blacklist if we get reports that things stop working?
And that blacklist should that live in hwdb in userspace or be
maintained as quirks list in the kernel, compiled in?
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] Shutdown problems
On Thu, 06.11.14 19:07, Nikolaus Rath (nikol...@rath.org) wrote: Hello, I'm having some trouble shutting down my system with systemd. What happens is the following: * If I execute systemctl reboot while a text console is active, everything works fine. * If I execute systemctl reboot while the X11 console is active, the system hangs (I tried waiting up to 7 minutes). Furthermore, I am unable to switch to another console with Ctrl+Alt+Fn, the computer becomes unresponsive to the keyboard and the monitor powers down. On which tty/pty systemctl itself is executed does not matter (I tested this by running systemctl in an ssh session from a remote system), it only matters which console is currently active. I tried the debugging technique from http://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1 and created a file debug.sh in /lib/systemd/system-shutdown with permisson 755 and the following contents: $ cat /lib/systemd/system-shutdown/debug.sh #!/bin/sh exec /shutdown.log exec 21 mount -o remount,rw / echo stdout echo stderr 2 dmesg systemctl list-jobs systemctl status echo done mount -o remount,ro / You open the file for writing before you actually mount the fs read-only. That cannot work. However, no file /shutdown.log is created after reboot. I also tried placing debug.sh in /usr/lib/systemd/system-shutdown instead (this is a Debian system), but this did not work either. I also tried enabling the debug-shell, but this did not help because I can't access tty9 when the hang occurs. I also tried running an sshd process in the debug shell (to see if I can still reach the system remotely when it hangs), but the connection got closed when I ran the systemctl command - why might that be? I had hoped that processes spawned from the debug-shell would not get killed? I am using systemd 215-5+b1 on Debian jessie. I also have plymouth enabled. Anyone able to help? Please boot with systemd.log_level=debug, then make the machine hang and check what the last things in the logs say. Maybe then paste that somewhere online and post the URL for that here, so that we can have a look. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shared/install: don't report 'static' when unit contains only Also=
On Fri, 07.11.14 09:49, Jan Synacek (jsyna...@redhat.com) wrote: Lennart Poettering lenn...@poettering.net writes: On Thu, 06.11.14 10:49, Jan Synacek (jsyna...@redhat.com) wrote: I think that this patch might be a bit ineffective, as it calls unit_file_load() again just to get an InstallContext. I wasn't sure how to get Also= targets in any other way. If such change makes sense, this patch should probably be considered a preview rather than something to be committed right away. Hmm, wouldn't it be nicer to introduce a new UnitFileState enum value for this? Maybe UNIT_FILE_ALSO or so? I am not sure I like the idea of implicitly following the Also= setting here, due to the awkwarndess if multiple units are listed and how to map exotic states of that other unit back to ours... Would that make sense? Lennart Yes, that makes sense. What should a string representation of UNIT_FILE_ALSO be? I don't think that reporting 'also' would feel right. We should always keep the enum name and the string it translates to in sync. I can see that reporting also might be confusing, note sure what we could name it better though. But if we use a different string we should also rename its enum really. Maybe indirect? other? Hmm, see-also could work? With the counterpart UNIT_FILE_SEE_ALSO? Also, is there a better way to find out if unit has any Also= targets than how I did it? I think the best way would be to extend InstallInfo to get a new also strv field, that is upated by config_parse_also(). Then unit_file_can_install() can find it and return the fact that the list is not empty in an extra parameter. 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] Udev rules hardware database
On Fri, 2014-11-07 at 12:55 +0100, Lennart Poettering wrote: On Fri, 07.11.14 09:23, Oliver Neukum (oneu...@suse.de) wrote: It is inconsistent. That is at least partially to the inability to find general rules. So what would you recommend we do? Experiment with turning auto-suspend on by default and then start building a blacklist if we get reports that things stop working? No. I suggest giving administrators (users) a really easy way to enable autosuspend and gather the results. That isn't good. We've tried for years to come up with something better. And that blacklist should that live in hwdb in userspace or be maintained as quirks list in the kernel, compiled in? user space Regards Oliver ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd user service when x is started
My plan is to use after X is started a second target, let's call it wm.target, with all services relevant to the X session. For now, I have no idea how to define After= It can't be right after the console.target as X need to be started first. I don't understand, if you start X manually, why don't you launch systemctl --user wm.target from your .xprofile or an equivalent file? Maybe use systemctl import-environment DISPLAY before to get the correct $DISPLAY. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shared/install: don't report 'static' when unit contains only Also=
On Fri, Nov 07, 2014 at 01:06:41PM +0100, Lennart Poettering wrote: On Fri, 07.11.14 09:49, Jan Synacek (jsyna...@redhat.com) wrote: Lennart Poettering lenn...@poettering.net writes: On Thu, 06.11.14 10:49, Jan Synacek (jsyna...@redhat.com) wrote: I think that this patch might be a bit ineffective, as it calls unit_file_load() again just to get an InstallContext. I wasn't sure how to get Also= targets in any other way. If such change makes sense, this patch should probably be considered a preview rather than something to be committed right away. Hmm, wouldn't it be nicer to introduce a new UnitFileState enum value for this? Maybe UNIT_FILE_ALSO or so? I am not sure I like the idea of implicitly following the Also= setting here, due to the awkwarndess if multiple units are listed and how to map exotic states of that other unit back to ours... Would that make sense? Lennart Yes, that makes sense. What should a string representation of UNIT_FILE_ALSO be? I don't think that reporting 'also' would feel right. Maybe I'm missing something, but wouldn't be enough to report is as 'enabled'? For some units adding another name from Also= really enables the unit, and for other units the name from Also= is mostly cosmetic. What I'm trying to say is that having or not the Also= name enabled is only approximate information and does not always tell us if the unit will be started. I'd prefer to redefine enabled/disabled/static as this unit has at least on of the declared links in the filesystem/the unit does not have any defined links in the filesystem/this unit does not declare any links in the filesystem, which is something that we can actually check. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Tagging NVIDIA graphics devices (with proprietary drivers) as master-of-seat
Hi there!
For anyone interested in tagging NVIDIA graphics devices with proprietary
drivers as master-of-seat for use with logind, I suggest the following
udev rule:
SUBSYSTEM==drm, KERNEL==card[0-9]*, ATTRS{vendor}==0x10de,
DRIVERS==nvidia, TAG+=master-of-seat
If no /dev/dri/card* kernel devices are available in the system (e.g. if
linux drm module is not loaded), the following alternative works, too:
SUBSYSTEM==pci, ATTRS{vendor}==0x10de, DRIVER==nvidia, TAG+=seat,
TAG+=master-of-seat
NOTE: These rules can be adapted for AMD proprietary drivers. Just replace
0x10de with 0x1002 and nvidia with fglrx.
I don't know if there's any upstream interest in shipping these rules with
systemd (I guess not), but at least one downstream (Ubuntu) already ships
them (with NVIDIA/AMD driver packages). I've already posted these rules in
NVIDIA Developer Forums.
Hope it may be useful.
--
*Laércio de Sousa*
*Orientador de Informática*
*Escola Municipal Professor Eulálio Gruppi*
*Rua Ismael da Silva Mello, 559, Mogi Moderno*
*Mogi das Cruzes - SPCEP 08717-390*
Telefone: (11) 4726-8313
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] units/basic.target units/poweroff.target units/reboot.target
On Thursday, 6. November 2014, 14:28:12 Lennart Poettering wrote: Is unattended-upgrades a package of its own? Yes, it's a separate package (although it's obviously closely coupled with the apt package manager). If so, I'd probably ask the packagers to include drop-ins for reboot.target to override the timeout. That way, as soon as you install it the shutdown timeouts are disabled. That should be possible. Currently the package contains /lib/systemd/system/unattended-upgrades.service which contains: [Unit] Description=Unattended Upgrades DefaultDependencies=no Before=shutdown.target reboot.target halt.target Documentation=man:unattended-upgrade(8) [Service] Type=oneshot ExecStart=/usr/share/unattended-upgrades/unattended-upgrade-shutdown [Install] WantedBy=shutdown.target Only the maintainer Michael Vogt can decide if he wants to go in that direction, thus I added him as CC. @Michael Vogt: The discussion is about adding a watchdog to systemd to power down the system if the shutdown takes longer than some time (i.e. 30 minutes). The question was how to avoid killing unattended-upgrade during a longer upgrade if it is configured to update the packages at shutdown. Kind regards Patrick signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] shared/install: when unit contains only Also=, report 'indirect'
Continuation of http://lists.freedesktop.org/archives/systemd-devel/2014-November/025041.html. Jan Synacek (1): shared/install: when unit contains only Also=, report 'indirect' man/systemctl.xml | 5 + src/shared/install.c | 45 +++-- src/shared/install.h | 2 ++ src/systemctl/systemctl.c | 7 +++ 4 files changed, 41 insertions(+), 18 deletions(-) -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] shared/install: when unit contains only Also=, report 'indirect'
If a unit contains only Also=, with no Alias= or WantedBy=, it shouldn't
be reported as static. New 'indirect' status shall be introduced.
https://bugzilla.redhat.com/show_bug.cgi?id=864298
---
man/systemctl.xml | 5 +
src/shared/install.c | 45 +++--
src/shared/install.h | 2 ++
src/systemctl/systemctl.c | 7 +++
4 files changed, 41 insertions(+), 18 deletions(-)
diff --git a/man/systemctl.xml b/man/systemctl.xml
index 7cbaa6c..fa85d0b 100644
--- a/man/systemctl.xml
+++ b/man/systemctl.xml
@@ -1013,6 +1013,11 @@ kobject-uevent 1 systemd-udevd-kernel.socket
systemd-udevd.service
entry0/entry
/row
row
+entryliteralindirect/literal/entry
+entryUnit's status is determined indirectly by another
unit(s) specified in literalAlso=/literal in [Install] section/entry
+entry0/entry
+ /row
+ row
entryliteraldisabled/literal/entry
entryUnit is not enabled/entry
entry1/entry
diff --git a/src/shared/install.c b/src/shared/install.c
index cab93e8..83d1093 100644
--- a/src/shared/install.c
+++ b/src/shared/install.c
@@ -840,6 +840,7 @@ static void install_info_free(InstallInfo *i) {
strv_free(i-aliases);
strv_free(i-wanted_by);
strv_free(i-required_by);
+strv_free(i-also);
free(i-default_instance);
free(i);
}
@@ -948,6 +949,7 @@ static int config_parse_also(
size_t l;
const char *word, *state;
InstallContext *c = data;
+InstallInfo *i = userdata;
assert(filename);
assert(lvalue);
@@ -964,6 +966,10 @@ static int config_parse_also(
r = install_info_add(c, n, NULL);
if (r 0)
return r;
+
+r = strv_extend(i-also, n);
+if (r 0)
+return r;
}
if (!isempty(state))
log_syntax(unit, LOG_ERR, filename, line, EINVAL,
@@ -1043,7 +1049,8 @@ static int unit_file_load(
const char *path,
const char *root_dir,
bool allow_symlink,
-bool load) {
+bool load,
+char ***also) {
const ConfigTableItem items[] = {
{ Install, Alias, config_parse_strv,
0, info-aliases },
@@ -1087,6 +1094,9 @@ static int unit_file_load(
if (r 0)
return r;
+if (also !strv_isempty(info-also))
+*also = strv_copy(info-also);
+
return
(int) strv_length(info-aliases) +
(int) strv_length(info-wanted_by) +
@@ -1099,7 +1109,8 @@ static int unit_file_search(
LookupPaths *paths,
const char *root_dir,
bool allow_symlink,
-bool load) {
+bool load,
+char ***also) {
char **p;
int r;
@@ -1109,7 +1120,7 @@ static int unit_file_search(
assert(paths);
if (info-path)
-return unit_file_load(c, info, info-path, root_dir,
allow_symlink, load);
+return unit_file_load(c, info, info-path, root_dir,
allow_symlink, load, also);
assert(info-name);
@@ -1120,7 +1131,7 @@ static int unit_file_search(
if (!path)
return -ENOMEM;
-r = unit_file_load(c, info, path, root_dir, allow_symlink,
load);
+r = unit_file_load(c, info, path, root_dir, allow_symlink,
load, also);
if (r = 0) {
info-path = path;
path = NULL;
@@ -1149,7 +1160,7 @@ static int unit_file_search(
if (!path)
return -ENOMEM;
-r = unit_file_load(c, info, path, root_dir,
allow_symlink, load);
+r = unit_file_load(c, info, path, root_dir,
allow_symlink, load, also);
if (r = 0) {
info-path = path;
path = NULL;
@@ -1167,7 +1178,8 @@ static int unit_file_can_install(
LookupPaths *paths,
const char *root_dir,
const char *name,
-bool allow_symlink) {
+bool allow_symlink,
+char ***also) {
_cleanup_(install_context_done) InstallContext c = {};
InstallInfo *i;
@@ -1182,7 +1194,7 @@ static int unit_file_can_install(
assert_se(i = ordered_hashmap_first(c.will_install));
-r = unit_file_search(c, i, paths, root_dir, allow_symlink, true);
+r = unit_file_search(c, i, paths, root_dir, allow_symlink,
Re: [systemd-devel] [PATCH] shared/install: don't report 'static' when unit contains only Also=
Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl writes: On Fri, Nov 07, 2014 at 01:06:41PM +0100, Lennart Poettering wrote: On Fri, 07.11.14 09:49, Jan Synacek (jsyna...@redhat.com) wrote: Lennart Poettering lenn...@poettering.net writes: On Thu, 06.11.14 10:49, Jan Synacek (jsyna...@redhat.com) wrote: I think that this patch might be a bit ineffective, as it calls unit_file_load() again just to get an InstallContext. I wasn't sure how to get Also= targets in any other way. If such change makes sense, this patch should probably be considered a preview rather than something to be committed right away. Hmm, wouldn't it be nicer to introduce a new UnitFileState enum value for this? Maybe UNIT_FILE_ALSO or so? I am not sure I like the idea of implicitly following the Also= setting here, due to the awkwarndess if multiple units are listed and how to map exotic states of that other unit back to ours... Would that make sense? Lennart Yes, that makes sense. What should a string representation of UNIT_FILE_ALSO be? I don't think that reporting 'also' would feel right. Maybe I'm missing something, but wouldn't be enough to report is as 'enabled'? AFAIK, it can also be disabled... Take systemd-journal-gatewayd.service as an example. It doesn't have anything but Also=systemd-journal-gatewayd.socket in the Install section. If you disable the socket, you would then return enabled, which would be wrong. Howerever, I'm not sure about more complicated setups. For some units adding another name from Also= really enables the unit, and for other units the name from Also= is mostly cosmetic. What I'm trying to say is that having or not the Also= name enabled is only approximate information and does not always tell us if the unit will be started. I'd prefer to redefine enabled/disabled/static as this unit has at least on of the declared links in the filesystem/the unit does not have any defined links in the filesystem/this unit does not declare any links in the filesystem, which is something that we can actually check. Zbyszek 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] shared/install: don't report 'static' when unit contains only Also=
Lennart Poettering lenn...@poettering.net writes: On Fri, 07.11.14 09:49, Jan Synacek (jsyna...@redhat.com) wrote: Lennart Poettering lenn...@poettering.net writes: On Thu, 06.11.14 10:49, Jan Synacek (jsyna...@redhat.com) wrote: I think that this patch might be a bit ineffective, as it calls unit_file_load() again just to get an InstallContext. I wasn't sure how to get Also= targets in any other way. If such change makes sense, this patch should probably be considered a preview rather than something to be committed right away. Hmm, wouldn't it be nicer to introduce a new UnitFileState enum value for this? Maybe UNIT_FILE_ALSO or so? I am not sure I like the idea of implicitly following the Also= setting here, due to the awkwarndess if multiple units are listed and how to map exotic states of that other unit back to ours... Would that make sense? Lennart Yes, that makes sense. What should a string representation of UNIT_FILE_ALSO be? I don't think that reporting 'also' would feel right. We should always keep the enum name and the string it translates to in sync. I can see that reporting also might be confusing, note sure what we could name it better though. But if we use a different string we should also rename its enum really. Maybe indirect? other? Hmm, see-also could work? With the counterpart UNIT_FILE_SEE_ALSO? Also, is there a better way to find out if unit has any Also= targets than how I did it? I think the best way would be to extend InstallInfo to get a new also strv field, that is upated by config_parse_also(). Then unit_file_can_install() can find it and return the fact that the list is not empty in an extra parameter. Thanks for the pointers! I've resubmitted the patch and went with the indirect version, as it felt the best to me. -- 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] [systemd-commits] units/basic.target units/poweroff.target units/reboot.target
On Fri, Nov 07, 2014 at 03:02:49PM +0100, Patrick Häcker wrote: That should be possible. Currently the package contains /lib/systemd/system/unattended-upgrades.service which contains: [Unit] Description=Unattended Upgrades DefaultDependencies=no Before=shutdown.target reboot.target halt.target Documentation=man:unattended-upgrade(8) [Service] Type=oneshot ExecStart=/usr/share/unattended-upgrades/unattended-upgrade-shutdown [Install] WantedBy=shutdown.target Only the maintainer Michael Vogt can decide if he wants to go in that direction, thus I added him as CC. @Michael Vogt: The discussion is about adding a watchdog to systemd to power down the system if the shutdown takes longer than some time (i.e. 30 minutes). The question was how to avoid killing unattended-upgrade during a longer upgrade if it is configured to update the packages at shutdown. Systemd has to provide a mechanism, but how it is to be implemented is our problem. I don't think that this is a question for maintainers of other packages to answer. On Thursday, 6. November 2014, 14:28:12 Lennart Poettering wrote: If so, I'd probably ask the packagers to include drop-ins for reboot.target to override the timeout. That way, as soon as you install it the shutdown timeouts are disabled. That's not nice. Installed but unused should not matter. I think we should be asking a different question: does the upgrade process currently run a a job after shutdown.target or reboot.target is scheduled? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] rules: rerun vconsole-setup when switching from vgacon to fbcon
On Thursday 06 November 2014 at 11:02:44, David Herrmann wrote: Hi Ray On Thu, Nov 6, 2014 at 10:40 AM, David Herrmann dh.herrm...@gmail.com wrote: On Wed, Nov 5, 2014 at 4:11 PM, Ray Strode halfl...@gmail.com wrote: So if you have no idea how to make that rule be generated only if ENABLE_VCONSOLE is set by configure, then we probably should take my patch below. Your patch seems far better than the options above, but I think it needs a dracut patch to make sure the new rules file gets in the initrd too, or it won't work. I will push the patch to systemd and let Harald know. I'm not really familiar with dracut.. Pushed. Isn't it ugly to re-runn systemd-vconsole-setup straight from an udev rule? I mean, udev has a tendency to kill long-running RUN processes, and I've seen systemd-vconsole-setup.service to take 5 seconds on some systems... Also, these additional systemd-vconsole-setup instances aren't supervised by systemd... -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] inhibit: allow filtering --list by mode
Usually there are a few delay inhibitors all the time (NetworkManager,
Telepathy, etc.), but I'm only interested in the block ones.
---
src/login/inhibit.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/login/inhibit.c b/src/login/inhibit.c
index d5ea1d9..122c69d 100644
--- a/src/login/inhibit.c
+++ b/src/login/inhibit.c
@@ -36,7 +36,7 @@
static const char* arg_what = idle:sleep:shutdown;
static const char* arg_who = NULL;
static const char* arg_why = Unknown reason;
-static const char* arg_mode = block;
+static const char* arg_mode = NULL;
static enum {
ACTION_INHIBIT,
@@ -97,6 +97,9 @@ static int print_inhibitors(sd_bus *bus, sd_bus_error *error)
{
while ((r = sd_bus_message_read(reply, (uu), what, who, why,
mode, uid, pid)) 0) {
_cleanup_free_ char *comm = NULL, *u = NULL;
+if (arg_mode !streq(mode, arg_mode))
+continue;
+
get_process_comm(pid, comm);
u = uid_to_name(uid);
@@ -252,6 +255,9 @@ int main(int argc, char *argv[]) {
if (!arg_who)
arg_who = w = strv_join(argv + optind, );
+if (!arg_mode)
+arg_mode = block;
+
fd = inhibit(bus, error);
if (fd 0) {
log_error(Failed to inhibit: %s,
bus_error_message(error, -r));
--
2.1.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shared/install: don't report 'static' when unit contains only Also=
On Fri, 07.11.14 14:24, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Fri, Nov 07, 2014 at 01:06:41PM +0100, Lennart Poettering wrote: On Fri, 07.11.14 09:49, Jan Synacek (jsyna...@redhat.com) wrote: Lennart Poettering lenn...@poettering.net writes: On Thu, 06.11.14 10:49, Jan Synacek (jsyna...@redhat.com) wrote: I think that this patch might be a bit ineffective, as it calls unit_file_load() again just to get an InstallContext. I wasn't sure how to get Also= targets in any other way. If such change makes sense, this patch should probably be considered a preview rather than something to be committed right away. Hmm, wouldn't it be nicer to introduce a new UnitFileState enum value for this? Maybe UNIT_FILE_ALSO or so? I am not sure I like the idea of implicitly following the Also= setting here, due to the awkwarndess if multiple units are listed and how to map exotic states of that other unit back to ours... Would that make sense? Lennart Yes, that makes sense. What should a string representation of UNIT_FILE_ALSO be? I don't think that reporting 'also' would feel right. Maybe I'm missing something, but wouldn't be enough to report is as 'enabled'? For some units adding another name from Also= really enables the unit, and for other units the name from Also= is mostly cosmetic. What I'm trying to say is that having or not the Also= name enabled is only approximate information and does not always tell us if the unit will be started. Also= isn't necessarily symmetric. If you have a service A and a service B, then it might very well be that B has Also=A.service, but not the other way round. I think there are only two strategies here: a) if a unit has Also= set, determine the state of the unit files listed in it, any propagate that. This is what Jan's patch did originally. But I am not sure I like this propagation since it leaves so many open questions regarding correct propagation the precise state and what to do if multiple units are listed. or b) just report that Also= is set, which is what I was proposing. This might not be particularly self-explanatory, but maybe we can explain this in the man page or so... I'd prefer to redefine enabled/disabled/static as this unit has at least on of the declared links in the filesystem/the unit does not have any defined links in the filesystem/this unit does not declare any links in the filesystem, which is something that we can actually check. So, are you proposing to follow strategy a) 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] Tagging NVIDIA graphics devices (with proprietary drivers) as master-of-seat
On Fri, 07.11.14 11:41, Laércio de Sousa
(laercioso...@sme-mogidascruzes.sp.gov.br) wrote:
Hi there!
For anyone interested in tagging NVIDIA graphics devices with proprietary
drivers as master-of-seat for use with logind, I suggest the following
udev rule:
SUBSYSTEM==drm, KERNEL==card[0-9]*, ATTRS{vendor}==0x10de,
DRIVERS==nvidia, TAG+=master-of-seat
If no /dev/dri/card* kernel devices are available in the system (e.g. if
linux drm module is not loaded), the following alternative works, too:
SUBSYSTEM==pci, ATTRS{vendor}==0x10de, DRIVER==nvidia, TAG+=seat,
TAG+=master-of-seat
NOTE: These rules can be adapted for AMD proprietary drivers. Just replace
0x10de with 0x1002 and nvidia with fglrx.
I don't know if there's any upstream interest in shipping these rules with
systemd (I guess not), but at least one downstream (Ubuntu) already ships
them (with NVIDIA/AMD driver packages). I've already posted these rules in
NVIDIA Developer Forums.
Yes, we don't want to ship rules for closed-source or out-of-tree
drivers. Rules for that should really be shipped with the drivers
package, instead.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shared/install: don't report 'static' when unit contains only Also=
On Fri, Nov 07, 2014 at 03:25:11PM +0100, Jan Synacek wrote: Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl writes: On Fri, Nov 07, 2014 at 01:06:41PM +0100, Lennart Poettering wrote: On Fri, 07.11.14 09:49, Jan Synacek (jsyna...@redhat.com) wrote: Lennart Poettering lenn...@poettering.net writes: On Thu, 06.11.14 10:49, Jan Synacek (jsyna...@redhat.com) wrote: I think that this patch might be a bit ineffective, as it calls unit_file_load() again just to get an InstallContext. I wasn't sure how to get Also= targets in any other way. If such change makes sense, this patch should probably be considered a preview rather than something to be committed right away. Hmm, wouldn't it be nicer to introduce a new UnitFileState enum value for this? Maybe UNIT_FILE_ALSO or so? I am not sure I like the idea of implicitly following the Also= setting here, due to the awkwarndess if multiple units are listed and how to map exotic states of that other unit back to ours... Would that make sense? Lennart Yes, that makes sense. What should a string representation of UNIT_FILE_ALSO be? I don't think that reporting 'also' would feel right. Maybe I'm missing something, but wouldn't be enough to report is as 'enabled'? AFAIK, it can also be disabled... Take systemd-journal-gatewayd.service as an example. It doesn't have anything but Also=systemd-journal-gatewayd.socket in the Install section. If you disable the socket, you would then return enabled, which would be wrong. Shit, sorry, I was thinking about about Alias=. Please disregard my previous mail, I need to reread the thread while not trying to do something else at the same time. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] inhibit: allow filtering --list by mode
On Fri, 07.11.14 16:45, Mantas Mikulėnas (graw...@gmail.com) wrote: Usually there are a few delay inhibitors all the time (NetworkManager, Telepathy, etc.), but I'm only interested in the block ones. Applied! 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] rules: rerun vconsole-setup when switching from vgacon to fbcon
On Fri, 07.11.14 17:45, Ivan Shapovalov (intelfx...@gmail.com) wrote: On Thursday 06 November 2014 at 11:02:44, David Herrmann wrote: Hi Ray On Thu, Nov 6, 2014 at 10:40 AM, David Herrmann dh.herrm...@gmail.com wrote: On Wed, Nov 5, 2014 at 4:11 PM, Ray Strode halfl...@gmail.com wrote: So if you have no idea how to make that rule be generated only if ENABLE_VCONSOLE is set by configure, then we probably should take my patch below. Your patch seems far better than the options above, but I think it needs a dracut patch to make sure the new rules file gets in the initrd too, or it won't work. I will push the patch to systemd and let Harald know. I'm not really familiar with dracut.. Pushed. Isn't it ugly to re-runn systemd-vconsole-setup straight from an udev rule? I mean, udev has a tendency to kill long-running RUN processes, and I've seen systemd-vconsole-setup.service to take 5 seconds on some systems... Also, these additional systemd-vconsole-setup instances aren't supervised by systemd... Is systemd-vconsole-setup really long-running? Why would it need that long? To me it appears to be quite OK to be run inside a udev rule. 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] Expected behavior when systemd cannot load SELinux policy
On Fri, 07.11.14 11:30, Jan Synáček (jsyna...@redhat.com) wrote: Hello, currently, when SELINUX=enforcing and SELINUXTYPE=invalid value are set in /etc/selinux/config, systemd refuses to boot with Failed to load SELinux policy. Freezing. Is this really what should happen? If SELINUX is set to permissive or disabled, though, systemd happily continues booting. I think that that's what should happen when SELINUX is set to enforcing as well. Plus a big warning in the log, or maybe even on the console, of course. What do you think? Well, if we are in enforcing mode then this means that everything that is not OK needs to fail, and this includes the policy being corrupted or missing really. Enforcing mode is really this super secure mode where we'd rather hang the machine then possibly allow things to go through that might not be let through if the policy would be order... 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] manager: Ensure user's systemd runtime directory exists.
On Fri, 07.11.14 09:38, Colin Guthrie (gm...@colin.guthr.ie) wrote: Lennart Poettering wrote on 07/11/14 01:06: On Wed, 05.11.14 14:51, Colin Guthrie (gm...@colin.guthr.ie) wrote: Colin Guthrie wrote on 03/11/14 08:02: Zbigniew Jędrzejewski-Szmek wrote on 02/11/14 18:18: On Sun, Nov 02, 2014 at 02:04:20PM +, Colin Guthrie wrote: This mirrors code in dbus.c when creating the private socket and avoids error messages like: systemd[1353]: bind(/run/user/603/systemd/notify) failed: No such file or directory systemd[1353]: Failed to fully start up daemon: No such file or directory Seems reasonable. But why not move the mkdir_parent_label() to the shared code path? Even if the dir is created elsewhere, it seems cleaner to ensure here that it is available. Well, to be honest, I just copied the structure from dbus.c. I can easily do as you suggest in both places if you think it's nicer. I guess this would add two unnecessary stat()s (at least - not looked at the mkdir... implementation!) on boot however, so might just be better leaving it as is (not that that is a real problem practically speaking, especially in tmpfs!). Just pushed as is for now. I'm sure any moving of mkdir*() to common code path can come later (both here and in dbus.c) if it's deemed more readable and doesn't have a negative impact on performance (I'd expect it to be negligible, but I'm not an embedded guy) It's not an inner loop. We it is usually called exactly once. We do not optimize such cases for individual syscalls. Stuff that ends up in inner loops is something to optimize, possibly. Anyway, I moved the mkdir now to the common path. Not that it really matters, but more because I wanted to cast the result to (void), in order to make sure Coverity doesn't trip up over us ignoring the return value from mkdir(). And while I was at it... Cool, as I mentioned in the thread, you likely want to make a similar change in src/core/dbus.c too when creating the private socket (and the dir to hold it). If nothing else you'll want the (void) cast on mkdir call. There may be other reasons to leave it as it is tho', so I don't want to assume too much and make the change myself in case there are subtleties that are beyond me this early in the morning! I made the two codepaths look more alike now. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shared/install: when unit contains only Also=, report 'indirect'
On Fri, 07.11.14 15:18, Jan Synacek (jsyna...@redhat.com) wrote:
}
if (!isempty(state))
log_syntax(unit, LOG_ERR, filename, line, EINVAL,
@@ -1043,7 +1049,8 @@ static int unit_file_load(
const char *path,
const char *root_dir,
bool allow_symlink,
-bool load) {
+bool load,
+char ***also) {
Hmm, do we really want to return the full list here? I don't think any
caller really is interested in that, or am I wrong? Wouldn't a bool*
suffice here that tells us if also is empty, that we fill in?
I mean, I think the inner calls should parse the whole strv, i see no
problem with that, I just don't think we really need to pass the whole
thing all the way up...
const ConfigTableItem items[] = {
{ Install, Alias, config_parse_strv,
0, info-aliases },
@@ -1087,6 +1094,9 @@ static int unit_file_load(
if (r 0)
return r;
+if (also !strv_isempty(info-also))
+*also = strv_copy(info-also);
+
If the argument would just be a bool* we wouldn't have to do the
expensive strv_copy() here... (which is missing an OOM check btw...)
Otherwise looks great!
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] Allow PID 1 systemd --user instances to exit
On Thu, 06.11.14 18:32, Michael Marineau (michael.marin...@coreos.com) wrote: On Thu, Nov 6, 2014 at 6:02 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 06.11.14 17:48, Michael Marineau (michael.marin...@coreos.com) wrote: So, what's the real usecase for all of this? Can you elaborate on that? The basic idea is to create a container that has the ability to return a normal exit code when it exits. System instances don't allow this. Well, but this is something we could allow. In fact our shutdown code invokes exit(0) if reboot() returns EPERM already (in case of CAP_SYS_BOOT is missing). That said, note that in a PID namespace reboot() nowadays results in the equivalent of raise(SIGINT) anyway, which isn't too different from a simple exit(). The trick then is just reworking that to support plumbing through an exit code to exit() instead. Yeah, I'd be willing to take a patch for this. But the patch should refuse such an Exit()/ExitWitCode() invocation unless we are in either --user mode, or in --system mode inside of a container. i.e. if we run outside of a container in --system mode the Exit() call should return with permission denied or so. Hmm, so what you are trying to do running one systemd instance as a service on another one, in a way that they see the same file hiearchy but operate based on unit files in a different directory? Is that correct? Wouldn't a container (maybe nspawn) work for this with some clevery set up --bind= mounts? I nspawn (or similar? I'm not actually part of this particular project) is being used here, hence running as PID 1. Running the instance as --user seemed like the more fruitful way to plumb through an exit code but fixing --system probably would fit our needs too. Yes, making --system work like you need it sounds much preferable to me. 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] smack: introduce new SmackLabelExec option
On Fri, 07.11.14 15:43, WaLyong Cho (walyong@samsung.com) wrote: On 11/07/2014 09:35 AM, Lennart Poettering wrote: On Fri, 07.11.14 04:17, WaLyong Cho (walyong@gmail.com) wrote: SMACK64 Used to make access control decisions. In almost all cases the label given to a new filesystem object will be the label of the process that created it. SMACK64EXEC The Smack label of a process that execs a program file with this attribute set will run with this attribute's value. I am sorry, but I cannot parse this. The smack label will run with this attribute's value? smack labels run? That sentence makes no sense to me at all... Again, what kind of objects are SMACK64 and SMACK64EXEC applied to? files? processes? Sorry, I'm also confused. OK, I asked some about this to my security friend. And I add Casey Schaufler who the Author of smack. I hope my below explain it not wrong. But if not, please point out. Quoting the Wikipedia: In practice, a subject is usually a process or thread; objects are constructs such as files, directories, TCP/UDP ports, shared memory segments, IO devices etc. In case of SMACK, subject is SMACK64EXEC and object is SMACK64. Assume like this: /usr/bin/dbus-daemon has both label. SMACK64 is foo and SMACK64EXEC is bar. And current process (what will execute the /usr/bin/dbus-daemon) has foo label. Let's assume the current process So, here you are talking about *files* that have the SMACK64EXEC and SMACK64 type labels, while the *process* only as one generic label type. With your patch you want to introduce SmackLabelExec= now. It's a label applied to a *process* however, not to a *file*, right? This appears incompatible to me: I mean, if a process only has one single generic label, and doesn't distuingish between SMACK64 and SMACK64EXEC type labels, why would you call the option SmackLabelExec= and not the more generic SmackLabel=? This really doesn't make sense to me. I have no understanding of SMACK, and I am not sure I want to understand it, and I figure I'd merge the patch regardless which name you pick for the option, but this is a bit too blatantly contradictory for me to completely ignore. Let my simplify my questions: a) Why would you call a setting that controls a label is written into /proc/$PID/attr/current SmackLabelExec= instead of just SmackLabel=? b) If SmackLabelExec= is appropriate (which it might well be, after all I really don't grok this), and SmackLabel= is a misnomer that would suggest that something different would happen than actually assumed, then what would an option by the name SmackLabel= for a service unit do differntly from one called SmackLabelExec? For both SELinux and AppArmor we now have simple options: SELinuxContext= and AppArmorProfile=. They only come in one flavour, and apply a label/profile to the process being executed and that's it. Why would SMACK be more complicated there so that SmackLabel= and SmackLabelExec= would even be a distinction? 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] Udev rules hardware database
On Fri, 07.11.14 13:07, Oliver Neukum (oneu...@suse.de) wrote: On Fri, 2014-11-07 at 12:55 +0100, Lennart Poettering wrote: On Fri, 07.11.14 09:23, Oliver Neukum (oneu...@suse.de) wrote: It is inconsistent. That is at least partially to the inability to find general rules. So what would you recommend we do? Experiment with turning auto-suspend on by default and then start building a blacklist if we get reports that things stop working? No. I suggest giving administrators (users) a really easy way to enable autosuspend and gather the results. That isn't good. We've tried for years to come up with something better. Well, opt-in for this will never work to get a good dataset. I figure if we want this to really happen, then we should turn on autosuspend globally early in the cycle of fedora rawhide, and then collect as much data as we can during testing, and then turn if off before the release if it happens to be too bad. I figure doing this would require some buy-in from FESCO first though. Given the bureaucracy for that this would need a champion though who's willing to do 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] [PATCH] smack: introduce new SmackLabelExec option
On 11/7/2014 8:36 AM, Lennart Poettering wrote: On Fri, 07.11.14 15:43, WaLyong Cho (walyong@samsung.com) wrote: On 11/07/2014 09:35 AM, Lennart Poettering wrote: On Fri, 07.11.14 04:17, WaLyong Cho (walyong@gmail.com) wrote: SMACK64 Used to make access control decisions. In almost all cases the label given to a new filesystem object will be the label of the process that created it. SMACK64EXEC The Smack label of a process that execs a program file with this attribute set will run with this attribute's value. I am sorry, but I cannot parse this. The smack label will run with this attribute's value? smack labels run? That sentence makes no sense to me at all... Again, what kind of objects are SMACK64 and SMACK64EXEC applied to? files? processes? Sorry, I'm also confused. OK, I asked some about this to my security friend. And I add Casey Schaufler who the Author of smack. I hope my below explain it not wrong. But if not, please point out. Quoting the Wikipedia: In practice, a subject is usually a process or thread; objects are constructs such as files, directories, TCP/UDP ports, shared memory segments, IO devices etc. In case of SMACK, subject is SMACK64EXEC and object is SMACK64. Assume like this: /usr/bin/dbus-daemon has both label. SMACK64 is foo and SMACK64EXEC is bar. And current process (what will execute the /usr/bin/dbus-daemon) has foo label. Let's assume the current process So, here you are talking about *files* that have the SMACK64EXEC and SMACK64 type labels, while the *process* only as one generic label type. With your patch you want to introduce SmackLabelExec= now. It's a label applied to a *process* however, not to a *file*, right? Yes, it would apply to the process, not the file. We're talking about the Smack attribute on the process, not a SMACK64EXEC attribute on the program file. This appears incompatible to me: I mean, if a process only has one single generic label, and doesn't distuingish between SMACK64 and SMACK64EXEC type labels, why would you call the option SmackLabelExec= and not the more generic SmackLabel=? It seemed like a good idea at the time. This really doesn't make sense to me. I have no understanding of SMACK, and I am not sure I want to understand it, and I figure I'd merge the patch regardless which name you pick for the option, but this is a bit too blatantly contradictory for me to completely ignore. Let my simplify my questions: a) Why would you call a setting that controls a label is written into /proc/$PID/attr/current SmackLabelExec= instead of just SmackLabel=? b) If SmackLabelExec= is appropriate (which it might well be, after all I really don't grok this), and SmackLabel= is a misnomer that would suggest that something different would happen than actually assumed, then what would an option by the name SmackLabel= for a service unit do differntly from one called SmackLabelExec? For both SELinux and AppArmor we now have simple options: SELinuxContext= and AppArmorProfile=. They only come in one flavour, and apply a label/profile to the process being executed and that's it. Why would SMACK be more complicated there so that SmackLabel= and SmackLabelExec= would even be a distinction? Calling it SmackLabel= instead of SmackLabelExec= would be fine as far as I'm concerned. SmackLabel= is more consistent with SELinuxContext= and AppArmorProfile=, as you point out. Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Poor man's reboot doesn't work
Am Freitag, den 07.11.2014, 01:59 +0100 schrieb Lennart Poettering:
On Sun, 02.11.14 12:48, Thomas Meyer (tho...@m3y3r.de) wrote:
Hi,
I tried to switch to the emergency target and back to the graphical target,
but this doesn't seem to work.
Should this work, i.e.?
# systemctl isolate emergency.target
# systemctl isolate graphical.target
The services seems to fail with this error once I'm in the emergency.target
and try to switch back to the graphical.target:
status=219/CGROUP
Hmm, this is certainly weird.
Any chance you can do strace -ff -p 1 -o /tmp/someplace/log (maybe
from the debug shell). Then, trigger the issue again, and find the
tight log file in /tmp/someplace that ends with an exit(219). It would
be good to paste that file somewhere (or at least the last few lines
which might give an indication on what precisely fails), so that I can
have a look.
Here you go, I tried to extract one example here. if you miss something
I guess I can upload all traces somewhere.
AFAIU pid 1 tries to start the restorecond.service here (I removed all
sendmsg calls):
access(/etc/selinux/restorecond.conf, F_OK) = 0
open(/sys/fs/cgroup/systemd/system.slice/restorecond.service/control/cgroup.procs,
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD,
/sys/fs/cgroup/systemd/system.slice/restorecond.service/control,
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or
directory)
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x7f06d74bcb90) = 31006
access(/sys/fs/cgroup/systemd, F_OK) = 0
open(/sys/fs/cgroup/systemd/system.slice/restorecond.service/cgroup.procs,
O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = -1 ENOENT (No such file or
directory)
open(/proc/31006/stat, O_RDONLY|O_CLOEXEC) = 49
fstat(49, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f06d74e
read(49, 31006 (systemd) R 1 1 1 0 -1 420..., 1024) = 343
close(49) = 0
munmap(0x7f06d74e, 4096)= 0
open(/sys/fs/cgroup/systemd/system.slice/restorecond.service/cgroup.procs,
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, /sys/fs/cgroup/systemd/system.slice/restorecond.service,
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or
directory)
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
0x7fffa38779d0) = -1 ENOTTY (Inappropriate ioctl for device)
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
0x7fffa38779d0) = -1 ENOTTY (Inappropriate ioctl for device)
ioctl(2, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
0x7fffa38779d0) = -1 ENOTTY (Inappropriate ioctl for device)
sendto(18, l\0\0\0j\4\5\0\233\0\0\0\0\0\0\0 comm=\restoreco..., 108, 0,
{sa_family=AF_NETLINK, pid=0, groups=}, 12) = 108
poll([{fd=18, events=POLLIN}], 1, 500) = 1 ([{fd=18, revents=POLLIN}])
recvfrom(18,
$\0\0\0\2\0\0\0\233\0\0\0\1\0\0\0\0\0\0\0l\0\0\0j\4\5\0\233\0\0\0..., 8988,
MSG_PEEK|MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=}, [12]) =
36
recvfrom(18,
$\0\0\0\2\0\0\0\233\0\0\0\1\0\0\0\0\0\0\0l\0\0\0j\4\5\0\233\0\0\0..., 8988,
MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=}, [12]) = 36
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 49
connect(49, {sa_family=AF_LOCAL, sun_path=@/org/freedesktop/plymouthd}, 29) = 0
open(/proc/self/maps, O_RDONLY|O_CLOEXEC) = 50
fstat(50, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
[...]
waitid(P_PID, 31003, {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=31003,
si_uid=0, si_status=219, si_utime=0, si_stime=0}, WEXITED, NULL) = 0
waitid(P_ALL, 0, {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=31006, si_uid=0,
si_status=219, si_utime=0, si_stime=0}, WNOHANG|WEXITED|WNOWAIT, NULL) = 0
open(/proc/31006/comm, O_RDONLY|O_CLOEXEC) = 47
fstat(47, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f06d74e
read(47, (torecond)\n, 1024) = 11
close(47) = 0
munmap(0x7f06d74e, 4096)= 0
open(/proc/31006/cgroup, O_RDONLY|O_CLOEXEC) = 47
fstat(47, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f06d74e
read(47, 6:blkio:/\n5:freezer:/\n4:devices:..., 1024) = 78
close(47) = 0
munmap(0x7f06d74e, 4096)= 0
open(/sys/fs/cgroup/systemd/system.slice/restorecond.service/cgroup.procs,
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, /sys/fs/cgroup/systemd/system.slice/restorecond.service,
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or
directory)
open(/sys/fs/cgroup/systemd/system.slice/restorecond.service/cgroup.procs,
O_RDONLY|O_CLOEXEC) = -1 ENOENT
Re: [systemd-devel] user environment variables
We could probably at least open up DefaultEnvironment= to specifier expansion, so that %t would work the same way as in unit files. I added a TODO list item for this now. Thank you so much This refers to the recent flame about systemd. As a newbie, I can testify the dev team is doing everything to help. As for the variable, two more wishes (not a big deal yet): - in units, why not add a specifier reflecting $XDG_CONFIG_HOME - why not systemctl --export-environment Unfortunately I can't contribute to your code. Keep your good work and thanks for being here in the linux world. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] generator logging during daemon-reload
Hi, I know that generators should log to /dev/kmsg during early boot. But, when they are restarted later by systemcl daemon-reload; is it better to write to the journal instead, by using systemd-cat for example ? Or is it racy/forbidden ? Greetings, Alexandre Detiste ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd user service when x is started
I don't understand, if you start X manually, why don't you launch systemctl --user wm.target from your .xprofile or an equivalent file? I maybe was not explicit enough. I have a bunch of user services started as soon as I log in. -- gabx@hortensia ➤➤ core/linux % systemctl --user status ● hortensia State: running Jobs: 0 queued Failed: 0 units Since: Fri 2014-11-07 10:55:24 CET; 10h ago CGroup: /user.slice/user-1000.slice/user@1000.service ├─761 /usr/lib/systemd/systemd --user ├─762 (sd-pam) ├─dbus.service │ └─803 /usr/bin/dbus-daemon --session --address=systemd: --nofork --systemd-activation ├─tmux.service │ ├─6488 /usr/bin/tmux new-session -d -n irc irssi zsh │ ├─6489 zsh -c irssi zsh │ └─6490 irssi ├─urxvtd.service │ └─1132 /usr/bin/urxvtd -o -q -f ├─gpg-agent.service │ └─805 /usr/bin/gpg-agent --daemon --homedir=/home/gabx/.config/gnupg └─ssh-agent.service └─801 /usr/bin/ssh-agent -d -a /run/user/1000/ssh_auth_sock then I $ startx After this command, I would like systemctl --user start some services (window manager, etc). The first bunch of services are grouped under the console.target. Now I am looking for a way to group GUI services in something like graphical.target (or whatever else name). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shared/install: when unit contains only Also=, report 'indirect'
Lennart Poettering lenn...@poettering.net writes:
On Fri, 07.11.14 15:18, Jan Synacek (jsyna...@redhat.com) wrote:
}
if (!isempty(state))
log_syntax(unit, LOG_ERR, filename, line, EINVAL,
@@ -1043,7 +1049,8 @@ static int unit_file_load(
const char *path,
const char *root_dir,
bool allow_symlink,
-bool load) {
+bool load,
+char ***also) {
Hmm, do we really want to return the full list here? I don't think any
caller really is interested in that, or am I wrong? Wouldn't a bool*
suffice here that tells us if also is empty, that we fill in?
No, it's not necessary. I'm not sure why I wrote it that way. Let's
blame it on friday...
I mean, I think the inner calls should parse the whole strv, i see no
problem with that, I just don't think we really need to pass the whole
thing all the way up...
const ConfigTableItem items[] = {
{ Install, Alias, config_parse_strv,
0, info-aliases },
@@ -1087,6 +1094,9 @@ static int unit_file_load(
if (r 0)
return r;
+if (also !strv_isempty(info-also))
+*also = strv_copy(info-also);
+
If the argument would just be a bool* we wouldn't have to do the
expensive strv_copy() here... (which is missing an OOM check btw...)
Otherwise looks great!
Lennart
Next version incoming!
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
[systemd-devel] [PATCH v2] shared/install: when unit contains only Also=, report 'indirect'
If a unit contains only Also=, with no Alias= or WantedBy=, it shouldn't
be reported as static. New 'indirect' status shall be introduced.
https://bugzilla.redhat.com/show_bug.cgi?id=864298
---
Changes in version 2
- don't pass the whole strv to the higher level calls, use bool instead
man/systemctl.xml | 5 +
src/shared/install.c | 45 +++--
src/shared/install.h | 2 ++
src/systemctl/systemctl.c | 7 +++
4 files changed, 41 insertions(+), 18 deletions(-)
diff --git a/man/systemctl.xml b/man/systemctl.xml
index 7cbaa6c..fa85d0b 100644
--- a/man/systemctl.xml
+++ b/man/systemctl.xml
@@ -1013,6 +1013,11 @@ kobject-uevent 1 systemd-udevd-kernel.socket
systemd-udevd.service
entry0/entry
/row
row
+entryliteralindirect/literal/entry
+entryUnit's status is determined indirectly by another
unit(s) specified in literalAlso=/literal in [Install] section/entry
+entry0/entry
+ /row
+ row
entryliteraldisabled/literal/entry
entryUnit is not enabled/entry
entry1/entry
diff --git a/src/shared/install.c b/src/shared/install.c
index cab93e8..8a7f7e2 100644
--- a/src/shared/install.c
+++ b/src/shared/install.c
@@ -840,6 +840,7 @@ static void install_info_free(InstallInfo *i) {
strv_free(i-aliases);
strv_free(i-wanted_by);
strv_free(i-required_by);
+strv_free(i-also);
free(i-default_instance);
free(i);
}
@@ -948,6 +949,7 @@ static int config_parse_also(
size_t l;
const char *word, *state;
InstallContext *c = data;
+InstallInfo *i = userdata;
assert(filename);
assert(lvalue);
@@ -964,6 +966,10 @@ static int config_parse_also(
r = install_info_add(c, n, NULL);
if (r 0)
return r;
+
+r = strv_extend(i-also, n);
+if (r 0)
+return r;
}
if (!isempty(state))
log_syntax(unit, LOG_ERR, filename, line, EINVAL,
@@ -1043,7 +1049,8 @@ static int unit_file_load(
const char *path,
const char *root_dir,
bool allow_symlink,
-bool load) {
+bool load,
+bool *also) {
const ConfigTableItem items[] = {
{ Install, Alias, config_parse_strv,
0, info-aliases },
@@ -1087,6 +1094,9 @@ static int unit_file_load(
if (r 0)
return r;
+if (also)
+*also = !strv_isempty(info-also);
+
return
(int) strv_length(info-aliases) +
(int) strv_length(info-wanted_by) +
@@ -1099,7 +1109,8 @@ static int unit_file_search(
LookupPaths *paths,
const char *root_dir,
bool allow_symlink,
-bool load) {
+bool load,
+bool *also) {
char **p;
int r;
@@ -1109,7 +1120,7 @@ static int unit_file_search(
assert(paths);
if (info-path)
-return unit_file_load(c, info, info-path, root_dir,
allow_symlink, load);
+return unit_file_load(c, info, info-path, root_dir,
allow_symlink, load, also);
assert(info-name);
@@ -1120,7 +1131,7 @@ static int unit_file_search(
if (!path)
return -ENOMEM;
-r = unit_file_load(c, info, path, root_dir, allow_symlink,
load);
+r = unit_file_load(c, info, path, root_dir, allow_symlink,
load, also);
if (r = 0) {
info-path = path;
path = NULL;
@@ -1149,7 +1160,7 @@ static int unit_file_search(
if (!path)
return -ENOMEM;
-r = unit_file_load(c, info, path, root_dir,
allow_symlink, load);
+r = unit_file_load(c, info, path, root_dir,
allow_symlink, load, also);
if (r = 0) {
info-path = path;
path = NULL;
@@ -1167,7 +1178,8 @@ static int unit_file_can_install(
LookupPaths *paths,
const char *root_dir,
const char *name,
-bool allow_symlink) {
+bool allow_symlink,
+bool *also) {
_cleanup_(install_context_done) InstallContext c = {};
InstallInfo *i;
@@ -1182,7 +1194,7 @@ static int unit_file_can_install(
assert_se(i = ordered_hashmap_first(c.will_install));
-r = unit_file_search(c, i, paths, root_dir, allow_symlink, true);
+
[systemd-devel] remount
When I start a container like this: [root@limsdev ~]# systemd-nspawn -bD /home/limsbox --bind-ro=/usr/lib64 --bind-ro=/home/oracle/Ora12c/db Is there any way I can stop the container root from being able to do this?: ~ # mount -o remount,rw /usr/lib64 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Expected behavior when systemd cannot load SELinux policy
On 11/07/2014 11:09 AM, Lennart Poettering wrote: On Fri, 07.11.14 11:30, Jan Synáček (jsyna...@redhat.com) wrote: Hello, currently, when SELINUX=enforcing and SELINUXTYPE=invalid value are set in /etc/selinux/config, systemd refuses to boot with Failed to load SELinux policy. Freezing. Is this really what should happen? If SELINUX is set to permissive or disabled, though, systemd happily continues booting. I think that that's what should happen when SELINUX is set to enforcing as well. Plus a big warning in the log, or maybe even on the console, of course. What do you think? Well, if we are in enforcing mode then this means that everything that is not OK needs to fail, and this includes the policy being corrupted or missing really. Enforcing mode is really this super secure mode where we'd rather hang the machine then possibly allow things to go through that might not be let through if the policy would be order... Lennart Yes think of super secure systems. If you had a machine that contained TopSecret information, then booting without the policy in effect would potentially lead to compromised information. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
