Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
Hi On Fri, Oct 17, 2014 at 6:14 PM, Colin Guthrie gm...@colin.guthr.ie wrote: Hi, How soon after login can I rely on systemd --user having reached sockets.target? This feels a bit like a you shouldn't rely on that point in time... type answer is warrented, and when e.g. GNOME or KDE sessions fully use systemd to bring themselves up it won't be an issue, but right now, systemd --user is started by (I think) PAM. I want to rely on systemd --user to handle PulseAudio's activation (ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE might start up their own session stuff and spawn some PA consuming process before systemd --user has reached it's sockets.target and is thus ready and listening on PA's native socket. Doesn't seem to be a problem on my machine here (it's working really nicely actually!) but figured I should ask here too. Ordering of user units is (see /usr/lib/systemd/user/): default.target after basic.target after sockets.target PAM creates sessions by calling into systemd's pam-module, which then uses CreateSession() (internal api!). This call does not return until the job of user@.service is done. `systemd --user` notifies READY=1 only after default.target is ready. Long story short: The PAM module blocks until the user-manager is ready. Therefore, sockets.target is loaded and ready. (I'm no expert in sd job handling, so maybe Lennart can confirm this) Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] udev hwdb: Support shipping pre-compiled database in system images
On Sunday 19 October 2014 at 05:42:28, Ivan Shapovalov wrote: On Friday 17 October 2014 at 15:44:51, Martin Pitt wrote: Hello again, the previous patch had a typo in the manpage (it said /lib/udev instead of /usr/lib/udev at one place), and also forgot to adjust systemd-udev-hwdb-update.service.in. Both done now. However, the latter currently has a gotcha: +ConditionPathExists=!@udevlibexecdir@/hwdb.bin This works correctly if you use this with the factory reset semantics, i. e. start with an empty /etc. But it would not work if you update /usr and have an already existing /etc/udev/hwdb.d/*. So ideally the condition would be ConditionPathExists=!@udevlibexecdir@/hwdb.bin OR ConditionDirectoryNotEmpty=/etc/udev/hwdb.d/ but this isn't possible AFAIK. The alternative would be to change the Exec= to call hdwb --update --vendor iff /etc/udev/hwdb.d/ is empty. I'm just an innocent bystander, but isn't it possible with these two lines? ConditionPathExists=|!@udevlibexecdir@/hwdb.bin ConditionDirectoryNotEmpty=|/etc/udev/hwdb.d/ This will succeed if EITHER @udevlibexecdir@/hwdb.bin does not exist OR /etc/udev/hwdb.d/ is not empty. Or have I misunderstood you? Ugh, I haven't seen your second message. There's something strange with mail delivery -- I could swear that I've fetched everything before replying... Sorry for the noise. -- 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
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
David Herrmann wrote on 19/10/14 12:05: Hi On Fri, Oct 17, 2014 at 6:14 PM, Colin Guthrie gm...@colin.guthr.ie wrote: Hi, How soon after login can I rely on systemd --user having reached sockets.target? This feels a bit like a you shouldn't rely on that point in time... type answer is warrented, and when e.g. GNOME or KDE sessions fully use systemd to bring themselves up it won't be an issue, but right now, systemd --user is started by (I think) PAM. I want to rely on systemd --user to handle PulseAudio's activation (ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE might start up their own session stuff and spawn some PA consuming process before systemd --user has reached it's sockets.target and is thus ready and listening on PA's native socket. Doesn't seem to be a problem on my machine here (it's working really nicely actually!) but figured I should ask here too. Ordering of user units is (see /usr/lib/systemd/user/): default.target after basic.target after sockets.target PAM creates sessions by calling into systemd's pam-module, which then uses CreateSession() (internal api!). This call does not return until the job of user@.service is done. `systemd --user` notifies READY=1 only after default.target is ready. Long story short: The PAM module blocks until the user-manager is ready. Therefore, sockets.target is loaded and ready. (I'm no expert in sd job handling, so maybe Lennart can confirm this) Thanks for the clarification. This is pretty much what Lennart thought when I quizzed him a couple nights ago, but said he'd double check. It sound like this is indeed the case. Nice :) 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] How soon after login can I rely on systemd --user having reached sockets.target?
On Sun, Oct 19, 2014 at 12:43:59PM +0200, Colin Guthrie wrote: David Herrmann wrote on 19/10/14 12:05: Hi On Fri, Oct 17, 2014 at 6:14 PM, Colin Guthrie gm...@colin.guthr.ie wrote: Hi, How soon after login can I rely on systemd --user having reached sockets.target? This feels a bit like a you shouldn't rely on that point in time... type answer is warrented, and when e.g. GNOME or KDE sessions fully use systemd to bring themselves up it won't be an issue, but right now, systemd --user is started by (I think) PAM. I want to rely on systemd --user to handle PulseAudio's activation (ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE might start up their own session stuff and spawn some PA consuming process before systemd --user has reached it's sockets.target and is thus ready and listening on PA's native socket. Doesn't seem to be a problem on my machine here (it's working really nicely actually!) but figured I should ask here too. Ordering of user units is (see /usr/lib/systemd/user/): default.target after basic.target after sockets.target PAM creates sessions by calling into systemd's pam-module, which then uses CreateSession() (internal api!). This call does not return until the job of user@.service is done. `systemd --user` notifies READY=1 only after default.target is ready. Hm, this seems a bit excessive, because default.target can take a while. basic.target would seem more natural. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
On Sun, Oct 19, 2014 at 4:58 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Sun, Oct 19, 2014 at 12:43:59PM +0200, Colin Guthrie wrote: David Herrmann wrote on 19/10/14 12:05: Hi On Fri, Oct 17, 2014 at 6:14 PM, Colin Guthrie gm...@colin.guthr.ie wrote: Hi, How soon after login can I rely on systemd --user having reached sockets.target? This feels a bit like a you shouldn't rely on that point in time... type answer is warrented, and when e.g. GNOME or KDE sessions fully use systemd to bring themselves up it won't be an issue, but right now, systemd --user is started by (I think) PAM. I want to rely on systemd --user to handle PulseAudio's activation (ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE might start up their own session stuff and spawn some PA consuming process before systemd --user has reached it's sockets.target and is thus ready and listening on PA's native socket. Doesn't seem to be a problem on my machine here (it's working really nicely actually!) but figured I should ask here too. Ordering of user units is (see /usr/lib/systemd/user/): default.target after basic.target after sockets.target PAM creates sessions by calling into systemd's pam-module, which then uses CreateSession() (internal api!). This call does not return until the job of user@.service is done. `systemd --user` notifies READY=1 only after default.target is ready. Hm, this seems a bit excessive, because default.target can take a while. basic.target would seem more natural. Same -- I never noticed this since I have linger enabled, but I would be a bit worried about the login blocking until /all/ of my services have started... Which makes socket activation not very useful. -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Apply ProtectSystem to non-merged /usr directories
Hello all,
in Debian/Ubuntu we don't use the merged /usr tree for now. systemd
generally supports that (HAVE_SPLIT_USR), but doesn't consider that
for ProtectSystem=.
Ansgar (CC'ed) wrote a Debian specific patch for that some months ago.
I generalized it for upstream now.
Thanks for considering,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From 84133fed054b02702955d9371a553c213a45ee9e Mon Sep 17 00:00:00 2001
From: Martin Pitt martin.p...@ubuntu.com
Date: Sun, 19 Oct 2014 11:56:45 -0400
Subject: [PATCH] Apply ProtectSystem to non-merged /usr directories
For systems that don't use a merged /usr, also protect /bin, /sbin, /lib, and
/lib64.
Separately handle /etc (for ProtectSystem=full) to make the code a bit easier
to read.
Replace hard-coded length of systemd dirs list with strv_length() to avoid
pitfalls.
---
src/core/namespace.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/src/core/namespace.c b/src/core/namespace.c
index ab03aeb..ac48f4d 100644
--- a/src/core/namespace.c
+++ b/src/core/namespace.c
@@ -420,6 +420,12 @@ static int make_read_only(BindMount *m) {
return r;
}
+#ifdef HAVE_SPLIT_USR
+#define SYSTEM_DIRS STRV_MAKE(/usr, /bin, /sbin, /lib, -/lib64, -/boot)
+#else
+#define SYSTEM_DIRS STRV_MAKE(/usr, -/boot)
+#endif
+
int setup_namespace(
char** read_write_dirs,
char** read_only_dirs,
@@ -448,7 +454,7 @@ int setup_namespace(
strv_length(inaccessible_dirs) +
private_dev +
(protect_home != PROTECT_HOME_NO ? 3 : 0) +
-(protect_system != PROTECT_SYSTEM_NO ? 2 : 0) +
+(protect_system != PROTECT_SYSTEM_NO ? strv_length(SYSTEM_DIRS) : 0) +
(protect_system == PROTECT_SYSTEM_FULL ? 1 : 0);
if (n 0) {
@@ -496,9 +502,14 @@ int setup_namespace(
}
if (protect_system != PROTECT_SYSTEM_NO) {
-r = append_mounts(m, protect_system == PROTECT_SYSTEM_FULL ? STRV_MAKE(/usr, -/boot, /etc) : STRV_MAKE(/usr, -/boot), READONLY);
+r = append_mounts(m, SYSTEM_DIRS, READONLY);
if (r 0)
return r;
+if (protect_system == PROTECT_SYSTEM_FULL) {
+r = append_mounts(m, STRV_MAKE(/etc), READONLY);
+if (r 0)
+return r;
+}
}
assert(mounts + n == m);
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] udev hwdb: Support shipping pre-compiled database in system images
Hello Ivan, Ivan Shapovalov [2014-10-19 5:42 +0400]: but this isn't possible AFAIK. The alternative would be to change the Exec= to call hdwb --update --vendor iff /etc/udev/hwdb.d/ is empty. I'm just an innocent bystander, but isn't it possible with these two lines? ConditionPathExists=|!@udevlibexecdir@/hwdb.bin ConditionDirectoryNotEmpty=|/etc/udev/hwdb.d/ This will succeed if EITHER @udevlibexecdir@/hwdb.bin does not exist OR /etc/udev/hwdb.d/ is not empty. Correct. That's indeed what got pointed out to me on IRC on Friday, and I sent another followup to the list. For some unknown reason that didn't actually hit the list though, so I bounced my reply again this morning. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
