Re: [systemd-devel] [systemd-commits] units/basic.target units/poweroff.target units/reboot.target
Zbigniew Jędrzejewski-Szmek wrote on 06/11/14 05:52: However, this one appears bogus to me. Is there any such software around that really does this? And if so, this really appears weird to me to support. Delaying shutdown for more than 30min is just wrong. Isn't this what the various download updates and reboot gnome-y things are doing? I thought they rebooted into a special mode and then did their upgrades and then rebooted again. I don't think the updates are actually performed *while* rebooting. But I could be wrong here as I've not looked at it too closely yet (as much as I would like to) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] rules: rerun vconsole-setup when switching from vgacon to fbcon
Hi On Wed, Nov 5, 2014 at 4:11 PM, Ray Strode halfl...@gmail.com wrote: Hi, On Wed, Nov 5, 2014 at 9:53 AM, David Herrmann dh.herrm...@gmail.com wrote: I had that change locally, but didn't push it because vconsole is optional. Thus, this rule must be optional, too. I'm now digging into autoconf+m4 to see how to do this... but I'm getting nowhere so far... Well you could: 1) rename 99-systemd.rules.in to 99-systemd.rules.in.in and then add it to AC_CONFIG_FILES in configure.ac and add substitution variable to 99-systemd.rules.in.in that expands to the empty string when ENABLE_VCONSOLE isn't set and the udev rule when it is set. I don't like that though, it would mean separating the udev rule from the file. 2) Alternatively, you could leave 99-systemd.rules.in as is and hack SED_PROCESS stuff in the makefile to remove the line if ENABLE_VCONSOLE isn't set. I don't like this either, it's ugly. E, this does indeed all sound ugly. 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.. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] shared/install: don't report 'static' when unit contains only Also=
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. Jan Synacek (1): shared/install: don't report 'static' when unit contains only Also= src/shared/install.c | 23 ++- 1 file changed, 22 insertions(+), 1 deletion(-) -- 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: don't report 'static' when unit contains only Also=
If a unit contains only Also=, with no Alias= or WantedBy=, it shouldn't
be reported as static. If any target unit specified in Also= is enabled
or disabled, report this unit as enabled or disabled as well.
https://bugzilla.redhat.com/show_bug.cgi?id=864298
---
src/shared/install.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/src/shared/install.c b/src/shared/install.c
index cab93e8..781832f 100644
--- a/src/shared/install.c
+++ b/src/shared/install.c
@@ -1874,8 +1874,29 @@ UnitFileState unit_file_get_state(
return r;
else if (r 0)
return UNIT_FILE_DISABLED;
-else if (r == 0)
+else if (r == 0) {
+_cleanup_(install_context_done) InstallContext c = {};
+InstallInfo info = {}, *tmp;
+Iterator it;
+const char *key;
+
+(void) unit_file_load(c, info, path, root_dir, true,
true);
+
+/* At this point, the unit contains only Also=, no
Alias= or WantedBy= are specified.
+ It can be enabled/disabled through any of the Also=
targets, we should check
+ if they're enabled/disabled. */
+if (c.will_install) {
+ORDERED_HASHMAP_FOREACH_KEY(tmp, key,
c.will_install, it) {
+r = find_symlinks_in_scope(scope,
root_dir, key, state);
+if (r 0)
+return r;
+else if (r 0)
+return state;
+}
+return UNIT_FILE_DISABLED;
+}
return UNIT_FILE_STATIC;
+}
}
return r 0 ? r : state;
--
1.9.3
___
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
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. systemd: http://cgit.freedesktop.org/systemd/systemd/commit/?id=f6ba8671d83f9fce9a00045d8fa399a1c07ba7fc dracut: http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=027565d0233f76edf434b63a847a717185d267e2 Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] bus-proxy: cloning smack label
When dbus client connects to systemd-bus-proxyd through
Unix domain socket proxy takes client's smack label and sets for itself.
It is done before and independent of dropping privileges.
The reason of such soluton is fact that tests of access rights
performed by lsm may take place inside kernel, not only
in userspace of recipient of message.
The bus-proxyd needs CAP_MAC_ADMIN to manipulate its label.
In case of systemd running in system mode, CAP_MAC_ADMIN
should be added to CapabilityBoundingSet in service file of bus-proxyd.
In case of systemd running in user mode ('systemd --user')
it can be achieved by addition
Capabilities=cap_mac_admin=i and SecureBits=keep-caps
to user@.service file
and setting cap_mac_admin+ei on bus-proxyd binary.
Signed-off-by: Przemyslaw Kedzierski p.kedzier...@samsung.com
---
src/bus-proxyd/bus-proxyd.c | 16
src/shared/capability.c | 18 ++
src/shared/capability.h | 2 ++
src/shared/smack-util.c | 18 ++
src/shared/smack-util.h | 1 +
units/systemd-bus-pro...@.service.in | 2 +-
units/u...@.service.in | 2 ++
7 files changed, 58 insertions(+), 1 deletion(-)
diff --git a/src/bus-proxyd/bus-proxyd.c b/src/bus-proxyd/bus-proxyd.c
index d10de2f..066232e 100644
--- a/src/bus-proxyd/bus-proxyd.c
+++ b/src/bus-proxyd/bus-proxyd.c
@@ -45,6 +45,7 @@
#include def.h
#include capability.h
#include bus-policy.h
+#include smack-util.h
static char *arg_address = NULL;
static char *arg_command_line_buffer = NULL;
@@ -1168,6 +1169,21 @@ int main(int argc, char *argv[]) {
if (is_unix) {
(void) getpeercred(in_fd, ucred);
(void) getpeersec(in_fd, peersec);
+
+if (mac_smack_use()) {
+if (peersec) {
+
+r = mac_smack_set_process_label(peersec);
+if (r 0)
+log_warning(Failed to set SMACK label
%s : %s, peersec, strerror(-r));
+} else {
+log_warning(Invalid SMACK label);
+}
+
+r = drop_capability(CAP_MAC_ADMIN);
+if (r 0)
+log_warning(Failed to drop CAP_MAC_ADMIN:
%s, strerror(-r));
+}
}
if (arg_drop_privileges) {
diff --git a/src/shared/capability.c b/src/shared/capability.c
index 0226542..9dc42ec 100644
--- a/src/shared/capability.c
+++ b/src/shared/capability.c
@@ -285,3 +285,21 @@ int drop_privileges(uid_t uid, gid_t gid, uint64_t
keep_capabilities) {
return 0;
}
+
+int drop_capability(cap_value_t cv) {
+_cleanup_cap_free_ cap_t tmp_cap = NULL;
+
+tmp_cap = cap_get_proc();
+if (!tmp_cap)
+return -errno;
+
+if ((cap_set_flag(tmp_cap, CAP_INHERITABLE, 1, cv, CAP_CLEAR) 0) ||
+(cap_set_flag(tmp_cap, CAP_PERMITTED, 1, cv, CAP_CLEAR) 0) ||
+(cap_set_flag(tmp_cap, CAP_EFFECTIVE, 1, cv, CAP_CLEAR) 0))
+return -errno;
+
+if (cap_set_proc(tmp_cap) 0)
+return -errno;
+
+return 0;
+}
diff --git a/src/shared/capability.h b/src/shared/capability.h
index 3e6d999..6f2f6f9 100644
--- a/src/shared/capability.h
+++ b/src/shared/capability.h
@@ -34,6 +34,8 @@ int capability_bounding_set_drop_usermode(uint64_t drop);
int drop_privileges(uid_t uid, gid_t gid, uint64_t keep_capabilites);
+int drop_capability(cap_value_t cv);
+
DEFINE_TRIVIAL_CLEANUP_FUNC(cap_t, cap_free);
#define _cleanup_cap_free_ _cleanup_(cap_freep)
diff --git a/src/shared/smack-util.c b/src/shared/smack-util.c
index a8dccd1..3e9810c 100644
--- a/src/shared/smack-util.c
+++ b/src/shared/smack-util.c
@@ -181,3 +181,21 @@ int mac_smack_fix(const char *path, bool ignore_enoent,
bool ignore_erofs) {
return r;
}
+
+int mac_smack_set_process_label(char *label) {
+#ifdef HAVE_SMACK
+int ret;
+
+if (!label) {
+log_debug(No SMACK label given);
+return -1;
+}
+ret = write_string_file(/proc/self/attr/current, label);
+if (ret) {
+log_debug(Failed to set current SMACK label \%s\ on self:
%s,
+ label, strerror(-ret));
+return ret;
+}
+#endif
+return 0;
+}
diff --git a/src/shared/smack-util.h b/src/shared/smack-util.h
index 68778da..a49405b 100644
--- a/src/shared/smack-util.h
+++ b/src/shared/smack-util.h
@@ -33,3 +33,4 @@ int mac_smack_apply(const char *path, const char *label);
int mac_smack_apply_fd(int fd, const char *label);
int mac_smack_apply_ip_in_fd(int fd, const char *label);
int mac_smack_apply_ip_out_fd(int fd, const char *label);
+int mac_smack_set_process_label(char *label);
diff --git a/units/systemd-bus-pro...@.service.in
Re: [systemd-devel] [systemd-commits] units/basic.target units/poweroff.target units/reboot.target
On Thu, 06.11.14 06:52, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On shutdown there might be other jobs, like downloading of updates for installation, and other custom jobs. It seems better to schedule an individual timeout on each one separately, when it is known what timeout is useful. However, this one appears bogus to me. Is there any such software around that really does this? And if so, this really appears weird to me to support. Delaying shutdown for more than 30min is just wrong. Isn't this what the various download updates and reboot gnome-y things are doing? No, they shutdown, reboot into a special mode, install, reboot again. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] units/basic.target units/poweroff.target units/reboot.target
However, this one appears bogus to me. Is there any such software around that really does this? And if so, this really appears weird to me to support. Delaying shutdown for more than 30min is just wrong. Isn't this what the various download updates and reboot gnome-y things are doing? At least unattended-upgrades from Debian/Ubuntu/... can be configured to install updates on shutdown (without any special mode or something). And, yes, this can run for more than 30 minutes, which I could already observe in its default mode (installing during normal system activities), so I see no reason why this should not happen when configured to install during shutdown. The reason is, that unattended-upgrades can basically update the whole distribution to the next version, which naturally can take a lot of time. It's questionable if this is a sane setup, but I can think of setups where this might be useful, e.g. having two identically configured servers for redundancy reasons where one server would be enough. Then it might make sense to update one system during shutdown while the other one takes over. This has the advantage, that normally running servers either have the old or the new state, but never some intermediate state during the update. The shutdown time does not really matter in this case and a watchdog killing the system wouldn't be welcome. But all in all this seems like an exotic use case. 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
Re: [systemd-devel] [systemd-commits] units/basic.target units/poweroff.target units/reboot.target
On Thu, Nov 06, 2014 at 12:48:23PM +0100, Lennart Poettering wrote: On Thu, 06.11.14 06:52, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On shutdown there might be other jobs, like downloading of updates for installation, and other custom jobs. It seems better to schedule an individual timeout on each one separately, when it is known what timeout is useful. However, this one appears bogus to me. Is there any such software around that really does this? And if so, this really appears weird to me to support. Delaying shutdown for more than 30min is just wrong. Isn't this what the various download updates and reboot gnome-y things are doing? No, they shutdown, reboot into a special mode, install, reboot again. I know that package *installation* is done after reboot. I was thinking that the *download* was done during shutdown. But it appears that the 'install and shutdown' dialog button appears only after they have been downloaded. In other words, they are downloaded while system is running. It seems that indeed there's no reason for long shutdowns right now. I reenabled the timeouts now in git. Zbyszek ___ 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 Thu, 06.11.14 12:45, Patrick Häcker (pa...@web.de) wrote: However, this one appears bogus to me. Is there any such software around that really does this? And if so, this really appears weird to me to support. Delaying shutdown for more than 30min is just wrong. Isn't this what the various download updates and reboot gnome-y things are doing? At least unattended-upgrades from Debian/Ubuntu/... can be configured to install updates on shutdown (without any special mode or something). And, yes, this can run for more than 30 minutes, which I could already observe in its default mode (installing during normal system activities), so I see no reason why this should not happen when configured to install during shutdown. The reason is, that unattended-upgrades can basically update the whole distribution to the next version, which naturally can take a lot of time. It's questionable if this is a sane setup, but I can think of setups where this might be useful, e.g. having two identically configured servers for redundancy reasons where one server would be enough. Then it might make sense to update one system during shutdown while the other one takes over. This has the advantage, that normally running servers either have the old or the new state, but never some intermediate state during the update. The shutdown time does not really matter in this case and a watchdog killing the system wouldn't be welcome. But all in all this seems like an exotic use case. Is unattended-upgrades a package of its own? 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. I think we should find good defaults, that work for most cases, and make things robust in the common case. Now, an fsck or selinux relabel taking a long time is a pretty common case, we shouldn't break that, hence I figure turning off the boot timeout is probably a good idea. However, doing unattended upgrades at shutdown is not really a common case. 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] hostnamed: add chassis type robot
On Thu, 06.11.14 06:34, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Wed, Nov 05, 2014 at 06:40:51PM +0100, Noé Rubinstein wrote: --- man/hostnamectl.xml | 3 ++- man/machine-info.xml | 3 ++- shell-completion/bash/hostnamectl | 2 +- shell-completion/zsh/_hostnamectl | 2 +- src/hostname/hostnamed.c | 3 ++- 5 files changed, 8 insertions(+), 5 deletions(-) diff --git a/man/hostnamectl.xml b/man/hostnamectl.xml index 128d92f..0292bad 100644 --- a/man/hostnamectl.xml +++ b/man/hostnamectl.xml @@ -217,7 +217,8 @@ literalserver/literal, literaltablet/literal, literalhandset/literal, -literalwatch/literal, as well as +literalwatch/literal, +literalrobot/literal, as well as the special chassis types literalvm/literal and literalcontainer/literal for This is a nice fun patch. But I'm a bit concerned where this is going... Soon we'll have to add fridge, car, aircraft, ISS, extraterrestial rover, etc., since systmed is being used everywhere. I know that it's rather mundane, but would other work for you instead? Hmm, maybe embedded would be a good idea, to cover all those aircraft, ISS, car, fridge, robot things? other sounds so generic, that it stops being useful... 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] hostnamed: add chassis type robot
On Thu, 06.11.14 14:34, Lennart Poettering (lenn...@poettering.net) wrote: On Thu, 06.11.14 06:34, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Wed, Nov 05, 2014 at 06:40:51PM +0100, Noé Rubinstein wrote: --- man/hostnamectl.xml | 3 ++- man/machine-info.xml | 3 ++- shell-completion/bash/hostnamectl | 2 +- shell-completion/zsh/_hostnamectl | 2 +- src/hostname/hostnamed.c | 3 ++- 5 files changed, 8 insertions(+), 5 deletions(-) diff --git a/man/hostnamectl.xml b/man/hostnamectl.xml index 128d92f..0292bad 100644 --- a/man/hostnamectl.xml +++ b/man/hostnamectl.xml @@ -217,7 +217,8 @@ literalserver/literal, literaltablet/literal, literalhandset/literal, -literalwatch/literal, as well as +literalwatch/literal, +literalrobot/literal, as well as the special chassis types literalvm/literal and literalcontainer/literal for This is a nice fun patch. But I'm a bit concerned where this is going... Soon we'll have to add fridge, car, aircraft, ISS, extraterrestial rover, etc., since systmed is being used everywhere. I know that it's rather mundane, but would other work for you instead? Hmm, maybe embedded would be a good idea, to cover all those aircraft, ISS, car, fridge, robot things? I have added that now, to cut this short. Noé, does this work for you? 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] [systemd-commits] units/basic.target units/poweroff.target units/reboot.target
On Thu, Nov 06, 2014 at 02:28:12PM +0100, Lennart Poettering wrote: On Thu, 06.11.14 12:45, Patrick Häcker (pa...@web.de) wrote: However, this one appears bogus to me. Is there any such software around that really does this? And if so, this really appears weird to me to support. Delaying shutdown for more than 30min is just wrong. Isn't this what the various download updates and reboot gnome-y things are doing? At least unattended-upgrades from Debian/Ubuntu/... can be configured to install updates on shutdown (without any special mode or something). And, yes, this can run for more than 30 minutes, which I could already observe in its default mode (installing during normal system activities), so I see no reason why this should not happen when configured to install during shutdown. The reason is, that unattended-upgrades can basically update the whole distribution to the next version, which naturally can take a lot of time. It's questionable if this is a sane setup, but I can think of setups where this might be useful, e.g. having two identically configured servers for redundancy reasons where one server would be enough. Then it might make sense to update one system during shutdown while the other one takes over. This has the advantage, that normally running servers either have the old or the new state, but never some intermediate state during the update. The shutdown time does not really matter in this case and a watchdog killing the system wouldn't be welcome. But all in all this seems like an exotic use case. Is unattended-upgrades a package of its own? 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 is suboptimal. There really should be a way to this dynamically, like saying: I'm a log-running job, I need more time, but everything is still fine. This type of status should require periodical pings, watchdog style. Let's say that the backup job run during shutdown hangs because there's no network, we want to shutdown at some point anyway. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] does poweroff -f really sync
On a related note: if I read the code correctly, reboot -f or JobFailureAction=reboot-force should sync the filesystems. But this doesn't seem to work: - on fedora-devel Adam W. said that fsck ran after a boot timeout - yesterday I did something like 'sudo install ./systemd /usr/lib/systemd/ sudo reboot -f' and ended up with an _empty_ file in /usr/lib/systmed/systemd. Am I missing something? Does this look like a kernel bug, or some timing issue? Maybe the sync in running asynchronously? Zbyszek ___ 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 11/06/2014 01:28 PM, Lennart Poettering wrote: However, doing unattended upgrades at shutdown is not really a common case. Well for Debian and Debian based distribution it most certainly can be the case since it has allowed for it's update/upgrade mechanism to be configured to install updates on shutdown. In Fedora we had at least couple of cases where users were doing the same. And if memory serves me correct with at least one case that was one large installation in university where they had an cron job that updated the lab computers , then shut them down at a spesific time of day or updated them before they got shutdown In both cases ( cronjob, shutdown command ) I think the solution would be to create a unit that is installed and executed before the shutdown target. JBG ___ 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 Thu, Nov 06, 2014 at 02:12:52PM +, Jóhann B. Guðmundsson wrote: On 11/06/2014 01:28 PM, Lennart Poettering wrote: However, doing unattended upgrades at shutdown is not really a common case. Well for Debian and Debian based distribution it most certainly can be the case since it has allowed for it's update/upgrade mechanism to be configured to install updates on shutdown. In Fedora we had at least couple of cases where users were doing the same. And if memory serves me correct with at least one case that was one large installation in university where they had an cron job that updated the lab computers , then shut them down at a spesific time of day or updated them before they got shutdown In both cases ( cronjob, shutdown command ) I think the solution would be to create a unit that is installed and executed before the shutdown target. What matters is how it is all arranged: - if there's a job that does stuff, and then calls reboot or shutdown - a hook into the shutdown or reboot target does some work In the first case, things are fine. In the second, not. But it seems that only the first case is actually used. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] does poweroff -f really sync
On Thu, 06.11.14 15:08, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On a related note: if I read the code correctly, reboot -f or JobFailureAction=reboot-force should sync the filesystems. But this doesn't seem to work: - on fedora-devel Adam W. said that fsck ran after a boot timeout - yesterday I did something like 'sudo install ./systemd /usr/lib/systemd/ sudo reboot -f' and ended up with an _empty_ file in /usr/lib/systmed/systemd. Am I missing something? Does this look like a kernel bug, or some timing issue? Maybe the sync in running asynchronously? Well, it will sync() but the fs will still be dirty and thus require fsck on next boot. If you want to avoid that you need to umount all before rebooting. That said, while we have the sync() in place before we invoke reboot() during clean shutdowns (see shutdown.c) we actually are missing that when you invoke reboot -f. Or more, correctly: we *were* missing it until 30s ago, until I added it there too. I'd really recommend running systemctl reboot -f though in such emergency situations, since it will immediately reboot, but still umount all file systems before. systemctl reboot -ff (which is the same as reboot -f) is really just the last emergency if PID 1 is hung. 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] s/commandline/command line/g
On 05.11.2014 14:56, har...@redhat.com wrote: From: Harald Hoyer har...@redhat.com --- TODO | 2 +- m4/attributes.m4 | 2 +- man/systemd-bootchart.xml | 4 ++-- man/systemd-delta.xml | 2 +- man/systemd-run.xml| 2 +- man/systemd.link.xml | 2 +- man/udev.conf.xml | 2 +- src/core/shutdown.c| 2 +- src/cryptsetup/cryptsetup-generator.c | 4 ++-- src/fstab-generator/fstab-generator.c | 2 +- src/journal/coredump.c | 2 +- src/network/networkd-wait-online-manager.c | 2 +- src/shared/condition-util.c| 2 +- src/udev/collect/collect.c | 2 +- src/udev/net/link-config.c | 2 +- src/udev/udevd.c | 2 +- 16 files changed, 18 insertions(+), 18 deletions(-) pushed ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] switch_root: do not fail, if base_filesystem_create() failed
On 04.11.2014 19:17, Daniel Buch wrote:
I think you might want to cast it to avoid compiler warning. Like:
(void) base_filesystem_create()
Den 04/11/2014 17.36 skrev har...@redhat.com mailto:har...@redhat.com:
From: Harald Hoyer har...@redhat.com mailto:har...@redhat.com
Not all switch roots are like base_filesystem_create() wants them
to look like. They might even boot, if they are RO and don't have the FS
layout. Just ignore the error and switch_root nevertheless.
base_filesystem_create() should have logged, what went wrong.
---
src/shared/switch-root.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/src/shared/switch-root.c b/src/shared/switch-root.c
index bac0e5c..673f8a7 100644
--- a/src/shared/switch-root.c
+++ b/src/shared/switch-root.c
@@ -103,11 +103,7 @@ int switch_root(const char *new_root, const char
*oldroot, bool detach_oldroot,
}
}
-r = base_filesystem_create(new_root);
-if (r 0) {
-log_error(Failed to create the base filesystem: %s,
strerror(-r));
-return r;
-}
+base_filesystem_create(new_root);
if (chdir(new_root) 0) {
log_error(Failed to change directory to %s: %m,
new_root);
--
Thanks! Pushed with (void)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] s/commandline/command line/g
On Wed, 05.11.14 14:56, har...@redhat.com (har...@redhat.com) wrote: +++ b/man/systemd-run.xml @@ -215,7 +215,7 @@ along with systemd; If not, see http://www.gnu.org/licenses/. /variablelist paraAll command-line arguments after the first non-option -argument become part of the commandline of the launched +argument become part of the command line of the launched process. If a command is run as service unit, its first argument needs to be an absolute binary path./para /refsect1 I figure there are some more cleanups to be done here... The example above shows that we not only use commandline and command line, but also command-line... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] src/shared
On Thu, 06.11.14 06:28, Harald Hoyer (har...@kemper.freedesktop.org) wrote:
Not all switch roots are like base_filesystem_create() wants them
to look like. They might even boot, if they are RO and don't have the FS
layout. Just ignore the error and switch_root nevertheless.
I think a comment like this would be really good in the code itself, I
think. It's a good idea to explicitly clarify when we cast errors away
I figure.
base_filesystem_create() should have logged, what went wrong.
diff --git a/src/shared/switch-root.c b/src/shared/switch-root.c
index bac0e5c..1a558b8 100644
--- a/src/shared/switch-root.c
+++ b/src/shared/switch-root.c
@@ -47,7 +47,6 @@ int switch_root(const char *new_root, const char *oldroot,
bool detach_oldroot,
struct stat new_root_stat;
bool old_root_remove;
const char *i, *temporary_old_root;
-int r;
if (path_equal(new_root, /))
return 0;
@@ -103,11 +102,7 @@ int switch_root(const char *new_root, const char
*oldroot, bool detach_oldroot,
}
}
-r = base_filesystem_create(new_root);
-if (r 0) {
-log_error(Failed to create the base filesystem: %s,
strerror(-r));
-return r;
-}
+(void) base_filesystem_create(new_root);
if (chdir(new_root) 0) {
log_error(Failed to change directory to %s: %m, new_root);
___
systemd-commits mailing list
systemd-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-commits
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] So how am I supposed to put together my Linux system?
On 22.10.2014 21:08, Tobias Hunger wrote: Hi Lennart, On Wed, Oct 22, 2014 at 7:03 PM, Lennart Poettering lenn...@poettering.net wrote: Sorry for the late response, been travelling for a month, and then have been more travelling, and still trying to process all the mails that queued up since. No problem at all:-) On Fri, Sep 5, 2014 at 6:58 PM, Lennart Poettering I see that secure boot wants one file and that you will need to merge kernel and initrd into one. But you will need the meta data to link the kernel/initrd combo to a combination of root-subvolume and usr-subvolume. IIRC chromeos also has that and stores that meta-data in non-volatile memory accessible to the BIOS. My idea would be that the initrd contains that info. Each usr tree comes with one initrd, and that initrd knows which usr tree to boot. That implies that each installation snapshot must come with an initrd, even if the only change to earlier versions is the snapshot name. That sounds suboptimal to me. But then I am playing with atomic upgrades for a while now and in practice each snapshots comes with its own initrd anyway. 2. If we cannot have external config files, then kernel/initrd should find their stuff an empty kernel cmdline option. Nice ideal, but I do not see how that will work in general. You could bake some id into the kernel (kernel version or whatever), but usually the kernel changes slower than the sum of the files in /usr. You do want to boot different of these usr-setups with one kernel. Note that at least chromeos doesn't do this. They update the whole OS at once, including the kernel. And never kernel and /usr independently. I am following Arch and create new snapshots daily. For me the kernel updates way less often than the rest. The initrd does change for each snapshot though. I need to investigate what is causing that. I would have expected the initrd to change more often than the kernel, but definitely not for each update. Maybe mkinitcpio bakes in some timestamp or something. 4. The initrds should probably use information from /usr/lib/os-release (as shipped in the initrd as a copy of the OS' version) to build the btrfs sub-volume name to boot from. It should not allow overriding this name via the kernel cmdline, at least as long as we are in a mode where secureboot is actually turned on... That could work, provided there is something like a timestamp/version number in /usr/lib/os-release that actually changes every time *anything* in /usr changes (or at least when those changes are getting distributed as an image). You still need to store that information somewhere though for the kernel to know what to boot. Well, gummiboot picks a kernel with the initrd attached. the initrd then finds the right /usr tree according to the information it contains. Hope that makes some sense? Not really. I do see how this can work to boot the newest installation of distroX: You just need to look for the newest version of the usr-subvolume and boot that. Well, I think kernel and /usr hierarchy really belong together. If you pick a kernel you thus implicitly also pick a /usr tree. (Of course, this strict we only need to be for a verified boot. For other cases, we of course can allow passing arbitrary kernel cmdline options, to pick different usr tree. The user should be able to override things, unless the device is in trusted mode) How do I boot the version I ran before the upgrade in case the upgrade failed? In general the rule should probably be to go back in version one-by-one if a kernel/system failed to boot. THe boot loader should by default boot the newest kernel, thus the newest /usr, too. if that for some reason nerver finishes, on next reboot it should pick the kernel one version older, and so on. I really do not see how you can get around storing meta-data somehow. You can not change the kernel/initrd when it is signed, so you can not bake any information into that file. You can apparently not have a separate file when using secure boot. That leaves EFI vars I think. Do those integrate with secure boot? Sure, we can store failure info in EFI Vars, no problem really. I agree that this should work for secure boot and a classic distribution upgrade. For my non-secure boot use case with incremental/daily upgrades the necessary changes to the systemd-fstab-generator were already merged (Thanks!), so I am waiting impatiently for the next systemd release to hit the arch repos. Those were the last bits I needed for my grand atomic upgrade scheme to work without me having to patch stuff locally:-) Now I can proceed to move more of my systems over to actually use it. PS: Your scheme was significantly simpler to get up and running than the ostree-approach I tried before. But maybe that was just because I started out with a working ostree setup:-) Best Regards, Tobias So, this what I do for the
Re: [systemd-devel] [PATCH] smack: introduce new SmackLabelExec option
On Tue, 04.11.14 17:35, WaLyong Cho (walyong@samsung.com) wrote:
In case of systemd has _ label and run as root, if a service file
has User= option and the command line file has a special SMACK label
then systemd will fail to execute the command. Generally, SMACK label
is ignored for the root. But if a service has a User= then systemd
will call setresuid() in the child process. After then it no more
root. So it should have some of executable label for the command. To
set the SMACK64EXEC before the uid is changed introduce new
SmackLabelExec option.
Hmm, I am not sure I like the abbreviation of this. Can't we just call
this SmackLabel=?
+#ifdef HAVE_SMACK
+#include smack-util.h
+#endif
+
ifdeffing the include is unnecessary. YOu can just include it without
ifdef protectionn, there's nothing in it that we need to avoid pullin in.
#define SMACK_FLOOR_LABEL _
@@ -123,6 +124,31 @@ int mac_smack_apply_ip_in_fd(int fd, const char *label) {
return r;
}
+int mac_smack_apply_pid(pid_t pid, const char *label) {
+int r = 0;
+_cleanup_free_ char *path = NULL;
+
+assert(label);
+
+#ifdef HAVE_SMACK
+if (!mac_smack_use())
+return 0;
+
+if (pid)
+r = asprintf(path, /proc/%lu/attr/current, (unsigned
long) pid);
+else
+r = asprintf(path, /proc/self/attr/current);
+if (r 0)
+return -ENOMEM;
Please use procfs_file_alloca() for this. It makes this much nicer!
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] So how am I supposed to put together my Linux system?
On 09.09.2014 17:01, Colin Guthrie wrote: Tobias Hunger wrote on 05/09/14 19:34: Any place that you would care to recomend? It would suck to have each distro put kernels somewhere else. Good question. On Mageia and Fedora (at least originally, not sure if it's changed recently), the modules are in: /lib/modules/kernel-version/ tree. These days this should of course be: /usr/lib/modules/kernel-version/ The actual modules are stored in a: /lib/modules/kernel-version/kernel/ subfolder. If there are no compelling reasons to pick otherwise, we could use: /usr/lib/kernel/kernel-version/ tree. Inside there would be a: /usr/lib/kernel/kernel-version/modules/ folder containing the actual modules (same as /lib/modules/kernel-version/kernel/) For compatibility, the /lib/modules/kernel-version could be symlinked to /usr/lib/kernel/kernel-version and a simple modules - kernel symlink shipped inside the /usr/lib/kernel/kernel-version/ folder. All old paths would work in that case. The kernel itself could then simply be: /usr/lib/kernel/kernel-version/vmlinuz Not sure if this is just completely made up in my head or if this is how others have envisioned it also. I don't think any of the spec documents talked about the actual filesystem layout of the actual kernel files/modules. Cheers Col Hmm, those symlinks would look ugly, but of course /usr/lib/kernel/kernel-version would be the sane name. Anyway, as a first step, I would put just put the kernel, System.map, config and any precompiled initrd in the modules directory: # ls /lib/modules/3.18.0-0.rc0.git9.2.fc22.1.x86_64/ System.map config initrd vmlinuz ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] hostnamed: add chassis type robot
Yes, In our use case (and prolly likewise in a lot of embedded use cases) there is another layer that provides more info on what kind of robot it is. So we are not using this variable for anything other than setting it right now, and embedded sounds good indeed. Thanks, Noé. 2014-11-06 14:39 GMT+01:00 Lennart Poettering lenn...@poettering.net: On Thu, 06.11.14 14:34, Lennart Poettering (lenn...@poettering.net) wrote: On Thu, 06.11.14 06:34, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Wed, Nov 05, 2014 at 06:40:51PM +0100, Noé Rubinstein wrote: --- man/hostnamectl.xml | 3 ++- man/machine-info.xml | 3 ++- shell-completion/bash/hostnamectl | 2 +- shell-completion/zsh/_hostnamectl | 2 +- src/hostname/hostnamed.c | 3 ++- 5 files changed, 8 insertions(+), 5 deletions(-) diff --git a/man/hostnamectl.xml b/man/hostnamectl.xml index 128d92f..0292bad 100644 --- a/man/hostnamectl.xml +++ b/man/hostnamectl.xml @@ -217,7 +217,8 @@ literalserver/literal, literaltablet/literal, literalhandset/literal, -literalwatch/literal, as well as +literalwatch/literal, +literalrobot/literal, as well as the special chassis types literalvm/literal and literalcontainer/literal for This is a nice fun patch. But I'm a bit concerned where this is going... Soon we'll have to add fridge, car, aircraft, ISS, extraterrestial rover, etc., since systmed is being used everywhere. I know that it's rather mundane, but would other work for you instead? Hmm, maybe embedded would be a good idea, to cover all those aircraft, ISS, car, fridge, robot things? I have added that now, to cut this short. Noé, does this work for you? Thanks, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] does poweroff -f really sync
On Thu, Nov 06, 2014 at 03:22:50PM +0100, Lennart Poettering wrote: On Thu, 06.11.14 15:08, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On a related note: if I read the code correctly, reboot -f or JobFailureAction=reboot-force should sync the filesystems. But this doesn't seem to work: - on fedora-devel Adam W. said that fsck ran after a boot timeout - yesterday I did something like 'sudo install ./systemd /usr/lib/systemd/ sudo reboot -f' and ended up with an _empty_ file in /usr/lib/systmed/systemd. Am I missing something? Does this look like a kernel bug, or some timing issue? Maybe the sync in running asynchronously? Well, it will sync() but the fs will still be dirty and thus require fsck on next boot. Well, I'd expect the journal to be replayed without any fsck. That said, while we have the sync() in place before we invoke reboot() during clean shutdowns (see shutdown.c) we actually are missing that when you invoke reboot -f. Or more, correctly: we *were* missing it until 30s ago, until I added it there too. Thanks. That completely explains what I was seeing. I'd really recommend running systemctl reboot -f though in such emergency situations, since it will immediately reboot, but still umount all file systems before. systemctl reboot -ff (which is the same as reboot -f) is really just the last emergency if PID 1 is hung. Zbyszek ___ 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 06/11/14 14:16, Zbigniew Jędrzejewski-Szmek wrote: What matters is how it is all arranged: - if there's a job that does stuff, and then calls reboot or shutdown - a hook into the shutdown or reboot target does some work unattended-upgrades is currently the latter: the user shuts down (or is reminded to shut down by an update notification), and unattended-upgrades runs as a side-effect. This is an optional (non-default) configuration of an optional package, not core Debian/Ubuntu functionality; so it doesn't necessarily have to be like this forever, it could be modified to tell systemd I'm still shutting down, continue to wait periodically, it could be modified to use reboot into a special mode, install, then reboot again logic under systemd if that's something you already have, and, worst-case, it could install a drop-in to override the timeout. The default configuration is currently to perform the upgrades in-place and prompt the user to reboot when convenient, just like a manual apt/zypp/etc. run would. I have worked on improving u-u's upgrade-during-shutdown mode for SteamOS, where it is actively used in that mode (SteamOS doesn't use systemd yet, as far as I know). With my patchset, it pre-downloads all necessary packages and performs a pre-prepared transaction during shutdown. Without my patchset, it downloads stuff during shutdown, which seemed rather more precarious than anyone wants. S ___ 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 Thu, Nov 06, 2014 at 03:21:33PM +, Simon McVittie wrote: On 06/11/14 14:16, Zbigniew Jędrzejewski-Szmek wrote: What matters is how it is all arranged: - if there's a job that does stuff, and then calls reboot or shutdown - a hook into the shutdown or reboot target does some work unattended-upgrades is currently the latter: the user shuts down (or is reminded to shut down by an update notification), and unattended-upgrades runs as a side-effect. This is an optional (non-default) configuration of an optional package, not core Debian/Ubuntu functionality; so it doesn't necessarily have to be like this forever, it could be modified to tell systemd I'm still shutting down, continue to wait periodically, it could be modified to use reboot into a special mode, install, then reboot again logic under systemd if that's something you already have, and, worst-case, it could install a drop-in to override the timeout. The default configuration is currently to perform the upgrades in-place and prompt the user to reboot when convenient, just like a manual apt/zypp/etc. run would. I have worked on improving u-u's upgrade-during-shutdown mode for SteamOS, where it is actively used in that mode (SteamOS doesn't use systemd yet, as far as I know). With my patchset, it pre-downloads all necessary packages and performs a pre-prepared transaction during shutdown. Without my patchset, it downloads stuff during shutdown, which seemed rather more precarious than anyone wants. Hm, so maybe I was a bit hasty with the revert. It doesn't really matter if download+updates or just updates are done during shutdown. In either case, a fixed timeout is dangerous. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] segfault in timesyncd
Here are the logs: Nov 06 16:14:56 numenor systemd[1]: Started Network Time Synchronization. Nov 06 16:14:56 numenor systemd-timesyncd[4881]: Using NTP server 10.3.255.254:123 (10.3.255.254). Nov 06 16:15:06 numenor systemd-timesyncd[4881]: Timed out waiting for reply from 10.3.255.254:123 (10.3.255.254). Nov 06 16:15:06 numenor kernel: systemd-timesyn[4881]: segfault at 8 ip b77bea0a sp bfddf800 error 4 in systemd-timesyncd[b77b5000+1c000] Nov 06 16:15:06 numenor systemd[1]: systemd-timesyncd.service: main process exited, code=killed, status=11/SEGV Nov 06 16:15:06 numenor systemd[1]: Unit systemd-timesyncd.service entered failed state. Nov 06 16:15:06 numenor systemd[1]: systemd-timesyncd.service has no holdoff time, scheduling restart. I don't understand why I don't get a core dump, sending SIGABRT to a 'sleep' does produce one: Nov 06 16:09:39 numenor systemd-coredump[4321]: Process 4315 (sleep) of user 100 0 dumped core. And my systemd/system.conf does not have a DefaultLimitCORE, and indeed $ systemctl show systemd-timesyncd | grep LimitCORE LimitCORE=18446744073709551615 -- Damien ___ 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
Simon McVittie wrote on 06/11/14 15:21: On 06/11/14 14:16, Zbigniew Jędrzejewski-Szmek wrote: What matters is how it is all arranged: - if there's a job that does stuff, and then calls reboot or shutdown - a hook into the shutdown or reboot target does some work unattended-upgrades is currently the latter: the user shuts down (or is reminded to shut down by an update notification), and unattended-upgrades runs as a side-effect. This is an optional (non-default) configuration of an optional package, not core Debian/Ubuntu functionality; so it doesn't necessarily have to be like this forever, it could be modified to tell systemd I'm still shutting down, continue to wait periodically, it could be modified to use reboot into a special mode, install, then reboot again logic under systemd if that's something you already have, and, worst-case, it could install a drop-in to override the timeout. Was there not talk of teaching the sd-notify protocol the ability to tell systemd that I'm still alive and doing stuff - so please don't kill me? A sort of keep-alive (or keep-me-in-this-state-please) ping. Not sure if that ever came to pass but I remember seeing a discussion kicking around the list about this. 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] systemd-machined sigterm, cgroups trimmed
On Tue, 04.11.14 08:38, Major Hayden (ma...@mhtx.net) wrote: Hello there, I'm currently running systemd 216 on Fedora 21 and I've found an issue where systemd-machined stops running and cgroups are trimmed from the scope of running qemu virtual machines. The series of events looks like this: 1) OpenStack nova creates a KVM virtual machine via libvirt 2) Libvirt registers the VM with systemd-machined, cgroups appear 3) 0-300 seconds pass 4) systemd-machined gets a sigterm and stops 5) cgroups are trimmed for running virtual machines The cgroup trimming is a disaster because it removes devices.allow and devices.deny ACL's for the running virtual machine. Here is a snippet of the systemd journal with two virtual machines running. You'll see that systemd-machined gets a sigterm and stops: https://gist.github.com/major/2d76cbf0d0de0d62ce3f Shortly after systemd-machined goes offline, the cgroups are removed. Rebooting the hypervisor, rebooting a virtual machine, or building a new virtual machine will cause systemd-machined to start again but it will stop shortly afterwards. I figure machined terminates because it's idle. This would suggest the registration of the machine didn't work, or that the unit that libvirt registered went away. Right after the machine was started, but before machined dies, do you see the machine's scope registered in systemctl list-units? Do you see the machine show up in machinectl's output? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Leak mempool/hashmap
Hi,
I just noticed that mempool/hashmap leaks memory. It's as simple as this
to trigger:
#include hashmap.h
int main(int argc, const char *argv[]) {
Hashmap *m = hashmap_new(string_hash_ops);
hashmap_free(m);
}
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Leak mempool/hashmap
On Thu, 06.11.14 18:36, Jan Janssen (medhe...@web.de) wrote:
Hi,
I just noticed that mempool/hashmap leaks memory. It's as simple as this to
trigger:
#include hashmap.h
int main(int argc, const char *argv[]) {
Hashmap *m = hashmap_new(string_hash_ops);
hashmap_free(m);
}
How did you determine the leak?
Note that the hashmap uses an allocation cache. It's not freed on
shutdown, but it's not leaked either...
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] Poor man's reboot doesn't work
Am 04.11.2014 um 20:01 schrieb Thomas Meyer tho...@m3y3r.de: Am 02.11.2014 um 12:48 schrieb Thomas Meyer tho...@m3y3r.de: 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.? Can anybody answer my question? Or give hints were I can find an answer? # 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 EXIT_CGROUP seems to get set at three locations in the source code, but I'm not sure what is the original underlying error code. Any ideas wash at could be wrong here? example status output: abrt-ccpp.service - '/org/freedesktop/systemd1/unit/abrt_2dccpp_2eservice' abrt-ccpp.service - Install ABRT coredump hook Loaded: loaded (/usr/lib/systemd/system/abrt-ccpp.service; enabled) Active: failed (Result: exit-code) since So 2014-11-02 12:32:45 CET; 2min 32s ago Process: 4715 ExecStop=/usr/sbin/abrt-install-ccpp-hook uninstall (code=exited, status=0/SUCCESS) Process: 13227 ExecStart=/usr/sbin/abrt-install-ccpp-hook install (code=exited, status=219/CGROUP) Main PID: 13227 (code=exited, status=219/CGROUP) CGroup: /system.slice/abrt-ccpp.service Nov 02 12:32:45 localhost.localdomain systemd[1]: abrt-ccpp.service: main process exited, code=exited, status=219/CGROUP Nov 02 12:32:45 localhost.localdomain systemd[1]: Failed to start Install ABRT coredump hook. Nov 02 12:32:45 localhost.localdomain systemd[1]: Unit abrt-ccpp.service entered failed state Bug or feature? This happens with systemd version: systemd 208 +PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ on Fedora 20. with kind regards thomas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel 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/06/2014 11:54 PM, Lennart Poettering wrote:
On Tue, 04.11.14 17:35, WaLyong Cho (walyong@samsung.com) wrote:
In case of systemd has _ label and run as root, if a service file
has User= option and the command line file has a special SMACK label
then systemd will fail to execute the command. Generally, SMACK label
is ignored for the root. But if a service has a User= then systemd
will call setresuid() in the child process. After then it no more
root. So it should have some of executable label for the command. To
set the SMACK64EXEC before the uid is changed introduce new
SmackLabelExec option.
Hmm, I am not sure I like the abbreviation of this. Can't we just call
this SmackLabel=?
SmackLabel is already used as socket. Can we use that also here?
By the way, I hope to discuss about the naming of the SMACK options.
SmackLabel/SmackLabelIPIn/SmackLabelIPOut are. They are used in socket
group. According to SMACK description,
SMACK64/SMACK64EXEC/SMACK64MMAP/SMACK64TRANSMUTE/SMACK64IPIN/SMACK64IPOUT are
the origin attribute name. I think using origin name is most make sense.
If you agree, then in this case, SMACK64EXEC will be.
+#ifdef HAVE_SMACK
+#include smack-util.h
+#endif
+
ifdeffing the include is unnecessary. YOu can just include it without
ifdef protectionn, there's nothing in it that we need to avoid pullin in.
SELINUX/APPARMOR also use #ifdef. But can SMACK use without that?
#define SMACK_FLOOR_LABEL _
@@ -123,6 +124,31 @@ int mac_smack_apply_ip_in_fd(int fd, const char *label)
{
return r;
}
+int mac_smack_apply_pid(pid_t pid, const char *label) {
+int r = 0;
+_cleanup_free_ char *path = NULL;
+
+assert(label);
+
+#ifdef HAVE_SMACK
+if (!mac_smack_use())
+return 0;
+
+if (pid)
+r = asprintf(path, /proc/%lu/attr/current, (unsigned
long) pid);
+else
+r = asprintf(path, /proc/self/attr/current);
+if (r 0)
+return -ENOMEM;
Please use procfs_file_alloca() for this. It makes this much nicer!
Thanks for advising. I will change.
WaLyong
Lennart
___
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 03:18, WaLyong Cho (walyong@gmail.com) wrote: On 11/06/2014 11:54 PM, Lennart Poettering wrote: On Tue, 04.11.14 17:35, WaLyong Cho (walyong@samsung.com) wrote: In case of systemd has _ label and run as root, if a service file has User= option and the command line file has a special SMACK label then systemd will fail to execute the command. Generally, SMACK label is ignored for the root. But if a service has a User= then systemd will call setresuid() in the child process. After then it no more root. So it should have some of executable label for the command. To set the SMACK64EXEC before the uid is changed introduce new SmackLabelExec option. Hmm, I am not sure I like the abbreviation of this. Can't we just call this SmackLabel=? SmackLabel is already used as socket. Can we use that also here? Well, sure. I mean, SmackLabel= on a socket unit applies to the socket, and SmackLabel= on a service unit applies to the processes forked off, that feels quite natural I think. Overloading the field in this way appears to be quite appropriate to me in this case. By the way, I hope to discuss about the naming of the SMACK options. SmackLabel/SmackLabelIPIn/SmackLabelIPOut are. They are used in socket group. According to SMACK description, SMACK64/SMACK64EXEC/SMACK64MMAP/SMACK64TRANSMUTE/SMACK64IPIN/SMACK64IPOUT are the origin attribute name. I think using origin name is most make sense. If you agree, then in this case, SMACK64EXEC will be. What precisely is the SMACK64 label, and in which way does it differ from SMACK64EXEC? The former is the xattr field on files, the latter the current procfs file on processes? What is SMACK64MMAP for? Does any of the other labels apply to processes? Naming things is always one of the most difficult problems in computer science I guesss... In general we try to not do unnecessary abbreviations, especially for more exotic functionality. It's certainly a good idea to stay close to the low-level concepts, but then again dropping components of a low-level name doesn't sound too bad to me. ifdeffing the include is unnecessary. YOu can just include it without ifdef protectionn, there's nothing in it that we need to avoid pullin in. SELINUX/APPARMOR also use #ifdef. But can SMACK use without that? Well, they import system headers, but smack-util.h is not a system header, it's shipped in systemd itself... 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] bus-proxy: cloning smack label
On Thu, 06.11.14 11:44, Przemyslaw Kedzierski (p.kedzier...@samsung.com) wrote:
When dbus client connects to systemd-bus-proxyd through
Unix domain socket proxy takes client's smack label and sets for itself.
It is done before and independent of dropping privileges.
The reason of such soluton is fact that tests of access rights
performed by lsm may take place inside kernel, not only
in userspace of recipient of message.
The bus-proxyd needs CAP_MAC_ADMIN to manipulate its label.
In case of systemd running in system mode, CAP_MAC_ADMIN
should be added to CapabilityBoundingSet in service file of bus-proxyd.
In case of systemd running in user mode ('systemd --user')
it can be achieved by addition
Capabilities=cap_mac_admin=i and SecureBits=keep-caps
to user@.service file
and setting cap_mac_admin+ei on bus-proxyd binary.
Hmm, is this really the way this should work? I am a bit afraid of
including these lines on systems without SMACK. I figure this part at
least should be removed on non-SMACK builds, with m4 magic.
Signed-off-by: Przemyslaw Kedzierski p.kedzier...@samsung.com
We don't use S-o-b btw.
(void) getpeercred(in_fd, ucred);
(void) getpeersec(in_fd, peersec);
+
+if (mac_smack_use()) {
+if (peersec) {
+
+r = mac_smack_set_process_label(peersec);
+if (r 0)
+log_warning(Failed to set SMACK
label %s : %s, peersec, strerror(-r));
Your colleage at Samsung, WaLyong Cho just posted a patch that added a
new call mac_smack_apply_pid() which is a superset of the
mac_smack_set_process_label(). I kinda like mac_smack_apply_pid()
better I must say, hence I'd love if we could get his patch in first,
and you could then rework your patch on top of his?
+} else {
+log_warning(Invalid SMACK label);
+}
Please no {} on single-line if blocks.
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 Wed, 05.11.14 16:55, Patrick Häcker (pa...@web.de) wrote: heya, sorry if this list is not the correct one for my post. In this case please just point me to the correct list. It is the correct list. 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 devices do not work with active power saving, which is the reason why it's not activated by default. To get it working anyway, users should activated it for all devices and create their own blacklists. I did exactly that and had to copy blacklists to multiple computers when moving my devices around. As this should be distribution agnostic, I wonder if there are upstream blacklists or whitelists to take care of this problem. A power save whitelist would be useful, as distributions could start activating power saving for theses devices immediately. A power save blacklist would be useful as users could try to activate power saving for all devices and if their problematic hardware is already on the blacklist, everything works and they can save even more power as with the whitelist. In the long run there could even be a small please test your hardware tool, where the power saving is activated for, e.g., your mouse. You then have to click to confirm that it is working. Otherwise power saving gets deactivated after a timeout, so you can use your mouse again. This result could then be automatically uploaded (after user confirmation) and added to the blacklist/whitelist. So I have several questions: - Is there already something like this? No there's nothing like that to my knowledge. - If not, is udev the correct piece in the Linux stack to put this? Yes, and the hwdb has been created for things likt this. - What is the general way to contribute udev rules? The matching bits really belong in hwdb. The matching should then set a property and a udev rule should then update the hw device. - Where is it documented? it's tersely documented in the udev man page. systemd already ships some hwdb bits (such as the PCI/USB name databases), and we should add more to this. IIUC we probably can implement this as a blacklist, rather than a whitelist. IIRC there used to be a kernel bug that caused autosuspend to mostly not work on Linux, which they however blamed on crappy devices for a long time. After that kernel bug got fixed I think autosuspend works on most devices now, hence we only need a blacklist? I figure Greg has all the details on this, let's ask him (added to CC): Greg, say something! Is the autosuspend stuff something we can enable safely on most devices now? Do we need a blacklist? Or should we even go for a whitelist? 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] Leak mempool/hashmap
On 2014-11-06 19:05, Lennart Poettering wrote:
On Thu, 06.11.14 18:36, Jan Janssen (medhe...@web.de) wrote:
Hi,
I just noticed that mempool/hashmap leaks memory. It's as simple as this to
trigger:
#include hashmap.h
int main(int argc, const char *argv[]) {
Hashmap *m = hashmap_new(string_hash_ops);
hashmap_free(m);
}
How did you determine the leak?
Note that the hashmap uses an allocation cache. It's not freed on
shutdown, but it's not leaked either...
Lennart
I've noticed while testing my cryptsetup-generator rewrite with
valgrind. It's still reachable according to valgrind, but a silent
output would be nice to have.
Jan
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] src/shared
On Thu, 06.11.14 15:30, Lennart Poettering (lenn...@poettering.net) wrote: On Thu, 06.11.14 06:28, Harald Hoyer (har...@kemper.freedesktop.org) wrote: Not all switch roots are like base_filesystem_create() wants them to look like. They might even boot, if they are RO and don't have the FS layout. Just ignore the error and switch_root nevertheless. I think a comment like this would be really good in the code itself, I think. It's a good idea to explicitly clarify when we cast errors away I figure. I made such an addition 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] Leak mempool/hashmap
2014-11-06 19:59 GMT+01:00 Jan Janssen medhe...@web.de:
Hi,
On 2014-11-06 19:05, Lennart Poettering wrote:
On Thu, 06.11.14 18:36, Jan Janssen (medhe...@web.de) wrote:
Hi,
I just noticed that mempool/hashmap leaks memory. It's as simple as this
to
trigger:
#include hashmap.h
int main(int argc, const char *argv[]) {
Hashmap *m = hashmap_new(string_hash_ops);
hashmap_free(m);
}
How did you determine the leak?
Note that the hashmap uses an allocation cache. It's not freed on
shutdown, but it's not leaked either...
Lennart
I've noticed while testing my cryptsetup-generator rewrite with valgrind.
It's still reachable according to valgrind, but a silent output would be
nice to have.
If you add -DVALGRIND=1 to the CFLAGS there will be no false positive
leaks reported.
Jan
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] smack: introduce new SmackLabelExec option
On 11/07/2014 03:30 AM, Lennart Poettering wrote: On Fri, 07.11.14 03:18, WaLyong Cho (walyong@gmail.com) wrote: On 11/06/2014 11:54 PM, Lennart Poettering wrote: On Tue, 04.11.14 17:35, WaLyong Cho (walyong@samsung.com) wrote: In case of systemd has _ label and run as root, if a service file has User= option and the command line file has a special SMACK label then systemd will fail to execute the command. Generally, SMACK label is ignored for the root. But if a service has a User= then systemd will call setresuid() in the child process. After then it no more root. So it should have some of executable label for the command. To set the SMACK64EXEC before the uid is changed introduce new SmackLabelExec option. Hmm, I am not sure I like the abbreviation of this. Can't we just call this SmackLabel=? SmackLabel is already used as socket. Can we use that also here? Well, sure. I mean, SmackLabel= on a socket unit applies to the socket, and SmackLabel= on a service unit applies to the processes forked off, that feels quite natural I think. Overloading the field in this way appears to be quite appropriate to me in this case. By the way, I hope to discuss about the naming of the SMACK options. SmackLabel/SmackLabelIPIn/SmackLabelIPOut are. They are used in socket group. According to SMACK description, SMACK64/SMACK64EXEC/SMACK64MMAP/SMACK64TRANSMUTE/SMACK64IPIN/SMACK64IPOUT are the origin attribute name. I think using origin name is most make sense. If you agree, then in this case, SMACK64EXEC will be. What precisely is the SMACK64 label, and in which way does it differ from SMACK64EXEC? The former is the xattr field on files, the latter the current procfs file on processes? What is SMACK64MMAP for? Does any of the other labels apply to processes? Sorry, I missed attaching URL: http://www.webcitation.org/6AqzohCXq 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. SMACK64MMAP Don't allow the file to be mmapped by a process whose Smack label does not allow all of the access permitted to a process with the label contained in this attribute. This is a very specific use case for shared libraries. SMACK64TRANSMUTE Can only have the value TRUE. If this attribute is present on a directory when an object is created in the directory and the Smack rule (more below) that permitted the write access to the directory includes the transmute (t) mode the object gets the label of the directory instead of the label of the creating process. If the object being created is a directory the SMACK64TRANSMUTE attribute is set as well. Maybe SMACK64MMAP/SMACK64TRANSMUTE wasn't used in systemd. So we don't need to discuss about SMACK64MMAP/SMACK64TRANSMUTE on here. I'm not an expert on SMACK, but if I add some explain, we generally assign three kind of label to filesystem object. We usally call them as label, execute label and transmute. transmute has only effect on directory. So we just need to think about label and execute label. Every filesystem objects have to have a label. That can be some string or be _ or *...but the execute label is excuted process's attribute label. That can be none. If a object has none execute label then the object will be run as caller processes label. (I think I'd confused. We should use SMACK64 or SmackLabel instead SMACK64EXEC or SmackLabelExec in here.) Auke, what do you think? Naming things is always one of the most difficult problems in computer science I guesss... In general we try to not do unnecessary abbreviations, especially for more exotic functionality. It's certainly a good idea to stay close to the low-level concepts, but then again dropping components of a low-level name doesn't sound too bad to me. ifdeffing the include is unnecessary. YOu can just include it without ifdef protectionn, there's nothing in it that we need to avoid pullin in. SELINUX/APPARMOR also use #ifdef. But can SMACK use without that? Well, they import system headers, but smack-util.h is not a system header, it's shipped in systemd itself... 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
Hi On Sun, Nov 2, 2014 at 12:48 PM, 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 example status output: abrt-ccpp.service - '/org/freedesktop/systemd1/unit/abrt_2dccpp_2eservice' abrt-ccpp.service - Install ABRT coredump hook Loaded: loaded (/usr/lib/systemd/system/abrt-ccpp.service; enabled) Active: failed (Result: exit-code) since So 2014-11-02 12:32:45 CET; 2min 32s ago Process: 4715 ExecStop=/usr/sbin/abrt-install-ccpp-hook uninstall (code=exited, status=0/SUCCESS) Process: 13227 ExecStart=/usr/sbin/abrt-install-ccpp-hook install (code=exited, status=219/CGROUP) Main PID: 13227 (code=exited, status=219/CGROUP) CGroup: /system.slice/abrt-ccpp.service Nov 02 12:32:45 localhost.localdomain systemd[1]: abrt-ccpp.service: main process exited, code=exited, status=219/CGROUP Nov 02 12:32:45 localhost.localdomain systemd[1]: Failed to start Install ABRT coredump hook. Nov 02 12:32:45 localhost.localdomain systemd[1]: Unit abrt-ccpp.service entered failed state Bug or feature? So it's just the abrt-ccpp.service that fails? If you disable it, everything works as expected? I'd recommend reporting it to the abrt-ccpp people. I don't think this is related to how systemd starts/stops it. The developers of it should probably know more. Btw., I'm not entirely sure what that service does, so you might wanna show us the service file. It's not part of the systemd tarball, as far as I see. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] s/commandline/command line/g
On Thu, 06.11.14 15:37, Lennart Poettering (lenn...@poettering.net) wrote: On Wed, 05.11.14 14:56, har...@redhat.com (har...@redhat.com) wrote: +++ b/man/systemd-run.xml @@ -215,7 +215,7 @@ along with systemd; If not, see http://www.gnu.org/licenses/. /variablelist paraAll command-line arguments after the first non-option -argument become part of the commandline of the launched +argument become part of the command line of the launched process. If a command is run as service unit, its first argument needs to be an absolute binary path./para /refsect1 I figure there are some more cleanups to be done here... The example above shows that we not only use commandline and command line, but also command-line... I have cleaned up this now, too. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Allow PID 1 systemd --user instances to exit
--- src/core/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/core/main.c b/src/core/main.c index d48604e..cd9d6ee 100644 --- a/src/core/main.c +++ b/src/core/main.c @@ -2013,7 +2013,7 @@ finish: getpid() == 1 ? freezing : quitting); } -if (getpid() == 1) +if (arg_running_as != SYSTEMD_USER getpid() == 1) freeze(); return retval; -- 2.1.1 ___ 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 14:44, Vito Caputo (vito.cap...@coreos.com) wrote: Hmm? What is this about? Why would you want to run systemd --user as PID 1? diff --git a/src/core/main.c b/src/core/main.c index d48604e..cd9d6ee 100644 --- a/src/core/main.c +++ b/src/core/main.c @@ -2013,7 +2013,7 @@ finish: getpid() == 1 ? freezing : quitting); } -if (getpid() == 1) +if (arg_running_as != SYSTEMD_USER getpid() == 1) freeze(); return retval; -- 2.1.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Udev rules hardware database
On Thu, Nov 06, 2014 at 07:49:38PM +0100, Lennart Poettering wrote: On Wed, 05.11.14 16:55, Patrick Häcker (pa...@web.de) wrote: heya, sorry if this list is not the correct one for my post. In this case please just point me to the correct list. It is the correct list. 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 devices do not work with active power saving, which is the reason why it's not activated by default. To get it working anyway, users should activated it for all devices and create their own blacklists. I did exactly that and had to copy blacklists to multiple computers when moving my devices around. As this should be distribution agnostic, I wonder if there are upstream blacklists or whitelists to take care of this problem. A power save whitelist would be useful, as distributions could start activating power saving for theses devices immediately. A power save blacklist would be useful as users could try to activate power saving for all devices and if their problematic hardware is already on the blacklist, everything works and they can save even more power as with the whitelist. In the long run there could even be a small please test your hardware tool, where the power saving is activated for, e.g., your mouse. You then have to click to confirm that it is working. Otherwise power saving gets deactivated after a timeout, so you can use your mouse again. This result could then be automatically uploaded (after user confirmation) and added to the blacklist/whitelist. So I have several questions: - Is there already something like this? No there's nothing like that to my knowledge. - If not, is udev the correct piece in the Linux stack to put this? Yes, and the hwdb has been created for things likt this. - What is the general way to contribute udev rules? The matching bits really belong in hwdb. The matching should then set a property and a udev rule should then update the hw device. - Where is it documented? it's tersely documented in the udev man page. systemd already ships some hwdb bits (such as the PCI/USB name databases), and we should add more to this. IIUC we probably can implement this as a blacklist, rather than a whitelist. IIRC there used to be a kernel bug that caused autosuspend to mostly not work on Linux, which they however blamed on crappy devices for a long time. After that kernel bug got fixed I think autosuspend works on most devices now, hence we only need a blacklist? I figure Greg has all the details on this, let's ask him (added to CC): Greg, say something! Is the autosuspend stuff something we can enable safely on most devices now? Do we need a blacklist? Or should we even go for a whitelist? I really don't know. Some other operating system relies on a whitelist due to all of the horrible devices out there that can't handle suspend (keyboards and mice are notorious for being bad.) You might want to ask one of the distro people to see if they have ever turned it on by default and what happened if they tried that. thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SELinux code in method_{disable, enable}_unit_files_generic() functions
On Tue, 04.11.14 09:17, Laurent Bigonville (bi...@debian.org) wrote:
Hello,
After looking a bit around the code, I've two questions about the
SELinux code in method_{disable,enable}_unit_files_generic() functions.
In method_enable_unit_files_generic(),
mac_selinux_unit_access_check_strv() is used to check the SELinux
permissions while in method_disable_unit_files_generic(),
mac_selinux_access_check() is used.
The enablement commands only can work for unit files that are
installed. This is different for the disablement commands. You can use
them to remove symlinks to unit files that already have been
removed. For removing no unit files need to exist.
Also, I'm a bit puzzled by the fact that you pass the disable verb to
the method_enable_unit_files_generic() function in the case of
masking/unmasking a service (and the opposite is also true with the
disable function).
Well, the way selinux works is that there shouldn't be an arbitrary
number of verbs we use to protect these things in the policy. Hence
for the unit file management we try to break things down to just
enable and disable. Now, masking/unmasking doesn't really map
nicely to that. Since masking a unit is a bit like a disable on
steroids we map it to disable. But unmasking a unit is not really
enabling either, hence we also map it to disable.
Am I missing something here? Or should a bug be opened?
No bug, this is indeed weird, but it's how SELinux works I guess...
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] timer: reenable TIMER_ACTIVE timers when restarted
A timer configured with OnActiveSec will start its associated unit again
if the timer is stopped, then started. However, if the timer unit is
restarted -- with systemctl restart, say -- this does not occur.
This commit ensures that TIMER_ACTIVE timers are re-enabled whenever the
timer is started, even if that's within a restart job.
---
src/core/timer.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/core/timer.c b/src/core/timer.c
index a3713e2..5c4e9f9 100644
--- a/src/core/timer.c
+++ b/src/core/timer.c
@@ -521,6 +521,7 @@ fail:
static int timer_start(Unit *u) {
Timer *t = TIMER(u);
+TimerValue *v;
assert(t);
assert(t-state == TIMER_DEAD || t-state == TIMER_FAILED);
@@ -530,6 +531,11 @@ static int timer_start(Unit *u) {
t-last_trigger = DUAL_TIMESTAMP_NULL;
+/* Reenable all timers that depend on unit activation time */
+LIST_FOREACH(value, v, t-values)
+if (v-base == TIMER_ACTIVE)
+v-disabled = false;
+
if (t-stamp_path) {
struct stat st;
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timer: reenable TIMER_ACTIVE timers when restarted
On Thu, 06.11.14 19:47, Michael Chapman (m...@very.puzzling.org) wrote:
Makes sense! Applied!
A timer configured with OnActiveSec will start its associated unit again
if the timer is stopped, then started. However, if the timer unit is
restarted -- with systemctl restart, say -- this does not occur.
This commit ensures that TIMER_ACTIVE timers are re-enabled whenever the
timer is started, even if that's within a restart job.
---
src/core/timer.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/core/timer.c b/src/core/timer.c
index a3713e2..5c4e9f9 100644
--- a/src/core/timer.c
+++ b/src/core/timer.c
@@ -521,6 +521,7 @@ fail:
static int timer_start(Unit *u) {
Timer *t = TIMER(u);
+TimerValue *v;
assert(t);
assert(t-state == TIMER_DEAD || t-state == TIMER_FAILED);
@@ -530,6 +531,11 @@ static int timer_start(Unit *u) {
t-last_trigger = DUAL_TIMESTAMP_NULL;
+/* Reenable all timers that depend on unit activation time */
+LIST_FOREACH(value, v, t-values)
+if (v-base == TIMER_ACTIVE)
+v-disabled = false;
+
if (t-stamp_path) {
struct stat st;
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Allow PID 1 systemd --user instances to exit
Imagine running systemd --user post-CLONE_NEWPID to manage services in the new namespace. Cheers, Vito Caputo On Thu, Nov 6, 2014 at 2:56 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 06.11.14 14:44, Vito Caputo (vito.cap...@coreos.com) wrote: Hmm? What is this about? Why would you want to run systemd --user as PID 1? diff --git a/src/core/main.c b/src/core/main.c index d48604e..cd9d6ee 100644 --- a/src/core/main.c +++ b/src/core/main.c @@ -2013,7 +2013,7 @@ finish: getpid() == 1 ? freezing : quitting); } -if (getpid() == 1) +if (arg_running_as != SYSTEMD_USER getpid() == 1) freeze(); return retval; -- 2.1.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Allow PID 1 systemd --user instances to exit
On Thu, 06.11.14 16:26, Vito Caputo (vito.cap...@coreos.com) wrote: Imagine running systemd --user post-CLONE_NEWPID to manage services in the new namespace. But why not run it as --system then? Not following... 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 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? (I think I'd confused. We should use SMACK64 or SmackLabel instead SMACK64EXEC or SmackLabelExec in here.) Auke, what do you think? Now I am even more confused than I was before... 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
Because for all intents and purposes it's effectively still a user instance, just having its own PID namespace isn't cause --system behaviors like disabling systemctl exit for example. Preventing exit from PID 1 makes sense when you're going to panic the kernel, but doesn't --user imply otherwise? Cheers, Vito Caputo On Thu, Nov 6, 2014 at 4:31 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 06.11.14 16:26, Vito Caputo (vito.cap...@coreos.com) wrote: Imagine running systemd --user post-CLONE_NEWPID to manage services in the new namespace. But why not run it as --system then? Not following... 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 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... 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 16:59, Vito Caputo (vito.cap...@coreos.com) wrote: Because for all intents and purposes it's effectively still a user instance, just having its own PID namespace isn't cause --system behaviors like disabling systemctl exit for example. I am pretty sure doing something like this will break at a ton of other places. I really wonder if it's worth supporting this, after all a lot of our code checks getpid() == 1 to see if we are run in system mode. I mean, once upon a time we had a mode in systemd, where we supported running --system system as PID != 1. We removed that because it only ever half-worked, because it confused things, because the usecase was weak, because nobody really cared and because it bitrotted. Now, supporting running systemd --user in a PID namespace kinda feels like the same story, just inverted. Which makes me immediately wonder why this should be different for this case. So, what's the real usecase for all of this? Can you elaborate on that? Preventing exit from PID 1 makes sense when you're going to panic the kernel, but doesn't --user imply otherwise? Well, the --user switch as PID 1 is probably something we should refuse early on... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2 1/2] utf8: intruduce utf8_escape_non_printable
On Mon, 03.11.14 15:00, WaLyong Cho (walyong@samsung.com) wrote:
---
src/shared/utf8.c| 87
src/shared/utf8.h| 1 +
src/test/test-utf8.c | 30 ++
3 files changed, 118 insertions(+)
diff --git a/src/shared/utf8.c b/src/shared/utf8.c
index 9353559..5245604 100644
--- a/src/shared/utf8.c
+++ b/src/shared/utf8.c
@@ -210,6 +210,93 @@ char *utf8_escape_invalid(const char *str) {
return p;
}
+char *utf8_escape_non_printable(const char *str) {
+char *p, *s;
+
+assert(str);
+
+p = s = malloc(strlen(str) * 4 + 1);
+if (!p)
+return NULL;
+
+while (*str) {
+int len;
+
+len = utf8_encoded_valid_unichar(str);
+if (len 0) {
+if (utf8_is_printable(str, len)) {
+s = mempcpy(s, str, len);
+str += len;
+} else {
+switch (*str) {
+
+case '\a':
+*(s++) = '\\';
+*(s++) = 'a';
+break;
+case '\b':
+*(s++) = '\\';
+*(s++) = 'b';
+break;
+case '\f':
+*(s++) = '\\';
+*(s++) = 'f';
+break;
+case '\n':
+*(s++) = '\\';
+*(s++) = 'n';
+break;
+case '\r':
+*(s++) = '\\';
+*(s++) = 'r';
+break;
+case '\t':
+*(s++) = '\\';
+*(s++) = 't';
+break;
+case '\v':
+*(s++) = '\\';
+*(s++) = 'v';
+break;
+case '\\':
+*(s++) = '\\';
+*(s++) = '\\';
+break;
+case '':
+*(s++) = '\\';
+*(s++) = '';
+break;
+case '\'':
+*(s++) = '\\';
+*(s++) = '\'';
+break;
+
+default:
+/* For special chars we prefer octal
over
+ * hexadecimal encoding, simply
because glib's
+ * g_strescape() does the same */
+if ((*str ' ') || (*str = 127)) {
+*(s++) = '\\';
+*(s++) = octchar((unsigned
char) *str 6);
+*(s++) = octchar((unsigned
char) *str 3);
+*(s++) = octchar((unsigned
char) *str);
+} else
+*(s++) = *str;
+break;
+}
Hmm, do we really want the C style of escaping here? wouldn't be the
\x style of escaping more appropriate here?
If the C style of escaping is appropriate, then we should find a way
to unify this case block between cescape() and this call, i.e. split
it out in a new call, maybe called:
char* cescape_one(char c, char *buf);
That call would take the char to escape, plus a pointer to the buf
where to place the escaped version, and return a pointer that points
into the buffer right after where the escaped version was written.
That way cescape() and your new call could call it like this:
s = cescape_one(*str, s);
To escape one character. If you follow what I mean?
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2 2/2] bootchart: escape non printable process name
On Mon, 03.11.14 15:00, WaLyong Cho (walyong@samsung.com) wrote:
---
src/bootchart/svg.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/bootchart/svg.c b/src/bootchart/svg.c
index faf377e..e5569e1 100644
--- a/src/bootchart/svg.c
+++ b/src/bootchart/svg.c
@@ -39,6 +39,7 @@
#include svg.h
#include bootchart.h
#include list.h
+#include utf8.h
#define time_to_graph(t) ((t) * arg_scale_x)
#define ps_to_graph(n) ((n) * arg_scale_y)
@@ -1006,12 +1007,15 @@ static void svg_ps_bars(void) {
/* pass 2 - ps boxes */
ps = ps_first;
while ((ps = get_next_ps(ps))) {
-_cleanup_free_ char *enc_name = NULL;
+_cleanup_free_ char *enc_name = NULL, *escaped = NULL;
double endtime;
double starttime;
int t;
-enc_name = xml_comment_encode(ps-name);
+if (!utf8_is_printable(ps-name, strlen(ps-name)))
+escaped = utf8_escape_non_printable(ps-name);
+
+enc_name = xml_comment_encode(escaped ? escaped : ps-name);
Not liking the nonchalant ignoring of OOM here, but I figure the
bootchart code isn't very good at than anyway...
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 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 -- 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 Nov 6, 2014 5:17 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 06.11.14 16:59, Vito Caputo (vito.cap...@coreos.com) wrote: Because for all intents and purposes it's effectively still a user instance, just having its own PID namespace isn't cause --system behaviors like disabling systemctl exit for example. I am pretty sure doing something like this will break at a ton of other places. I really wonder if it's worth supporting this, after all a lot of our code checks getpid() == 1 to see if we are run in system mode. I mean, once upon a time we had a mode in systemd, where we supported running --system system as PID != 1. We removed that because it only ever half-worked, because it confused things, because the usecase was weak, because nobody really cared and because it bitrotted. Now, supporting running systemd --user in a PID namespace kinda feels like the same story, just inverted. Which makes me immediately wonder why this should be different for this case. 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. User instances do and also avoid other undesired things like reading extra args from /proc/cmdline which isn't applicable to a container. There seems to be a odd fit here between expecting a system instance to behave nicely like yet another service on a host or a user instance to be pid 1 in a container. Preventing exit from PID 1 makes sense when you're going to panic the kernel, but doesn't --user imply otherwise? Well, the --user switch as PID 1 is probably something we should refuse early on... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] unit: do not order timers.target before basic.target
On Sun, 02.11.14 17:59, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: Since commit 19f8d037833f2 'timer: order OnCalendar units after timer-sync.target if DefaultDependencies=no' timers might get a dependency on time-sync.target, which does not really belong in early boot. If ntp is enabled, time-sync.target might be delayed until a network connection is established. Hmm, this is indeed a problem. It turns out that majority of timer units found in the wild do not need to be started in early boot. Out of the timer units available in Fedora 21, only systemd-readahead-done.timer and mdadm-last-resort@.timer should be started early, but they both have DefaultDependencies=no, so are not part of timers.target anyway. All the rest look like they will be fine with being started a bit later (and the majority even much later, since they run daily or weekly). I must say I kinda like the fact that pulling in and reaching basic.target makes sure all those background things that can fire have been set up for firing, and everything else can then just assume that things are available and ready. The pretty ASCII diagram I did in bootup(7) kinda makes this visible too I figure? Let timers.target be pulled in by basic.target, but without the temporal dependency. This means timer units are started on a best effort schedule. Maybe we should intrdouce a new target calendar-timers.target or so, that is used instead of timers.target for timers that have OnCalendar set. That target we could then pull in later, whenever it is appropriate. This would then feel a bit similar to local-fs.target (which is early-boot) and remote-fs.target (which is late-boot). Does this make sense? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Allow PID 1 systemd --user instances to exit
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(). User instances do and also avoid other undesired things like reading extra args from /proc/cmdline which isn't applicable to a container. There's already an explicit check in place that makes sure read /proc/1/cmdline in place of of /proc/cmdline if we detect we are run in a container: http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/util.c#n6174 There seems to be a odd fit here between expecting a system instance to behave nicely like yet another service on a host or a user instance to be pid 1 in a container. 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? 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] unit: do not order timers.target before basic.target
On Fri, Nov 07, 2014 at 02:49:59AM +0100, Lennart Poettering wrote: On Sun, 02.11.14 17:59, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: Since commit 19f8d037833f2 'timer: order OnCalendar units after timer-sync.target if DefaultDependencies=no' timers might get a dependency on time-sync.target, which does not really belong in early boot. If ntp is enabled, time-sync.target might be delayed until a network connection is established. Hmm, this is indeed a problem. It turns out that majority of timer units found in the wild do not need to be started in early boot. Out of the timer units available in Fedora 21, only systemd-readahead-done.timer and mdadm-last-resort@.timer should be started early, but they both have DefaultDependencies=no, so are not part of timers.target anyway. All the rest look like they will be fine with being started a bit later (and the majority even much later, since they run daily or weekly). I must say I kinda like the fact that pulling in and reaching basic.target makes sure all those background things that can fire have been set up for firing, and everything else can then just assume that things are available and ready. Yes, that's true, but OTOH, there's a downside to complexity. We have to explain the difference between timers, and timer-calendar... Timers can have multiple On* stanzas, so adding an OnCalendar= would move the timer from one group to another, which would mean that adding a new On* stanza could *delay* a timer. This behaviour would have to be documented and explained. I find the idea of simply saying timers by default are started asynchronously on boot much nicer. The pretty ASCII diagram I did in bootup(7) kinda makes this visible too I figure? Let timers.target be pulled in by basic.target, but without the temporal dependency. This means timer units are started on a best effort schedule. Maybe we should intrdouce a new target calendar-timers.target or so, that is used instead of timers.target for timers that have OnCalendar set. That target we could then pull in later, whenever it is appropriate. This would then feel a bit similar to local-fs.target (which is early-boot) and remote-fs.target (which is late-boot). Two differences: mounts are of one type only, so they cleanly fall into one of those targets, and two, we actually need to treat them differently for things to work. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Add support for supplying an exit status code to systemctl exit
The capability of directly propagating a return code out to the caller of
systemd --user from within something like an OnFailure unit has utility.
This also contains a minor fixup to the documentation adding exit to the
--force section.
Cheers,
Vito Caputo
---
man/systemctl.xml | 11 ++-
src/core/dbus-manager.c | 6 +-
src/core/main.c | 2 +-
src/core/manager.c| 1 +
src/core/manager.h| 1 +
src/systemctl/systemctl.c | 20 ++--
6 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/man/systemctl.xml b/man/systemctl.xml
index 7cbaa6c..25ad2f7 100644
--- a/man/systemctl.xml
+++ b/man/systemctl.xml
@@ -432,9 +432,9 @@ along with systemd; If not, see
http://www.gnu.org/licenses/.
paraWhen used with commandenable/command, overwrite
any existing conflicting symlinks./para
- paraWhen used with commandhalt/command,
- commandpoweroff/command, commandreboot/command or
- commandkexec/command, execute the selected operation
+ paraWhen used with commandexit/command,
commandhalt/command,
+ commandpoweroff/command, commandreboot/command or
+ commandkexec/command, execute the selected operation
without shutting down all units. However, all processes will
be killed forcibly and all file systems are unmounted or
remounted read-only. This is hence a drastic but relatively
@@ -1485,13 +1485,14 @@ kobject-uevent 1 systemd-udevd-kernel.socket
systemd-udevd.service
/listitem
/varlistentry
varlistentry
- termcommandexit/command/term
+ termcommandexit
optionalreplaceableSTATUS/replaceable/optional/command/term
listitem
paraAsk the systemd manager to quit. This is only
supported for user service managers (i.e. in conjunction
with the option--user/option option) and will fail
-otherwise./para
+otherwise. Used in conjunction with --force a status code may
be
+ propagated into the sytemd manager's exit code./para
/listitem
/varlistentry
diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
index c54abd3..78f7f6d 100644
--- a/src/core/dbus-manager.c
+++ b/src/core/dbus-manager.c
@@ -1140,6 +1140,10 @@ static int method_exit(sd_bus *bus, sd_bus_message
*message, void *userdata, sd_
if (m-running_as == SYSTEMD_SYSTEM)
return sd_bus_error_setf(error,
SD_BUS_ERROR_NOT_SUPPORTED, Exit is only supported for user service
managers.);
+r = sd_bus_message_read(message, i, m-exit_retval);
+if (r 0)
+return r;
+
m-exit_code = MANAGER_EXIT;
return sd_bus_reply_method_return(message, NULL);
@@ -1918,7 +1922,7 @@ const sd_bus_vtable bus_manager_vtable[] = {
SD_BUS_METHOD(RemoveSnapshot, s, NULL, method_remove_snapshot,
0),
SD_BUS_METHOD(Reload, NULL, NULL, method_reload,
SD_BUS_VTABLE_UNPRIVILEGED),
SD_BUS_METHOD(Reexecute, NULL, NULL, method_reexecute,
SD_BUS_VTABLE_UNPRIVILEGED),
-SD_BUS_METHOD(Exit, NULL, NULL, method_exit, 0),
+SD_BUS_METHOD(Exit, i, NULL, method_exit, 0),
SD_BUS_METHOD(Reboot, NULL, NULL, method_reboot,
SD_BUS_VTABLE_CAPABILITY(CAP_SYS_BOOT)),
SD_BUS_METHOD(PowerOff, NULL, NULL, method_poweroff,
SD_BUS_VTABLE_CAPABILITY(CAP_SYS_BOOT)),
SD_BUS_METHOD(Halt, NULL, NULL, method_halt,
SD_BUS_VTABLE_CAPABILITY(CAP_SYS_BOOT)),
diff --git a/src/core/main.c b/src/core/main.c
index d48604e..2481f5c 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -1737,7 +1737,7 @@ int main(int argc, char *argv[]) {
switch (m-exit_code) {
case MANAGER_EXIT:
-retval = EXIT_SUCCESS;
+retval = m-exit_retval;
log_debug(Exit.);
goto finish;
diff --git a/src/core/manager.c b/src/core/manager.c
index 129f6dd..e417514 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -550,6 +550,7 @@ int manager_new(SystemdRunningAs running_as, bool
test_run, Manager **_m) {
m-running_as = running_as;
m-exit_code = _MANAGER_EXIT_CODE_INVALID;
+m-exit_retval = EXIT_SUCCESS;
m-default_timer_accuracy_usec = USEC_PER_MINUTE;
m-idle_pipe[0] = m-idle_pipe[1] = m-idle_pipe[2] =
m-idle_pipe[3] = -1;
diff --git a/src/core/manager.h b/src/core/manager.h
index ab72548..ef96e03 100644
--- a/src/core/manager.h
+++ b/src/core/manager.h
@@ -232,6 +232,7 @@ struct Manager {
/* Flags */
SystemdRunningAs running_as;
ManagerExitCode exit_code:5;
+int exit_retval;
bool dispatching_load_queue:1;
bool dispatching_dbus_queue:1;
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index d9e9c2a..11c7e55 100644
--- a/src/systemctl/systemctl.c
+++
Re: [systemd-devel] [PATCH] unit: do not order timers.target before basic.target
On Fri, 07.11.14 03:02, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: I must say I kinda like the fact that pulling in and reaching basic.target makes sure all those background things that can fire have been set up for firing, and everything else can then just assume that things are available and ready. Yes, that's true, but OTOH, there's a downside to complexity. We have to explain the difference between timers, and timer-calendar... Timers can have multiple On* stanzas, so adding an OnCalendar= would move the timer from one group to another, which would mean that adding a new On* stanza could *delay* a timer. This behaviour would have to be documented and explained. I find the idea of simply saying timers by default are started asynchronously on boot much nicer. Well, sure, we'd have to document this, but it's really just one sentence. I think in real-life we'll probably not have too many timers that mix monotonic and calendar triggers... I mean, you do have a point, they are asynchronous anyway, there are no latency guarantees, and it is hence of little value to know that they are established before basic.target... Maybe I can live with moving timers.target to a later point, but somebody needs to update the bootup(7) graphic 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] Add support for supplying an exit status code to systemctl exit
On Thu, 06.11.14 18:09, Vito Caputo (vito.cap...@coreos.com) wrote:
The capability of directly propagating a return code out to the caller of
systemd --user from within something like an OnFailure unit has utility.
This also contains a minor fixup to the documentation adding exit to the
--force section.
Patch is borked, is line-broken. Please resend non-line-broken
version! It's so hard to review otherwise.
Cheers,
Vito Caputo
---
man/systemctl.xml | 11 ++-
src/core/dbus-manager.c | 6 +-
src/core/main.c | 2 +-
src/core/manager.c| 1 +
src/core/manager.h| 1 +
src/systemctl/systemctl.c | 20 ++--
6 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/man/systemctl.xml b/man/systemctl.xml
index 7cbaa6c..25ad2f7 100644
--- a/man/systemctl.xml
+++ b/man/systemctl.xml
@@ -432,9 +432,9 @@ along with systemd; If not, see
http://www.gnu.org/licenses/.
paraWhen used with commandenable/command, overwrite
any existing conflicting symlinks./para
- paraWhen used with commandhalt/command,
- commandpoweroff/command, commandreboot/command or
- commandkexec/command, execute the selected operation
+ paraWhen used with commandexit/command,
commandhalt/command,
+ commandpoweroff/command, commandreboot/command or
+ commandkexec/command, execute the selected operation
without shutting down all units. However, all processes will
be killed forcibly and all file systems are unmounted or
remounted read-only. This is hence a drastic but relatively
@@ -1485,13 +1485,14 @@ kobject-uevent 1 systemd-udevd-kernel.socket
systemd-udevd.service
/listitem
/varlistentry
varlistentry
- termcommandexit/command/term
+ termcommandexit
optionalreplaceableSTATUS/replaceable/optional/command/term
listitem
paraAsk the systemd manager to quit. This is only
supported for user service managers (i.e. in conjunction
with the option--user/option option) and will fail
-otherwise./para
+otherwise. Used in conjunction with --force a status code may
be
+ propagated into the sytemd manager's exit code./para
/listitem
/varlistentry
diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
index c54abd3..78f7f6d 100644
--- a/src/core/dbus-manager.c
+++ b/src/core/dbus-manager.c
@@ -1140,6 +1140,10 @@ static int method_exit(sd_bus *bus, sd_bus_message
*message, void *userdata, sd_
if (m-running_as == SYSTEMD_SYSTEM)
return sd_bus_error_setf(error,
SD_BUS_ERROR_NOT_SUPPORTED, Exit is only supported for user service
managers.);
+r = sd_bus_message_read(message, i, m-exit_retval);
+if (r 0)
+return r;
+
m-exit_code = MANAGER_EXIT;
return sd_bus_reply_method_return(message, NULL);
@@ -1918,7 +1922,7 @@ const sd_bus_vtable bus_manager_vtable[] = {
SD_BUS_METHOD(RemoveSnapshot, s, NULL, method_remove_snapshot,
0),
SD_BUS_METHOD(Reload, NULL, NULL, method_reload,
SD_BUS_VTABLE_UNPRIVILEGED),
SD_BUS_METHOD(Reexecute, NULL, NULL, method_reexecute,
SD_BUS_VTABLE_UNPRIVILEGED),
-SD_BUS_METHOD(Exit, NULL, NULL, method_exit, 0),
+SD_BUS_METHOD(Exit, i, NULL, method_exit, 0),
SD_BUS_METHOD(Reboot, NULL, NULL, method_reboot,
SD_BUS_VTABLE_CAPABILITY(CAP_SYS_BOOT)),
SD_BUS_METHOD(PowerOff, NULL, NULL, method_poweroff,
SD_BUS_VTABLE_CAPABILITY(CAP_SYS_BOOT)),
SD_BUS_METHOD(Halt, NULL, NULL, method_halt,
SD_BUS_VTABLE_CAPABILITY(CAP_SYS_BOOT)),
diff --git a/src/core/main.c b/src/core/main.c
index d48604e..2481f5c 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -1737,7 +1737,7 @@ int main(int argc, char *argv[]) {
switch (m-exit_code) {
case MANAGER_EXIT:
-retval = EXIT_SUCCESS;
+retval = m-exit_retval;
log_debug(Exit.);
goto finish;
diff --git a/src/core/manager.c b/src/core/manager.c
index 129f6dd..e417514 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -550,6 +550,7 @@ int manager_new(SystemdRunningAs running_as, bool
test_run, Manager **_m) {
m-running_as = running_as;
m-exit_code = _MANAGER_EXIT_CODE_INVALID;
+m-exit_retval = EXIT_SUCCESS;
m-default_timer_accuracy_usec = USEC_PER_MINUTE;
m-idle_pipe[0] = m-idle_pipe[1] = m-idle_pipe[2] =
m-idle_pipe[3] = -1;
diff --git a/src/core/manager.h b/src/core/manager.h
index ab72548..ef96e03 100644
--- a/src/core/manager.h
+++ b/src/core/manager.h
@@ -232,6 +232,7 @@ struct Manager {
/* Flags */
Re: [systemd-devel] [PATCH] Add support for supplying an exit status code to systemctl exit
On Thu, 06.11.14 18:09, Vito Caputo (vito.cap...@coreos.com) wrote:
+r = sd_bus_message_read(message, i, m-exit_retval);
+if (r 0)
+return r;
+
m-exit_code = MANAGER_EXIT;
return sd_bus_reply_method_return(message, NULL);
@@ -1918,7 +1922,7 @@ const sd_bus_vtable bus_manager_vtable[] = {
SD_BUS_METHOD(RemoveSnapshot, s, NULL, method_remove_snapshot,
0),
SD_BUS_METHOD(Reload, NULL, NULL, method_reload,
SD_BUS_VTABLE_UNPRIVILEGED),
SD_BUS_METHOD(Reexecute, NULL, NULL, method_reexecute,
SD_BUS_VTABLE_UNPRIVILEGED),
-SD_BUS_METHOD(Exit, NULL, NULL, method_exit, 0),
+SD_BUS_METHOD(Exit, i, NULL, method_exit, 0),
I am not opposed to having this, but the bus interfaces are API we
cannot just change signatures of the calls. Please add a new call
ExitWithCode() or so as an alternative call with exit code.
@@ -4875,6 +4875,22 @@ static int daemon_reload(sd_bus *bus, char **args) {
if (r 0)
return bus_log_create_error(r);
+if (streq(method, Exit)) {
+int retval = EXIT_SUCCESS;
+
+if (strv_length(args) 1) {
+r = safe_atoi(args[1], retval);
+if (r 0) {
+log_error(Invalid exit status: %s,
strerror(-r));
+return -EINVAL;
+}
+}
+
+r = sd_bus_message_append(m, i, retval);
+if (r 0)
+return bus_log_create_error(r);
+}
This check really needs to be within the if block that checks if
arg_action is ACTION_SYSTEMCTL (the one with the assert). The
parameter should only be parsed if we are invoked as systemctl, not
as any of the other symlinked tools like reboot or so (not that we'd
expose Exit() in those other tools, but please let's keep this clean).
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] user environment variables
On Fri, 31.10.14 17:16, arnaud gaboury (arnaud.gabo...@gmail.com) wrote: For systemd be aware of certain environment variables, I usually use a drop-in config in /etc/systemd/system/user@service.d. This way, I can see the varibale when running $ systemctl --user show-environment Now I am wondering why not using the /etc/systemd/user.conf for these variables. I tried this: .. DefaultEnvironment=DISPLAY=:0 RXVT_SOCKET=$XDG_RUNTIME_DIR/urxvt-hortensia TOTO=me Unfortunately, - gabx@hortensia ➤➤ ~ % systemctl --user show-environment DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/dbus/user_bus_socket DISPLAY=:0 TOTO=me HOME=/home/gabx LANG=en_US.UTF-8 LC_COLLATE=C LOGNAME=gabx MAIL=/var/spool/mail/gabx PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin RXVT_SOCKET=$XDG_RUNTIME_DIR/urxvt-hortensia SHELL=/usr/bin/zsh USER=gabx XDG_RUNTIME_DIR=/run/user/1000 the path is not recognized, even if XDG_RUNTIME_DIR is a known variable. Please note that DISPLAY and TOTO are recognized I am wondering what I am doing wrong with RXVT_SOCKET ? When systemd parses user.conf it does not resolve env vars in the shel $foo syntax. In fact we don't do that for almost any field, except ExecStart= and friends really. 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. 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, 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. User instances do and also avoid other undesired things like reading extra args from /proc/cmdline which isn't applicable to a container. There's already an explicit check in place that makes sure read /proc/1/cmdline in place of of /proc/cmdline if we detect we are run in a container: http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/util.c#n6174 Missed that one, some other difference in behaviour mislead us I suppose. There seems to be a odd fit here between expecting a system instance to behave nicely like yet another service on a host or a user instance to be pid 1 in a container. 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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] unit: do not order timers.target before basic.target
On Fri, Nov 07, 2014 at 03:13:12AM +0100, Lennart Poettering wrote: On Fri, 07.11.14 03:02, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: I must say I kinda like the fact that pulling in and reaching basic.target makes sure all those background things that can fire have been set up for firing, and everything else can then just assume that things are available and ready. Yes, that's true, but OTOH, there's a downside to complexity. We have to explain the difference between timers, and timer-calendar... Timers can have multiple On* stanzas, so adding an OnCalendar= would move the timer from one group to another, which would mean that adding a new On* stanza could *delay* a timer. This behaviour would have to be documented and explained. I find the idea of simply saying timers by default are started asynchronously on boot much nicer. Well, sure, we'd have to document this, but it's really just one sentence. I think in real-life we'll probably not have too many timers that mix monotonic and calendar triggers... I mean, you do have a point, they are asynchronous anyway, there are no latency guarantees, and it is hence of little value to know that they are established before basic.target... Maybe I can live with moving timers.target to a later point, but somebody needs to update the bootup(7) graphic now! Deal! I'll push an update. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Shutdown problems
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 / 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? Thanks! -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC 0/4] use libmount for mount unit handling
This patchset is an attempt to use libmount for mount unit handling, in order to address the issues I raised with the _netdev option and remote-fs ordering not working as expected. The first three patches I think are fairly complete, while the final patch may need additional work to get everything right. Also, as I mention in that patch description, remounts aren't picking up utab settings but I think that's a libmount issue. Thanks for taking the time to look at this, Chris Leech (4): use libmount to enumerate /proc/self/mountinfo check options as well as fstype for network mounts monitor for utab changes with inotify add remote-fs dependencies if needed after change .travis.yml| 2 +- Makefile.am| 4 +- README | 1 + configure.ac | 13 + src/core/build.h | 7 +++ src/core/manager.c | 2 +- src/core/manager.h | 2 + src/core/mount.c | 145 + 8 files changed, 163 insertions(+), 13 deletions(-) -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC 4/4] add remote-fs dependencies if needed after change
This is an attempt to add it the remote-fs dependencies to a mount unit
if the options change, like when the utab options are picked up after
mountinfo has already been processed. It just adds the remote-fs
dependencies, leaving the local-fs ones in place.
With this change I always get mount units with proper remote-fs
dependencies when mounted with the _netdev option.
It it not working for -o remount,_netdev. But that looks like a
libmount issue in that the ROOT field is not being set in utab on a
remount, so if the initial mount did not require a utab entry then
remount options never get merge in properly in mnt_table_parse_mtab
---
src/core/mount.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/core/mount.c b/src/core/mount.c
index 7d77021..092a720 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -1436,6 +1436,19 @@ static int mount_add_one(
}
}
+if (m-running_as == SYSTEMD_SYSTEM) {
+const char* target;
+
+target = mount_needs_network(options, fstype) ?
SPECIAL_REMOTE_FS_TARGET : NULL;
+/* _netdev option may have shown up late, or on a
+ * remount. Add remote-fs dependencies, even though
+ * local-fs ones may already be there */
+if (target) {
+unit_add_dependency_by_name(u, UNIT_BEFORE,
target, NULL, true);
+load_extras = true;
+}
+}
+
if (u-load_state == UNIT_NOT_FOUND) {
u-load_state = UNIT_LOADED;
u-load_error = 0;
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC 2/4] check options as well as fstype for network mounts
When creating a new mount unit after an event on /proc/self/mountinfo,
check the mount options as well as the fstype to determine if this is a
remote mount that requires network access.
---
src/core/mount.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/src/core/mount.c b/src/core/mount.c
index a639515..2bc7b14 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -68,16 +68,20 @@ static const UnitActiveState
state_translation_table[_MOUNT_STATE_MAX] = {
static int mount_dispatch_timer(sd_event_source *source, usec_t usec, void
*userdata);
static int mount_dispatch_io(sd_event_source *source, int fd, uint32_t
revents, void *userdata);
+static bool mount_needs_network(const char *options, const char *fstype) {
+if (mount_test_option(options, _netdev))
+return true;
+
+if (fstype fstype_is_network(fstype))
+return true;
+
+return false;
+}
+
static bool mount_is_network(MountParameters *p) {
assert(p);
-if (mount_test_option(p-options, _netdev))
-return true;
-
-if (p-fstype fstype_is_network(p-fstype))
-return true;
-
-return false;
+return mount_needs_network(p-options, p-fstype);
}
static bool mount_is_bind(MountParameters *p) {
@@ -1408,8 +1412,7 @@ static int mount_add_one(
if (m-running_as == SYSTEMD_SYSTEM) {
const char* target;
-target = fstype_is_network(fstype) ?
SPECIAL_REMOTE_FS_TARGET : SPECIAL_LOCAL_FS_TARGET;
-
+target = mount_needs_network(options, fstype) ?
SPECIAL_REMOTE_FS_TARGET : SPECIAL_LOCAL_FS_TARGET;
r = unit_add_dependency_by_name(u, UNIT_BEFORE,
target, NULL, true);
if (r 0)
goto fail;
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC 3/4] monitor for utab changes with inotify
Parsing the mount table with libmount races against the mount command,
which will handle the actual mounting before updating utab. This means
the poll event on /proc/self/mountinfo can kick of a reparse in systemd
before the utab information is available.
This change adds in an additional event source using inotify to watch
for changes to utab. It only watches for IN_MOVED_TO events, matching
libmount behavior of always overwriting this file using rename(2).
This does add a second pass through the mount table parsing when utab is
updated.
---
src/core/manager.c | 2 +-
src/core/manager.h | 2 ++
src/core/mount.c | 57 +-
3 files changed, 55 insertions(+), 6 deletions(-)
diff --git a/src/core/manager.c b/src/core/manager.c
index 129f6dd..7362149 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -554,7 +554,7 @@ int manager_new(SystemdRunningAs running_as, bool test_run,
Manager **_m) {
m-idle_pipe[0] = m-idle_pipe[1] = m-idle_pipe[2] = m-idle_pipe[3]
= -1;
-m-pin_cgroupfs_fd = m-notify_fd = m-signal_fd = m-time_change_fd =
m-dev_autofs_fd = m-private_listen_fd = m-kdbus_fd = -1;
+m-pin_cgroupfs_fd = m-notify_fd = m-signal_fd = m-time_change_fd =
m-dev_autofs_fd = m-private_listen_fd = m-kdbus_fd = m-utab_inotify_fd = -1;
m-current_job_id = 1; /* start as id #1, so that we can leave #0
around as null-like value */
m-ask_password_inotify_fd = -1;
diff --git a/src/core/manager.h b/src/core/manager.h
index ab72548..bdeea14 100644
--- a/src/core/manager.h
+++ b/src/core/manager.h
@@ -182,6 +182,8 @@ struct Manager {
/* Data specific to the mount subsystem */
FILE *proc_self_mountinfo;
sd_event_source *mount_event_source;
+int utab_inotify_fd;
+sd_event_source *mount_utab_event_source;
/* Data specific to the swap filesystem */
FILE *proc_swaps;
diff --git a/src/core/mount.c b/src/core/mount.c
index 2bc7b14..7d77021 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -26,9 +26,8 @@
#include signal.h
#ifdef HAVE_LIBMOUNT
+#include sys/inotify.h
#include libmount.h
-#else
-#define mnt_init_debug(m) do {} while (0)
#endif
#include manager.h
@@ -1615,11 +1614,13 @@ static void mount_shutdown(Manager *m) {
assert(m);
m-mount_event_source = sd_event_source_unref(m-mount_event_source);
+m-mount_utab_event_source =
sd_event_source_unref(m-mount_utab_event_source);
if (m-proc_self_mountinfo) {
fclose(m-proc_self_mountinfo);
m-proc_self_mountinfo = NULL;
}
+m-utab_inotify_fd = safe_close(m-utab_inotify_fd);
}
static int mount_get_timeout(Unit *u, uint64_t *timeout) {
@@ -1640,8 +1641,6 @@ static int mount_enumerate(Manager *m) {
int r;
assert(m);
-mnt_init_debug(0);
-
if (!m-proc_self_mountinfo) {
m-proc_self_mountinfo = fopen(/proc/self/mountinfo, re);
if (!m-proc_self_mountinfo)
@@ -1658,6 +1657,27 @@ static int mount_enumerate(Manager *m) {
if (r 0)
goto fail;
}
+#ifdef HAVE_LIBMOUNT
+mnt_init_debug(0);
+
+if (m-utab_inotify_fd 0) {
+m-utab_inotify_fd = inotify_init1(IN_NONBLOCK|IN_CLOEXEC);
+if (m-utab_inotify_fd 0)
+goto fail_with_errno;
+
+r = inotify_add_watch(m-utab_inotify_fd, /run/mount,
IN_MOVED_TO);
+if (r 0)
+goto fail_with_errno;
+
+r = sd_event_add_io(m-event, m-mount_utab_event_source,
m-utab_inotify_fd, EPOLLIN, mount_dispatch_io, m);
+if (r 0)
+goto fail;
+
+r = sd_event_source_set_priority(m-mount_utab_event_source,
-10);
+if (r 0)
+goto fail;
+}
+#endif
r = mount_load_proc_self_mountinfo(m, false);
if (r 0)
@@ -1665,6 +1685,8 @@ static int mount_enumerate(Manager *m) {
return 0;
+fail_with_errno:
+r = -errno;
fail:
mount_shutdown(m);
return r;
@@ -1676,12 +1698,37 @@ static int mount_dispatch_io(sd_event_source *source,
int fd, uint32_t revents,
int r;
assert(m);
-assert(revents EPOLLPRI);
+assert(revents (EPOLLPRI | EPOLLIN));
/* The manager calls this for every fd event happening on the
* /proc/self/mountinfo file, which informs us about mounting
* table changes */
+#ifdef HAVE_LIBMOUNT
+/* This may also be called for /run/mount events */
+if (fd == m-utab_inotify_fd) {
+char inotify_buffer[sizeof(struct inotify_event) + NAME_MAX +
1];
+struct inotify_event *event;
+char *p;
+int rescan = 0;
+
+while ((r =
[systemd-devel] [RFC 1/4] use libmount to enumerate /proc/self/mountinfo
This lets libmount add in user options from /run/mount/utab, like
_netdev which is needed to get proper ordering against remote-fs.target
---
.travis.yml | 2 +-
Makefile.am | 4 +++-
README | 1 +
configure.ac | 13
src/core/build.h | 7 +++
src/core/mount.c | 62
6 files changed, 87 insertions(+), 2 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index 7e5251c..4ea2bc2 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -3,7 +3,7 @@ compiler:
- gcc
before_install:
- sudo apt-get update -qq
- - sudo apt-get install autotools-dev automake autoconf libtool libdbus-1-dev
libcap-dev libblkid-dev libpam-dev libcryptsetup-dev libaudit-dev libacl1-dev
libattr1-dev libselinux-dev liblzma-dev libgcrypt-dev libqrencode-dev
libmicrohttpd-dev gtk-doc-tools gperf python2.7-dev
+ - sudo apt-get install autotools-dev automake autoconf libtool libdbus-1-dev
libcap-dev libblkid-dev libmount-dev libpam-dev libcryptsetup-dev libaudit-dev
libacl1-dev libattr1-dev libselinux-dev liblzma-dev libgcrypt-dev
libqrencode-dev libmicrohttpd-dev gtk-doc-tools gperf python2.7-dev
script: ./autogen.sh ./configure --enable-gtk-doc --enable-gtk-doc-pdf
make V=1 sudo ./systemd-machine-id-setup make check make distcheck
after_failure: cat test-suite.log
notifications:
diff --git a/Makefile.am b/Makefile.am
index 461ffa9..3deffe8 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1163,6 +1163,7 @@ libsystemd_core_la_CFLAGS = \
$(KMOD_CFLAGS) \
$(APPARMOR_CFLAGS) \
$(SECCOMP_CFLAGS) \
+ $(MOUNT_CFLAGS) \
-pthread
libsystemd_core_la_LIBADD = \
@@ -1177,7 +1178,8 @@ libsystemd_core_la_LIBADD = \
$(CAP_LIBS) \
$(KMOD_LIBS) \
$(APPARMOR_LIBS) \
- $(SECCOMP_LIBS)
+ $(SECCOMP_LIBS) \
+ $(MOUNT_LIBS)
if HAVE_SECCOMP
libsystemd_core_la_LIBADD += \
diff --git a/README b/README
index aefb349..89abc3e 100644
--- a/README
+++ b/README
@@ -108,6 +108,7 @@ REQUIREMENTS:
libcap
libseccomp = 1.0.0 (optional)
libblkid = 2.20 (from util-linux) (optional)
+libmount = 2.20 (from util-linux) (optional)
libkmod = 15 (optional)
PAM = 1.1.2 (optional)
libcryptsetup (optional)
diff --git a/configure.ac b/configure.ac
index 05fc00d..85ff053 100644
--- a/configure.ac
+++ b/configure.ac
@@ -426,6 +426,18 @@ fi
AM_CONDITIONAL(HAVE_BLKID, [test $have_blkid = yes])
#
--
+have_libmount=no
+AC_ARG_ENABLE(libmount, AS_HELP_STRING([--disable-libmount], [disable libmount
support]))
+if test x$enable_libmount != xno; then
+PKG_CHECK_MODULES(MOUNT, [ mount = 2.20 ],
+[AC_DEFINE(HAVE_LIBMOUNT, 1, [Define if libmount is
available]) have_libmount=yes], have_libmount=no)
+if test x$have_libmount = xno -a x$enable_libmount = xyes; then
+AC_MSG_ERROR([*** libmount support requested but libraries not
found])
+fi
+fi
+AM_CONDITIONAL(HAVE_LIBMOUNT, [test $have_libmount = yes])
+
+#
--
have_seccomp=no
AC_ARG_ENABLE(seccomp, AS_HELP_STRING([--disable-seccomp], [Disable optional
SECCOMP support]))
if test x$enable_seccomp != xno; then
@@ -1374,6 +1386,7 @@ AC_MSG_RESULT([
efi: ${have_efi}
kmod:${have_kmod}
blkid: ${have_blkid}
+libmount:${have_libmount}
dbus:${have_dbus}
nss-myhostname: ${have_myhostname}
gudev: ${enable_gudev}
diff --git a/src/core/build.h b/src/core/build.h
index d5e5550..5644693 100644
--- a/src/core/build.h
+++ b/src/core/build.h
@@ -117,6 +117,12 @@
#define _BLKID_FEATURE_ -BLKID
#endif
+#ifdef HAVE_LIBMOUNT
+#define _LIBMOUNT_FEATURE_ +LIBMOUNT
+#else
+#define _LIBMOUNT_FEATURE_ -LIBMOUNT
+#endif
+
#ifdef HAVE_ELFUTILS
#define _ELFUTILS_FEATURE_ +ELFUTILS
#else
@@ -152,6 +158,7 @@
_LZ4_FEATURE_ \
_SECCOMP_FEATURE_ \
_BLKID_FEATURE_ \
+_LIBMOUNT_FEATURE_\
_ELFUTILS_FEATURE_\
_KMOD_FEATURE_\
_IDN_FEATURE_
diff --git a/src/core/mount.c b/src/core/mount.c
index 8b787f6..a639515 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -25,6 +25,12 @@
#include sys/epoll.h
#include signal.h
+#ifdef HAVE_LIBMOUNT
+#include libmount.h
+#else
+#define mnt_init_debug(m) do {} while (0)
+#endif
+
#include manager.h
#include unit.h
#include mount.h
@@ -1492,6 +1498,58 @@ fail:
Re: [systemd-devel] remote-fs ordering, iSCSI and _netdev
On Fri, Oct 31, 2014 at 09:32:57AM +0100, Karel Zak wrote: It would be really better to have within systemd a generic function is_net_blkdev() than rely on external fragile configuration. I have doubts that anyone uses -o _netdev on command line when manually mounts filesystem. The one thing I do like about _netdev, is that if it works is a simple workaround that can be documented for when more complicated detection schemes fail. Rather than trying to keep a list of all known network filesystem and block protocols up to date. 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. I'm sending an RFC patchset with a start at addressing this. - Chris ___ 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/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
is sh. Then /proc/$$/attr/current of sh is foo. There is no problems
to sh execute the /usr/bin/dbus-daemon because the sh has same label
with /usr/bin/dbus-daemon. Now /usr/bin/dbus-daemon will be executed by
sh. But it has SMACK64EXEC label bar. So executed attr/current of
/usr/bin/dbus-daemon is bar.
If the sh has label waldo, then maybe two case can be existed. If
label waldo has executable rule for label foo then the sh can
execute the /usr/bin/dbus-daemon. But if label waldo has no rule for
that, then sh can not execute the /usr/bin/dbus-daemon. EACCESS will be
occurred. If label waldo has executable rule for label foo and
/usr/bin/dbus-daemon was executed. Then the executed dbus-daemon process
has attribute bar at /proc/{pid of dbus-daemon}/attr/current.
# attr -l /bin/sleep
Attribute SMACK64 has a 4 byte value for /bin/sleep
Attribute SMACK64EXEC has a 3 byte value for /bin/sleep
# attr -S -g SMACK64 /bin/sleep
Attribute SMACK64 had a 4 byte value for /bin/sleep:
foo
# attr -S -g SMACK64EXEC /bin/sleep
Attribute SMACK64EXEC had a 3 byte value for /bin/sleep:
bar
# cat /proc/$$/attr/current
waldo
# /bin/sleep 100
[1] 15263
sh-3.2# cat /proc/15263/attr/current
bar
Additionally, SMACK64EXEC can be none. Then the executed process inherit
attribute from the caller process. So sh has attribute waldo and
/bin/sleep has only SMACK64 foo then the executed /bin/sleep process
has waldo attribute.
# cat /proc/$$/attr/current
waldo
# attr -l /bin/sleep
Attribute SMACK64 has a 4 byte value for /bin/sleep
# attr -S -g SMACK64 /bin/sleep
Attribute SMACK64 had a 4 byte value for /bin/sleep:
foo
# /bin/sleep 100
[1] 4509
# cat /proc/4509/attr/current
waldo
Back to the systemd execute problem with User= option. Exclude Netlabel,
the access checking is ignored for all root uid processes. So there is
no problems to execute the ExecStart= without User= option.
But if a service has User= option and executable binary on ExecStart=
has label foo then the fork()-ed systemd child process has no root
uid. And the child systemd process has _ label.(see below predefined
labels.) If _ has no executable rule for foo then access deny will
be occurred. So to successfully execute the ExecStart=, the child
systemd process have to has attribute something what can has executable
rule for the label of ExecStart= file.
Regarding to new option's naming, we will set attribute of process(child
systemd). So that is subject. So I think SmackLabelExec= or SMACK64EXEC=
are more appropriate.
I think we can consider another method. If we don't want to add new
SMACK option then we can do like this. Read the access label of
executable file of ExecStart=. And just set the label to attribute of
fork()-ed child systemd process. Then we don't need to add new SMACK
option. I'm not sure this is right way.
Regarding to the predefined labels:
https://www.kernel.org/doc/Documentation/security/Smack.txt
There are some predefined labels:
_ Pronounced floor, a single underscore character.
^ Pronounced hat, a single circumflex character.
* Pronounced star, a single asterisk character.
? Pronounced huh, a single question mark character.
@ Pronounced web, a single at sign character.
Every task on a Smack system is assigned a label. System tasks, such as
init(8) and systems daemons, are run with the floor (_) label. User tasks
are assigned labels according to the specification found in the
/etc/smack/user configuration file.
Thanks for reading,
WaLyong
(I think I'd confused. We should use SMACK64 or SmackLabel instead
SMACK64EXEC or SmackLabelExec
Re: [systemd-devel] Udev rules hardware database
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
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?
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.
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.
- 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.
- 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.
Martin
[1]
E: ID_MODEL=08af
E: ID_MODEL_FROM_DATABASE=QuickCam Easy/Cool
E: ID_VENDOR=046d
E: ID_VENDOR_FROM_DATABASE=Logitech, Inc.
--
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
