Re: [systemd-devel] [systemd-commits] units/basic.target units/poweroff.target units/reboot.target

[Colin Guthrie]

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

[David Herrmann]

Hi

On Wed, Nov 5, 2014 at 4:11 PM, Ray Strode  wrote:
> Hi,
>
> On Wed, Nov 5, 2014 at 9:53 AM, David Herrmann  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=

[Jan Synacek]

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=

[Jan Synacek]

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

[David Herrmann]

Hi Ray

On Thu, Nov 6, 2014 at 10:40 AM, David Herrmann  wrote:
> On Wed, Nov 5, 2014 at 4:11 PM, Ray Strode  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

[Przemyslaw Kedzierski]

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 
---
 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...@.serv

Re: [systemd-devel] [systemd-commits] units/basic.target units/poweroff.target units/reboot.target

[Lennart Poettering]

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

[Patrick Häcker]

> > 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

[Zbigniew Jędrzejewski-Szmek]

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

[Lennart Poettering]

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"

[Lennart Poettering]

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 @@
> >  server,
> >  tablet,
> >  handset,
> > -watch, as well as
> > +watch,
> > +robot, as well as
> >  the special chassis types
> >  vm and
> >  container 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"

[Lennart Poettering]

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 @@
> > >  server,
> > >  tablet,
> > >  handset,
> > > -watch, as well as
> > > +watch,
> > > +robot, as well as
> > >  the special chassis types
> > >  vm and
> > >  container 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

[Zbigniew Jędrzejewski-Szmek]

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

[Zbigniew Jędrzejewski-Szmek]

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

[Jóhann B. Guðmundsson]

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

[Zbigniew Jędrzejewski-Szmek]

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

[Lennart Poettering]

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

[Harald Hoyer]

On 05.11.2014 14:56, har...@redhat.com wrote:
> From: Harald Hoyer 
> 
> ---
>  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

[Harald Hoyer]

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 mailto:har...@redhat.com>>:
> 
> From: Harald Hoyer 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

[Lennart Poettering]

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 
> .
>  
>  
>  All 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.
>

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

[Lennart Poettering]

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?

[Harald Hoyer]

On 22.10.2014 21:08, Tobias Hunger wrote:
> Hi Lennart,
> 
> On Wed, Oct 22, 2014 at 7:03 PM, Lennart Poettering
>  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 sche

Re: [systemd-devel] [PATCH] smack: introduce new SmackLabelExec option

[Lennart Poettering]

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?

[Harald Hoyer]

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//
> 
> tree.
> 
> 
> These days this should of course be:
> 
> /usr/lib/modules//
> 
> 
> 
> The actual modules are stored in a:
> 
> /lib/modules//kernel/
> 
> subfolder.
> 
> 
> 
> If there are no compelling reasons to pick otherwise, we could use:
> 
> /usr/lib/kernel//
> 
> tree.
> 
> Inside there would be a:
> 
> /usr/lib/kernel//modules/
> 
> folder containing the actual modules (same as
> /lib/modules//kernel/)
> 
> 
> For compatibility, the /lib/modules/ could be symlinked
> to /usr/lib/kernel/ and a simple "modules -> kernel"
> symlink shipped inside the /usr/lib/kernel// folder. All
> old paths would work in that case.
> 
> 
> The kernel itself could then simply be:
> 
> /usr/lib/kernel//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/ 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"

[Noé RUBINSTEIN]

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 :

> 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 @@
> > > >  server,
> > > >  tablet,
> > > >  handset,
> > > > -watch, as well as
> > > > +watch,
> > > > +robot, as well as
> > > >  the special chassis types
> > > >  vm and
> > > >  container 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

[Zbigniew Jędrzejewski-Szmek]

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

[Simon McVittie]

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

[Zbigniew Jędrzejewski-Szmek]

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

[Damien Robert]

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

[Colin Guthrie]

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

[Lennart Poettering]

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

[Jan Janssen]

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

[Lennart Poettering]

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

[Thomas Meyer]

> Am 04.11.2014 um 20:01 schrieb Thomas Meyer :
> 
> 
>> Am 02.11.2014 um 12:48 schrieb Thomas Meyer :
>> 
>> 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

[WaLyong Cho]

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

[Lennart Poettering]

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

[Lennart Poettering]

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 

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

[Lennart Poettering]

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

[Jan Janssen]

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

[Lennart Poettering]

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

[Ronny Chevalier]

2014-11-06 19:59 GMT+01:00 Jan Janssen :
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

[WaLyong Cho]

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

[David Herrmann]

Hi

On Sun, Nov 2, 2014 at 12:48 PM, Thomas Meyer  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

[Lennart Poettering]

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 
> > .
> >  
> >  
> >  All 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.
> >
> 
> 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

[Vito Caputo]

---
 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

[Lennart Poettering]

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

[Greg Kroah-Hartman]

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

[Lennart Poettering]

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

[Michael Chapman]

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

[Lennart Poettering]

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

[Vito Caputo]

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 
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

[Lennart Poettering]

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

[Lennart Poettering]

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

[Vito Caputo]

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 
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] Poor man's reboot doesn't work

[Lennart Poettering]

On Sun, 02.11.14 12:48, Thomas Meyer (tho...@m3y3r.de) wrote:

> Hi,
> 
> I tried to switch to the emergency target and back to the graphical target,
> but this doesn't seem to work.
> 
> Should this work, i.e.?
> 
> # systemctl isolate emergency.target
> # systemctl isolate graphical.target
> 
> The services seems to fail with this error once I'm in the emergency.target
> and try to switch back to the graphical.target:
> status=219/CGROUP

Hmm, this is certainly weird.

Any chance you can do "strace -ff -p 1 -o /tmp/someplace/log" (maybe
from the debug shell). Then, trigger the issue again, and find the
tight log file in /tmp/someplace that ends with an exit(219). It would
be good to paste that file somewhere (or at least the last few lines
which might give an indication on what precisely fails), so that I can
have a look.

Also, try booting with debug logs on ("systemd.log_level=debug") and
see if this generates any additional log output that might be 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] manager: Ensure user's systemd runtime directory exists.

[Lennart Poettering]

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

[Lennart Poettering]

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

[Lennart Poettering]

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

Re: [systemd-devel] [PATCH v2 2/2] bootchart: escape non printable process name

[Lennart Poettering]

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=

[Lennart Poettering]

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

[Michael Marineau]

On Nov 6, 2014 5:17 PM, "Lennart Poettering"  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

[Lennart Poettering]

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

[Lennart Poettering]

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

[Zbigniew Jędrzejewski-Szmek]

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"

[Vito Caputo]

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/>.
   When used with enable, overwrite
   any existing conflicting symlinks.

-  When used with halt,
-  poweroff, reboot or
-  kexec, execute the selected operation
+ When used with exit,
halt,
+ poweroff, reboot or
+ kexec, 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
   
 
 
-  exit
+  exit
STATUS

   
 Ask the systemd manager to quit. This is only
 supported for user service managers (i.e. in conjunction
 with the --user option) and will fail
-otherwise.
+otherwise.  Used in conjunction with --force a status code may
be
+   propagated into the sytemd manager's exit code.
   

 
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
+++ b/src/systemctl/systemctl.c
@@ -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) {
+

Re: [systemd-devel] [PATCH] unit: do not order timers.target before basic.target

[Lennart Poettering]

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"

[Lennart Poettering]

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/>.
>When used with enable, overwrite
>any existing conflicting symlinks.
> 
> -  When used with halt,
> -  poweroff, reboot or
> -  kexec, execute the selected operation
> + When used with exit,
> halt,
> + poweroff, reboot or
> + kexec, 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
>
>  
>  
> -  exit
> +  exit
> STATUS
> 
>
>  Ask the systemd manager to quit. This is only
>  supported for user service managers (i.e. in conjunction
>  with the --user option) and will fail
> -otherwise.
> +otherwise.  Used in conjunction with --force a status code may
> be
> +   propagated into the sytemd manager's exit code.
>
> 
>  
> 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 

Re: [systemd-devel] [PATCH] Add support for supplying an exit status code to "systemctl exit"

[Lennart Poettering]

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

[Lennart Poettering]

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

[Michael Marineau]

On Thu, Nov 6, 2014 at 6:02 PM, Lennart Poettering
 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

[Zbigniew Jędrzejewski-Szmek]

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

[Nikolaus Rath]

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 2>&1
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

[Chris Leech]

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

[Chris Leech]

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

[Chris Leech]

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

[Chris Leech]

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 
 
 #ifdef HAVE_LIBMOUNT
+#include 
 #include 
-#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;
+
+   

[systemd-devel] [RFC 1/4] use libmount to enumerate /proc/self/mountinfo

[Chris Leech]

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 
 #include 
 
+#ifdef HAVE_LIBMOUNT
+#include 
+#else
+#define mnt_init_debug(m) do {} while (0)
+#endif
+
 #include "manager.h"
 #include "unit.h"
 #include "mou

Re: [systemd-devel] remote-fs ordering, iSCSI and _netdev

[Chris Leech]

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

[WaLyong Cho]

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

Re: [systemd-devel] Udev rules hardware database

[Martin Pitt]

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