Re: [systemd-devel] [PATCH, REVIEW, v2] find_symlinks: adds a cache of enabled unit symbolic link state

2014-10-17 Thread Ronny Chevalier 
Hi,

2014-10-18 1:34 GMT+02:00 Ken Sedgwick :
> The current find_symlinks_fd code traverses the config directories
> duplicatively. This is a performance problem if 1000s of units are
> being controlled. This patch adds a hashmap cache of symbolic link
> state which is filled in one traversal and then consulted as needed to
> prevent re-traversal.
>
> The enabled_context cache lives in the manager struct.  Initially the
> cache is empty and is filled on first use.  A pointer to the cache is
> passed to all routines which can call find_symlinks_fd.  If a NULL is
> passed to find_symlinks_fd a temporary cache is created and used for
> the single call.
>
> The cache has two levels, the first is keyed by config_path and the
> second by the names and paths of the units.
>
> The cache contains both forward and reverse mappings; from symbolic
> link name to target and from target to symbolic link name.
>
> The cache contains entries for both the basename of the unit and the
> full path of the link name and target.
>
> The test-enabled patch (previously submitted) checks that the results
> of unit_file_get_state and unit_file_get_list do not change as a
> result of this cache. This patch presumes the test-enabled patch has
> already been applied.
>
> The test-manyunits patch (previously submitted) checks that the performance
> of unit_file_get_list is acceptable in the face of thousands of units.
> This patch presumes the test-manyunits patch has already been applied.
If there is dependencies between your patches, you should use
something like "git format-patch -3" to generate 3 patchs from the 3
last commits. It will add [PATCH 1/3] [PATCH 2/3]... on the subjects
of the mails. It helps knowing if a patch needs to be applied before
applying another.

> ---
>  src/core/dbus-manager.c   |   6 +-
>  src/core/manager.c|   6 +
>  src/core/manager.h|   2 +
>  src/core/unit.c   |   2 +-
>  src/shared/install.c  | 273 
> +-
>  src/shared/install.h  |  18 ++-
>  src/systemctl/systemctl.c |   6 +-
>  src/test/test-enabled.c   |  24 ++--
>  src/test/test-install.c   |  87 ---
>  src/test/test-manyunits.c |  11 +-
>  src/test/test-unit-file.c |   2 +-
>  11 files changed, 325 insertions(+), 112 deletions(-)
>
> diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
> index 57db1c9..0ce41b0 100644
> --- a/src/core/dbus-manager.c
> +++ b/src/core/dbus-manager.c
> @@ -1403,7 +1403,7 @@ static int method_list_unit_files(sd_bus *bus, 
> sd_bus_message *message, void *us
>  if (!h)
>  return -ENOMEM;
>
> -r = unit_file_get_list(m->running_as == SYSTEMD_SYSTEM ? 
> UNIT_FILE_SYSTEM : UNIT_FILE_USER, NULL, h);
> +r = unit_file_get_list(m->running_as == SYSTEMD_SYSTEM ? 
> UNIT_FILE_SYSTEM : UNIT_FILE_USER, NULL, h, m->enabled);
>  if (r < 0)
>  goto fail;
>
> @@ -1454,7 +1454,7 @@ static int method_get_unit_file_state(sd_bus *bus, 
> sd_bus_message *message, void
>
>  scope = m->running_as == SYSTEMD_SYSTEM ? UNIT_FILE_SYSTEM : 
> UNIT_FILE_USER;
>
> -state = unit_file_get_state(scope, NULL, name);
> +state = unit_file_get_state(scope, NULL, name, m->enabled);
>  if (state < 0)
>  return state;
>
> @@ -1843,7 +1843,7 @@ static int method_add_dependency_unit_files(sd_bus 
> *bus, sd_bus_message *message
>
>  scope = m->running_as == SYSTEMD_SYSTEM ? UNIT_FILE_SYSTEM : 
> UNIT_FILE_USER;
>
> -r = unit_file_add_dependency(scope, runtime, NULL, l, target, dep, 
> force, &changes, &n_changes);
> +r = unit_file_add_dependency(scope, runtime, NULL, l, target, dep, 
> force, NULL, &changes, &n_changes);
>  if (r < 0)
>  return r;
>
> diff --git a/src/core/manager.c b/src/core/manager.c
> index 726977f..f8f41fb 100644
> --- a/src/core/manager.c
> +++ b/src/core/manager.c
> @@ -465,6 +465,10 @@ int manager_new(SystemdRunningAs running_as, bool 
> test_run, Manager **_m) {
>  if (r < 0)
>  goto fail;
>
> +m->enabled = enabled_context_new();
> +if (!m->enabled)
> +goto fail;
> +
>  r = set_ensure_allocated(&m->startup_units, NULL);
>  if (r < 0)
>  goto fail;
> @@ -822,6 +826,8 @@ void manager_free(Manager *m) {
>  hashmap_free(m->watch_pids2);
>  hashmap_free(m->watch_bus);
>
> +enabled_context_free(m->enabled);
> +
>  set_free(m->startup_units);
>  set_free(m->failed_units);
>
> diff --git a/src/core/manager.h b/src/core/manager.h
> index 8e3c146..3f54fe0 100644
> --- a/src/core/manager.h
> +++ b/src/core/manager.h
> @@ -72,6 +72,7 @@ typedef enum ManagerExitCode {
>  #include "unit-name.h"
>  #include "exit-status.h"
>  #include "show-status.h"
> +#include "install.h"
>  #include "failure-action.h"
>
>  struct Manager {
> @@ -82,6 +83,7 @@ struct Manager {
>

[systemd-devel] [PATCH, REVIEW, v2] find_symlinks: adds a cache of enabled unit symbolic link state

2014-10-17 Thread Ken Sedgwick 
The current find_symlinks_fd code traverses the config directories
duplicatively. This is a performance problem if 1000s of units are
being controlled. This patch adds a hashmap cache of symbolic link
state which is filled in one traversal and then consulted as needed to
prevent re-traversal.

The enabled_context cache lives in the manager struct.  Initially the
cache is empty and is filled on first use.  A pointer to the cache is
passed to all routines which can call find_symlinks_fd.  If a NULL is
passed to find_symlinks_fd a temporary cache is created and used for
the single call.

The cache has two levels, the first is keyed by config_path and the
second by the names and paths of the units.

The cache contains both forward and reverse mappings; from symbolic
link name to target and from target to symbolic link name.

The cache contains entries for both the basename of the unit and the
full path of the link name and target.

The test-enabled patch (previously submitted) checks that the results
of unit_file_get_state and unit_file_get_list do not change as a
result of this cache. This patch presumes the test-enabled patch has
already been applied.

The test-manyunits patch (previously submitted) checks that the performance
of unit_file_get_list is acceptable in the face of thousands of units.
This patch presumes the test-manyunits patch has already been applied.
---
 src/core/dbus-manager.c   |   6 +-
 src/core/manager.c|   6 +
 src/core/manager.h|   2 +
 src/core/unit.c   |   2 +-
 src/shared/install.c  | 273 +-
 src/shared/install.h  |  18 ++-
 src/systemctl/systemctl.c |   6 +-
 src/test/test-enabled.c   |  24 ++--
 src/test/test-install.c   |  87 ---
 src/test/test-manyunits.c |  11 +-
 src/test/test-unit-file.c |   2 +-
 11 files changed, 325 insertions(+), 112 deletions(-)

diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
index 57db1c9..0ce41b0 100644
--- a/src/core/dbus-manager.c
+++ b/src/core/dbus-manager.c
@@ -1403,7 +1403,7 @@ static int method_list_unit_files(sd_bus *bus, 
sd_bus_message *message, void *us
 if (!h)
 return -ENOMEM;
 
-r = unit_file_get_list(m->running_as == SYSTEMD_SYSTEM ? 
UNIT_FILE_SYSTEM : UNIT_FILE_USER, NULL, h);
+r = unit_file_get_list(m->running_as == SYSTEMD_SYSTEM ? 
UNIT_FILE_SYSTEM : UNIT_FILE_USER, NULL, h, m->enabled);
 if (r < 0)
 goto fail;
 
@@ -1454,7 +1454,7 @@ static int method_get_unit_file_state(sd_bus *bus, 
sd_bus_message *message, void
 
 scope = m->running_as == SYSTEMD_SYSTEM ? UNIT_FILE_SYSTEM : 
UNIT_FILE_USER;
 
-state = unit_file_get_state(scope, NULL, name);
+state = unit_file_get_state(scope, NULL, name, m->enabled);
 if (state < 0)
 return state;
 
@@ -1843,7 +1843,7 @@ static int method_add_dependency_unit_files(sd_bus *bus, 
sd_bus_message *message
 
 scope = m->running_as == SYSTEMD_SYSTEM ? UNIT_FILE_SYSTEM : 
UNIT_FILE_USER;
 
-r = unit_file_add_dependency(scope, runtime, NULL, l, target, dep, 
force, &changes, &n_changes);
+r = unit_file_add_dependency(scope, runtime, NULL, l, target, dep, 
force, NULL, &changes, &n_changes);
 if (r < 0)
 return r;
 
diff --git a/src/core/manager.c b/src/core/manager.c
index 726977f..f8f41fb 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -465,6 +465,10 @@ int manager_new(SystemdRunningAs running_as, bool 
test_run, Manager **_m) {
 if (r < 0)
 goto fail;
 
+m->enabled = enabled_context_new();
+if (!m->enabled)
+goto fail;
+
 r = set_ensure_allocated(&m->startup_units, NULL);
 if (r < 0)
 goto fail;
@@ -822,6 +826,8 @@ void manager_free(Manager *m) {
 hashmap_free(m->watch_pids2);
 hashmap_free(m->watch_bus);
 
+enabled_context_free(m->enabled);
+
 set_free(m->startup_units);
 set_free(m->failed_units);
 
diff --git a/src/core/manager.h b/src/core/manager.h
index 8e3c146..3f54fe0 100644
--- a/src/core/manager.h
+++ b/src/core/manager.h
@@ -72,6 +72,7 @@ typedef enum ManagerExitCode {
 #include "unit-name.h"
 #include "exit-status.h"
 #include "show-status.h"
+#include "install.h"
 #include "failure-action.h"
 
 struct Manager {
@@ -82,6 +83,7 @@ struct Manager {
 /* Active jobs and units */
 Hashmap *units;  /* name string => Unit object n:1 */
 Hashmap *jobs;   /* job id => Job object 1:1 */
+EnabledContext *enabled; /* name string => is enabled */
 
 /* To make it easy to iterate through the units of a specific
  * type we maintain a per type linked list */
diff --git a/src/core/unit.c b/src/core/unit.c
index 0389e6e..3e29944 100644
--- a/src/core/unit.c
+++ b/src/core/unit.c
@@ -2941,7 +2941,7 @@ UnitFileState unit_get_unit_file_state(Unit *u) {
 if (

[systemd-devel] [PATCH] test-manyunits: test unit_file_get_list perforamnce with many units

2014-10-17 Thread Ken Sedgwick 
This test temporarily creates several thousand unit files and checks
the performance of unit_file_get_list.

This test is currently added to manual_tests only since it does not
pass.

This test does pass if the enabled unit cache patch is applied.
---
 .gitignore|   1 +
 Makefile.am   |  13 -
 src/test/test-manyunits.c | 133 ++
 3 files changed, 146 insertions(+), 1 deletion(-)
 create mode 100644 src/test/test-manyunits.c

diff --git a/.gitignore b/.gitignore
index 97b2b2b..7d5c97c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -207,6 +207,7 @@
 /test-login-tables
 /test-loopback
 /test-machine-tables
+/test-manyunits
 /test-mmap-cache
 /test-namespace
 /test-network
diff --git a/Makefile.am b/Makefile.am
index 46d532c..12cae02 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1306,7 +1306,8 @@ manual_tests += \
test-install \
test-watchdog \
test-log \
-   test-ipcrm
+   test-ipcrm \
+   test-manyunits
 
 if HAVE_KMOD
 manual_tests += \
@@ -1819,6 +1820,16 @@ test_enabled_LDADD = \
libsystemd-shared.la \
libsystemd-internal.la
 
+test_manyunits_SOURCES = \
+   src/test/test-manyunits.c
+
+test_manyunits_LDADD = \
+   libsystemd-core.la \
+   libsystemd-units.la \
+   libsystemd-label.la \
+   libsystemd-shared.la \
+   libsystemd-internal.la
+
 test_watchdog_SOURCES = \
src/test/test-watchdog.c
 
diff --git a/src/test/test-manyunits.c b/src/test/test-manyunits.c
new file mode 100644
index 000..e76f04c
--- /dev/null
+++ b/src/test/test-manyunits.c
@@ -0,0 +1,133 @@
+/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
+
+/***
+  This file is part of systemd.
+
+  Copyright 2014 Pantheon, Inc.
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see .
+***/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "manager.h"
+#include "macro.h"
+#include "util.h"
+
+static const int NUNITS = 3000;
+
+static const char *root_dir;
+
+/* Cleanup the created unit files if we fail an assertion. */
+#define assert_se_cleanup(expr) \
+do {\
+if (_unlikely_(!(expr))) {  \
+cleanup_manyunits();\
+log_assert_failed(#expr, __FILE__, __LINE__,\
+  __PRETTY_FUNCTION__); \
+}   \
+} while (false) \
+
+static const char *many_path(int unitnum) {
+static char path[PATH_MAX];
+snprintf(path, PATH_MAX, "%s/%s/many-%06d.service",
+ root_dir, "usr/lib/systemd/system", unitnum);
+return path;
+}
+
+static const char *link_path(int unitnum) {
+static char path[PATH_MAX];
+snprintf(path, PATH_MAX, "%s/%s/many-%06d.service",
+ root_dir, "etc/systemd/system/some.target.wants", unitnum);
+return path;
+}
+
+static const char *another_path(void) {
+static char path[PATH_MAX];
+snprintf(path, PATH_MAX, "%s/%s/another.service",
+ root_dir, "usr/lib/systemd/system");
+return path;
+}
+
+
+static void cleanup_manyunits(void) {
+int unitnum;
+
+fprintf(stderr, "removing %d unit files\n", NUNITS);
+
+for (unitnum = 0; unitnum < NUNITS; ++unitnum) {
+unlink(link_path(unitnum));
+unlink(many_path(unitnum));
+}
+}
+
+static void setup_manyunits(void) {
+int unitnum;
+const char *another;
+
+another = another_path();
+
+fprintf(stderr, "creating %d unit files\n", NUNITS);
+
+for (unitnum = 0; unitnum < NUNITS; ++unitnum) {
+assert_se_cleanup(link(another, many_path(unitnum)) == 0);
+assert_se_cleanup(symlink(many_path(unitnum),
+  link_path(unitnum)) == 0);
+}
+}
+
+static void test_manyunits(void) {
+time_t t0, t1;
+int r = 0;
+int count = 0;
+Hashmap *h;
+UnitFileList *p;
+Iterator i;
+
+fprintf(stderr, "testing

Re: [systemd-devel] How to use cgroups within containers?

2014-10-17 Thread Cameron Norman 
On Fri, Oct 17, 2014 at 2:37 PM, Richard Weinberger
 wrote:
> ...fixing LXC devel mailinglist... :-\
>
> On Fri, Oct 17, 2014 at 11:35 PM, Richard Weinberger
>  wrote:
>> Dear systemd and container folks,
>>
>> at Plumbers the question raised how to provide cgroups to a systemd that 
>> lives
>> in a container (with user namespaces).
>> Due to the GDL train strikes I had to leave very soon and had no chance to
>> talk to you in person.
>>
>> Was a solution proposed?
>> All I want to know is how to provide cgroups in a sane and secure way
>> to systemd. :-)

I am not at all an expert on systemd's cgroups, however I do know the
basic design of cgmanager. cgmanager provides cgroups to containers
via a "cgproxy" service that relays messages to the main cgmanager
service. You can read more about it here:
https://github.com/cgmanager/cgmanager/blob/master/README. Perhaps
systemd can use a similar model.

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

Re: [systemd-devel] How to use cgroups within containers?

2014-10-17 Thread Richard Weinberger 
...fixing LXC devel mailinglist... :-\

On Fri, Oct 17, 2014 at 11:35 PM, Richard Weinberger
 wrote:
> Dear systemd and container folks,
>
> at Plumbers the question raised how to provide cgroups to a systemd that lives
> in a container (with user namespaces).
> Due to the GDL train strikes I had to leave very soon and had no chance to
> talk to you in person.
>
> Was a solution proposed?
> All I want to know is how to provide cgroups in a sane and secure way
> to systemd. :-)
>
> --
> Thanks,
> //richard



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

[systemd-devel] How to use cgroups within containers?

2014-10-17 Thread Richard Weinberger 
Dear systemd and container folks,

at Plumbers the question raised how to provide cgroups to a systemd that lives
in a container (with user namespaces).
Due to the GDL train strikes I had to leave very soon and had no chance to
talk to you in person.

Was a solution proposed?
All I want to know is how to provide cgroups in a sane and secure way
to systemd. :-)

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

[systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?

2014-10-17 Thread Colin Guthrie 
Hi,

How soon after login can I rely on systemd --user having reached
sockets.target?

This feels a bit like a "you shouldn't rely on that point in time..."
type answer is warrented, and when e.g. GNOME or KDE sessions fully use
systemd to bring themselves up it won't be an issue, but right now,
systemd --user is started by (I think) PAM.

I want to rely on systemd --user to handle PulseAudio's activation
(ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE
might start up their own session stuff and spawn some PA consuming
process before systemd --user has reached it's sockets.target and is
thus ready and listening on PA's native socket.

Doesn't seem to be a problem on my machine here (it's working really
nicely actually!) but figured I should ask here too.

Cheers

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] systemctl: add edit verb

2014-10-17 Thread Dale R. Worley 
> From: Mantas Mikulėnas 

> Normally $VISUAL would be first, followed by $EDITOR...
> 
> (But in practice nobody sets them to different values anyway, since no
> programs aside from mailx care about the distinction. So it's fine
> either way, and just ignoring $VISUAL would be just as good.)

I ran into an archived message which suggested what the "traditional"
indicator was for "visual" vs. "dumb" terminals:  If TERM is unset, or
had the value "dumb", then it's a dumb terminal.  Otherwise, it's a
visual terminal.

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

Re: [systemd-devel] [PATCH 2/2] localectl: verify layout, model, variant and options

2014-10-17 Thread Ran Benita 
On Fri, Oct 17, 2014 at 02:02:13PM +0200, Jan Synacek wrote:
> When setting any of those using set-x11-keymap, check that their values
> are available on the system.

I have only skimmed this patch, but generally:

1. There can only be one model.
2. There can be multiple layouts and variants, comma separated. E.g.,
   layout=us,il variant=,lyx. The amount of layouts and variants should
   match (or the variants can be empty), but most stuff you throw at it
   will be accepted though.
3. There can be multiple comma-separated options.

Do you handle input like "layout=us,il variant=,lyx" correctly?

Ran

> ---
>  src/locale/localectl.c | 179 
> ++---
>  1 file changed, 110 insertions(+), 69 deletions(-)
> 
> diff --git a/src/locale/localectl.c b/src/locale/localectl.c
> index 3690f9f..79bc2d0 100644
> --- a/src/locale/localectl.c
> +++ b/src/locale/localectl.c
> @@ -53,6 +53,14 @@ static BusTransport arg_transport = BUS_TRANSPORT_LOCAL;
>  static char *arg_host = NULL;
>  static bool arg_convert = true;
>  
> +enum keymap_state {
> +NONE,
> +MODELS   = 1 << 0,
> +LAYOUTS  = 1 << 1,
> +VARIANTS = 1 << 2,
> +OPTIONS  = 1 << 3
> +};
> +
>  static void pager_open_if_enabled(void) {
>  
>  if (arg_no_pager)
> @@ -350,59 +358,12 @@ static int list_vconsole_keymaps(sd_bus *bus, char 
> **args, unsigned n) {
>  return 0;
>  }
>  
> -static int set_x11_keymap(sd_bus *bus, char **args, unsigned n) {
> -_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
> -const char *layout, *model, *variant, *options;
> -int r;
> -
> -assert(bus);
> -assert(args);
> -
> -if (n > 5) {
> -log_error("Too many arguments.");
> -return -EINVAL;
> -}
> -
> -polkit_agent_open_if_enabled();
> -
> -layout = args[1];
> -model = n > 2 ? args[2] : "";
> -variant = n > 3 ? args[3] : "";
> -options = n > 4 ? args[4] : "";
> -
> -r = sd_bus_call_method(
> -bus,
> -"org.freedesktop.locale1",
> -"/org/freedesktop/locale1",
> -"org.freedesktop.locale1",
> -"SetX11Keyboard",
> -&error,
> -NULL,
> -"bb", layout, model, variant, options,
> -  arg_convert, arg_ask_password);
> -if (r < 0)
> -log_error("Failed to set keymap: %s", 
> bus_error_message(&error, -r));
> -
> -return r;
> -}
> -
> -static int list_x11_keymaps(sd_bus *bus, char **args, unsigned n) {
> +static int get_x11_keymaps_internal(char ***list, enum keymap_state 
> look_for, const char *layout)
> +{
>  _cleanup_fclose_ FILE *f = NULL;
> -_cleanup_strv_free_ char **list = NULL;
>  char line[LINE_MAX];
> -enum {
> -NONE,
> -MODELS,
> -LAYOUTS,
> -VARIANTS,
> -OPTIONS
> -} state = NONE, look_for;
> -int r;
> -
> -if (n > 2) {
> -log_error("Too many arguments.");
> -return -EINVAL;
> -}
> +enum keymap_state state = NONE;
> +int r = 0;
>  
>  f = fopen("/usr/share/X11/xkb/rules/base.lst", "re");
>  if (!f) {
> @@ -410,17 +371,6 @@ static int list_x11_keymaps(sd_bus *bus, char **args, 
> unsigned n) {
>  return -errno;
>  }
>  
> -if (streq(args[0], "list-x11-keymap-models"))
> -look_for = MODELS;
> -else if (streq(args[0], "list-x11-keymap-layouts"))
> -look_for = LAYOUTS;
> -else if (streq(args[0], "list-x11-keymap-variants"))
> -look_for = VARIANTS;
> -else if (streq(args[0], "list-x11-keymap-options"))
> -look_for = OPTIONS;
> -else
> -assert_not_reached("Wrong parameter");
> -
>  FOREACH_LINE(line, f, break) {
>  char *l, *w;
>  
> @@ -444,12 +394,12 @@ static int list_x11_keymaps(sd_bus *bus, char **args, 
> unsigned n) {
>  continue;
>  }
>  
> -if (state != look_for)
> +if (!(state & look_for))
>  continue;
>  
>  w = l + strcspn(l, WHITESPACE);
>  
> -if (n > 1) {
> +if (layout) {
>  char *e;
>  
>  if (*w == 0)
> @@ -465,23 +415,114 @@ static int list_x11_keymaps(sd_bus *bus, char **args, 
> unsigned n) {
>  
>  *e = 0;
>  
> -if (!streq(w, args[1]))
> +if (!streq(w, layout))
>  continue;
>  } else
>

Re: [systemd-devel] [PATCH v2] environment: append unit_id to error messages regarding EnvironmentFile

2014-10-17 Thread Lukáš Nykrýn 
Zbigniew Jędrzejewski-Szmek píše v Pá 17. 10. 2014 v 15:40 +0200:
> On Fri, Oct 17, 2014 at 11:46:01AM +0200, Lukas Nykryn wrote:
> > ---
> > 
> > I have swapped parameters in test-fileio in previous version
> >  src/core/execute.c | 6 +++---
> >  src/core/execute.h | 2 +-
> >  src/shared/env-util.c  | 7 ---
> >  src/shared/env-util.h  | 2 +-
> >  src/test/test-fileio.c | 2 +-
> >  5 files changed, 10 insertions(+), 9 deletions(-)
> Looks good.
> 
> Zbyszek

Thanks for review, pushed

Lukas

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

Re: [systemd-devel] [PATCH 1/2] man: fix localectl set-x11-keymap syntax description

2014-10-17 Thread Ran Benita 
On Fri, Oct 17, 2014 at 02:02:12PM +0200, Jan Synacek wrote:
> ---
>  man/localectl.xml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/man/localectl.xml b/man/localectl.xml
> index 38e73c7..c332027 100644
> --- a/man/localectl.xml
> +++ b/man/localectl.xml
> @@ -178,7 +178,7 @@
>  
>  
>  
> -set-x11-keymap LAYOUT [MODEL] 
> [VARIANT] [OPTIONS]
> +set-x11-keymap LAYOUT [MODEL 
> [VARIANT [OPTIONS]]]

Would have been nice if this used the same order as setxkbmap (which is
more sensible), but I suppose this cannot be changed?

>  
>  Set the system default
>  keyboard mapping for X11. This takes a
> -- 
> 1.9.3
> 
> ___
> 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] [PATCH v2] udev hwdb: Support shipping pre-compiled database in system images

2014-10-17 Thread Martin Pitt 
Hello again,

the previous patch had a typo in the manpage (it said "/lib/udev"
instead of "/usr/lib/udev" at one place), and also forgot to adjust
systemd-udev-hwdb-update.service.in. Both done now.

However, the latter currently has a gotcha:

  +ConditionPathExists=!@udevlibexecdir@/hwdb.bin

This works correctly if you use this with the "factory reset"
semantics, i. e. start with an empty /etc. But it would not work if
you update /usr and have an already existing /etc/udev/hwdb.d/*. So
ideally the condition would be

  ConditionPathExists=!@udevlibexecdir@/hwdb.bin OR
  ConditionDirectoryNotEmpty=/etc/udev/hwdb.d/

but this isn't possible AFAIK. The alternative would be to change the
Exec= to call "hdwb --update --vendor" iff /etc/udev/hwdb.d/ is empty.

An alternative that was discussed at Plumbers was to make hwdb
--update automatically use @udevlibexecdir@ if there is no
/etc/udev/hwdb.d/, which would avoid this problem, avoid introducing a
new option, and still generally DTRT. I'd prefer this, so if you think
that's easier/better, I'm happy to update the patch accordingly.

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
>From 5c093f2552d7ebbafe079eafe9b0a9bada7615ad Mon Sep 17 00:00:00 2001
From: Martin Pitt 
Date: Fri, 17 Oct 2014 15:01:01 +0200
Subject: [PATCH] udev hwdb: Support shipping pre-compiled database in system
 images

In some cases it is preferable to ship system images with a pre-generated
binary hwdb database, to avoid having to build it at runtime, avoid shipping
the source hwdb files, or avoid storing large binary files in /etc.

So if hwdb.bin does not exist in /etc/udev/, fall back to looking for it in
UDEVLIBEXECDIR. This keeps the possibility to add files to /etc/udev/hwdb.d/
and re-generating the database which trumps the one in /usr/lib.

Add a new --vendor flag to "udevadm hwdb --update" which puts the database
into UDEVLIBEXECDIR.

Adjust systemd-udev-hwdb-update.service to not generate the file in /etc if we
already have it in /usr.
---
 man/udev.xml  |  4 +++-
 man/udevadm.xml   |  9 +
 src/libudev/libudev-hwdb.c| 20 ++--
 src/udev/udevadm-hwdb.c   | 10 --
 units/systemd-udev-hwdb-update.service.in |  1 +
 5 files changed, 35 insertions(+), 9 deletions(-)

diff --git a/man/udev.xml b/man/udev.xml
index d77cbb0..87c16c7 100644
--- a/man/udev.xml
+++ b/man/udev.xml
@@ -766,7 +766,9 @@
 
   The content of all hwdb files is read by
   udevadm8
-  and compiled to a binary database located at /etc/udev/hwdb.bin.
+  and compiled to a binary database located at /etc/udev/hwdb.bin,
+  or alternatively /usr/lib/udev/hwdb.bin if you want ship the compiled
+  database in an immutable image.
   During runtime only the binary database is used.
   
 
diff --git a/man/udevadm.xml b/man/udevadm.xml
index 749144d..571ef7d 100644
--- a/man/udevadm.xml
+++ b/man/udevadm.xml
@@ -494,6 +494,15 @@
   
 
 
+  --vendor
+  
+Put the compiled database into /usr/lib/udev/hwdb.bin instead.
+Use this if you want to ship a pre-compiled database in immutable system images, or
+don't use /etc/udev/hwdb.d and want to avoid large binary files in
+/etc.
+  
+
+
   -t
   --test=string
   
diff --git a/src/libudev/libudev-hwdb.c b/src/libudev/libudev-hwdb.c
index 8fb7240..91c05e8 100644
--- a/src/libudev/libudev-hwdb.c
+++ b/src/libudev/libudev-hwdb.c
@@ -256,6 +256,13 @@ static int trie_search_f(struct udev_hwdb *hwdb, const char *search) {
 return 0;
 }
 
+static const char *get_hwdb_bin_path(void) {
+if (access("/etc/udev/hwdb.bin", F_OK) >= 0)
+return "/etc/udev/hwdb.bin";
+else
+return UDEVLIBEXECDIR "/hwdb.bin";
+}
+
 /**
  * udev_hwdb_new:
  * @udev: udev library context
@@ -267,6 +274,7 @@ static int trie_search_f(struct udev_hwdb *hwdb, const char *search) {
 _public_ struct udev_hwdb *udev_hwdb_new(struct udev *udev) {
 struct udev_hwdb *hwdb;
 const char sig[] = HWDB_SIG;
+const char *hwdb_bin_path = get_hwdb_bin_path();
 
 hwdb = new0(struct udev_hwdb, 1);
 if (!hwdb)
@@ -275,30 +283,30 @@ _public_ struct udev_hwdb *udev_hwdb_new(struct udev *udev) {
 hwdb->refcount = 1;
 udev_list_init(udev, &hwdb->properties_list, true);
 
-hwdb->f = fopen("/etc/udev/hwdb.bin", "re");
+hwdb->f = fopen(hwdb_bin_path, "re");
 if (!hwdb->f) {
-udev_dbg(udev, "error reading /etc/udev/hwdb.bin: %m");
+udev_dbg(udev, "error reading %s: %m", hwdb_bin_path);
 udev_hwdb_unref(hwdb);
 return NULL;
 }
 
 if (fstat(fileno(hwdb->f), &hwd

Re: [systemd-devel] [PATCH v2] environment: append unit_id to error messages regarding EnvironmentFile

2014-10-17 Thread Zbigniew Jędrzejewski-Szmek 
On Fri, Oct 17, 2014 at 11:46:01AM +0200, Lukas Nykryn wrote:
> ---
> 
> I have swapped parameters in test-fileio in previous version
>  src/core/execute.c | 6 +++---
>  src/core/execute.h | 2 +-
>  src/shared/env-util.c  | 7 ---
>  src/shared/env-util.h  | 2 +-
>  src/test/test-fileio.c | 2 +-
>  5 files changed, 10 insertions(+), 9 deletions(-)
Looks good.

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

[systemd-devel] [PATCH] udev hwdb: Support shipping pre-compiled database in system images

2014-10-17 Thread Martin Pitt 
Hello all,

as discussed on the plumbers conference, I would like to optionally
move the compiled hwdb.bin out of /etc/. For r/o system images it is
much nicer if they can just ship a pre-generated hwdb in /usr without
having to build it at runtime/factory reset time, and avoid having to
carry it in /etc.

The behaviour of this should be fully backwards compatible.

Thanks for considering,

Martin


-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
>From 38b8a915fd71204ed9e8b0568ad16516dfa9208b Mon Sep 17 00:00:00 2001
From: Martin Pitt 
Date: Fri, 17 Oct 2014 15:01:01 +0200
Subject: [PATCH] udev hwdb: Support shipping pre-compiled database in system
 images

In some cases it is preferable to ship system images with a pre-generated
binary hwdb database, to avoid having to build it at runtime, avoid shipping
the source hwdb files, or avoid storing large binary files in /etc.

So if hwdb.bin does not exist in /etc/udev/, fall back to looking for it in
UDEVLIBEXECDIR. This keeps the possibility to add files to /etc/udev/hwdb.d/
and re-generating the database which trumps the one in /usr/lib.

Also add a new --vendor flag to "udevadm hwdb --update" which puts the database
into UDEVLIBEXECDIR.
---
 man/udev.xml   |  4 +++-
 man/udevadm.xml|  9 +
 src/libudev/libudev-hwdb.c | 20 ++--
 src/udev/udevadm-hwdb.c| 10 --
 4 files changed, 34 insertions(+), 9 deletions(-)

diff --git a/man/udev.xml b/man/udev.xml
index d77cbb0..71c1220 100644
--- a/man/udev.xml
+++ b/man/udev.xml
@@ -766,7 +766,9 @@
 
   The content of all hwdb files is read by
   udevadm8
-  and compiled to a binary database located at /etc/udev/hwdb.bin.
+  and compiled to a binary database located at /etc/udev/hwdb.bin,
+  or alternatively /lib/udev/hwdb.bin if you want ship the compiled
+  database in an immutable image.
   During runtime only the binary database is used.
   
 
diff --git a/man/udevadm.xml b/man/udevadm.xml
index 749144d..571ef7d 100644
--- a/man/udevadm.xml
+++ b/man/udevadm.xml
@@ -494,6 +494,15 @@
   
 
 
+  --vendor
+  
+Put the compiled database into /usr/lib/udev/hwdb.bin instead.
+Use this if you want to ship a pre-compiled database in immutable system images, or
+don't use /etc/udev/hwdb.d and want to avoid large binary files in
+/etc.
+  
+
+
   -t
   --test=string
   
diff --git a/src/libudev/libudev-hwdb.c b/src/libudev/libudev-hwdb.c
index 8fb7240..91c05e8 100644
--- a/src/libudev/libudev-hwdb.c
+++ b/src/libudev/libudev-hwdb.c
@@ -256,6 +256,13 @@ static int trie_search_f(struct udev_hwdb *hwdb, const char *search) {
 return 0;
 }
 
+static const char *get_hwdb_bin_path(void) {
+if (access("/etc/udev/hwdb.bin", F_OK) >= 0)
+return "/etc/udev/hwdb.bin";
+else
+return UDEVLIBEXECDIR "/hwdb.bin";
+}
+
 /**
  * udev_hwdb_new:
  * @udev: udev library context
@@ -267,6 +274,7 @@ static int trie_search_f(struct udev_hwdb *hwdb, const char *search) {
 _public_ struct udev_hwdb *udev_hwdb_new(struct udev *udev) {
 struct udev_hwdb *hwdb;
 const char sig[] = HWDB_SIG;
+const char *hwdb_bin_path = get_hwdb_bin_path();
 
 hwdb = new0(struct udev_hwdb, 1);
 if (!hwdb)
@@ -275,30 +283,30 @@ _public_ struct udev_hwdb *udev_hwdb_new(struct udev *udev) {
 hwdb->refcount = 1;
 udev_list_init(udev, &hwdb->properties_list, true);
 
-hwdb->f = fopen("/etc/udev/hwdb.bin", "re");
+hwdb->f = fopen(hwdb_bin_path, "re");
 if (!hwdb->f) {
-udev_dbg(udev, "error reading /etc/udev/hwdb.bin: %m");
+udev_dbg(udev, "error reading %s: %m", hwdb_bin_path);
 udev_hwdb_unref(hwdb);
 return NULL;
 }
 
 if (fstat(fileno(hwdb->f), &hwdb->st) < 0 ||
 (size_t)hwdb->st.st_size < offsetof(struct trie_header_f, strings_len) + 8) {
-udev_dbg(udev, "error reading /etc/udev/hwdb.bin: %m");
+udev_dbg(udev, "error reading %s: %m", hwdb_bin_path);
 udev_hwdb_unref(hwdb);
 return NULL;
 }
 
 hwdb->map = mmap(0, hwdb->st.st_size, PROT_READ, MAP_SHARED, fileno(hwdb->f), 0);
 if (hwdb->map == MAP_FAILED) {
-udev_dbg(udev, "error mapping /etc/udev/hwdb.bin: %m");
+udev_dbg(udev, "error mapping %s: %m", hwdb_bin_path);
 udev_hwdb_unref(hwdb);
 return NULL;
 }
 
 if (memcmp(hwdb->map, sig, sizeof(hwdb->head->signature)) != 0 ||
 (size_t)hwdb->st.st_size != le64toh(hwdb->head->file_size)) {
-udev_dbg(udev, "error recognizing the format of /etc/udev/hwdb.bin"

Re: [systemd-devel] [PATCH] systemctl: add edit verb

2014-10-17 Thread Mantas Mikulėnas 
On Fri, Oct 17, 2014 at 3:11 PM, Lennart Poettering
 wrote:
> On Fri, 17.10.14 14:29, Mantas Mikulėnas (graw...@gmail.com) wrote:
>
>> > Technically proficient people will set $EDITOR or $VISUAL
>> > anyway. Non-technical people won't. Non-technical people are likel to
>> > be totally lost in vi/vim. For those folks probably nano makes a
>> > better choice, simply because it shows an explanation of they
>> > supported keys at the bottom of the screen.
>> >
>> > Hence, I think doing a logic like this would make sense:
>> >
>> > 1) if $EDITOR is set, use it
>> > 2) otherwise: if $VISUAL is set, use it
>> > 3) otherwise: if "nano" exists, use it
>> > 4) otherwise: if "vim" exists, use it
>> > 5) otherwise: if "vi" exists, use it
>>
>> The list of editors seems fine.
>>
>> Normally $VISUAL would be first, followed by $EDITOR...
>>
>> (But in practice nobody sets them to different values anyway, since no
>> programs aside from mailx care about the distinction. So it's fine
>> either way, and just ignoring $VISUAL would be just as good.)
>
> Is there a real distinction between $VISUAL and $EDITOR? environ(7)
> makes no distinction, have any better docs that clarify the supposed
> distinction?

It's much older than me, but as far as I know, one would have had
$EDITOR set to 'ed' or 'ex' for "dumb" typewriter-based terminals
(which were used before CRT terminals were a thing) and $VISUAL to
'vi' or 'emacs' for CRT-based terminals (which could show full-screen
programs), and programs would start the right one depending on $TERM
value.

But these days, I haven't seen any program (other than mailx) actually
care about the differences; they pretty much always go $VISUAL ||
$EDITOR || something || something || vi. So most people have both set
to the same editor, just in case. So I'd safely get rid of $VISUAL

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

Re: [systemd-devel] [PATCH] systemctl: add edit verb

2014-10-17 Thread Lennart Poettering 
On Fri, 17.10.14 13:30, David Timothy Strauss (da...@davidstrauss.net) wrote:

> On Fri, Oct 17, 2014 at 1:24 PM, Lennart Poettering
>  wrote:
> > Does this make sense?
> 
> Speaking as a nano user and someone who barely knows how to quit vim,
> I still think the decision of the default editor should be "vi" or the
> distribution's choice.

Well, what's the distribution's choice? I mean, if distributions want
to change things they can patch this in, they have that option anyway...

Note that with the order i proposed, systems that have no "nano"
installed will effectively only get vi/vim invoked here. I think nano
is mostly installed only on systems where it also is the default, or
where the user wants to use it, hence it's probably a good default,
since there's reason enough to believe that if it is available it
shall be used, and if it shall not be used it's probably not
installed...

In a way this mimics Debian's behaviour I figure, which also defaults
to "nano" in sensible-editor, currently, AFAIK...

That all said, this topic kinda enters bikeshed territory, so I figure
we should just implement some alg, and stick with 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] systemctl: add edit verb

2014-10-17 Thread Lennart Poettering 
On Fri, 17.10.14 14:29, Mantas Mikulėnas (graw...@gmail.com) wrote:

> > Technically proficient people will set $EDITOR or $VISUAL
> > anyway. Non-technical people won't. Non-technical people are likel to
> > be totally lost in vi/vim. For those folks probably nano makes a
> > better choice, simply because it shows an explanation of they
> > supported keys at the bottom of the screen.
> >
> > Hence, I think doing a logic like this would make sense:
> >
> > 1) if $EDITOR is set, use it
> > 2) otherwise: if $VISUAL is set, use it
> > 3) otherwise: if "nano" exists, use it
> > 4) otherwise: if "vim" exists, use it
> > 5) otherwise: if "vi" exists, use it
> 
> The list of editors seems fine.
> 
> Normally $VISUAL would be first, followed by $EDITOR...
> 
> (But in practice nobody sets them to different values anyway, since no
> programs aside from mailx care about the distinction. So it's fine
> either way, and just ignoring $VISUAL would be just as good.)

Is there a real distinction between $VISUAL and $EDITOR? environ(7)
makes no distinction, have any better docs that clarify the supposed
distinction?

To me it appears that $VISUAL is a bit more legacy thatn $EDITOR is...

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] Fwd: [PATCH v3] tests: added tests for unit_file_get_{state, list}

2014-10-17 Thread Martin Pitt 
Hello Ken, David,

sorry for breaking the thread.

Thanks for adding these tests! This looks good to me, I just have some
nitpicks. NB that I'm not really familiar with the systemd code, so my
comments are certainly not complete.

David Timothy Strauss [2014-10-17 13:42 +0200]:
> diff --git a/Makefile.am b/Makefile.am
> index e52db17..7d4f2f5 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -1358,7 +1358,8 @@ tests += \
> test-ratelimit \
> test-condition-util \
> test-uid-range \
> -   test-bus-policy
> +   test-bus-policy \
> +   test-enabled

Nitpick: Can we end lists with a $(NULL) line so that patches don't
always have to change the previous last line?

>  EXTRA_DIST += \
> test/a.service \
> @@ -1394,8 +1395,36 @@ EXTRA_DIST += \
> test/bus-policy/hello.conf \
> test/bus-policy/methods.conf \
> test/bus-policy/ownerships.conf \
> -   test/bus-policy/signals.conf
> -
> +   test/bus-policy/signals.conf \
> +   test/test-enabled-root/usr/lib/systemd/system/masked.service \

[...] Personally I find it a lot easier to have a test with this
style:

  unit = create_test_unit(contents);
  assert(something_about(unit));

as you keep the data what you test and what you expect together in one
spot. Also it keeps clutter out of the tree and it's easier to
factorize/mass-change test units.

But this is again just nitpicking, and actually also a question to the
systemd developers which style they prefer.

> +static void test_enabled(int argc, char* argv[]) {
> [...]
> +h = hashmap_new(&string_hash_ops);
> +r = unit_file_get_list(UNIT_FILE_SYSTEM, root_dir, h);
> +assert_se(r >= 0);

I'm a bit confused here -- is this supposed to have a side effect and
the condition was rewritten later?

> +HASHMAP_FOREACH(p, h, i) {
> +UnitFileState s;
> +
> +s = unit_file_get_state(UNIT_FILE_SYSTEM, root_dir,
> +basename(p->path));
> +
> +/* unit_file_get_list and unit_file_get_state are
> + * a little different in some cases.  Handle these
> + * cases here ...
> + */
> +switch ((int)s) {
> +case UNIT_FILE_ENABLED_RUNTIME:

Meh type safety (enum → int → back to enum), but this looks
safe/correct anyway. Handling both errno and enum value in the same
switch isn't otherwise possible, it'd need to be moved into an if/else
ladder.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH 2/2] localectl: verify layout, model, variant and options

2014-10-17 Thread Jan Synacek 
When setting any of those using set-x11-keymap, check that their values
are available on the system.
---
 src/locale/localectl.c | 179 ++---
 1 file changed, 110 insertions(+), 69 deletions(-)

diff --git a/src/locale/localectl.c b/src/locale/localectl.c
index 3690f9f..79bc2d0 100644
--- a/src/locale/localectl.c
+++ b/src/locale/localectl.c
@@ -53,6 +53,14 @@ static BusTransport arg_transport = BUS_TRANSPORT_LOCAL;
 static char *arg_host = NULL;
 static bool arg_convert = true;
 
+enum keymap_state {
+NONE,
+MODELS   = 1 << 0,
+LAYOUTS  = 1 << 1,
+VARIANTS = 1 << 2,
+OPTIONS  = 1 << 3
+};
+
 static void pager_open_if_enabled(void) {
 
 if (arg_no_pager)
@@ -350,59 +358,12 @@ static int list_vconsole_keymaps(sd_bus *bus, char 
**args, unsigned n) {
 return 0;
 }
 
-static int set_x11_keymap(sd_bus *bus, char **args, unsigned n) {
-_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
-const char *layout, *model, *variant, *options;
-int r;
-
-assert(bus);
-assert(args);
-
-if (n > 5) {
-log_error("Too many arguments.");
-return -EINVAL;
-}
-
-polkit_agent_open_if_enabled();
-
-layout = args[1];
-model = n > 2 ? args[2] : "";
-variant = n > 3 ? args[3] : "";
-options = n > 4 ? args[4] : "";
-
-r = sd_bus_call_method(
-bus,
-"org.freedesktop.locale1",
-"/org/freedesktop/locale1",
-"org.freedesktop.locale1",
-"SetX11Keyboard",
-&error,
-NULL,
-"bb", layout, model, variant, options,
-  arg_convert, arg_ask_password);
-if (r < 0)
-log_error("Failed to set keymap: %s", 
bus_error_message(&error, -r));
-
-return r;
-}
-
-static int list_x11_keymaps(sd_bus *bus, char **args, unsigned n) {
+static int get_x11_keymaps_internal(char ***list, enum keymap_state look_for, 
const char *layout)
+{
 _cleanup_fclose_ FILE *f = NULL;
-_cleanup_strv_free_ char **list = NULL;
 char line[LINE_MAX];
-enum {
-NONE,
-MODELS,
-LAYOUTS,
-VARIANTS,
-OPTIONS
-} state = NONE, look_for;
-int r;
-
-if (n > 2) {
-log_error("Too many arguments.");
-return -EINVAL;
-}
+enum keymap_state state = NONE;
+int r = 0;
 
 f = fopen("/usr/share/X11/xkb/rules/base.lst", "re");
 if (!f) {
@@ -410,17 +371,6 @@ static int list_x11_keymaps(sd_bus *bus, char **args, 
unsigned n) {
 return -errno;
 }
 
-if (streq(args[0], "list-x11-keymap-models"))
-look_for = MODELS;
-else if (streq(args[0], "list-x11-keymap-layouts"))
-look_for = LAYOUTS;
-else if (streq(args[0], "list-x11-keymap-variants"))
-look_for = VARIANTS;
-else if (streq(args[0], "list-x11-keymap-options"))
-look_for = OPTIONS;
-else
-assert_not_reached("Wrong parameter");
-
 FOREACH_LINE(line, f, break) {
 char *l, *w;
 
@@ -444,12 +394,12 @@ static int list_x11_keymaps(sd_bus *bus, char **args, 
unsigned n) {
 continue;
 }
 
-if (state != look_for)
+if (!(state & look_for))
 continue;
 
 w = l + strcspn(l, WHITESPACE);
 
-if (n > 1) {
+if (layout) {
 char *e;
 
 if (*w == 0)
@@ -465,23 +415,114 @@ static int list_x11_keymaps(sd_bus *bus, char **args, 
unsigned n) {
 
 *e = 0;
 
-if (!streq(w, args[1]))
+if (!streq(w, layout))
 continue;
 } else
 *w = 0;
 
- r = strv_extend(&list, l);
+ r = strv_extend(list, l);
  if (r < 0)
  return log_oom();
 }
 
-if (strv_isempty(list)) {
+if (strv_isempty(*list)) {
 log_error("Couldn't find any entries.");
 return -ENOENT;
 }
 
-strv_sort(list);
-strv_uniq(list);
+strv_sort(*list);
+strv_uniq(*list);
+
+return r;
+}
+
+static int set_x11_keymap(sd_bus *bus, char **args, unsigned n) {
+_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
+_cleanup_strv_free_ char **list = NULL;
+const char *layout, *model, *variant, *options;
+enum keymap_state lo

[systemd-devel] [PATCH 1/2] man: fix localectl set-x11-keymap syntax description

2014-10-17 Thread Jan Synacek 
---
 man/localectl.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man/localectl.xml b/man/localectl.xml
index 38e73c7..c332027 100644
--- a/man/localectl.xml
+++ b/man/localectl.xml
@@ -178,7 +178,7 @@
 
 
 
-set-x11-keymap LAYOUT [MODEL] 
[VARIANT] [OPTIONS]
+set-x11-keymap LAYOUT [MODEL 
[VARIANT [OPTIONS]]]
 
 Set the system default
 keyboard mapping for X11. This takes a
-- 
1.9.3

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

[systemd-devel] [PATCH 0/2] localectl: verify layout, model, varian and options; fix manpage

2014-10-17 Thread Jan Synacek 
Small localectl fixes.

Both patches fix https://bugzilla.redhat.com/show_bug.cgi?id=1049306.

Jan Synacek (2):
  man: fix localectl set-x11-keymap syntax description
  localectl: verify layout, model, variant and options

 man/localectl.xml  |   2 +-
 src/locale/localectl.c | 179 ++---
 2 files changed, 111 insertions(+), 70 deletions(-)

-- 
1.9.3

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

Re: [systemd-devel] [systemd-commits] src/core

2014-10-17 Thread Lennart Poettering 
On Fri, 17.10.14 02:58, Michal Sekletar (msekl...@kemper.freedesktop.org) wrote:

>  src/core/execute.c |5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> New commits:
> commit 0015ebf3fa524d414a947bdf0814782a8ee00799
> Author: Michal Sekletar 
> Date:   Fri Oct 17 11:51:46 2014 +0200
> 
> execute: don't fail child when we don't have privileges to setup 
> namespaces
> 
> If we don't have privileges to setup the namespaces then we are most 
> likely
> running inside some sort of unprivileged container, hence not being able 
> to
> create namespace is not a problem because spawned service can't access 
> host
> system anyway.
> 
> diff --git a/src/core/execute.c b/src/core/execute.c
> index b165b33..43f2764 100644
> --- a/src/core/execute.c
> +++ b/src/core/execute.c
> @@ -1545,7 +1545,10 @@ static int exec_child(ExecCommand *command,
>  context->protect_home,
>  context->protect_system,
>  context->mount_flags);
> -if (err < 0) {
> +
> +if (err == -EPERM)
> +log_error_unit(params->unit_id, "Failed to setup 
> namespace, ignoring: %s", strerror(-err));
> +else if (err < 0) {

I extended the message a bit, to be more helpful to users. Also, if
this is now effectively just a warning, but nothing fatal we need to
downgrade this to "log_warning_unit()". Made that change too.

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] systemctl: add edit verb

2014-10-17 Thread Mantas Mikulėnas 
On Fri, Oct 17, 2014 at 2:24 PM, Lennart Poettering
 wrote:
> On Mon, 13.10.14 13:40, David Herrmann (dh.herrm...@gmail.com) wrote:
>
>> Hi
>>
>> On Sat, Oct 11, 2014 at 8:17 PM, Daniel Buch  
>> wrote:
>> > Nice, I was in the process of implementing this. Looks good to me. But I
>> > think it would be better to use "vi" instead of "vim" if no &editor is set.
>> > Vim is not installed on every system as default but vi is most likely.
>>
>> I'd prefer doing nothing. "vi" has quite different behavior than
>> "vim", especially in Ex mode. And for people uncomfortable with 'vi'
>> it's even worth. And everyone should have set EDITOR anyway..
>
> Technically proficient people will set $EDITOR or $VISUAL
> anyway. Non-technical people won't. Non-technical people are likel to
> be totally lost in vi/vim. For those folks probably nano makes a
> better choice, simply because it shows an explanation of they
> supported keys at the bottom of the screen.
>
> Hence, I think doing a logic like this would make sense:
>
> 1) if $EDITOR is set, use it
> 2) otherwise: if $VISUAL is set, use it
> 3) otherwise: if "nano" exists, use it
> 4) otherwise: if "vim" exists, use it
> 5) otherwise: if "vi" exists, use it

The list of editors seems fine.

Normally $VISUAL would be first, followed by $EDITOR...

(But in practice nobody sets them to different values anyway, since no
programs aside from mailx care about the distinction. So it's fine
either way, and just ignoring $VISUAL would be just as good.)

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

Re: [systemd-devel] [PATCH] systemctl: add edit verb

2014-10-17 Thread Lennart Poettering 
On Mon, 13.10.14 13:40, David Herrmann (dh.herrm...@gmail.com) wrote:

> Hi
> 
> On Sat, Oct 11, 2014 at 8:17 PM, Daniel Buch  wrote:
> > Nice, I was in the process of implementing this. Looks good to me. But I
> > think it would be better to use "vi" instead of "vim" if no &editor is set.
> > Vim is not installed on every system as default but vi is most likely.
> 
> I'd prefer doing nothing. "vi" has quite different behavior than
> "vim", especially in Ex mode. And for people uncomfortable with 'vi'
> it's even worth. And everyone should have set EDITOR anyway..

Technically proficient people will set $EDITOR or $VISUAL
anyway. Non-technical people won't. Non-technical people are likel to
be totally lost in vi/vim. For those folks probably nano makes a
better choice, simply because it shows an explanation of they
supported keys at the bottom of the screen.

Hence, I think doing a logic like this would make sense:

1) if $EDITOR is set, use it
2) otherwise: if $VISUAL is set, use it
3) otherwise: if "nano" exists, use it
4) otherwise: if "vim" exists, use it
5) otherwise: if "vi" exists, use it

Note that I myself feel a bit lost in nano, and am a vim user for
cases like this, but I am still of the opinion that vi/vim is not what
you want to throw non-unix guru in without a warning. 

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

[systemd-devel] [PATCH v2] environment: append unit_id to error messages regarding EnvironmentFile

2014-10-17 Thread Lukas Nykryn 
---

I have swapped parameters in test-fileio in previous version
 src/core/execute.c | 6 +++---
 src/core/execute.h | 2 +-
 src/shared/env-util.c  | 7 ---
 src/shared/env-util.h  | 2 +-
 src/test/test-fileio.c | 2 +-
 5 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/src/core/execute.c b/src/core/execute.c
index b165b33..f515934 100644
--- a/src/core/execute.c
+++ b/src/core/execute.c
@@ -1782,7 +1782,7 @@ int exec_spawn(ExecCommand *command,
 n_fds = params->n_fds;
 }
 
-err = exec_context_load_environment(context, &files_env);
+err = exec_context_load_environment(context, params->unit_id, 
&files_env);
 if (err < 0) {
 log_struct_unit(LOG_ERR,
params->unit_id,
@@ -2011,7 +2011,7 @@ void exec_command_free_array(ExecCommand **c, unsigned n) 
{
 }
 }
 
-int exec_context_load_environment(const ExecContext *c, char ***l) {
+int exec_context_load_environment(const ExecContext *c, const char *unit_id, 
char ***l) {
 char **i, **r = NULL;
 
 assert(c);
@@ -2068,7 +2068,7 @@ int exec_context_load_environment(const ExecContext *c, 
char ***l) {
 }
 /* Log invalid environment variables with filename */
 if (p)
-p = strv_env_clean_log(p, pglob.gl_pathv[n]);
+p = strv_env_clean_log(p, unit_id, 
pglob.gl_pathv[n]);
 
 if (r == NULL)
 r = p;
diff --git a/src/core/execute.h b/src/core/execute.h
index 2694315..c45dde5 100644
--- a/src/core/execute.h
+++ b/src/core/execute.h
@@ -241,7 +241,7 @@ void exec_context_dump(ExecContext *c, FILE* f, const char 
*prefix);
 
 int exec_context_destroy_runtime_directory(ExecContext *c, const char 
*runtime_root);
 
-int exec_context_load_environment(const ExecContext *c, char ***l);
+int exec_context_load_environment(const ExecContext *c, const char *unit_id, 
char ***l);
 
 bool exec_context_may_touch_console(ExecContext *c);
 
diff --git a/src/shared/env-util.c b/src/shared/env-util.c
index 20b208f..d90b878 100644
--- a/src/shared/env-util.c
+++ b/src/shared/env-util.c
@@ -28,6 +28,7 @@
 #include "util.h"
 #include "env-util.h"
 #include "def.h"
+#include "unit.h"
 
 #define VALID_CHARS_ENV_NAME\
 DIGITS LETTERS  \
@@ -414,7 +415,7 @@ char *strv_env_get(char **l, const char *name) {
 return strv_env_get_n(l, name, strlen(name));
 }
 
-char **strv_env_clean_log(char **e, const char *message) {
+char **strv_env_clean_log(char **e, const char *unit_id, const char *message) {
 char **p, **q;
 int k = 0;
 
@@ -424,7 +425,7 @@ char **strv_env_clean_log(char **e, const char *message) {
 
 if (!env_assignment_is_valid(*p)) {
 if (message)
-log_error("Ignoring invalid environment '%s': 
%s", *p, message);
+log_error_unit(unit_id, "Ignoring invalid 
environment '%s': %s", *p, message);
 free(*p);
 continue;
 }
@@ -451,5 +452,5 @@ char **strv_env_clean_log(char **e, const char *message) {
 }
 
 char **strv_env_clean(char **e) {
-return strv_env_clean_log(e, NULL);
+return strv_env_clean_log(e, NULL, NULL);
 }
diff --git a/src/shared/env-util.h b/src/shared/env-util.h
index c0b1e38..3c6f9d7 100644
--- a/src/shared/env-util.h
+++ b/src/shared/env-util.h
@@ -30,7 +30,7 @@ bool env_assignment_is_valid(const char *e);
 
 bool strv_env_is_valid(char **e);
 char **strv_env_clean(char **l);
-char **strv_env_clean_log(char **e, const char *message);
+char **strv_env_clean_log(char **e, const char *unit_id, const char *message);
 
 bool strv_env_name_or_assignment_is_valid(char **l);
 
diff --git a/src/test/test-fileio.c b/src/test/test-fileio.c
index 76a9e8e..7e7b4ac 100644
--- a/src/test/test-fileio.c
+++ b/src/test/test-fileio.c
@@ -90,7 +90,7 @@ static void test_parse_env_file(void) {
 assert_se(streq_ptr(a[9], "ten="));
 assert_se(a[10] == NULL);
 
-strv_env_clean_log(a, "test");
+strv_env_clean_log(a, NULL, "test");
 
 k = 0;
 STRV_FOREACH(i, b) {
-- 
1.8.3.1

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

[systemd-devel] [PATCH] environment: append unit_id to error messages regarding EnvironmentFile

2014-10-17 Thread Lukas Nykryn 
---
 src/core/execute.c | 6 +++---
 src/core/execute.h | 2 +-
 src/shared/env-util.c  | 7 ---
 src/shared/env-util.h  | 2 +-
 src/test/test-fileio.c | 2 +-
 5 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/src/core/execute.c b/src/core/execute.c
index b165b33..f515934 100644
--- a/src/core/execute.c
+++ b/src/core/execute.c
@@ -1782,7 +1782,7 @@ int exec_spawn(ExecCommand *command,
 n_fds = params->n_fds;
 }
 
-err = exec_context_load_environment(context, &files_env);
+err = exec_context_load_environment(context, params->unit_id, 
&files_env);
 if (err < 0) {
 log_struct_unit(LOG_ERR,
params->unit_id,
@@ -2011,7 +2011,7 @@ void exec_command_free_array(ExecCommand **c, unsigned n) 
{
 }
 }
 
-int exec_context_load_environment(const ExecContext *c, char ***l) {
+int exec_context_load_environment(const ExecContext *c, const char *unit_id, 
char ***l) {
 char **i, **r = NULL;
 
 assert(c);
@@ -2068,7 +2068,7 @@ int exec_context_load_environment(const ExecContext *c, 
char ***l) {
 }
 /* Log invalid environment variables with filename */
 if (p)
-p = strv_env_clean_log(p, pglob.gl_pathv[n]);
+p = strv_env_clean_log(p, unit_id, 
pglob.gl_pathv[n]);
 
 if (r == NULL)
 r = p;
diff --git a/src/core/execute.h b/src/core/execute.h
index 2694315..c45dde5 100644
--- a/src/core/execute.h
+++ b/src/core/execute.h
@@ -241,7 +241,7 @@ void exec_context_dump(ExecContext *c, FILE* f, const char 
*prefix);
 
 int exec_context_destroy_runtime_directory(ExecContext *c, const char 
*runtime_root);
 
-int exec_context_load_environment(const ExecContext *c, char ***l);
+int exec_context_load_environment(const ExecContext *c, const char *unit_id, 
char ***l);
 
 bool exec_context_may_touch_console(ExecContext *c);
 
diff --git a/src/shared/env-util.c b/src/shared/env-util.c
index 20b208f..d90b878 100644
--- a/src/shared/env-util.c
+++ b/src/shared/env-util.c
@@ -28,6 +28,7 @@
 #include "util.h"
 #include "env-util.h"
 #include "def.h"
+#include "unit.h"
 
 #define VALID_CHARS_ENV_NAME\
 DIGITS LETTERS  \
@@ -414,7 +415,7 @@ char *strv_env_get(char **l, const char *name) {
 return strv_env_get_n(l, name, strlen(name));
 }
 
-char **strv_env_clean_log(char **e, const char *message) {
+char **strv_env_clean_log(char **e, const char *unit_id, const char *message) {
 char **p, **q;
 int k = 0;
 
@@ -424,7 +425,7 @@ char **strv_env_clean_log(char **e, const char *message) {
 
 if (!env_assignment_is_valid(*p)) {
 if (message)
-log_error("Ignoring invalid environment '%s': 
%s", *p, message);
+log_error_unit(unit_id, "Ignoring invalid 
environment '%s': %s", *p, message);
 free(*p);
 continue;
 }
@@ -451,5 +452,5 @@ char **strv_env_clean_log(char **e, const char *message) {
 }
 
 char **strv_env_clean(char **e) {
-return strv_env_clean_log(e, NULL);
+return strv_env_clean_log(e, NULL, NULL);
 }
diff --git a/src/shared/env-util.h b/src/shared/env-util.h
index c0b1e38..3c6f9d7 100644
--- a/src/shared/env-util.h
+++ b/src/shared/env-util.h
@@ -30,7 +30,7 @@ bool env_assignment_is_valid(const char *e);
 
 bool strv_env_is_valid(char **e);
 char **strv_env_clean(char **l);
-char **strv_env_clean_log(char **e, const char *message);
+char **strv_env_clean_log(char **e, const char *unit_id, const char *message);
 
 bool strv_env_name_or_assignment_is_valid(char **l);
 
diff --git a/src/test/test-fileio.c b/src/test/test-fileio.c
index 76a9e8e..56b4b08 100644
--- a/src/test/test-fileio.c
+++ b/src/test/test-fileio.c
@@ -90,7 +90,7 @@ static void test_parse_env_file(void) {
 assert_se(streq_ptr(a[9], "ten="));
 assert_se(a[10] == NULL);
 
-strv_env_clean_log(a, "test");
+strv_env_clean_log(a, "test", NULL);
 
 k = 0;
 STRV_FOREACH(i, b) {
-- 
1.8.3.1

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

Re: [systemd-devel] How is desktop container getting along?

2014-10-17 Thread Leslie Zhai 

Hi David,

Thanks for reply ;)

0. yes, container (namespaces, seccomp, pivot_root, cgroups) is more 
than that!


1 && 2. I just take cross library as an instance ;)

3. I have no idea about X11, but there is isolated Wayland solution, 
isn' it? so I want to follow the desktop container and GNOME sandboxed 
application, is there some demo or skeleton available?


On 10/17/2014 04:21 PM, David Timothy Strauss wrote:

On Fri, Oct 17, 2014 at 9:47 AM, Leslie Zhai  wrote:

But there are only lots of use cases about Linux Server and web application,
as a Linux desktop geek, I often consider about the disadvantage of
traditional deployment of Linux desktop application. Krita, for example, an
awesome digital painting application in KDE`s calligra suite, is depend on
Qt4, kdepimlibs 4.6.0, kdelibs4 and sort of KDE4 relative libraries; but
also as a KDE develop, my desktop environment is Qt5 and KF5, so I have to
git clone KDE4 relative libraries` repositories, then built them by myself
as what other Linux geeks often experienced


Desktop containers are not that far along, at least in the sense of
seeing any major distribution on the verge of installing applications
via containers. Even if/when it happens, it may not be the panacea for
dependencies you're expecting.

First, there are multiple ways to install different library versions
simultaneously without containers. Distributions regularly do this for
things like GTK2 and GTK3. Have you checked with your distribution?

Second, you don't need containers to package an application with its
own libraries. Distributions usually frown on packaging shared
libraries with an application. What you're suggesting for containers
wouldn't be any better than packaging to /opt/krita with all libraries
in the same directory, which is what some apps have done for years.

Finally, your desktop can only support a fixed set of graphical APIs.
Unless you render the application in the container and connect with
something like SPICE (which wouldn't be that great), containers won't
allow you to run arbitrary applications.



--
Regards
Leslie Zhai
a KDE developer
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How is desktop container getting along?

2014-10-17 Thread David Timothy Strauss 
On Fri, Oct 17, 2014 at 9:47 AM, Leslie Zhai  wrote:
> But there are only lots of use cases about Linux Server and web application,
> as a Linux desktop geek, I often consider about the disadvantage of
> traditional deployment of Linux desktop application. Krita, for example, an
> awesome digital painting application in KDE`s calligra suite, is depend on
> Qt4, kdepimlibs 4.6.0, kdelibs4 and sort of KDE4 relative libraries; but
> also as a KDE develop, my desktop environment is Qt5 and KF5, so I have to
> git clone KDE4 relative libraries` repositories, then built them by myself
> as what other Linux geeks often experienced

Desktop containers are not that far along, at least in the sense of
seeing any major distribution on the verge of installing applications
via containers. Even if/when it happens, it may not be the panacea for
dependencies you're expecting.

First, there are multiple ways to install different library versions
simultaneously without containers. Distributions regularly do this for
things like GTK2 and GTK3. Have you checked with your distribution?

Second, you don't need containers to package an application with its
own libraries. Distributions usually frown on packaging shared
libraries with an application. What you're suggesting for containers
wouldn't be any better than packaging to /opt/krita with all libraries
in the same directory, which is what some apps have done for years.

Finally, your desktop can only support a fixed set of graphical APIs.
Unless you render the application in the container and connect with
something like SPICE (which wouldn't be that great), containers won't
allow you to run arbitrary applications.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Starting different services from same process

2014-10-17 Thread David Timothy Strauss 
On Fri, Oct 17, 2014 at 9:03 AM, Paassen, Hiram van
 wrote:
> Is it possible to start multiple different services from one process?

In short, that is not sanely possible. If you care about latency for
accessing the service, even on the first request, then just don't
activate it using DBus. Enable it to start by default.

There are hacks you could use to move a process into another service's
cgroup, but it's highly unsupported and may not work coming kernel and
systemd changes to cgroups.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] How is desktop container getting along?

2014-10-17 Thread Leslie Zhai 

Hi systemd developers,

I am studying namespace, seccomp, pivot_root, cgroups and other thing 
behind Linux container such as lxc and docker recently.


But there are only lots of use cases about Linux Server and web 
application, as a Linux desktop geek, I often consider about the 
disadvantage of traditional deployment of Linux desktop application. 
Krita, for example, an awesome digital painting application in KDE`s 
calligra suite, is depend on Qt4, kdepimlibs 4.6.0, kdelibs4 and sort of 
KDE4 relative libraries; but also as a KDE develop, my desktop 
environment is Qt5 and KF5, so I have to git clone KDE4 relative 
libraries` repositories, then built them by myself as what other Linux 
geeks often experienced ;)


When I found Desktop Container 
http://blogs.gnome.org/uraeus/2014/07/10/desktop-containers-the-way-forward/ 
especially there is Sandboxed applications for GNOME keynote 
http://www.superlectures.com/guadec2013/sandboxed-applications-for-gnome 
by Lennart Poettering, it is impressed!


So I just want to know how is desktop container getting along? what is 
it`s status? is there some git repository or something to follow?


And I have to thank the one who helped us to be familiar with 
systemd-journal via systemd mailing list 
https://github.com/AOSC-Dev/FixMe/blob/master/test/test_systemd_journal.c


--
Regards
Leslie Zhai
a KDE developer
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCHv2] logind: Support logind.conf.d directories in the usual search paths

2014-10-17 Thread Josh Triplett 
On Fri, Oct 17, 2014 at 08:40:48AM +0300, Mantas Mikulėnas wrote:
> On Fri, Oct 17, 2014 at 7:29 AM, Josh Triplett  wrote:
> > This makes it possible to drop in logind configuration snippets from a
> > package or other configuration management mechanism.
> 
> I'm still very curious what packages would need to install drop-ins for 
> logind?

Configuration packages, metapackages, configuration management systems,
etc.

> > Introduce a new helper, conf_parse_many, to parse configuration files in
> > a search path.
> >
> > systemd now installs /usr/lib/systemd/logind.conf.d/50-default.conf
> > rather than /etc/systemd/logind.conf .  Distributions should migrate
> > existing modified versions of /etc/systemd/logind.conf to
> > /etc/systemd/logind.conf.d/50-default.conf .
> 
> Sounds like unnecessary shuffling things around...

It's the same process previously followed for /etc/modules moving to
/etc/modules-load.d, for instance.

> > For systemd, are "git format-patch -M" patches (with git-style renames
> > rather than whole-file deletion/insertions) acceptable for mailing list
> > review?  That format makes renames much easier to review.
> 
> I'm sure the patches are applied using `git am`, so that should work fine.

That was my hope as well.

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

[systemd-devel] Starting different services from same process

2014-10-17 Thread Paassen, Hiram van 
Hi,

We use systemd to manage some python processes in an embedded
environment (imx28 cpu). This works fantastic except for a fairly long
startup sequence due to python being slow during the initialization of
its standard libraries.

We found a possible solution inspired by
http://draketo.de/light/english/politics-and-free-software/reducing-python-startup-time

which basically means taking the startup overhead only once instead of x
times by starting a minimal python process which forks itself into
different programs.

However, I fail to see how this would play nice with systemd and its use
of cgroups.

We currently use type=dbus services so I expect that starting is not
really the problem but it would be annoying if systemd cannot stop one
service without killing them all since they are in the same cgroup

Is it possible to start multiple different services from one process?

With kind regards,

Hiram van Paassen



Power Products, LLC Email Notice

This message is intended only for the use of the Addressee and may contain 
information that is PRIVILEGED and/or CONFIDENTIAL.
This email is intended only for the personal and confidential use of the 
recipient(s) named above. If the reader of this email is not an intended 
recipient, you have received this email in error and any review, dissemination, 
distribution or copying is strictly prohibited.
If you have received this email in error, please notify the sender immediately 
by return mail and permanently delete the copy you received.

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