Re: [systemd-devel] [PATCH] units: add SecureBits

[Topi Miettinen]

On 02/11/15 16:32, Lennart Poettering wrote:
 On Wed, 11.02.15 16:24, Topi Miettinen (toiwo...@gmail.com) wrote:
 
 On 02/10/15 21:00, Lennart Poettering wrote:
 On Sat, 07.02.15 10:40, Topi Miettinen (toiwo...@gmail.com) wrote:

 No setuid programs are expected to be executed, so add
 SecureBits=no-setuid-fixup no-setuid-fixup-locked
 to unit files.

 So, hmm, after reading the man page again: what's the rationale for
 precisely these bits?

 I mean no-setuid-fixup seems to be something that applies to setuid(),
 setresuid() calls and suchlike, which seems pretty uninteresting. Much
 more interesting is SECBIT_NOROOT, which disables suid binary
 handling...

 Yes, noroot noroot-locked was actually my intention, sorry. I'll update
 the patch.

 Maybe all of noroot noroot-locked no-setuid-fixup
 no-setuid-fixup-locked would be OK, but that probably needs another
 look at the programs if they switch UIDs.
 
 I'd be careful with more than noroot, since the other flags alter
 bbehaviour across setuid() and similar calls, and much of our code
 makes assumptions that will likely not hold if you set those bits...

Going back to no-setuid-fixup no-setuid-fixup-locked: First, I looked at
the kernel code if it matches the description on the manual page
capabilities(7) to prevent more embarrassment. In this case it does,
NO_SETUID_FIXUP prevents capability changes when the task calls
set[res]*uid().

Then I looked at all use cases of set[res]*uid() in systemd. They are
called directly by run and nspawn. Then they are used when connecting to
journal and setting up PAM in exec_spawn() as well as in
namespace_enter(). These in turn are used by sd-bus init which is used
by unit setup, so pretty much everything is affected. The good thing is
that none of the daemons except machined use these directly.
drop_privileges() uses set[res]*uid() and it is called from resolved,
coredump, networkd, timesyncd and bus-proxyd.

So avoiding those, at least the following could be candidates:
systemd-hostnamed.service
systemd-importd.service
systemd-journal-gatewayd.service
systemd-journal-remote.service
systemd-journal-upload.service
systemd-journald.service
systemd-localed.service
systemd-logind.service
systemd-timedated.service

It could still be possible that an external library could detect that
uid==0 and then switch uids to do things at lower privilege. This would
work, but the capabilities would not be dropped.

There's of course the question whether no-setuid-fixup
no-setuid-fixup-locked is useful. For daemons runnig as root, it would
not help anything (or could even make things worse e.g. in the library
case). But when the daemon runs as a different user, the flags could
make the life of attacker a tiny bit more difficult. This leaves only:
systemd-journal-gatewayd.service
systemd-journal-remote.service
systemd-journal-upload.service

I can make a patch for those if you agree, or the original patch can be
applied selectively.

Maybe more daemons should run as unprivileged user.

-Topi

 
 Lennart
 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] shutdown: avoid calling `kexec` binary unnessecarily

[Zbigniew Jędrzejewski-Szmek]

On Fri, Feb 13, 2015 at 02:18:07PM -0800, Shawn Landden wrote:
 Still use helper when Xen Dom0, to avoid duplicating some hairy code.
 So we don't have any logic to load kexec kernels?
 ---
  TODO|  3 ---
  src/core/shutdown.c | 33 -
  2 files changed, 20 insertions(+), 16 deletions(-)
 
 diff --git a/TODO b/TODO
 index 883b994..68b0af6 100644
 --- a/TODO
 +++ b/TODO
 @@ -85,9 +85,6 @@ Features:
  * maybe introduce WantsMountsFor=? Usecase:

 http://lists.freedesktop.org/archives/systemd-devel/2015-January/027729.html
  
 -* rework kexec logic to use new kexec_file_load() syscall, so that we
 -  don't have to call kexec tool anymore.
You patch does not really change this. We can still use kexec_file_load() to
load a kernel. But removing a call to kexec to actually do the reboot seems 
good.
So I guess this TODO item should stay.

One comment below.

  * The udev blkid built-in should expose a property that reflects
whether media was sensed in USB CF/SD card readers. This should then
be used to control SYSTEMD_READY=1/0 so that USB card readers aren't
 diff --git a/src/core/shutdown.c b/src/core/shutdown.c
 index 71f001a..c64c05d 100644
 --- a/src/core/shutdown.c
 +++ b/src/core/shutdown.c
 @@ -350,26 +350,33 @@ int main(int argc, char *argv[]) {
  case LINUX_REBOOT_CMD_KEXEC:
  
  if (!in_container) {
 -/* We cheat and exec kexec to avoid doing all its 
 work */
 -pid_t pid;
 +_cleanup_free_ char *param = NULL;
  
  log_info(Rebooting with kexec.);
  
 -pid = fork();
 -if (pid  0)
 -log_error_errno(errno, Failed to fork: %m);
 -else if (pid == 0) {
 +/* kexec-tools has a bunch of special code to make 
 Xen Dom0 work,
 + * otherwise it is only doing stuff we have already 
 done */
 +if (access(/proc/xen, F_OK) == 0) {
Wouldn't it be better to use detect_virtualization() here instead of 
open-coding the check?

 +pid_t pid;
 +
 +pid = fork();
 +if (pid  0)
 +log_error_errno(errno, Failed to 
 fork: %m);
 +else if (pid == 0) {
 +
 +const char * const args[] = {
 +KEXEC, -e, NULL
 +};
  
 -const char * const args[] = {
 -KEXEC, -e, NULL
 -};
 +/* Child */
  
 -/* Child */
 +execv(args[0], (char * const *) 
 args);
 +_exit(EXIT_FAILURE);
 +} else
 +wait_for_terminate_and_warn(kexec, 
 pid, true);
  
 -execv(args[0], (char * const *) args);
 -_exit(EXIT_FAILURE);
  } else
 -wait_for_terminate_and_warn(kexec, pid, 
 true);
 +reboot(cmd);
  }
  
  cmd = RB_AUTOBOOT;

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 1/9] fsckd daemon for inter-fsckd communication

[Zbigniew Jędrzejewski-Szmek]

On Thu, Feb 05, 2015 at 06:06:50PM +0100, Didier Roche wrote:
 Hey,
 
 Posting the new set of patches for the fsck/plymouth integration,
 rebased from all the comments and the systemd event loop system.
 
 This version talks the raw plymouth protocol directly, supporting
 only what is needed (sending updates, messages, requesting key
 listening, get key events). It's using Control+C as the cancellation
 key. If plymouth disconnects and then later respawn, the connection
 will be taken back. Same for any new fsck connection incoming after
 a cancellation (they will get cancelled right away). The update
 progress message is always reflecting the current connection state
 (they will only disappear once they are actually cleaned).
 
 As always, I'm opened to any comments.
 Cheers,
 Didier

 From ac8d6f10768a5bcba0b7932547419637983637b2 Mon Sep 17 00:00:00 2001
 From: Didier Roche didro...@ubuntu.com
 Date: Wed, 4 Feb 2015 16:42:47 +0100
 Subject: [PATCH 1/9] fsckd daemon for inter-fsckd communication
 
 Add systemd-fsckd multiplexer which accepts multiple systemd-fsck
 instances to connect to it and sends progress report. systemd-fsckd then
 computes and writes to /dev/console the number of devices currently being
 checked and the minimum fsck progress. This will be used for interactive
 progress report and cancelling in plymouth.
 
 systemd-fsckd stops on idle when no systemd-fsck is connected.
 
 Make the necessary changes to systemd-fsck to connect to the systemd-fsckd
 socket.
 ---
  .gitignore |   1 +
  Makefile.am|  13 ++
  src/fsck/fsck.c|  88 +---
  src/fsckd/Makefile |   1 +
  src/fsckd/fsckd.c  | 403 
 +
  src/fsckd/fsckd.h  |  34 +
  6 files changed, 486 insertions(+), 54 deletions(-)
  create mode 12 src/fsckd/Makefile
  create mode 100644 src/fsckd/fsckd.c
  create mode 100644 src/fsckd/fsckd.h
 
 diff --git a/.gitignore b/.gitignore
 index ab6d9d1..9400e75 100644
 --- a/.gitignore
 +++ b/.gitignore
 @@ -74,6 +74,7 @@
  /systemd-evcat
  /systemd-firstboot
  /systemd-fsck
 +/systemd-fsckd
  /systemd-fstab-generator
  /systemd-getty-generator
  /systemd-gnome-ask-password-agent
 diff --git a/Makefile.am b/Makefile.am
 index c463f23..e0e8bc6 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -389,6 +389,7 @@ rootlibexec_PROGRAMS = \
   systemd-remount-fs \
   systemd-reply-password \
   systemd-fsck \
 + systemd-fsckd \
   systemd-machine-id-commit \
   systemd-ac-power \
   systemd-sysctl \
 @@ -2355,6 +2356,18 @@ systemd_fsck_LDADD = \
   libsystemd-shared.la
  
  # 
 --
 +systemd_fsckd_SOURCES = \
 + src/fsckd/fsckd.c \
 + $(NULL)
 +
 +systemd_fsckd_LDADD = \
 + libsystemd-internal.la \
 + libsystemd-label.la \
 + libsystemd-shared.la \
 + libudev-internal.la \
 + $(NULL)
 +
 +# 
 --
  systemd_machine_id_commit_SOURCES = \
   src/machine-id-commit/machine-id-commit.c \
   src/core/machine-id-setup.c \
 diff --git a/src/fsck/fsck.c b/src/fsck/fsck.c
 index 20b7940..9d9739b 100644
 --- a/src/fsck/fsck.c
 +++ b/src/fsck/fsck.c
 @@ -27,6 +27,7 @@
  #include unistd.h
  #include fcntl.h
  #include sys/file.h
 +#include sys/stat.h
  
  #include sd-bus.h
  #include libudev.h
 @@ -39,6 +40,8 @@
  #include fileio.h
  #include udev-util.h
  #include path-util.h
 +#include socket-util.h
 +#include fsckd/fsckd.h
  
  static bool arg_skip = false;
  static bool arg_force = false;
 @@ -132,58 +135,42 @@ static void test_files(void) {
  arg_show_progress = true;
  }
  
 -static double percent(int pass, unsigned long cur, unsigned long max) {
 -/* Values stolen from e2fsck */
 -
 -static const int pass_table[] = {
 -0, 70, 90, 92, 95, 100
 +static int process_progress(int fd, dev_t device_num) {
 +_cleanup_fclose_ FILE *f = NULL;
 +usec_t last = 0;
 +_cleanup_close_ int fsckd_fd = -1;
 +static const union sockaddr_union sa = {
 +.un.sun_family = AF_UNIX,
 +.un.sun_path = FSCKD_SOCKET_PATH,
  };
  
 -if (pass = 0)
 -return 0.0;
 -
 -if ((unsigned) pass = ELEMENTSOF(pass_table) || max == 0)
 -return 100.0;
 -
 -return (double) pass_table[pass-1] +
 -((double) pass_table[pass] - (double) pass_table[pass-1]) *
 -(double) cur / (double) max;
 -}
 -
 -static int process_progress(int fd) {
 -_cleanup_fclose_ FILE *console = NULL, *f = NULL;
 -usec_t last = 0;
 -bool locked = false;
 -int clear = 0;
 +fsckd_fd = socket(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC, 0);
 +if (fsckd_fd  0) {
 +log_warning_errno(errno, Cannot open fsckd socket, we won't 
 report fsck 

Re: [systemd-devel] [PATCH] bootchart: display each CPU utilization/wait

[Zbigniew Jędrzejewski-Szmek]

On Fri, Feb 13, 2015 at 02:59:39PM +0900, WaLyong Cho wrote:
 ---
  src/bootchart/bootchart.c| 38 +-
  src/bootchart/bootchart.conf |  1 +
  src/bootchart/bootchart.h|  1 +
  src/bootchart/svg.c  | 65 
 +---
  4 files changed, 70 insertions(+), 35 deletions(-)
 
 diff --git a/src/bootchart/bootchart.c b/src/bootchart/bootchart.c
 index b49e2c9..2c2b329 100644
 --- a/src/bootchart/bootchart.c
 +++ b/src/bootchart/bootchart.c
 @@ -87,6 +87,7 @@ bool arg_filter = true;
  bool arg_show_cmdline = false;
  bool arg_show_cgroup = false;
  bool arg_pss = false;
 +bool arg_percpu = false;
  int samples;
  int arg_samples_len = DEFAULT_SAMPLES_LEN; /* we record len+1 (1 start 
 sample) */
  double arg_hz = DEFAULT_HZ;
 @@ -122,6 +123,7 @@ static void parse_conf(void) {
  { Bootchart, ScaleX,   config_parse_double, 0, 
 arg_scale_x },
  { Bootchart, ScaleY,   config_parse_double, 0, 
 arg_scale_y },
  { Bootchart, ControlGroup, config_parse_bool,   0, 
 arg_show_cgroup },
 +{ Bootchart, PerCPU,   config_parse_bool,   0, 
 arg_percpu  },
  { NULL, NULL, NULL, 0, NULL }
  };
  
 @@ -151,6 +153,7 @@ static void help(void) {
-F, --no-filter   Disable filtering of unimportant or 
 ephemeral processes\n
-C, --cmdline Display full command lines with 
 arguments\n
-c, --control-group   Display process control group\n
 +  --per-cpu Draw each CPU utilization and wait 
 bar also\n
-h, --helpDisplay this message\n\n
  See bootchart.conf for more information.\n,
  program_invocation_short_name,
 @@ -163,20 +166,26 @@ static void help(void) {
  }
  
  static int parse_argv(int argc, char *argv[]) {
 +
 +enum {
 +ARG_PERCPU,
This get's initialized to 0. We normally do something like ARG_PERCPU = 0x100
on the first entry in this enum, to make sure that we get a value which is
higher than any ASCII character.

 +};
 +
  static const struct option options[] = {
 -{rel,   no_argument,NULL,  'r'},
 -{freq,  required_argument,  NULL,  'f'},
 -{samples,   required_argument,  NULL,  'n'},
 -{pss,   no_argument,NULL,  'p'},
 -{output,required_argument,  NULL,  'o'},
 -{init,  required_argument,  NULL,  'i'},
 -{no-filter, no_argument,NULL,  'F'},
 -{cmdline,   no_argument,NULL,  'C'},
 -{control-group, no_argument,NULL,  'c'},
 -{help,  no_argument,NULL,  'h'},
 -{scale-x,   required_argument,  NULL,  'x'},
 -{scale-y,   required_argument,  NULL,  'y'},
 -{entropy,   no_argument,NULL,  'e'},
 +{rel,   no_argument,NULL,  'r'   },
 +{freq,  required_argument,  NULL,  'f'   },
 +{samples,   required_argument,  NULL,  'n'   },
 +{pss,   no_argument,NULL,  'p'   },
 +{output,required_argument,  NULL,  'o'   },
 +{init,  required_argument,  NULL,  'i'   },
 +{no-filter, no_argument,NULL,  'F'   },
 +{cmdline,   no_argument,NULL,  'C'   },
 +{control-group, no_argument,NULL,  'c'   },
 +{help,  no_argument,NULL,  'h'   },
 +{scale-x,   required_argument,  NULL,  'x'   },
 +{scale-y,   required_argument,  NULL,  'y'   },
 +{entropy,   no_argument,NULL,  'e'   },
 +{per-cpu,   no_argument,NULL,  ARG_PERCPU},
  {}
  };
  int c, r;
 @@ -237,6 +246,9 @@ static int parse_argv(int argc, char *argv[]) {
  case 'e':
  arg_entropy = true;
  break;
 +case ARG_PERCPU:
 +arg_percpu = true;
 +break;
  case 'h':
  help();
  return 0;
 diff --git a/src/bootchart/bootchart.conf b/src/bootchart/bootchart.conf
 index c73328f..2d7cb61 100644
 --- a/src/bootchart/bootchart.conf
 +++ b/src/bootchart/bootchart.conf
 @@ -22,3 +22,4 @@
  #ScaleX=100
  #ScaleY=20
  #ControlGroup=no
 +#PerCPU=no
 diff --git a/src/bootchart/bootchart.h b/src/bootchart/bootchart.h
 index 2c37835..26de0dd 100644
 --- 

Re: [systemd-devel] [PATCH v3] Added support for Uplink Failure Detection using BindCarrier

[Tom Gundersen]

On Sat, Feb 14, 2015 at 3:05 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Fri, Feb 13, 2015 at 10:27:07PM +0100, Tom Gundersen wrote:
 Hi Alin,

 Thanks for the patch. This is starting to look pretty good now.

 I still have some questions/requests regarding some implementation
 details (below), but hopefully we can get this merged after the next
 release (trying to stabilize things at the moment).

 On Tue, Feb 10, 2015 at 12:30 PM, Alin Rauta alin.ra...@intel.com wrote:
  ---
   man/systemd.network.xml  |  11 ++
   src/libsystemd/sd-network/sd-network.c   |   4 +
   src/network/networkctl.c | 211 
  ---
   src/network/networkd-link.c  | 123 +-
   src/network/networkd-link.h  |   1 +
   src/network/networkd-manager.c   |   7 +
   src/network/networkd-network-gperf.gperf |   1 +
   src/network/networkd-network.c   |  10 ++
   src/network/networkd.h   |   2 +-
   src/systemd/sd-network.h |   3 +
   10 files changed, 355 insertions(+), 18 deletions(-)
 
  diff --git a/man/systemd.network.xml b/man/systemd.network.xml
  index 9b3a92d..8b2ca4e 100644
  --- a/man/systemd.network.xml
  +++ b/man/systemd.network.xml
  @@ -270,6 +270,17 @@
 /listitem
   /varlistentry
   varlistentry
  +  termvarnameBindCarrier=/varname/term
  +  listitem
  +paraA port or a list of ports. When set, controls the
  +behaviour of the current interface. When all ports in the list
  +are operational down, the failure is propagated to the current
 operational down does not follow normal grammar rules. are in an 
 operational
 down state?

  +interface. When at least one port has carrier, the current
  +interface is brought up.
  +/para

 Maybe we should make it clear that this is not necessarily a failure
 (the uplink may be down on purpose), and that the way we propagate it
 is to set the downlink administrative down.

  +  /listitem
  +/varlistentry
  +varlistentry
 termvarnameAddress=/varname/term
 listitem
   paraA static IPv4 or IPv6 address and its prefix length,
  diff --git a/src/libsystemd/sd-network/sd-network.c 
  b/src/libsystemd/sd-network/sd-network.c
  index c735cac..b574d19 100644
  --- a/src/libsystemd/sd-network/sd-network.c
  +++ b/src/libsystemd/sd-network/sd-network.c
  @@ -264,6 +264,10 @@ _public_ int sd_network_link_get_domains(int ifindex, 
  char ***ret) {
   return network_get_link_strv(DOMAINS, ifindex, ret);
   }
 
  +_public_ int sd_network_link_get_carriers(int ifindex, char ***ret) {
  +return network_get_link_strv(CARRIERS, ifindex, ret);
  +}

 I don't find get_carriers() very clear. At least call it
 get_carrier_bound_to() or something like that. I must say I agree with
 Lennart and Zbigniew, we should introduce the API in both directions,
 and then we can worry about the performance if that turns out to be a
 problem (worst case all the processing could be hidden in the
 sd-network library, but I don't think that will be necessary to be
 honest).

   _public_ int sd_network_link_get_wildcard_domain(int ifindex) {
   int r;
   _cleanup_free_ char *p = NULL, *s = NULL;
  diff --git a/src/network/networkctl.c b/src/network/networkctl.c
  index aa83f32..ffb38e8 100644
  --- a/src/network/networkctl.c
  +++ b/src/network/networkctl.c
  @@ -22,6 +22,7 @@
   #include stdbool.h
   #include getopt.h
   #include net/if.h
  +#include fnmatch.h
 
   #include sd-network.h
   #include sd-rtnl.h
  @@ -393,6 +394,161 @@ static int get_gateway_description(
   return -ENODATA;
   }
 
  +static bool is_carrier(const char *ifname,
  +   char **carriers) {
  +   char **i;
  +
  +   STRV_FOREACH(i, carriers)
  +   if (fnmatch(*i, ifname, 0) == 0)
  +   return true;
  +
  +   return false;
  +}
  +
  +/* get the links that are bound to this port. */
  +static int get_downlinks(const char *name,
  + sd_rtnl_message *m,
  + LinkInfo **downlinks,
  + int *down_count) {
  +_cleanup_free_ LinkInfo  *links = NULL;
  +sd_rtnl_message *i;
  +size_t size = 0;
  +size_t c = 0;
 Why is c size_t?

  +int r;
  +
  +assert(m);
  +assert(name);
  +
  +*down_count = 0;
  +*downlinks = NULL;
 Why do you initialize this here? If an error happens, it is nice to not 
 modify output
 parameters at all.

  +for (i = m; i; i = sd_rtnl_message_next(i)) {
  +_cleanup_strv_free_ char **carriers = NULL;
  +const char *link_name;
  +int ifindex;
  +
  +r = sd_rtnl_message_link_get_ifindex(i, ifindex);
  

Re: [systemd-devel] [PATCH v3] Added support for Uplink Failure Detection using BindCarrier

[Rauta, Alin]

Hi guys,

Thanks for your input on this. Much appreciated.
I'll try handle your remarks in the next patch.
Please find my comments below.

Best Regards,
Alin

 -Original Message-
 From: Tom Gundersen [mailto:t...@jklm.no] 
 Sent: Saturday, February 14, 2015 2:50 PM
 To: Zbigniew Jędrzejewski-Szmek
 Cc: Rauta, Alin; Lennart Poettering; systemd Mailing List; Kinsella, Ray
 Subject: Re: [PATCH v3] Added support for Uplink Failure Detection using 
 BindCarrier

 On Sat, Feb 14, 2015 at 3:05 PM, Zbigniew Jędrzejewski-Szmek 
 zbys...@in.waw.pl wrote:
 On Fri, Feb 13, 2015 at 10:27:07PM +0100, Tom Gundersen wrote:
 Hi Alin,

 Thanks for the patch. This is starting to look pretty good now.

 I still have some questions/requests regarding some implementation 
 details (below), but hopefully we can get this merged after the next 
 release (trying to stabilize things at the moment).

 On Tue, Feb 10, 2015 at 12:30 PM, Alin Rauta alin.ra...@intel.com wrote:
  ---
   man/systemd.network.xml  |  11 ++
   src/libsystemd/sd-network/sd-network.c   |   4 +
   src/network/networkctl.c | 211 
  ---
   src/network/networkd-link.c  | 123 +-
   src/network/networkd-link.h  |   1 +
   src/network/networkd-manager.c   |   7 +
   src/network/networkd-network-gperf.gperf |   1 +
   src/network/networkd-network.c   |  10 ++
   src/network/networkd.h   |   2 +-
   src/systemd/sd-network.h |   3 +
   10 files changed, 355 insertions(+), 18 deletions(-)
 
  diff --git a/man/systemd.network.xml b/man/systemd.network.xml 
  index 9b3a92d..8b2ca4e 100644
  --- a/man/systemd.network.xml
  +++ b/man/systemd.network.xml
  @@ -270,6 +270,17 @@
 /listitem
   /varlistentry
   varlistentry
  +  termvarnameBindCarrier=/varname/term
  +  listitem
  +paraA port or a list of ports. When set, controls the
  +behaviour of the current interface. When all ports in the list
  +are operational down, the failure is propagated to the 
  + current
 operational down does not follow normal grammar rules. are in an 
 operational down state?

  +interface. When at least one port has carrier, the current
  +interface is brought up.
  +/para

 Maybe we should make it clear that this is not necessarily a failure 
 (the uplink may be down on purpose), and that the way we propagate it 
 is to set the downlink administrative down.



Alin: 
I will think of something else here. Some other way to describe this.



  +  /listitem
  +/varlistentry
  +varlistentry
 termvarnameAddress=/varname/term
 listitem
   paraA static IPv4 or IPv6 address and its prefix 
  length, diff --git a/src/libsystemd/sd-network/sd-network.c 
  b/src/libsystemd/sd-network/sd-network.c
  index c735cac..b574d19 100644
  --- a/src/libsystemd/sd-network/sd-network.c
  +++ b/src/libsystemd/sd-network/sd-network.c
  @@ -264,6 +264,10 @@ _public_ int sd_network_link_get_domains(int ifindex, 
  char ***ret) {
   return network_get_link_strv(DOMAINS, ifindex, ret);  }
 
  +_public_ int sd_network_link_get_carriers(int ifindex, char ***ret) {
  +return network_get_link_strv(CARRIERS, ifindex, ret); }

 I don't find get_carriers() very clear. At least call it
 get_carrier_bound_to() or something like that. I must say I agree 
 with Lennart and Zbigniew, we should introduce the API in both 
 directions, and then we can worry about the performance if that turns 
 out to be a problem (worst case all the processing could be hidden in 
 the sd-network library, but I don't think that will be necessary to 
 be honest).



Alin:
I will change the name and provide functions in both directions.


   _public_ int sd_network_link_get_wildcard_domain(int ifindex) {
   int r;
   _cleanup_free_ char *p = NULL, *s = NULL; diff --git 
  a/src/network/networkctl.c b/src/network/networkctl.c index 
  aa83f32..ffb38e8 100644
  --- a/src/network/networkctl.c
  +++ b/src/network/networkctl.c
  @@ -22,6 +22,7 @@
   #include stdbool.h
   #include getopt.h
   #include net/if.h
  +#include fnmatch.h
 
   #include sd-network.h
   #include sd-rtnl.h
  @@ -393,6 +394,161 @@ static int get_gateway_description(
   return -ENODATA;
   }
 
  +static bool is_carrier(const char *ifname,
  +   char **carriers) {
  +   char **i;
  +
  +   STRV_FOREACH(i, carriers)
  +   if (fnmatch(*i, ifname, 0) == 0)
  +   return true;
  +
  +   return false;
  +}
  +
  +/* get the links that are bound to this port. */ static int 
  +get_downlinks(const char *name,
  + sd_rtnl_message *m,
  + LinkInfo **downlinks,
  + int *down_count) {
  +

Re: [systemd-devel] [PATCH v3] Added support for Uplink Failure Detection using BindCarrier

[Zbigniew Jędrzejewski-Szmek]

On Sat, Feb 14, 2015 at 03:26:00PM +, Rauta, Alin wrote:
 Hi guys,
 
 Thanks for your input on this. Much appreciated.
 I'll try handle your remarks in the next patch.
 Please find my comments below.
 
 Best Regards,
 Alin
 
  -Original Message-
  From: Tom Gundersen [mailto:t...@jklm.no] 
  Sent: Saturday, February 14, 2015 2:50 PM
  To: Zbigniew Jędrzejewski-Szmek
  Cc: Rauta, Alin; Lennart Poettering; systemd Mailing List; Kinsella, Ray
  Subject: Re: [PATCH v3] Added support for Uplink Failure Detection using 
  BindCarrier
 
  On Sat, Feb 14, 2015 at 3:05 PM, Zbigniew Jędrzejewski-Szmek 
  zbys...@in.waw.pl wrote:
  On Fri, Feb 13, 2015 at 10:27:07PM +0100, Tom Gundersen wrote:
  Hi Alin,
 
  Thanks for the patch. This is starting to look pretty good now.
 
  I still have some questions/requests regarding some implementation 
  details (below), but hopefully we can get this merged after the next 
  release (trying to stabilize things at the moment).
 
  On Tue, Feb 10, 2015 at 12:30 PM, Alin Rauta alin.ra...@intel.com wrote:
   ---
man/systemd.network.xml  |  11 ++
src/libsystemd/sd-network/sd-network.c   |   4 +
src/network/networkctl.c | 211 
   ---
src/network/networkd-link.c  | 123 +-
src/network/networkd-link.h  |   1 +
src/network/networkd-manager.c   |   7 +
src/network/networkd-network-gperf.gperf |   1 +
src/network/networkd-network.c   |  10 ++
src/network/networkd.h   |   2 +-
src/systemd/sd-network.h |   3 +
10 files changed, 355 insertions(+), 18 deletions(-)
  
   diff --git a/man/systemd.network.xml b/man/systemd.network.xml 
   index 9b3a92d..8b2ca4e 100644
   --- a/man/systemd.network.xml
   +++ b/man/systemd.network.xml
   @@ -270,6 +270,17 @@
  /listitem
/varlistentry
varlistentry
   +  termvarnameBindCarrier=/varname/term
   +  listitem
   +paraA port or a list of ports. When set, controls the
   +behaviour of the current interface. When all ports in the 
   list
   +are operational down, the failure is propagated to the 
   + current
  operational down does not follow normal grammar rules. are in an 
  operational down state?
 
   +interface. When at least one port has carrier, the current
   +interface is brought up.
   +/para
 
  Maybe we should make it clear that this is not necessarily a failure 
  (the uplink may be down on purpose), and that the way we propagate it 
  is to set the downlink administrative down.
 
 
 
 Alin: 
 I will think of something else here. Some other way to describe this.
 
 
 
   +  /listitem
   +/varlistentry
   +varlistentry
  termvarnameAddress=/varname/term
  listitem
paraA static IPv4 or IPv6 address and its prefix 
   length, diff --git a/src/libsystemd/sd-network/sd-network.c 
   b/src/libsystemd/sd-network/sd-network.c
   index c735cac..b574d19 100644
   --- a/src/libsystemd/sd-network/sd-network.c
   +++ b/src/libsystemd/sd-network/sd-network.c
   @@ -264,6 +264,10 @@ _public_ int sd_network_link_get_domains(int 
   ifindex, char ***ret) {
return network_get_link_strv(DOMAINS, ifindex, ret);  }
  
   +_public_ int sd_network_link_get_carriers(int ifindex, char ***ret) {
   +return network_get_link_strv(CARRIERS, ifindex, ret); }
 
  I don't find get_carriers() very clear. At least call it
  get_carrier_bound_to() or something like that. I must say I agree 
  with Lennart and Zbigniew, we should introduce the API in both 
  directions, and then we can worry about the performance if that turns 
  out to be a problem (worst case all the processing could be hidden in 
  the sd-network library, but I don't think that will be necessary to 
  be honest).
 
 
 
 Alin:
 I will change the name and provide functions in both directions.
 
 
_public_ int sd_network_link_get_wildcard_domain(int ifindex) {
int r;
_cleanup_free_ char *p = NULL, *s = NULL; diff --git 
   a/src/network/networkctl.c b/src/network/networkctl.c index 
   aa83f32..ffb38e8 100644
   --- a/src/network/networkctl.c
   +++ b/src/network/networkctl.c
   @@ -22,6 +22,7 @@
#include stdbool.h
#include getopt.h
#include net/if.h
   +#include fnmatch.h
  
#include sd-network.h
#include sd-rtnl.h
   @@ -393,6 +394,161 @@ static int get_gateway_description(
return -ENODATA;
}
  
   +static bool is_carrier(const char *ifname,
   +   char **carriers) {
   +   char **i;
   +
   +   STRV_FOREACH(i, carriers)
   +   if (fnmatch(*i, ifname, 0) == 0)
   +   return true;
   +
   +   return false;
   +}
   +
   +/* get the links that are bound to this port. */ static int 

Re: [systemd-devel] user units and system units behavior

[Ivan Shapovalov]

On 2015-02-14 at 00:17 -0800, Alison Chaiken wrote:
 Inside a Fedora 21 Qemu, I made a dead-simple 'gnome-weather.service'
 and experimented with moving it in between system and user directories
 in systemd 215.
 
 Case 0: With /etc/systemd/system/gnome-weather.service,  starts
 normally with 'systemctl start gnome-weather'
 
 Case 1: With /etc/systemd/user/gnome-weather.service, starts normally
 with 'systemctl --user start gnome-weather'
 
 I wanted to try 'busctl monitor' so I compiled systemd 218 and installed it.
 
 [achaiken@fedora21 ~]$ systemctl --version
 systemd 218
 -PAM -AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP
 +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID +ELFUTILS
 +KMOD +IDN
 
 Case 0: works as before, with 'busctl monitor
 org.freedesktop.systemd1' producing many screens of output.
 
 Case 1: 'systemctl --user start gnome-weather'  now fails:
 
 [achaiken@fedora21 ~]$ systemctl start --user gnome-weather
 Failed to start gnome-weather.service: Process
 org.freedesktop.systemd1 exited with status 1
 
 Meanwhile 'busctl --user monitor org.freedesktop.systemd1' shows no output.
 
 Question: What does the error message 'Process
 org.freedesktop.systemd1 exited with status 1' mean?

Hi Alison,

this is a sign of that the systemd user instance (`systemd --user`)
isn't running.

More specifically, the systemd user instance wasn't running, so its bus
name hadn't been taken, so the dbus1 server tried to do the bus
activation, but the dbus1 service file for systemd (not to be confused
with systemd's unit files) contains Exec=/bin/false (as to prevent bus
activation), so that activation had failed.

..or this could be a sign of that `systemctl --user` couldn't connect to
`systemd --user`.

 
 Question: is it correct that the user bus show no traffic in the
 second case?   Or is that a symptom of what's wrong?

This is the current out-of-the-box situation. The problem lies in that
there is currently no single user bus. There is a number of session
busses, launched by a scriptlet in /etc/X11/xinitrc.d for each X11
session separately. Everything in the user's world works through that
bus. But not `systemd --user`: it is per-user, not per-session. It just
appears before any session is created, so it does not know about any
session busses.

The intent here, as I understand it, some time ago was to have a single
user bus under a well-defined address
($XDG_RUNTIME_DIR/dbus/user_bus_socket), which will be managed by the
systemd user instance (by means of dbus.socket+dbus.service, just like
in the system instance). But there is no such bus, so `systemctl --user`
connects to the systemd user instance via their own private bus: cf.
src/libsystemd/sd-bus/bus-util.c:bus_open_transport_systemd() and
src/libsystemd/sd-bus/bus-util.c:bus_open_user_systemd().

That's why you can't see the traffic using `busctl --user`.

And this all is going to change when kdbus becomes finally there.

HTHs,
-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] util: Use a shared lookup function for string tables

[David Herrmann]

Hi

On Fri, Feb 13, 2015 at 9:40 PM, Bruno Bottazzini
bruno.bottazz...@intel.com wrote:
 Macro DEFINE_STRING_TABLE_LOOKUP expands to a new function for each
 of the almost 120 tables throghout the code.
 Move the its implementation to a function (guaranteed to never be inlined),
 and make the macro expand to an inlined function that calls this function.
 This saves a few kilobytes from the systemd binary
 ---
  src/shared/util.c |  9 +
  src/shared/util.h | 15 ++-
  2 files changed, 15 insertions(+), 9 deletions(-)

Hm, this adds an additional level of indirection, but -lto should
probably fix this up. Haven't verified this, though.
Only a few lookup-tables are used in fast-paths, so I guess the
.text-size reduction is worth it. I fixed up some issues (see below)
and applied this patch.

Anyway, as a followup, we might consider moving all the
DEFINE_STRING_TABLE_LOOKUP() into header-files and export the
string-tables. This way, we get rid of the double-indirection even
without relying on the compiler. And we can actually get rid of one
LOC per lookup-table.

 diff --git a/src/shared/util.c b/src/shared/util.c
 index 891182a..5c8e698 100644
 --- a/src/shared/util.c
 +++ b/src/shared/util.c
 @@ -8080,3 +8080,12 @@ int syslog_parse_priority(const char **p, int 
 *priority, bool with_facility) {
  *p += k;
  return 1;
  }
 +
 +size_t _string_table_lookup(const char *const *table, size_t len, const char 
 *key){
 +size_t i;
 +if (key)
 +for (i = 0; i  len; i++)
 +if (table[i]  streq(table[i], key))
 +return i;
 +return (size_t) -1;

I fixed up the coding-style:
 - we avoid prefixing functions with underscores
 - several whitespace fixups
 - use streq_ptr()

Furthermore, I changed 'size_t' to 'ssize_t'. Imagine a 32bit
'size_t', but a 64bit 'type' in the lookup-macro, this will produce
2^32-1 on ENOENT, instead of 2^64-1. We need to actually return the
signed value, otherwise sign extension will not work.

Thanks
David

 +}
 diff --git a/src/shared/util.h b/src/shared/util.h
 index ca0c2e5..caa960d 100644
 --- a/src/shared/util.h
 +++ b/src/shared/util.h
 @@ -334,6 +334,8 @@ int make_console_stdio(void);
  int dev_urandom(void *p, size_t n);
  void random_bytes(void *p, size_t n);
  void initialize_srand(void);
 +size_t _string_table_lookup(const char *const *table, size_t len, const char 
 *key)
 +__attribute__((noinline));

  static inline uint64_t random_u64(void) {
  uint64_t u;
 @@ -355,16 +357,11 @@ static inline uint32_t random_u32(void) {
  return name##_table[i]; \
  }

 +
  #define _DEFINE_STRING_TABLE_LOOKUP_FROM_STRING(name,type,scope)\
 -scope type name##_from_string(const char *s) {  \
 -type i; \
 -if (!s) \
 -return (type) -1;   \
 -for (i = 0; i  (type)ELEMENTSOF(name##_table); i++)\
 -if (name##_table[i]   \
 -streq(name##_table[i], s))  \
 -return i;   \
 -return (type) -1;   \
 +scope inline type name##_from_string(const char *s) {   \
 +return (type)_string_table_lookup(name##_table, \
 +ELEMENTSOF(name##_table), s);   \
  }

  #define _DEFINE_STRING_TABLE_LOOKUP(name,type,scope)\
 --
 1.9.1

 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v3] Added support for Uplink Failure Detection using BindCarrier

[Zbigniew Jędrzejewski-Szmek]

On Fri, Feb 13, 2015 at 10:27:07PM +0100, Tom Gundersen wrote:
 Hi Alin,
 
 Thanks for the patch. This is starting to look pretty good now.
 
 I still have some questions/requests regarding some implementation
 details (below), but hopefully we can get this merged after the next
 release (trying to stabilize things at the moment).
 
 On Tue, Feb 10, 2015 at 12:30 PM, Alin Rauta alin.ra...@intel.com wrote:
  ---
   man/systemd.network.xml  |  11 ++
   src/libsystemd/sd-network/sd-network.c   |   4 +
   src/network/networkctl.c | 211 
  ---
   src/network/networkd-link.c  | 123 +-
   src/network/networkd-link.h  |   1 +
   src/network/networkd-manager.c   |   7 +
   src/network/networkd-network-gperf.gperf |   1 +
   src/network/networkd-network.c   |  10 ++
   src/network/networkd.h   |   2 +-
   src/systemd/sd-network.h |   3 +
   10 files changed, 355 insertions(+), 18 deletions(-)
 
  diff --git a/man/systemd.network.xml b/man/systemd.network.xml
  index 9b3a92d..8b2ca4e 100644
  --- a/man/systemd.network.xml
  +++ b/man/systemd.network.xml
  @@ -270,6 +270,17 @@
 /listitem
   /varlistentry
   varlistentry
  +  termvarnameBindCarrier=/varname/term
  +  listitem
  +paraA port or a list of ports. When set, controls the
  +behaviour of the current interface. When all ports in the list
  +are operational down, the failure is propagated to the current
operational down does not follow normal grammar rules. are in an operational
down state?

  +interface. When at least one port has carrier, the current
  +interface is brought up.
  +/para
 
 Maybe we should make it clear that this is not necessarily a failure
 (the uplink may be down on purpose), and that the way we propagate it
 is to set the downlink administrative down.
 
  +  /listitem
  +/varlistentry
  +varlistentry
 termvarnameAddress=/varname/term
 listitem
   paraA static IPv4 or IPv6 address and its prefix length,
  diff --git a/src/libsystemd/sd-network/sd-network.c 
  b/src/libsystemd/sd-network/sd-network.c
  index c735cac..b574d19 100644
  --- a/src/libsystemd/sd-network/sd-network.c
  +++ b/src/libsystemd/sd-network/sd-network.c
  @@ -264,6 +264,10 @@ _public_ int sd_network_link_get_domains(int ifindex, 
  char ***ret) {
   return network_get_link_strv(DOMAINS, ifindex, ret);
   }
 
  +_public_ int sd_network_link_get_carriers(int ifindex, char ***ret) {
  +return network_get_link_strv(CARRIERS, ifindex, ret);
  +}
 
 I don't find get_carriers() very clear. At least call it
 get_carrier_bound_to() or something like that. I must say I agree with
 Lennart and Zbigniew, we should introduce the API in both directions,
 and then we can worry about the performance if that turns out to be a
 problem (worst case all the processing could be hidden in the
 sd-network library, but I don't think that will be necessary to be
 honest).
 
   _public_ int sd_network_link_get_wildcard_domain(int ifindex) {
   int r;
   _cleanup_free_ char *p = NULL, *s = NULL;
  diff --git a/src/network/networkctl.c b/src/network/networkctl.c
  index aa83f32..ffb38e8 100644
  --- a/src/network/networkctl.c
  +++ b/src/network/networkctl.c
  @@ -22,6 +22,7 @@
   #include stdbool.h
   #include getopt.h
   #include net/if.h
  +#include fnmatch.h
 
   #include sd-network.h
   #include sd-rtnl.h
  @@ -393,6 +394,161 @@ static int get_gateway_description(
   return -ENODATA;
   }
 
  +static bool is_carrier(const char *ifname,
  +   char **carriers) {
  +   char **i;
  +
  +   STRV_FOREACH(i, carriers)
  +   if (fnmatch(*i, ifname, 0) == 0)
  +   return true;
  +
  +   return false;
  +}
  +
  +/* get the links that are bound to this port. */
  +static int get_downlinks(const char *name,
  + sd_rtnl_message *m,
  + LinkInfo **downlinks,
  + int *down_count) {
  +_cleanup_free_ LinkInfo  *links = NULL;
  +sd_rtnl_message *i;
  +size_t size = 0;
  +size_t c = 0;
Why is c size_t?

  +int r;
  +
  +assert(m);
  +assert(name);
  +
  +*down_count = 0;
  +*downlinks = NULL;
Why do you initialize this here? If an error happens, it is nice to not modify 
output
parameters at all.

  +for (i = m; i; i = sd_rtnl_message_next(i)) {
  +_cleanup_strv_free_ char **carriers = NULL;
  +const char *link_name;
  +int ifindex;
  +
  +r = sd_rtnl_message_link_get_ifindex(i, ifindex);
  +if (r  0)
  +return r;
  +
  +r 

Re: [systemd-devel] [PATCH 8/9] Add man page and references to it.

[Zbigniew Jędrzejewski-Szmek]

On Thu, Feb 05, 2015 at 06:11:24PM +0100, Didier Roche wrote:
 

 From 2533acf15135d9db18fbd79e63de9a702e3859cc Mon Sep 17 00:00:00 2001
 From: Didier Roche didro...@ubuntu.com
 Date: Mon, 26 Jan 2015 17:34:59 +0100
 Subject: [PATCH 8/9] Add man page and references to it.
 
 Add man page explaining the plymouth theme protocol, usage of the daemon
 as well as the socket activation part.
 Adapt existing fsck man page.
 ---
  Makefile-man.am|  12 +++
  man/systemd-f...@.service.xml  |   6 +-
  man/systemd-fsckd.service.xml  | 165 
 +
  units/systemd-fsckd.service.in |   1 +
  units/systemd-fsckd.socket |   2 +-
  5 files changed, 183 insertions(+), 3 deletions(-)
  create mode 100644 man/systemd-fsckd.service.xml
 
 diff --git a/Makefile-man.am b/Makefile-man.am
 index 105853e..f2e13e8 100644
 --- a/Makefile-man.am
 +++ b/Makefile-man.am
 @@ -67,6 +67,7 @@ MANPAGES += \
   man/systemd-escape.1 \
   man/systemd-firstboot.1 \
   man/systemd-fsck@.service.8 \
 + man/systemd-fsckd.service.8 \
   man/systemd-fstab-generator.8 \
   man/systemd-getty-generator.8 \
   man/systemd-gpt-auto-generator.8 \
 @@ -210,6 +211,8 @@ MANPAGES_ALIAS += \
   man/systemd-firstboot.service.1 \
   man/systemd-fsck-root.service.8 \
   man/systemd-fsck.8 \
 + man/systemd-fsckd.8 \
 + man/systemd-fsckd.socket.8 \
   man/systemd-hibernate-resume.8 \
   man/systemd-hibernate.service.8 \
   man/systemd-hybrid-sleep.service.8 \
 @@ -323,6 +326,8 @@ man/systemd-ask-password-wall.service.8: 
 man/systemd-ask-password-console.servic
  man/systemd-firstboot.service.1: man/systemd-firstboot.1
  man/systemd-fsck-root.service.8: man/systemd-fsck@.service.8
  man/systemd-fsck.8: man/systemd-fsck@.service.8
 +man/systemd-fsckd.8: man/systemd-fsckd.service.8
 +man/systemd-fsckd.socket.8: man/systemd-fsckd.service.8
  man/systemd-hibernate-resume.8: man/systemd-hibernate-resume@.service.8
  man/systemd-hibernate.service.8: man/systemd-suspend.service.8
  man/systemd-hybrid-sleep.service.8: man/systemd-suspend.service.8
 @@ -606,6 +611,12 @@ man/systemd-fsck-root.service.html: 
 man/systemd-f...@.service.html
  man/systemd-fsck.html: man/systemd-f...@.service.html
   $(html-alias)
  
 +man/systemd-fsckd.html: man/systemd-fsckd.service.html
 + $(html-alias)
 +
 +man/systemd-fsckd.socket.html: man/systemd-fsckd.service.html
 + $(html-alias)
 +
  man/systemd-hibernate-resume.html: man/systemd-hibernate-res...@.service.html
   $(html-alias)
  
 @@ -1732,6 +1743,7 @@ EXTRA_DIST += \
   man/systemd-escape.xml \
   man/systemd-firstboot.xml \
   man/systemd-f...@.service.xml \
 + man/systemd-fsckd.service.xml \
   man/systemd-fstab-generator.xml \
   man/systemd-getty-generator.xml \
   man/systemd-gpt-auto-generator.xml \
 diff --git a/man/systemd-f...@.service.xml b/man/systemd-f...@.service.xml
 index ee66f37..d366712 100644
 --- a/man/systemd-f...@.service.xml
 +++ b/man/systemd-f...@.service.xml
 @@ -87,8 +87,9 @@
  check, number of mounts, unclean unmount, etc./para
  
  parafilenamesystemd-fsck/filename will forward
 -file system checking progress to the console. If a
 -file system check fails for a service without
 +file system checking progress to
 +filenamesystemd-fsckd.service/filename
 +socket. If a file system check fails for a service without
  optionnofail/option, emergency mode is activated,
  by isolating to
  filenameemergency.target/filename./para
 @@ -142,6 +143,7 @@
  para
  
 citerefentryrefentrytitlesystemd/refentrytitlemanvolnum1/manvolnum/citerefentry,
  
 citerefentryrefentrytitlefsck/refentrytitlemanvolnum8/manvolnum/citerefentry,
 +
 citerefentryrefentrytitlesystemd-fsckd.service/refentrytitlemanvolnum8/manvolnum/citerefentry,
  
 citerefentryrefentrytitlesystemd-quotacheck.service/refentrytitlemanvolnum8/manvolnum/citerefentry,
  
 citerefentryrefentrytitlefsck.btrfs/refentrytitlemanvolnum8/manvolnum/citerefentry,
  
 citerefentryrefentrytitlefsck.cramfs/refentrytitlemanvolnum8/manvolnum/citerefentry,
 diff --git a/man/systemd-fsckd.service.xml b/man/systemd-fsckd.service.xml
 new file mode 100644
 index 000..4a3b60d
 --- /dev/null
 +++ b/man/systemd-fsckd.service.xml
 @@ -0,0 +1,165 @@
 +?xml version=1.0?
 +!--*-nxml-*--
 +!DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook XML V4.2//EN 
 http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;
 +!--
 +  This file is part of systemd.
 +
 +  Copyright 2015 Canonical
 +
 +  systemd is free software; you can redistribute it and/or modify it
 +  under the terms of the GNU Lesser General Public License as 

Re: [systemd-devel] avahi disconnects from bus with kdbus

[David Herrmann]

Hi Daniel!

On Fri, Feb 13, 2015 at 1:16 PM, David Herrmann dh.herrm...@gmail.com wrote:
 Hi

 On Thu, Feb 12, 2015 at 11:32 PM, Daniel Buch boogiewasth...@gmail.com 
 wrote:
 Hi again,

 I found another problem, again with avahi-daemon but in combination with
 Telepathy haze.
 feb 13 08:26:39 dbuch-laptop systemd-coredump[1211]: Process 1167
 (telepathy-haze) of user 1000 dumped core.

  Stack trace of thread
 1167:
  #0  0x7fe0c9557ae0
 g_logv (libglib-2.0.so.0)
  #1  0x7fe0c9557d1f
 g_log (libglib-2.0.so.0)
  #2  0x0041261c
 n/a (telepathy-haze)
  #3  0x7fe0c955091d
 g_main_context_dispatch (libglib-2.0.so.0)
  #4  0x7fe0c9550cf8
 n/a (libglib-2.0.so.0)
  #5  0x7fe0c9551022
 g_main_loop_run (libglib-2.0.so.0)
  #6  0x7fe0c9214631
 tp_run_connection_manager (libtelepathy-glib.so.0)
  #7  0x0040e73b
 n/a (telepathy-haze)
  #8  0x7fe0c8b1e800
 __libc_start_main (libc.so.6)
  #9  0x0040e7ad
 n/a (telepathy-haze)

 This looks like a bug in telepathy, properly triggered by a dbus
 error. This should be fixed upstream, but..

 feb 13 08:26:42 dbuch-laptop systemd[642]: Starting DBUS1:
 org.freedesktop.Telepathy.ConnectionManager.haze...
 feb 13 08:26:42 dbuch-laptop systemd[642]: Started DBUS1:
 org.freedesktop.Telepathy.ConnectionManager.haze.
 feb 13 08:26:42 dbuch-laptop systemd[1]: Starting Avahi mDNS/DNS-SD Stack...
 feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Found user 'avahi' (UID 84)
 and group 'avahi' (GID 84).
 feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Successfully dropped root
 privileges.
 feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: avahi-daemon 0.6.31
 starting up.
 feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Successfully called
 chroot().
 feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Successfully dropped
 remaining capabilities.
 feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Loading service file
 /services/sftp-ssh.service.
 feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Process 313 died: No such
 process; trying to remove PID file. (/var/run/avahi-daemon//pid)
 feb 13 08:26:42 dbuch-laptop systemd[1]: Started Avahi mDNS/DNS-SD Stack.
 feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Loading service file
 /services/ssh.service.
 feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Joining mDNS multicast
 group on interface wlp3s0.IPv4 with address 192.168.1.2.
 feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: New relevant interface
 wlp3s0.IPv4 for mDNS.
 feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Network interface
 enumeration completed.
 feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Registering new address
 record for fe80::eab1:fcff:fec4:eae1 on wlp3s0.*.
 feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Registering new address
 record for 192.168.1.2 on wlp3s0.IPv4.
 feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Registering HINFO record
 with values 'X86_64'/'LINUX'.
 feb 13 08:26:42 dbuch-laptop systemd-bus-proxyd[329]: Failed to send message
 to bus: Operation not permitted

 ..this might be what triggered it. It'd be interesting to see which
 message was refused here. I'll see whether we can make the bus-proxy
 more verbose on EPERM.

This issue should be fixed with systemd-git and kdbus-git:
 - systemd-bus-proxyd no longer closes the connection on EPERM, but
forwards the error
 - kdbus no longer generates EPERM for unicast-signals

The bus-proxyd fix should make sure that avahi continues running, the
kdbus fix should make sure that EPERM is no longer generated for
avahi.

Thanks
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] user units and system units behavior

[Alison Chaiken]

Thanks very much, Ivan, for the detailed explanation.

I asked:
 Question: What does the error message 'Process
 org.freedesktop.systemd1 exited with status 1' mean?

Ivan:
 this is a sign of that the systemd user instance (`systemd --user`)
 isn't running.  More specifically, the systemd user instance wasn't running, 
 so its bus
 name hadn't been taken, so the dbus1 server tried to do the bus
 activation, but the dbus1 service file for systemd (not to be confused
 with systemd's unit files) contains Exec=/bin/false (as to prevent bus
 activation), so that activation had failed.

Why shouldn't the user be able to activate the systemd user instance?
 Should they start services in the /user unit directories with
'systemctl --session' then?In the spirit of 'systemctl cat' and
'systemctl edit' commands that find the applicable unit even when the
invoker doesn't know the complete path, I would hope that non-SUID
users could type 'systemctl start foo.service' and it would just
work.

Is 'systemctl --user' completely broken then?   If so, shouldn't we
remove it from the documentation?

'ps | grep dbus' does in fact show a --session bus on Fedora 21 and
GNOME, but I guess there is no direct 'plumbing' way to request it to
start units.   Instead the 'porcelain' GNOME method of configured
services calling each other is required.

Ivan:
 This is the current out-of-the-box situation. The problem lies in that
 there is currently no single user bus. There is a number of session
 busses, launched by a scriptlet in /etc/X11/xinitrc.d for each X11
 session separately.

I see that for my fully updated, stock (except for freshly compiled
systemd) Fedora 21 GNOME installation that there is no
/etc/X11/xinitrc.d directory.   I take it that means that is no way
for users to start services without suid.Services can only be
started by root, and only system services, as root's search path for
units does not include user units.

I read Simon McVittie's previous posting on related topics.   He says in part:

http://lists.freedesktop.org/archives/systemd-devel/2015-January/027711.html

systemd-logind implements those semantics, and also runs a `systemd --user`
for the lifetime of the user-session.. . .
In graphical sessions, vaguely modern Unix OSs typically know how to
start up a dbus-daemon during the creation of a graphical session (e.g.
in Debian and derivatives it's started by /etc/X11/Xsession.d, and
Fedora derivatives have a similar setup under a different name). If they
don't, modern desktop environments also know how to start a dbus-daemon
if they need one (e.g. gnome-session does this for GNOME), and if *that*
doesn't start one (the I use Firefox under fvwm use-case), we have a
slightly shaky but functional autolaunch mechanism based on X11
properties.

I suppose, Ivan, that your reference is to these autolaunch mechanisms
when you mentioned /etc/X11/xinitrc.d/.   But shouldn't gnome-session
be starting the user bus already?gnome-session is running on the
stock Fedora 21, but 'ps -ppid' shows that it has parented no D-Bus
daemons.   I suppose that the takeaway then is that the gnome-session
in Fedora 21 is not ready for systemd 218.

 And this all is going to change when kdbus becomes finally there.

My original intention was to test 3.19 with kdbus and systemd 218 in a
Qemu, but so far I'm stumped by the initramfs creation for Fedora.
That's a different topic, though!

-- Alison

-- 
Alison Chaiken   ali...@she-devel.com
650-279-5600
http://{she-devel.com,exerciseforthereader.org}
Never underestimate the cleverness of advertisers, or mischief makers,
or criminals.  -- Don Norman
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] shutdown: avoid calling `kexec` binary unnessecarily

[Zbigniew Jędrzejewski-Szmek]

On Sat, Feb 14, 2015 at 10:00:54AM -0800, Shawn Landden wrote:
 On Sat, Feb 14, 2015 at 5:54 AM, Zbigniew Jędrzejewski-Szmek 
 zbys...@in.waw.pl wrote:
 
  On Fri, Feb 13, 2015 at 02:18:07PM -0800, Shawn Landden wrote:
   Still use helper when Xen Dom0, to avoid duplicating some hairy code.
   So we don't have any logic to load kexec kernels?
   ---
TODO|  3 ---
src/core/shutdown.c | 33 -
2 files changed, 20 insertions(+), 16 deletions(-)
  
   diff --git a/TODO b/TODO
   index 883b994..68b0af6 100644
   --- a/TODO
   +++ b/TODO
   @@ -85,9 +85,6 @@ Features:
* maybe introduce WantsMountsFor=? Usecase:
  
  http://lists.freedesktop.org/archives/systemd-devel/2015-January/027729.html
  
   -* rework kexec logic to use new kexec_file_load() syscall, so that we
   -  don't have to call kexec tool anymore.
  You patch does not really change this. We can still use kexec_file_load()
  to
  load a kernel. But removing a call to kexec to actually do the reboot
  seems good.
  So I guess this TODO item should stay.
 
 I would be happy to change that, but I couldn't find any uses of
 kexec_load() or any other calls to the kexec binary in systemd's git.
I think we should try to load the kernel when 'systemctl kexec' is invoked.
Current behaviour of silently falling through to reboot is annoying.

  One comment below.
 
* The udev blkid built-in should expose a property that reflects
  whether media was sensed in USB CF/SD card readers. This should then
  be used to control SYSTEMD_READY=1/0 so that USB card readers aren't
   diff --git a/src/core/shutdown.c b/src/core/shutdown.c
   index 71f001a..c64c05d 100644
   --- a/src/core/shutdown.c
   +++ b/src/core/shutdown.c
   @@ -350,26 +350,33 @@ int main(int argc, char *argv[]) {
case LINUX_REBOOT_CMD_KEXEC:
  
if (!in_container) {
   -/* We cheat and exec kexec to avoid doing all
  its work */
   -pid_t pid;
   +_cleanup_free_ char *param = NULL;
  
log_info(Rebooting with kexec.);
  
   -pid = fork();
   -if (pid  0)
   -log_error_errno(errno, Failed to fork:
  %m);
   -else if (pid == 0) {
   +/* kexec-tools has a bunch of special code to
  make Xen Dom0 work,
   + * otherwise it is only doing stuff we have
  already done */
   +if (access(/proc/xen, F_OK) == 0) {
  Wouldn't it be better to use detect_virtualization() here instead of
  open-coding the check?
 
  That would be *way* more code, and I don't have a xen system to check if
 that detects Dom0, which is all that we are interested in (otherwise kexec
 doesn't work in virtualized environments.)
I think your test detects Dom0 and also DomU. detect_virtualization() only
detects (or should only detect) DomU. So d_v() is wrong for this usecase.

So I think your patch is fine, but a comment should be added explaining
that the test is imprecise and covers all xen domains, but this is OK, since
the fallback to real kexec is OK.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Fail to reset-failed as user

[Olivier Brunel]

On 02/11/15 21:13, Lennart Poettering wrote:
 On Thu, 05.02.15 19:20, Olivier Brunel (j...@jjacky.com) wrote:
 
 On 02/03/15 22:17, Lennart Poettering wrote:
 On Fri, 12.12.14 16:06, Olivier Brunel (j...@jjacky.com) wrote:

 Sorry for resurrecting this old thread this late. Is this still an
 issue? Does this work on current git?

 Still an issue w/ 218 yes, haven't actually had time to try with current
 git. I'll try to do that over the weekend.

 Today I had one unit in failed state, and after taking care of things I
 wanted to simply reset its state (to inactive) w/out having to start it.

 Looking up the man page, I see there's a command reset-failed for this
 exact purpose, awesome. So I go:

 % systemctl reset-failed backups2.service
 Failed to reset failed state of unit backups2.service: No such device or
 address

 Hmm, did you issue this from some weird environment (su/sudo context,
 from a system service context or so?)

 If this is still an issue, could you try to reproduce this after
 issuing systemd-analyze set-log-level debug? Then please attach the
 log output this generates!

 Meanwhile, this is what I get today: http://ix.io/gaR
 This is not from some weird environment no (or, not that I'm aware of),
 but an (almost) up-to-date Arch Linux x64, systemd 218.
 
 Puzzled. Don't see how this can happen. Also, works fine here...
 
 If you can reproduce this on git, it would be good to gdb this. For
 that:
 
 a) start gdb, type attach 1, to attach to PID 1
 
 b) add a breakpoint on method_reset_failed_unit, by issuing b
method_reset_failed_unit
 
 c) Continue execution of PID 1, by typing in the line c
 
 d) trigger the issue, gdb should break at that instant. 
 
 e) now, check which call fails by stepping through the function with
n. As soon as the function is left, use c to continue
execution. Not that the function will be executed twice, one after
the other. The first invocation will be without PolicyKit privs,
the second one with PolicyKit privs. The second invocation is the
interesting one. Check why it exits non-zero, and whether
unit_reset_failed() is invoked at all (which actually does the
inetersting work).
 
 f) post your findings here

Alright so I did some testing, here's what I found:

- on that second invocation, method_reset_failed_unit() fails from its
call to bus_unit_method_reset_failed(), and that comes down to
bus_message_enter_struct() returning -ENXIO.

- I don't know how this whole thing is supposed to work, but what I
noticed is that bus_message_enter_struct() is called twice from
method_reset_failed_unit(), once from bus_verify_manage_unit_async() and
then from bus_unit_method_reset_failed(). Details as follow:

First, when bus_verify_manage_unit_async() is called:

#0  bus_message_enter_struct (m=0x7f5fb0cb88b0, c=0x7f5fb0cb8aa0,
contents=0x7f5faef0d152 bba{ss}, item_size=0x7fffcebd4928,
offsets=0x7fffcebd4918,
n_offsets=0x7fffcebd4920) at src/libsystemd/sd-bus/bus-message.c:3865
#1  0x7f5faee80136 in sd_bus_message_enter_container
(m=0x7f5fb0cb88b0, type=114 'r',
contents=0x7f5faef0d152 bba{ss}) at
src/libsystemd/sd-bus/bus-message.c:4012
#2  0x7f5faee8e00d in bus_verify_polkit_async (call=0x7f5fb0ca59a0,
capability=21,
action=0x7f5faeef05f8 org.freedesktop.systemd1.manage-units,
interactive=false,
registry=0x7f5fb0c0a890, error=0x7fffcebd4ad0) at
src/libsystemd/sd-bus/bus-util.c:374
#3  0x7f5faee0aa00 in bus_verify_manage_unit_async
(m=0x7f5fb0c0a460, call=0x7f5fb0ca59a0,
error=0x7fffcebd4ad0) at src/core/dbus.c:1196
#4  0x7f5faee0c801 in method_reset_failed_unit (bus=0x7f5fb0ca32f0,
message=0x7f5fb0ca59a0,
userdata=0x7f5fb0c0a460, error=0x7fffcebd4ad0) at
src/core/dbus-manager.c:574

(gdb) p *c
$38 = {enclosing = 0 '\000', need_offsets = false, index = 0,
saved_index = 0,
  signature = 0x7f5fb0c09110 (bba{ss}), before = 0, begin = 0, end =
133, array_size = 0x0,
  offsets = 0x0, n_offsets = 0, offsets_allocated = 0, offset_index = 0,
item_size = 133,
  peeked_signature = 0x0}
(gdb) p contents
$39 = 0x7f5faef0d152 bba{ss}

It eventually returns 1.

Then it gets to called from bus_unit_method_reset_failed():

#0  bus_message_enter_struct (m=0x7f5fb0cb88b0, c=0x7f5fb0cb8250,
contents=0x7f5faef0d152 bba{ss}, item_size=0x7fffcebd48e8,
offsets=0x7fffcebd48d8,
n_offsets=0x7fffcebd48e0) at src/libsystemd/sd-bus/bus-message.c:3865
#1  0x7f5faee80136 in sd_bus_message_enter_container
(m=0x7f5fb0cb88b0, type=114 'r',
contents=0x7f5faef0d152 bba{ss}) at
src/libsystemd/sd-bus/bus-message.c:4012
#2  0x7f5faee8e00d in bus_verify_polkit_async (call=0x7f5fb0ca59a0,
capability=21,
action=0x7f5faeef05f8 org.freedesktop.systemd1.manage-units,
interactive=false,
registry=0x7f5fb0c0a890, error=0x7fffcebd4ad0) at
src/libsystemd/sd-bus/bus-util.c:374
#3  0x7f5faee0aa00 in bus_verify_manage_unit_async
(m=0x7f5fb0c0a460, call=0x7f5fb0ca59a0,
error=0x7fffcebd4ad0) at 

Re: [systemd-devel] [PATCH 3/9] Connect to plymouth and support cancellation of in, progress fsck

[Zbigniew Jędrzejewski-Szmek]

On Thu, Feb 05, 2015 at 06:09:24PM +0100, Didier Roche wrote:
 

 From ec3b3d2cd4b0097f9fafa6c3f0f400e06292e21c Mon Sep 17 00:00:00 2001
 From: Didier Roche didro...@ubuntu.com
 Date: Thu, 5 Feb 2015 17:08:18 +0100
 Subject: [PATCH 3/9] Connect to plymouth and support cancellation of in
  progress fsck
 
 Try to connect and send to plymouth (if running) some checked report progress,
 using direct plymouth protocole.
 
 Update message is the following:
 fsckd:num_devices:progress:string
 * num_devices corresponds to the current number of devices being checked (int)
 * progress corresponds to the current minimum percentage of all devices being
   checked (float, from 0 to 100)
 * string is a translated message ready to be displayed by the plymouth theme
   displaying the information above. It can be overriden by plymouth themes
   supporting i18n.
 
 Grab in fsckd plymouth watch key Control+C, and propagate this cancel request
 to systemd-fsck which will terminate fsck.
 
 Send a message to signal to user what key we are grabbing for fsck cancel.
 
 Message is: fsckd-cancel-msg:string
 Where string is a translated string ready to be displayed by the plymouth 
 theme
 indicating that Control+C can be used to cancel current checks. It can be
 overriden (matching only fsckd-cancel-msg prefix) for themes supporting i18n.
 ---
  src/fsck/fsck.c   |  33 +
  src/fsckd/fsckd.c | 145 
 +-
  src/fsckd/fsckd.h |   5 ++
  3 files changed, 173 insertions(+), 10 deletions(-)
 
 diff --git a/src/fsck/fsck.c b/src/fsck/fsck.c
 index d5aaf9e..1f5a3de 100644
 --- a/src/fsck/fsck.c
 +++ b/src/fsck/fsck.c
 @@ -132,7 +132,7 @@ static void test_files(void) {
  
  }
  
 -static int process_progress(int fd, dev_t device_num) {
 +static int process_progress(int fd, pid_t fsck_pid, dev_t device_num) {
  _cleanup_fclose_ FILE *f = NULL;
  usec_t last = 0;
  _cleanup_close_ int fsckd_fd = -1;
 @@ -159,11 +159,13 @@ static int process_progress(int fd, dev_t device_num) {
  
  while (!feof(f)) {
  int pass;
 +size_t buflen;
  size_t cur, max;
 -ssize_t n;
 +ssize_t r;
  usec_t t;
  _cleanup_free_ char *device = NULL;
  FsckProgress progress;
 +FsckdMessage fsckd_message;
  
  if (fscanf(f, %i %lu %lu %ms, pass, cur, max, device) 
 != 4)
  break;
 @@ -181,9 +183,19 @@ static int process_progress(int fd, dev_t device_num) {
  progress.max = max;
  progress.pass = pass;
  
 -n = send(fsckd_fd, progress, sizeof(FsckProgress), 0);
 -if (n  0 || (size_t) n  sizeof(FsckProgress))
 +r = send(fsckd_fd, progress, sizeof(FsckProgress), 0);
 +if (r  0 || (size_t) r  sizeof(FsckProgress))
  log_warning_errno(errno, Cannot communicate fsck 
 progress to fsckd: %m);
 +
 +/* get fsckd requests, only read when we have coherent size 
 data */
 +r = ioctl(fsckd_fd, FIONREAD, buflen);
 +if (r == 0  (size_t) buflen == sizeof(FsckdMessage)) {
Shoudlnt' this be = ? If two messages are queued, buflen will be
bigger then one message, and we'll never read it.

 +r = recv(fsckd_fd, fsckd_message, 
 sizeof(FsckdMessage), 0);
 +if (r  0  fsckd_message.cancel) {
 +log_warning(Request to cancel fsck from 
 fsckd);
log_notice or log_info. Actually log_info I think, since this is a
legitimate user request.

 +kill(fsck_pid, SIGTERM);
 +}
 +}
  }
  
  return 0;
 @@ -193,6 +205,7 @@ int main(int argc, char *argv[]) {
  const char *cmdline[9];
  int i = 0, r = EXIT_FAILURE, q;
  pid_t pid;
 +int progress_rc;
  siginfo_t status;
  _cleanup_udev_unref_ struct udev *udev = NULL;
  _cleanup_udev_device_unref_ struct udev_device *udev_device = NULL;
 @@ -335,7 +348,7 @@ int main(int argc, char *argv[]) {
  progress_pipe[1] = safe_close(progress_pipe[1]);
  
  if (progress_pipe[0] = 0) {
 -process_progress(progress_pipe[0], st.st_rdev);
 +progress_rc = process_progress(progress_pipe[0], pid, 
 st.st_rdev);
  progress_pipe[0] = -1;
  }
  
 @@ -345,13 +358,14 @@ int main(int argc, char *argv[]) {
  goto finish;
  }
  
 -if (status.si_code != CLD_EXITED || (status.si_status  ~1)) {
 +if (status.si_code != CLD_EXITED || (status.si_status  ~1) || 
 progress_rc != 0) {
  
 -if (status.si_code == CLD_KILLED || status.si_code == 
 CLD_DUMPED)
 +/* cancel will kill fsck (but 

Re: [systemd-devel] user units and system units behavior

[Mantas Mikulėnas]

On Sat, Feb 14, 2015 at 7:36 PM, Alison Chaiken ali...@she-devel.com
wrote:

 Thanks very much, Ivan, for the detailed explanation.

 I asked:
  Question: What does the error message 'Process
  org.freedesktop.systemd1 exited with status 1' mean?

 Ivan:
  this is a sign of that the systemd user instance (`systemd --user`)
  isn't running.  More specifically, the systemd user instance wasn't
 running, so its bus
  name hadn't been taken, so the dbus1 server tried to do the bus
  activation, but the dbus1 service file for systemd (not to be confused
  with systemd's unit files) contains Exec=/bin/false (as to prevent bus
  activation), so that activation had failed.

 Why shouldn't the user be able to activate the systemd user instance?


I think the idea was that the user instance would be started automatically
when the user first logged in.

(Which it *is*, at least on Arch: logind starts user@1000.service for me
as soon as pam_systemd tells it that I've logged in.

Some distros break it, either intentionally or by accident. Not sure about
Fedora.)


  Should they start services in the /user unit directories with
 'systemctl --session' then?


`systemctl --session` was never a thing.

In the spirit of 'systemctl cat' and
 'systemctl edit' commands that find the applicable unit even when the
 invoker doesn't know the complete path, I would hope that non-SUID
 users could type 'systemctl start foo.service' and it would just
 work.


Not sure how that's at all related to knowing the complete path?


 Is 'systemctl --user' completely broken then?   If so, shouldn't we
 remove it from the documentation?


It's not broken on stock systemd. As long as your `systemd --user` instance
is running, systemctl can contact it directly over the
$XDG_RUNTIME_DIR/systemd/private socket, so there's no hard dependency on
on any D-Bus bus either (neither system nor session nor user).

So if you see `systemctl --user` trying to contact systemd over the bus, it
only does so after it has given up trying to contact it over the private
socket. Does that socket exist?

Also check if the system service user@*your uid*.service is active, if
it has logged any errors. Try starting that .service manually too.


 'ps | grep dbus' does in fact show a --session bus on Fedora 21 and
 GNOME, but I guess there is no direct 'plumbing' way to request it to
 start units.   Instead the 'porcelain' GNOME method of configured
 services calling each other is required.


The bus doesn't start systemd units directly, only pre-systemd DBus
services.

(Those can be started manually, by
calling org.freedesktop.DBus.StartServiceByName() over DBus – e.g. using
`gdbus call` – or automatically, by simply trying to use them.)

To start systemd units/.services, you need to have a `systemd --user`
running; see above.

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Do not realize and migrate cgroups multiple times / test suite patch

[Zbigniew Jędrzejewski-Szmek]

On Tue, Feb 03, 2015 at 10:49:01PM +0100, Lennart Poettering wrote:
 On Sat, 13.12.14 17:15, Martin Pitt (martin.p...@ubuntu.com) wrote:
 
  Hello Lennart,
  
  Lennart Poettering [2014-12-09  2:37 +0100]:
   hashmap_put() will actually compare the string, not the pointer to
   it. Our hashmap implementation gets a hash function pointer as well as
   an element comparison function as input, to ensure that that works
   correctly.
  
  Ah right. I understand how these work now, and I extended the test
  case to cover this case (equal key, but different pointer).
 
 The patch for this has been merged, apparently.
 
  However, unit_create_cgroups() still seems to be quite wasteful: It
  still gets called dozens of time for -.slice for every unit that gets
  started, and thus calls cg_create_everywhere() for the already
  existing cgroup. Why doesn't this function just check if
  u-cgroup_path already exists, and if so just return right away? Are
  there situations where the same unit cgroup needs to be realized and
  pids migrated to it multiple times?
 
 unit_create_cgroups() is invoked from unit_realize_cgroup_now(), which
 exits early if the unit is already realized for all controllers
 that the unit needs. Thus, unit_create_cgroups() should not be called
 that often, but only when the mask of controllers to realize changes.
Martin,

is there anything left to fix here?

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] user units and system units behavior

[Alison Chaiken]

Mantas offers:
 I think the idea was that the user instance would be started automatically
 when the user first logged in.

 (Which it is, at least on Arch: logind starts user@1000.service for me as
 soon as pam_systemd tells it that I've logged in.

 Some distros break it, either intentionally or by accident. Not sure about
 Fedora.)

On Fedora 21, I see

[achaiken@fedora21]$ sudo systemctl status -l user@1000.service
● user@1000.service - User Manager for UID 1000
   Loaded: loaded (/usr/lib/systemd/system/user@.service; static;
vendor preset: disabled)
   Active: inactive (dead)

[achaiken@fedora21]$ sudo systemctl enable user@service
The unit files have no [Install] section. They are not meant to be enabled
using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
   .wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
   a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
   D-Bus, udev, scripted systemctl call, ...).

[achaiken@fedora21]$ sudo systemctl start user@1000.service
[achaiken@fedora21]$ systemctl start --user gnome-weather.service
Failed to start gnome-weather.service: Process
org.freedesktop.systemd1 exited with status 1

I wrote:
 In the spirit of 'systemctl cat' and
 'systemctl edit' commands that find the applicable unit even when the
 invoker doesn't know the complete path, I would hope that non-SUID
 users could type 'systemctl start foo.service' and it would just
 work.

Mantas answers:
 Not sure how that's at all related to knowing the complete path?

I meant only that expecting users to know that they have to type
systemctl --user is undesirable if it's not necessary.

Mantas:
 It's not broken on stock systemd. As long as your `systemd --user` instance
 is running, systemctl can contact it directly over the
 $XDG_RUNTIME_DIR/systemd/private socket, so there's no hard dependency on
 on any D-Bus bus either (neither system nor session nor user).

 So if you see `systemctl --user` trying to contact systemd over the bus, it
 only does so after it has given up trying to contact it over the private
 socket. Does that socket exist?

No, I gather that's the problem: 'ls $XDG_RUNTIME_DIR' shows no
systemd sub-directory at all.

 Also check if the system service user@your uid.service is active, if it
 has logged any errors. Try starting that .service manually too.

'systemctl start user@1000.service' shows no errors in the journal; it
just seems to 'exit 0' with no lasting effects.
I suppose that gnome-session is supposed to create
$XDG_RUNTIME_DIR/systemd/private and for some reason, silently fails
to do so.   gnome-session shows no associated errors in the journal
either.

Thanks,
Alison

-- 
Alison Chaiken   ali...@she-devel.com
650-279-5600http://{she-devel.com,
exerciseforthereader.org}
Never underestimate the cleverness of advertisers, or mischief makers,
or criminals.  -- Don Norman
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] user units and system units behavior

[Mantas Mikulėnas]

On Sat, Feb 14, 2015 at 9:37 PM, Alison Chaiken ali...@she-devel.com
wrote:

 Mantas:
  It's not broken on stock systemd. As long as your `systemd --user`
 instance
  is running, systemctl can contact it directly over the
  $XDG_RUNTIME_DIR/systemd/private socket, so there's no hard dependency
 on
  on any D-Bus bus either (neither system nor session nor user).
 
  So if you see `systemctl --user` trying to contact systemd over the bus,
 it
  only does so after it has given up trying to contact it over the private
  socket. Does that socket exist?

 No, I gather that's the problem: 'ls $XDG_RUNTIME_DIR' shows no
 systemd sub-directory at all.


That's weird.

Does that directory have correct permissions (owned by you, etc.)? Can you
mkdir the systemd subdirectory manually?

Also try editing user@.service to launch systemd with --log-level=debug to
see if it reveals anything more useful.


  Also check if the system service user@your uid.service is active,
 if it
  has logged any errors. Try starting that .service manually too.

 'systemctl start user@1000.service' shows no errors in the journal; it
 just seems to 'exit 0' with no lasting effects.
 I suppose that gnome-session is supposed to create
 $XDG_RUNTIME_DIR/systemd/private and for some reason, silently fails
 to do so.   gnome-session shows no associated errors in the journal
 either.


It's systemd that would be listening on this socket, so it's systemd that
would be creating it.

gnome-session has absolutely nothing to do with this... (At most, sometime
in the future it might connect to the `systemd --user` instance, or be
replaced by it entirely; but it has no hand in actually starting it.)

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Complex supervision structures/delegating watchdog?

[Holger Freyther]

Hi,

for one application we will spawn one or more pppd daemons. Once
a link is up I would like to monitor them. The closest thing that
I can do right now is systemctl start mon@$PPP_IFACE from within
a /etc/ppp/ip-up.d/mon file.

In case I consider the link broken or I want to bring it down, I
don't know how to do it. What options do I have? I can look at 
/run/$PPP_IFACE.pid and then send a SIGHUP to the task (this
requires that the monitor app is allowed to do that).

What would be neat is that if I could spawn a watchdog from
with-in /etc/ppp/ip-up.d/mon for the existing service and that
when the application exits (or doesn't respond/send watchdog
messages to systemd) the parent will be stopped.

Is something like this already possible or wanted behavior? How
would you handle that?

holger

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] user units and system units behavior

[Mantas Mikulėnas]

On Sat, Feb 14, 2015 at 10:20 PM, Alison Chaiken ali...@she-devel.com
wrote:

 Ivan writes:
  So, I suppose, your `systemd --user` just fails to start somewhy, and
  you are getting that cryptic error message because systemctl can't find
  systemd on either of the buses.

 Ah, after restarting the Qemu, I see in the journal:

 Feb 13 22:09:06 fedora21.exerciseforthereader.org systemd[1900]:
 Trying to run as user instance, but $XDG_RUNTIME_DIR is not set.


That's weird.

Normally this envvar is set by pam_systemd, so take a look at
/etc/pam.d/systemd-user and see if it calls the pam_systemd module, either
directly or via include/substack...

(I don't know exactly how Fedora's PAM configuration looks like, but I
think 'systemd-user' is supposed to include either 'system-auth' or
'system-login'.)

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] user units and system units behavior

[Alison Chaiken]

Ivan writes:
 So, I suppose, your `systemd --user` just fails to start somewhy, and
 you are getting that cryptic error message because systemctl can't find
 systemd on either of the buses.

Ah, after restarting the Qemu, I see in the journal:

Feb 13 22:09:06 fedora21.exerciseforthereader.org systemd[1900]:
Trying to run as user instance, but $XDG_RUNTIME_DIR is not set.

By the time a gnome-terminal appears, 'echo $XDG_RUNTIME_DIR' shows
/run/user/1000, but it looks like 'systemd --user' is failing because
it can't find the value of this variable.Perhaps this is somehow
related to running in the virtualized environment.   So my takeway
from all this is that systemctl --user gnome-weather in the
beginning was still correct in systemd 218, but I need to track down
why 'systemd --user' can't read this variable when I log in.

Ivan:
 Hope it makes things a bit more clear. And I hope I haven't misunderstood 
 anything in the first place.

Very much so.   I can see that in automotive, where I work, the puzzle
of giving different privileges to driver (can control navigation
system but no Facebook, unless vehicle is stationary), passenger (can
read Facebook at any time, plus view any website, but has no
navigation control) and rear-seat (a kind of passenger who suffers
parental controls to prevent reading of porn) is going to be lots of
fun.   There is especially true when internationalization, which
involves different map and streaming audio databases, is thrown in to
the mix.   I have no fear that we will run out of work.

-- Alison


-- 
Alison Chaiken   ali...@she-devel.com
650-279-5600http://{she-devel.com,
exerciseforthereader.org}
Never underestimate the cleverness of advertisers, or mischief makers,
or criminals.  -- Don Norman
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Complex supervision structures/delegating watchdog?

[Mantas Mikulėnas]

On Sat, Feb 14, 2015 at 10:31 PM, Holger Freyther hol...@freyther.de
wrote:

 Hi,

 for one application we will spawn one or more pppd daemons. Once
 a link is up I would like to monitor them. The closest thing that
 I can do right now is systemctl start mon@$PPP_IFACE from within
 a /etc/ppp/ip-up.d/mon file.

 In case I consider the link broken or I want to bring it down, I
 don't know how to do it. What options do I have? I can look at
 /run/$PPP_IFACE.pid and then send a SIGHUP to the task (this
 requires that the monitor app is allowed to do that).


Pidfiles?

systemctl kill -s SIGHUP pppd@$PPP_IFACE.service

ExecReload=/bin/kill -HUP $MAINPID
systemctl reload pppd@$PPP_IFACE.service


 What would be neat is that if I could spawn a watchdog from
 with-in /etc/ppp/ip-up.d/mon for the existing service and that
 when the application exits (or doesn't respond/send watchdog
 messages to systemd) the parent will be stopped.


I wonder if you could have the pppd service automatically start the
pppd-watchdog@ service using some combination of Before=, Requires=, and
BindsTo= (or something similar that I'd forgotten). When the watchdog
process exits, the pppd-watchdog@ service fails, causing pppd@ to also fail
due to the Requires=.

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] user units and system units behavior

[Alison Chaiken]

Inside a Fedora 21 Qemu, I made a dead-simple 'gnome-weather.service'
and experimented with moving it in between system and user directories
in systemd 215.

Case 0: With /etc/systemd/system/gnome-weather.service,  starts
normally with 'systemctl start gnome-weather'

Case 1: With /etc/systemd/user/gnome-weather.service, starts normally
with 'systemctl --user start gnome-weather'

I wanted to try 'busctl monitor' so I compiled systemd 218 and installed it.

[achaiken@fedora21 ~]$ systemctl --version
systemd 218
-PAM -AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP
+LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID +ELFUTILS
+KMOD +IDN

Case 0: works as before, with 'busctl monitor
org.freedesktop.systemd1' producing many screens of output.

Case 1: 'systemctl --user start gnome-weather'  now fails:

[achaiken@fedora21 ~]$ systemctl start --user gnome-weather
Failed to start gnome-weather.service: Process
org.freedesktop.systemd1 exited with status 1

Meanwhile 'busctl --user monitor org.freedesktop.systemd1' shows no output.

Question: What does the error message 'Process
org.freedesktop.systemd1 exited with status 1' mean?

Question: is it correct that the user bus show no traffic in the
second case?   Or is that a symptom of what's wrong?

Thanks,
Alison

-- 
Alison Chaiken   ali...@she-devel.com
650-279-5600
http://{she-devel.com,exerciseforthereader.org}
Never underestimate the cleverness of advertisers, or mischief makers,
or criminals.  -- Don Norman
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel