[systemd-devel] [ systemd-devel ] [PATCH] Fix Bug 72611 (systemctl is-enabled scales poorly with many units

[david]

From: Rami Rosen 

This patch fixes Bug 72611 (systemctl is-enabled scales poorly with many units)
by using a hashmap for enabled/disabled services instead. The hashmap is a 
member of the manager and is initialized by a new method, build_enabled_cache(),
which is called from the manager_startup() method.  
---
 Makefile.am   |   3 +-
 src/core/dbus-manager.c   |  54 ++--
 src/core/manager.c|   9 ++-
 src/core/manager.h|   1 +
 src/core/unit.c   |   2 +-
 src/shared/install.c  | 154 +-
 src/shared/install.h  |   6 +-
 src/systemctl/systemctl.c |   2 +-
 src/test/test-install.c   |  51 +--
 9 files changed, 235 insertions(+), 47 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 5d84605..fa294f1 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1520,7 +1520,8 @@ test_install_LDADD = \
libsystemd-units.la \
libsystemd-label.la \
libsystemd-shared.la \
-   libsystemd-internal.la
+   libsystemd-internal.la \
+   libsystemd-core.la
 
 test_watchdog_SOURCES = \
src/test/test-watchdog.c
diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
index 135d314..7f196dd 100644
--- a/src/core/dbus-manager.c
+++ b/src/core/dbus-manager.c
@@ -1298,7 +1298,6 @@ static int method_list_unit_files(sd_bus *bus, 
sd_bus_message *message, void *us
 _cleanup_bus_message_unref_ sd_bus_message *reply = NULL;
 Manager *m = userdata;
 UnitFileList *item;
-Hashmap *h;
 Iterator i;
 int r;
 
@@ -1314,27 +1313,17 @@ static int method_list_unit_files(sd_bus *bus, 
sd_bus_message *message, void *us
 if (r < 0)
 return r;
 
-h = hashmap_new(string_hash_func, string_compare_func);
-if (!h)
-return -ENOMEM;
-
-r = unit_file_get_list(m->running_as == SYSTEMD_SYSTEM ? 
UNIT_FILE_SYSTEM : UNIT_FILE_USER, NULL, h);
-if (r < 0)
-goto fail;
-
 r = sd_bus_message_open_container(reply, 'a', "(ss)");
 if (r < 0)
 goto fail;
 
-HASHMAP_FOREACH(item, h, i) {
+HASHMAP_FOREACH(item, m->enabled, i) {
 
 r = sd_bus_message_append(reply, "(ss)", item->path, 
unit_file_state_to_string(item->state));
 if (r < 0)
 goto fail;
 }
 
-unit_file_list_free(h);
-
 r = sd_bus_message_close_container(reply);
 if (r < 0)
 return r;
@@ -1342,7 +1331,6 @@ static int method_list_unit_files(sd_bus *bus, 
sd_bus_message *message, void *us
 return sd_bus_send(bus, reply, NULL);
 
 fail:
-unit_file_list_free(h);
 return r;
 }
 
@@ -1350,7 +1338,7 @@ static int method_get_unit_file_state(sd_bus *bus, 
sd_bus_message *message, void
 Manager *m = userdata;
 const char *name;
 UnitFileState state;
-UnitFileScope scope;
+UnitFileList *f;
 int r;
 
 assert(bus);
@@ -1365,12 +1353,11 @@ static int method_get_unit_file_state(sd_bus *bus, 
sd_bus_message *message, void
 if (r < 0)
 return r;
 
-scope = m->running_as == SYSTEMD_SYSTEM ? UNIT_FILE_SYSTEM : 
UNIT_FILE_USER;
-
-state = unit_file_get_state(scope, NULL, name);
-if (state < 0)
-return state;
-
+f = hashmap_get(m->enabled, name);
+if (f)
+state = f->state;
+else
+state = UNIT_FILE_INVALID;
 return sd_bus_reply_method_return(message, "s", 
unit_file_state_to_string(state));
 }
 
@@ -1480,6 +1467,7 @@ static int method_enable_unit_files_generic(
 unsigned n_changes = 0;
 UnitFileScope scope;
 int runtime, force, r;
+char **j;
 
 assert(bus);
 assert(message);
@@ -1501,6 +1489,22 @@ static int method_enable_unit_files_generic(
 }
 }
 #endif
+STRV_FOREACH(j, l) {
+UnitFileList *f;
+char *val = strdup(*j);
+
+f = hashmap_get(m->enabled, val);
+if (!f) {
+f = new0(UnitFileList, 1);
+f->path = val;
+}
+f->state = UNIT_FILE_ENABLED;
+r = hashmap_put(m->enabled, val, f);
+if (r < 0) {
+free(val);
+return r;
+}
+}
 
 r = sd_bus_message_read(message, "bb", &runtime, &force);
 if (r < 0)
@@ -1548,6 +1552,7 @@ static int method_disable_unit_files_generic(
 unsigned n_changes = 0;
 UnitFileScope scope;
 int r, runtime;
+char **j;
 
 assert(bus);
 assert(message);
@@ -1561,6 +1566,15 @@ static int method_disable_unit_files_generic(
 if (r < 0)
 return r;
 
+STRV_FOREACH(j, l

[systemd-devel] [PATCH] core: Filter by state behind the D-Bus API, not in the systemctl client.

[david]

From: David Strauss 

---
 src/core/dbus-manager.c| 24 +++-
 src/core/org.freedesktop.systemd1.conf |  4 
 src/systemctl/systemctl.c  | 24 +---
 3 files changed, 40 insertions(+), 12 deletions(-)

diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
index 135d314..febf475 100644
--- a/src/core/dbus-manager.c
+++ b/src/core/dbus-manager.c
@@ -728,7 +728,7 @@ static int method_reset_failed(sd_bus *bus, sd_bus_message 
*message, void *userd
 return sd_bus_reply_method_return(message, NULL);
 }
 
-static int method_list_units(sd_bus *bus, sd_bus_message *message, void 
*userdata, sd_bus_error *error) {
+static int list_units_filtered(sd_bus *bus, sd_bus_message *message, void 
*userdata, sd_bus_error *error, char **states) {
 _cleanup_bus_message_unref_ sd_bus_message *reply = NULL;
 Manager *m = userdata;
 const char *k;
@@ -761,6 +761,12 @@ static int method_list_units(sd_bus *bus, sd_bus_message 
*message, void *userdat
 
 following = unit_following(u);
 
+if (!strv_isempty(states) &&
+!strv_contains(states, 
unit_load_state_to_string(u->load_state)) &&
+!strv_contains(states, 
unit_active_state_to_string(unit_active_state(u))) &&
+!strv_contains(states, unit_sub_state_to_string(u)))
+continue;
+
 unit_path = unit_dbus_path(u);
 if (!unit_path)
 return -ENOMEM;
@@ -794,6 +800,21 @@ static int method_list_units(sd_bus *bus, sd_bus_message 
*message, void *userdat
 return sd_bus_send(bus, reply, NULL);
 }
 
+static int method_list_units(sd_bus *bus, sd_bus_message *message, void 
*userdata, sd_bus_error *error) {
+return list_units_filtered(bus, message, userdata, error, NULL);
+}
+
+static int method_list_units_filtered(sd_bus *bus, sd_bus_message *message, 
void *userdata, sd_bus_error *error) {
+_cleanup_strv_free_ char **states = NULL;
+int r;
+
+r = sd_bus_message_read_strv(message, &states);
+if (r < 0)
+return r;
+
+return list_units_filtered(bus, message, userdata, error, states);
+}
+
 static int method_list_jobs(sd_bus *bus, sd_bus_message *message, void 
*userdata, sd_bus_error *error) {
 _cleanup_bus_message_unref_ sd_bus_message *reply = NULL;
 Manager *m = userdata;
@@ -1670,6 +1691,7 @@ const sd_bus_vtable bus_manager_vtable[] = {
 SD_BUS_METHOD("ClearJobs", NULL, NULL, method_clear_jobs, 0),
 SD_BUS_METHOD("ResetFailed", NULL, NULL, method_reset_failed, 0),
 SD_BUS_METHOD("ListUnits", NULL, "a(ssouso)", method_list_units, 
SD_BUS_VTABLE_UNPRIVILEGED),
+SD_BUS_METHOD("ListUnitsFiltered", "as", "a(ssouso)", 
method_list_units_filtered, SD_BUS_VTABLE_UNPRIVILEGED),
 SD_BUS_METHOD("ListJobs", NULL, "a(usssoo)", method_list_jobs, 
SD_BUS_VTABLE_UNPRIVILEGED),
 SD_BUS_METHOD("Subscribe", NULL, NULL, method_subscribe, 
SD_BUS_VTABLE_UNPRIVILEGED),
 SD_BUS_METHOD("Unsubscribe", NULL, NULL, method_unsubscribe, 
SD_BUS_VTABLE_UNPRIVILEGED),
diff --git a/src/core/org.freedesktop.systemd1.conf 
b/src/core/org.freedesktop.systemd1.conf
index a375dce..9dfca81 100644
--- a/src/core/org.freedesktop.systemd1.conf
+++ b/src/core/org.freedesktop.systemd1.conf
@@ -64,6 +64,10 @@
 
 
+
+
 
 load_state) ||
-strv_contains(arg_states, u->sub_state) ||
-strv_contains(arg_states, u->active_state);
-
 if (!strv_isempty(patterns)) {
 char **pattern;
 
@@ -513,6 +507,7 @@ static int get_unit_list(
 int c,
 sd_bus_message **_reply) {
 
+_cleanup_bus_message_unref_ sd_bus_message *m = NULL;
 _cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
 _cleanup_bus_message_unref_ sd_bus_message *reply = NULL;
 size_t size = c;
@@ -523,15 +518,22 @@ static int get_unit_list(
 assert(unit_infos);
 assert(_reply);
 
-r = sd_bus_call_method(
+r = sd_bus_message_new_method_call(
 bus,
+&m,
 "org.freedesktop.systemd1",
 "/org/freedesktop/systemd1",
 "org.freedesktop.systemd1.Manager",
-"ListUnits",
-&error,
-&reply,
-NULL);
+"ListUnitsFiltered");
+
+if (r < 0)
+return bus_log_create_error(r);
+
+r = 

[systemd-devel] [PATCH] Add sabridge for socket activation of traditional daemons.

[david]

From: David Strauss 

---
 .gitignore  |  1 +
 Makefile-man.am |  1 +
 Makefile.am | 20 +++-
 3 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/.gitignore b/.gitignore
index 5e63b2a..d2d5da5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -71,6 +71,7 @@
 /systemd-reply-password
 /systemd-rfkill
 /systemd-run
+/systemd-sabridge
 /systemd-shutdown
 /systemd-shutdownd
 /systemd-sleep
diff --git a/Makefile-man.am b/Makefile-man.am
index 6c9b790..e78a8a2 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -66,6 +66,7 @@ MANPAGES += \
man/systemd-nspawn.1 \
man/systemd-remount-fs.service.8 \
man/systemd-run.1 \
+   man/systemd-sabridge.1 \
man/systemd-shutdownd.service.8 \
man/systemd-sleep.conf.5 \
man/systemd-suspend.service.8 \
diff --git a/Makefile.am b/Makefile.am
index 6601244..ce740ef 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5,6 +5,7 @@
 #  Copyright 2010-2012 Lennart Poettering
 #  Copyright 2010-2012 Kay Sievers
 #  Copyright 2013 Zbigniew Jędrzejewski-Szmek
+#  Copyright 2013 David Strauss
 #
 #  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
@@ -298,7 +299,8 @@ bin_PROGRAMS = \
systemd-detect-virt \
systemd-delta \
systemd-analyze \
-   systemd-run
+   systemd-run \
+   systemd-sabridge
 
 dist_bin_SCRIPTS = \
src/kernel-install/kernel-install
@@ -3213,6 +3215,22 @@ EXTRA_DIST += \
units/systemd-journal-gatewayd.service.in
 
 # 
--
+
+systemd_sabridge_SOURCES = \
+   src/sabridge/sabridge.c
+
+systemd_sabridge_LDADD = \
+   libsystemd-shared.la \
+   libsystemd-logs.la \
+   libsystemd-journal-internal.la \
+   libsystemd-id128-internal.la \
+   libsystemd-daemon.la \
+   libsystemd-bus.la
+
+systemd_sabridge_CFLAGS = \
+   $(AM_CFLAGS)
+
+# 
--
 if ENABLE_COREDUMP
 systemd_coredump_SOURCES = \
src/journal/coredump.c
-- 
1.8.3.1

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

[systemd-devel] [PATCH] Add sabridge for socket activation of traditional daemons

[david]

From: David Strauss 

---
 .gitignore   |   1 +
 Makefile-man.am  |   1 +
 Makefile.am  |  20 +-
 man/systemd-sabridge.xml | 264 
 src/sabridge/Makefile|  28 +++
 src/sabridge/sabridge.c  | 519 +++
 6 files changed, 832 insertions(+), 1 deletion(-)
 create mode 100644 man/systemd-sabridge.xml
 create mode 100644 src/sabridge/Makefile
 create mode 100644 src/sabridge/sabridge.c

diff --git a/.gitignore b/.gitignore
index 5e63b2a..d2d5da5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -71,6 +71,7 @@
 /systemd-reply-password
 /systemd-rfkill
 /systemd-run
+/systemd-sabridge
 /systemd-shutdown
 /systemd-shutdownd
 /systemd-sleep
diff --git a/Makefile-man.am b/Makefile-man.am
index 6c9b790..e78a8a2 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -66,6 +66,7 @@ MANPAGES += \
man/systemd-nspawn.1 \
man/systemd-remount-fs.service.8 \
man/systemd-run.1 \
+   man/systemd-sabridge.1 \
man/systemd-shutdownd.service.8 \
man/systemd-sleep.conf.5 \
man/systemd-suspend.service.8 \
diff --git a/Makefile.am b/Makefile.am
index 6601244..ce740ef 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5,6 +5,7 @@
 #  Copyright 2010-2012 Lennart Poettering
 #  Copyright 2010-2012 Kay Sievers
 #  Copyright 2013 Zbigniew Jędrzejewski-Szmek
+#  Copyright 2013 David Strauss
 #
 #  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
@@ -298,7 +299,8 @@ bin_PROGRAMS = \
systemd-detect-virt \
systemd-delta \
systemd-analyze \
-   systemd-run
+   systemd-run \
+   systemd-sabridge
 
 dist_bin_SCRIPTS = \
src/kernel-install/kernel-install
@@ -3213,6 +3215,22 @@ EXTRA_DIST += \
units/systemd-journal-gatewayd.service.in
 
 # 
--
+
+systemd_sabridge_SOURCES = \
+   src/sabridge/sabridge.c
+
+systemd_sabridge_LDADD = \
+   libsystemd-shared.la \
+   libsystemd-logs.la \
+   libsystemd-journal-internal.la \
+   libsystemd-id128-internal.la \
+   libsystemd-daemon.la \
+   libsystemd-bus.la
+
+systemd_sabridge_CFLAGS = \
+   $(AM_CFLAGS)
+
+# 
--
 if ENABLE_COREDUMP
 systemd_coredump_SOURCES = \
src/journal/coredump.c
diff --git a/man/systemd-sabridge.xml b/man/systemd-sabridge.xml
new file mode 100644
index 000..d7afb0e
--- /dev/null
+++ b/man/systemd-sabridge.xml
@@ -0,0 +1,264 @@
+
+
+http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";>
+
+
+
+systemd-sabridge
+systemd
+
+
+Developer
+    David
+Strauss
+da...@davidstrauss.net
+
+
+
+
+systemd-sabridge
+1
+
+
+systemd-sabridge
+Inherit a socket. Bidirectionally
+proxy.
+
+
+
+systemd-sabridge
+OPTIONS
+HOSTNAME-OR-IP
+PORT-OR-SERVICE
+
+
+systemd-sabridge
+OPTIONS
+UNIX-DOMAIN-SOCKET-PATH
+
+
+
+
+Description
+
+systemd-sabridgeprovides a proxy
+to socket-activate services that do not yet support
+native socket activation. On behalf of the daemon,
+the proxy inherits the socket from systemd, accept
+each client connection, opens a server connection
+for each client, and then bidirectionally forwards
+data between the two.
+This utility's behavior is similar to
+socat
+1 . The main
+differences for systemd-sabridge are
+support for socket activation with
+Accept=false and an event-driven
+design that scales better with the number of
+connections.
+
+
+Options
+The following options are understood:
+
+
+
+-h
+
+
+--help
+
+
+Prints

[systemd-devel] [PATCH] Add sabridge for socket activation of traditional daemons

[david]

From: David Strauss 

---
 .gitignore   |   1 +
 Makefile-man.am  |   1 +
 Makefile.am  |  20 +-
 man/systemd-sabridge.xml | 254 ++
 src/sabridge/Makefile|  28 +++
 src/sabridge/sabridge.c  | 534 +++
 6 files changed, 837 insertions(+), 1 deletion(-)
 create mode 100644 man/systemd-sabridge.xml
 create mode 100644 src/sabridge/Makefile
 create mode 100644 src/sabridge/sabridge.c

diff --git a/.gitignore b/.gitignore
index 5e63b2a..d2d5da5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -71,6 +71,7 @@
 /systemd-reply-password
 /systemd-rfkill
 /systemd-run
+/systemd-sabridge
 /systemd-shutdown
 /systemd-shutdownd
 /systemd-sleep
diff --git a/Makefile-man.am b/Makefile-man.am
index 6c9b790..e78a8a2 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -66,6 +66,7 @@ MANPAGES += \
man/systemd-nspawn.1 \
man/systemd-remount-fs.service.8 \
man/systemd-run.1 \
+   man/systemd-sabridge.1 \
man/systemd-shutdownd.service.8 \
man/systemd-sleep.conf.5 \
man/systemd-suspend.service.8 \
diff --git a/Makefile.am b/Makefile.am
index 7ae6a1a..2877184 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5,6 +5,7 @@
 #  Copyright 2010-2012 Lennart Poettering
 #  Copyright 2010-2012 Kay Sievers
 #  Copyright 2013 Zbigniew Jędrzejewski-Szmek
+#  Copyright 2013 David Strauss
 #
 #  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
@@ -298,7 +299,8 @@ bin_PROGRAMS = \
systemd-detect-virt \
systemd-delta \
systemd-analyze \
-   systemd-run
+   systemd-run \
+   systemd-sabridge
 
 dist_bin_SCRIPTS = \
src/kernel-install/kernel-install
@@ -3207,6 +3209,22 @@ EXTRA_DIST += \
units/systemd-journal-gatewayd.service.in
 
 # 
--
+
+systemd_sabridge_SOURCES = \
+   src/sabridge/sabridge.c
+
+systemd_sabridge_LDADD = \
+   libsystemd-shared.la \
+   libsystemd-logs.la \
+   libsystemd-journal-internal.la \
+   libsystemd-id128-internal.la \
+   libsystemd-daemon.la \
+   libsystemd-bus.la
+
+systemd_sabridge_CFLAGS = \
+   $(AM_CFLAGS)
+
+# 
--
 if ENABLE_COREDUMP
 systemd_coredump_SOURCES = \
src/journal/coredump.c
diff --git a/man/systemd-sabridge.xml b/man/systemd-sabridge.xml
new file mode 100644
index 000..abeb1a5
--- /dev/null
+++ b/man/systemd-sabridge.xml
@@ -0,0 +1,254 @@
+
+
+http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";>
+
+
+
+systemd-sabridge
+systemd
+
+
+Developer
+    David
+Strauss
+da...@davidstrauss.net
+
+
+
+
+systemd-sabridge
+1
+
+
+systemd-sabridge
+Inherit a socket. Bidirectionally
+proxy.
+
+
+
+systemd-sabridge
+OPTIONS
+HOSTNAME-OR-IP
+PORT-OR-SERVICE
+
+
+systemd-sabridge
+OPTIONS
+UNIX-DOMAIN-SOCKET-PATH
+
+
+
+
+Description
+
+systemd-sabridgeprovides a proxy
+to socket-activate services that do not yet support
+native socket activation. On behalf of the daemon,
+the proxy inherits the socket from systemd, accepts
+each client connection, opens a connection to the server
+for each client, and then bidirectionally forwards
+data between the two.
+This utility's behavior is similar to
+
socat1 
.
+The main differences for systemd-sabridge
+are support for socket activation with
+Accept=false and an event-driven
+design that scales better with the number of
+connections.
+
+
+Options
+The following options are understood:
+
+
+-h
+--help
+
+Prints a short help
+t

[systemd-devel] [PATCH v4] Add sabridge for socket activation of traditional daemons

[david]

From: David Strauss 

---
 .gitignore   |   1 +
 Makefile-man.am  |   1 +
 Makefile.am  |  20 +-
 man/systemd-sabridge.xml | 254 ++
 src/sabridge/Makefile|  28 +++
 src/sabridge/sabridge.c  | 551 +++
 6 files changed, 854 insertions(+), 1 deletion(-)
 create mode 100644 man/systemd-sabridge.xml
 create mode 100644 src/sabridge/Makefile
 create mode 100644 src/sabridge/sabridge.c

diff --git a/.gitignore b/.gitignore
index 5e63b2a..d2d5da5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -71,6 +71,7 @@
 /systemd-reply-password
 /systemd-rfkill
 /systemd-run
+/systemd-sabridge
 /systemd-shutdown
 /systemd-shutdownd
 /systemd-sleep
diff --git a/Makefile-man.am b/Makefile-man.am
index 6c9b790..e78a8a2 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -66,6 +66,7 @@ MANPAGES += \
man/systemd-nspawn.1 \
man/systemd-remount-fs.service.8 \
man/systemd-run.1 \
+   man/systemd-sabridge.1 \
man/systemd-shutdownd.service.8 \
man/systemd-sleep.conf.5 \
man/systemd-suspend.service.8 \
diff --git a/Makefile.am b/Makefile.am
index 7ae6a1a..2877184 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5,6 +5,7 @@
 #  Copyright 2010-2012 Lennart Poettering
 #  Copyright 2010-2012 Kay Sievers
 #  Copyright 2013 Zbigniew Jędrzejewski-Szmek
+#  Copyright 2013 David Strauss
 #
 #  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
@@ -298,7 +299,8 @@ bin_PROGRAMS = \
systemd-detect-virt \
systemd-delta \
systemd-analyze \
-   systemd-run
+   systemd-run \
+   systemd-sabridge
 
 dist_bin_SCRIPTS = \
src/kernel-install/kernel-install
@@ -3207,6 +3209,22 @@ EXTRA_DIST += \
units/systemd-journal-gatewayd.service.in
 
 # 
--
+
+systemd_sabridge_SOURCES = \
+   src/sabridge/sabridge.c
+
+systemd_sabridge_LDADD = \
+   libsystemd-shared.la \
+   libsystemd-logs.la \
+   libsystemd-journal-internal.la \
+   libsystemd-id128-internal.la \
+   libsystemd-daemon.la \
+   libsystemd-bus.la
+
+systemd_sabridge_CFLAGS = \
+   $(AM_CFLAGS)
+
+# 
--
 if ENABLE_COREDUMP
 systemd_coredump_SOURCES = \
src/journal/coredump.c
diff --git a/man/systemd-sabridge.xml b/man/systemd-sabridge.xml
new file mode 100644
index 000..abeb1a5
--- /dev/null
+++ b/man/systemd-sabridge.xml
@@ -0,0 +1,254 @@
+
+
+http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";>
+
+
+
+systemd-sabridge
+systemd
+
+
+Developer
+    David
+Strauss
+da...@davidstrauss.net
+
+
+
+
+systemd-sabridge
+1
+
+
+systemd-sabridge
+Inherit a socket. Bidirectionally
+proxy.
+
+
+
+systemd-sabridge
+OPTIONS
+HOSTNAME-OR-IP
+PORT-OR-SERVICE
+
+
+systemd-sabridge
+OPTIONS
+UNIX-DOMAIN-SOCKET-PATH
+
+
+
+
+Description
+
+systemd-sabridgeprovides a proxy
+to socket-activate services that do not yet support
+native socket activation. On behalf of the daemon,
+the proxy inherits the socket from systemd, accepts
+each client connection, opens a connection to the server
+for each client, and then bidirectionally forwards
+data between the two.
+This utility's behavior is similar to
+
socat1 
.
+The main differences for systemd-sabridge
+are support for socket activation with
+Accept=false and an event-driven
+design that scales better with the number of
+connections.
+
+
+Options
+The following options are understood:
+
+
+-h
+--help
+
+Prints a short help
+t

[systemd-devel] [PATCH v5] Add sabridge for socket activation of traditional daemons

[david]

From: David Strauss 

---
 .gitignore   |   1 +
 Makefile-man.am  |   1 +
 Makefile.am  |  20 +-
 man/systemd-sabridge.xml | 254 +
 src/sabridge/Makefile|  28 +++
 src/sabridge/sabridge.c  | 575 +++
 6 files changed, 878 insertions(+), 1 deletion(-)
 create mode 100644 man/systemd-sabridge.xml
 create mode 100644 src/sabridge/Makefile
 create mode 100644 src/sabridge/sabridge.c

diff --git a/.gitignore b/.gitignore
index 5e63b2a..d2d5da5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -71,6 +71,7 @@
 /systemd-reply-password
 /systemd-rfkill
 /systemd-run
+/systemd-sabridge
 /systemd-shutdown
 /systemd-shutdownd
 /systemd-sleep
diff --git a/Makefile-man.am b/Makefile-man.am
index 6c9b790..e78a8a2 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -66,6 +66,7 @@ MANPAGES += \
man/systemd-nspawn.1 \
man/systemd-remount-fs.service.8 \
man/systemd-run.1 \
+   man/systemd-sabridge.1 \
man/systemd-shutdownd.service.8 \
man/systemd-sleep.conf.5 \
man/systemd-suspend.service.8 \
diff --git a/Makefile.am b/Makefile.am
index 7ae6a1a..2877184 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5,6 +5,7 @@
 #  Copyright 2010-2012 Lennart Poettering
 #  Copyright 2010-2012 Kay Sievers
 #  Copyright 2013 Zbigniew Jędrzejewski-Szmek
+#  Copyright 2013 David Strauss
 #
 #  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
@@ -298,7 +299,8 @@ bin_PROGRAMS = \
systemd-detect-virt \
systemd-delta \
systemd-analyze \
-   systemd-run
+   systemd-run \
+   systemd-sabridge
 
 dist_bin_SCRIPTS = \
src/kernel-install/kernel-install
@@ -3207,6 +3209,22 @@ EXTRA_DIST += \
units/systemd-journal-gatewayd.service.in
 
 # 
--
+
+systemd_sabridge_SOURCES = \
+   src/sabridge/sabridge.c
+
+systemd_sabridge_LDADD = \
+   libsystemd-shared.la \
+   libsystemd-logs.la \
+   libsystemd-journal-internal.la \
+   libsystemd-id128-internal.la \
+   libsystemd-daemon.la \
+   libsystemd-bus.la
+
+systemd_sabridge_CFLAGS = \
+   $(AM_CFLAGS)
+
+# 
--
 if ENABLE_COREDUMP
 systemd_coredump_SOURCES = \
src/journal/coredump.c
diff --git a/man/systemd-sabridge.xml b/man/systemd-sabridge.xml
new file mode 100644
index 000..abeb1a5
--- /dev/null
+++ b/man/systemd-sabridge.xml
@@ -0,0 +1,254 @@
+
+
+http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";>
+
+
+
+systemd-sabridge
+systemd
+
+
+Developer
+    David
+Strauss
+da...@davidstrauss.net
+
+
+
+
+systemd-sabridge
+1
+
+
+systemd-sabridge
+Inherit a socket. Bidirectionally
+proxy.
+
+
+
+systemd-sabridge
+OPTIONS
+HOSTNAME-OR-IP
+PORT-OR-SERVICE
+
+
+systemd-sabridge
+OPTIONS
+UNIX-DOMAIN-SOCKET-PATH
+
+
+
+
+Description
+
+systemd-sabridgeprovides a proxy
+to socket-activate services that do not yet support
+native socket activation. On behalf of the daemon,
+the proxy inherits the socket from systemd, accepts
+each client connection, opens a connection to the server
+for each client, and then bidirectionally forwards
+data between the two.
+This utility's behavior is similar to
+
socat1 
.
+The main differences for systemd-sabridge
+are support for socket activation with
+Accept=false and an event-driven
+design that scales better with the number of
+connections.
+
+
+Options
+The following options are understood:
+
+
+-h
+--help
+
+Prints a short help
+t

[systemd-devel] [PATCH] Experimental socket process pool.

[david]

From: David Strauss 

---
 .gitignore |   1 +
 Makefile.am|  13 ++
 src/socket-process-pool/Makefile   |   1 +
 src/socket-process-pool/socket-process-poold.c | 247 +
 src/socket-proxy/socket-proxyd.c   |   3 +-
 5 files changed, 264 insertions(+), 1 deletion(-)
 create mode 12 src/socket-process-pool/Makefile
 create mode 100644 src/socket-process-pool/socket-process-poold.c

diff --git a/.gitignore b/.gitignore
index 6253e0d..d3ab8bb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -67,6 +67,7 @@
 /systemd-reply-password
 /systemd-rfkill
 /systemd-run
+/systemd-socket-process-poold
 /systemd-socket-proxyd
 /systemd-shutdown
 /systemd-shutdownd
diff --git a/Makefile.am b/Makefile.am
index 379e878..41e7012 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -319,6 +319,7 @@ rootlibexec_PROGRAMS = \
systemd-ac-power \
systemd-sysctl \
systemd-sleep \
+   systemd-socket-process-poold \
systemd-socket-proxyd
 
 systemgenerator_PROGRAMS = \
@@ -3146,6 +3147,18 @@ EXTRA_DIST += \
 
 # 
--
 
+systemd_socket_process_poold_SOURCES = \
+   src/socket-process-pool/socket-process-poold.c
+
+systemd_socket_process_poold_LDADD = \
+   libsystemd-shared.la \
+   libsystemd-logs.la \
+   libsystemd-journal-internal.la \
+   libsystemd-id128-internal.la \
+   libsystemd-daemon.la
+
+# 
--
+
 systemd_socket_proxyd_SOURCES = \
src/socket-proxy/socket-proxyd.c
 
diff --git a/src/socket-process-pool/Makefile b/src/socket-process-pool/Makefile
new file mode 12
index 000..d0b0e8e
--- /dev/null
+++ b/src/socket-process-pool/Makefile
@@ -0,0 +1 @@
+../Makefile
\ No newline at end of file
diff --git a/src/socket-process-pool/socket-process-poold.c 
b/src/socket-process-pool/socket-process-poold.c
new file mode 100644
index 000..57c1210
--- /dev/null
+++ b/src/socket-process-pool/socket-process-poold.c
@@ -0,0 +1,247 @@
+/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
+
+/***
+  This file is part of systemd.
+
+  Copyright 2013 David Strauss
+
+  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 <http://www.gnu.org/licenses/>.
+ ***/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sd-daemon.h"
+#include "log.h"
+#include "util.h"
+#include "env-util.h"
+#include "strv.h"
+
+struct pool {
+int start_listen_fd;
+size_t num_listen_fds;
+bool ignore_env;
+size_t num_cores;
+size_t procs_per_core;
+char *path;
+char **argp;
+char **envp;
+};
+
+static int help(void) {
+
+printf("%s [OPTIONS]... EXECUTABLE-PATH [ARGS-FOR-EXECUTABLE]...\n"
+   "Distribute an inherited socket to a process pool.\n\n"
+   "  -h --helpShow this help\n"
+   "  --versionPrint version and exit\n"
+   /*"  --num-procs=NUM  Run an explicit number of processes\n"*/,
+   program_invocation_short_name);
+
+return 0;
+}
+
+static void version(void) {
+puts(PACKAGE_STRING " socket-process-poold");
+}
+
+static int parse_argv(int argc, char *argv[], struct pool *p) {
+
+enum {
+ARG_VERSION = 0x100
+};
+
+static const struct option options[] = {
+{ "help",   no_argument, NULL, 'h'   },
+{ "version",no_argument, NULL, ARG_VERSION   },
+{ NULL, 0,   NULL, 0 }
+};
+
+int c;
+
+assert(argc >= 0);
+assert(argv);
+
+while ((c = getopt_long(argc, argv, "h", options, NULL)) >= 0) {
+
+switch (c) {
+
+case 'h':
+help();
+return 0;
+
+case '?':
+return -EINVAL;
+
+case ARG_VERSION:
+version();
+return 0;
+
+default:
+   

[systemd-devel] [PATCH] Cache aggregated cgroup mask data at the slice level.

[david]

From: David Strauss 

---
 src/core/cgroup.c | 20 +++-
 src/core/cgroup.h |  2 ++
 src/core/unit.c   |  2 ++
 3 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/src/core/cgroup.c b/src/core/cgroup.c
index 6a6c504..b75ab55 100644
--- a/src/core/cgroup.c
+++ b/src/core/cgroup.c
@@ -345,6 +345,14 @@ static CGroupControllerMask unit_get_cgroup_mask(Unit *u) {
 return cgroup_context_get_mask(c);
 }
 
+void unit_update_parent_slice_mask(Unit *u) {
+if (UNIT_ISSET(u->slice)) {
+UNIT_DEREF(u->slice)->cgroup_mask |= unit_get_cgroup_mask(u);
+log_warning("Setting slice to mask: %x", 
unit_get_cgroup_mask(u));
+}
+log_warning("No slice to update.");
+}
+
 static CGroupControllerMask unit_get_members_mask(Unit *u) {
 CGroupControllerMask mask = 0;
 Unit *m;
@@ -425,12 +433,22 @@ static int unit_realize_cgroup_now(Unit *u) {
 
 assert(u);
 
+log_warning("unit_realize_cgroup_now");
+
 if (u->in_cgroup_queue) {
 LIST_REMOVE(cgroup_queue, u->manager->cgroup_queue, u);
 u->in_cgroup_queue = false;
 }
 
-mask = unit_get_cgroup_mask(u) | unit_get_members_mask(u) | 
unit_get_siblings_mask(u);
+/* If the unit is a member of a slice, the slice will contain
+ * aggregated cgroup mask data for the unit and all siblings. */
+if (UNIT_ISSET(u->slice)) {
+mask = UNIT_DEREF(u->slice)->cgroup_mask;
+log_warning("Using cgroup_mask.");
+} else {
+mask = unit_get_cgroup_mask(u) | unit_get_members_mask(u) | 
unit_get_siblings_mask(u);
+log_warning("Not using cgroup_mask.");
+}
 mask &= u->manager->cgroup_supported;
 
 if (u->cgroup_realized &&
diff --git a/src/core/cgroup.h b/src/core/cgroup.h
index 0a079e9..1a24d07 100644
--- a/src/core/cgroup.h
+++ b/src/core/cgroup.h
@@ -113,3 +113,5 @@ int manager_notify_cgroup_empty(Manager *m, const char 
*group);
 
 const char* cgroup_device_policy_to_string(CGroupDevicePolicy i) _const_;
 CGroupDevicePolicy cgroup_device_policy_from_string(const char *s) _pure_;
+
+void unit_update_parent_slice_mask(Unit *u);
diff --git a/src/core/unit.c b/src/core/unit.c
index e19d281..a018dad 100644
--- a/src/core/unit.c
+++ b/src/core/unit.c
@@ -981,6 +981,8 @@ int unit_load(Unit *u) {
 goto fail;
 }
 
+unit_update_parent_slice_mask(u);
+
 r = unit_add_mount_links(u);
 if (r < 0)
 goto fail;
-- 
1.8.3.1

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

[systemd-devel] [PATCHv2] Cache aggregated cgroup mask data at the slice level.

[david]

From: David Strauss 

---
 src/core/cgroup.c | 7 ++-
 src/core/cgroup.h | 2 ++
 src/core/unit.c   | 2 ++
 src/core/unit.h   | 1 +
 4 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/src/core/cgroup.c b/src/core/cgroup.c
index 6a6c504..81255ea 100644
--- a/src/core/cgroup.c
+++ b/src/core/cgroup.c
@@ -345,6 +345,11 @@ static CGroupControllerMask unit_get_cgroup_mask(Unit *u) {
 return cgroup_context_get_mask(c);
 }
 
+void unit_update_parent_slice_mask(Unit *u) {
+if (UNIT_ISSET(u->slice))
+UNIT_DEREF(u->slice)->cgroup_children_mask |= 
unit_get_cgroup_mask(u);
+}
+
 static CGroupControllerMask unit_get_members_mask(Unit *u) {
 CGroupControllerMask mask = 0;
 Unit *m;
@@ -371,7 +376,7 @@ static CGroupControllerMask unit_get_siblings_mask(Unit *u) 
{
 
 /* Sibling propagation is only relevant for weight-based
  * controllers, so let's mask out everything else */
-return unit_get_members_mask(UNIT_DEREF(u->slice)) &
+return UNIT_DEREF(u->slice)->cgroup_children_mask &
 (CGROUP_CPU|CGROUP_BLKIO|CGROUP_CPUACCT);
 }
 
diff --git a/src/core/cgroup.h b/src/core/cgroup.h
index 0a079e9..1a24d07 100644
--- a/src/core/cgroup.h
+++ b/src/core/cgroup.h
@@ -113,3 +113,5 @@ int manager_notify_cgroup_empty(Manager *m, const char 
*group);
 
 const char* cgroup_device_policy_to_string(CGroupDevicePolicy i) _const_;
 CGroupDevicePolicy cgroup_device_policy_from_string(const char *s) _pure_;
+
+void unit_update_parent_slice_mask(Unit *u);
diff --git a/src/core/unit.c b/src/core/unit.c
index e19d281..a018dad 100644
--- a/src/core/unit.c
+++ b/src/core/unit.c
@@ -981,6 +981,8 @@ int unit_load(Unit *u) {
 goto fail;
 }
 
+unit_update_parent_slice_mask(u);
+
 r = unit_add_mount_links(u);
 if (r < 0)
 goto fail;
diff --git a/src/core/unit.h b/src/core/unit.h
index 6971048..1a3f21d 100644
--- a/src/core/unit.h
+++ b/src/core/unit.h
@@ -174,6 +174,7 @@ struct Unit {
 /* Counterparts in the cgroup filesystem */
 char *cgroup_path;
 CGroupControllerMask cgroup_mask;
+CGroupControllerMask cgroup_children_mask;
 
 UnitRef slice;
 
-- 
1.8.3.1

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

[systemd-devel] [PATCH] cgroups: Cache controller masks and optimize queues.

[david]

From: David Strauss 

---
 .gitignore  |  1 +
 Makefile.am | 13 +++
 src/core/cgroup.c   | 94 +++--
 src/core/cgroup.h   |  2 +
 src/core/unit.c |  8 +++-
 src/core/unit.h |  1 +
 src/test/test-cgroup-mask.c | 83 +++
 test/daughter.service   |  7 
 test/parent.slice   |  5 +++
 test/son.service|  8 
 10 files changed, 192 insertions(+), 30 deletions(-)
 create mode 100644 src/test/test-cgroup-mask.c
 create mode 100644 test/daughter.service
 create mode 100644 test/parent.slice
 create mode 100644 test/son.service

diff --git a/.gitignore b/.gitignore
index 458cea5..20edf32 100644
--- a/.gitignore
+++ b/.gitignore
@@ -104,6 +104,7 @@
 /test-calendarspec
 /test-catalog
 /test-cgroup
+/test-cgroup-mask
 /test-cgroup-util
 /test-daemon
 /test-date
diff --git a/Makefile.am b/Makefile.am
index 82e46a9..df3e810 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1139,6 +1139,7 @@ tests += \
test-calendarspec \
test-strip-tab-ansi \
test-cgroup-util \
+   test-cgroup-mask \
test-prioq \
test-fileio \
test-time \
@@ -1358,6 +1359,18 @@ test_cgroup_LDADD = \
libsystemd-label.la \
libsystemd-shared.la
 
+test_cgroup_mask_SOURCES = \
+   src/test/test-cgroup-mask.c
+
+test_cgroup_mask_CFLAGS = \
+   $(AM_CFLAGS) \
+   $(DBUS_CFLAGS) \
+   -D"STR(s)=\#s" -D"TEST_DIR=STR($(abs_top_srcdir)/test/)"
+
+test_cgroup_mask_LDADD = \
+   libsystemd-core.la \
+   $(RT_LIBS)
+
 test_cgroup_util_SOURCES = \
src/test/test-cgroup-util.c
 
diff --git a/src/core/cgroup.c b/src/core/cgroup.c
index 1a8fd37..c2b1b7d 100644
--- a/src/core/cgroup.c
+++ b/src/core/cgroup.c
@@ -346,21 +346,8 @@ static CGroupControllerMask unit_get_cgroup_mask(Unit *u) {
 }
 
 static CGroupControllerMask unit_get_members_mask(Unit *u) {
-CGroupControllerMask mask = 0;
-Unit *m;
-Iterator i;
-
 assert(u);
-
-SET_FOREACH(m, u->dependencies[UNIT_BEFORE], i) {
-
-if (UNIT_DEREF(m->slice) != u)
-continue;
-
-mask |= unit_get_cgroup_mask(m) | unit_get_members_mask(m);
-}
-
-return mask;
+return u->cgroup_members_mask;
 }
 
 static CGroupControllerMask unit_get_siblings_mask(Unit *u) {
@@ -375,6 +362,26 @@ static CGroupControllerMask unit_get_siblings_mask(Unit 
*u) {
 (CGROUP_CPU|CGROUP_BLKIO|CGROUP_CPUACCT);
 }
 
+static CGroupControllerMask unit_get_target_mask(Unit *u) {
+CGroupControllerMask mask;
+
+mask = unit_get_cgroup_mask(u) | unit_get_members_mask(u) | 
unit_get_siblings_mask(u);
+mask &= u->manager->cgroup_supported;
+
+return mask;
+}
+
+/* Recurse from a unit up through its containing slices, propagating
+ * mask bits upward. A unit is also member of itself. */
+void unit_update_member_masks(Unit *u) {
+u->cgroup_members_mask |= unit_get_cgroup_mask(u);
+if (UNIT_ISSET(u->slice)) {
+Unit *s = UNIT_DEREF(u->slice);
+s->cgroup_members_mask |= u->cgroup_members_mask;
+unit_update_member_masks(s);
+}
+}
+
 static int unit_create_cgroups(Unit *u, CGroupControllerMask mask) {
 _cleanup_free_ char *path;
 int r;
@@ -422,8 +429,19 @@ static int unit_create_cgroups(Unit *u, 
CGroupControllerMask mask) {
 return 0;
 }
 
+static bool unit_has_mask_realized(Unit *u, CGroupControllerMask mask) {
+return u->cgroup_realized && u->cgroup_mask == mask;
+}
+
+/* Check if necessary controllers and attributes for a unit are in place.
+ *
+ * If so, do nothing.
+ * If not, create paths, move processes over, and set attributes.
+ *
+ * Returns 0 on success and < 0 on failure. */
 static int unit_realize_cgroup_now(Unit *u) {
 CGroupControllerMask mask;
+int r;
 
 assert(u);
 
@@ -432,19 +450,28 @@ static int unit_realize_cgroup_now(Unit *u) {
 u->in_cgroup_queue = false;
 }
 
-mask = unit_get_cgroup_mask(u) | unit_get_members_mask(u) | 
unit_get_siblings_mask(u);
-mask &= u->manager->cgroup_supported;
+mask = unit_get_target_mask(u);
 
-if (u->cgroup_realized &&
-u->cgroup_mask == mask)
+/* TODO: Consider skipping this check. It may be redundant. */
+if (unit_has_mask_realized(u, mask))
 return 0;
 
 /* First, realize parents */
-if (UNIT_ISSET(u->slice))
-unit_realize_cgroup_now(UNIT_DEREF(u->slice));
+if (UNIT_ISSET(u->slice)) {
+r = unit_realize_cgroup_now(UNIT_DEREF(u->slice));
+if (r < 0)
+return 

[systemd-devel] [PATCH] install: Assume *.wants symlinks have the same name as their target for scalability.

[david]

From: David Strauss 

---
 src/shared/install.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/shared/install.c b/src/shared/install.c
index 17e8a75..14c0f4b 100644
--- a/src/shared/install.c
+++ b/src/shared/install.c
@@ -423,6 +423,11 @@ static int find_symlinks_fd(
 bool found_path, found_dest, b = false;
 int q;
 
+/* Skip symlinks with a different basename than
+ * the target unit */
+if (!streq(basename(de->d_name), name))
+continue;
+
 /* Acquire symlink name */
 p = path_make_absolute(de->d_name, path);
 if (!p)
-- 
1.8.3.1

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

[systemd-devel] [PATCHv2] install: Assume *.wants symlinks have the same name as their target for scalability.

[david]

From: David Strauss 

---
 src/shared/install.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/shared/install.c b/src/shared/install.c
index 17e8a75..512e3df 100644
--- a/src/shared/install.c
+++ b/src/shared/install.c
@@ -419,10 +419,15 @@ static int find_symlinks_fd(
 r = q;
 
 } else if (de->d_type == DT_LNK) {
-_cleanup_free_ char *p = NULL, *dest = NULL;
+_cleanup_free_ char *p = NULL, *dest = NULL, *no_inst 
= NULL;
 bool found_path, found_dest, b = false;
 int q;
 
+/* Skip symlinks with a different name the target unit 
*/
+no_inst = 
unit_name_replace_instance(basename(de->d_name), "");
+if (!streq(no_inst, name))
+continue;
+
 /* Acquire symlink name */
 p = path_make_absolute(de->d_name, path);
 if (!p)
-- 
1.8.3.1

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

[systemd-devel] [PATCH] Drop Before=paths/sockets/timers.target from DefaultDependencies.

[david]

From: David Strauss 

---
 src/core/path.c   | 5 -
 src/core/socket.c | 4 
 src/core/timer.c  | 4 
 3 files changed, 13 deletions(-)

diff --git a/src/core/path.c b/src/core/path.c
index fc7069e..95ed015 100644
--- a/src/core/path.c
+++ b/src/core/path.c
@@ -336,11 +336,6 @@ static int path_add_default_dependencies(Path *p) {
 
 assert(p);
 
-r = unit_add_dependency_by_name(UNIT(p), UNIT_BEFORE,
-SPECIAL_PATHS_TARGET, NULL, true);
-if (r < 0)
-return r;
-
 if (UNIT(p)->manager->running_as == SYSTEMD_SYSTEM) {
 r = unit_add_two_dependencies_by_name(UNIT(p), UNIT_AFTER, 
UNIT_REQUIRES,
   SPECIAL_SYSINIT_TARGET, 
NULL, true);
diff --git a/src/core/socket.c b/src/core/socket.c
index 7eac0eb..4917185 100644
--- a/src/core/socket.c
+++ b/src/core/socket.c
@@ -283,10 +283,6 @@ static int socket_add_default_dependencies(Socket *s) {
 int r;
 assert(s);
 
-r = unit_add_dependency_by_name(UNIT(s), UNIT_BEFORE, 
SPECIAL_SOCKETS_TARGET, NULL, true);
-if (r < 0)
-return r;
-
 if (UNIT(s)->manager->running_as == SYSTEMD_SYSTEM) {
 r = unit_add_two_dependencies_by_name(UNIT(s), UNIT_AFTER, 
UNIT_REQUIRES, SPECIAL_SYSINIT_TARGET, NULL, true);
 if (r < 0)
diff --git a/src/core/timer.c b/src/core/timer.c
index a4ff662..ae7a07f 100644
--- a/src/core/timer.c
+++ b/src/core/timer.c
@@ -96,10 +96,6 @@ static int timer_add_default_dependencies(Timer *t) {
 
 assert(t);
 
-r = unit_add_dependency_by_name(UNIT(t), UNIT_BEFORE, 
SPECIAL_TIMERS_TARGET, NULL, true);
-if (r < 0)
-return r;
-
 if (UNIT(t)->manager->running_as == SYSTEMD_SYSTEM) {
 r = unit_add_two_dependencies_by_name(UNIT(t), UNIT_AFTER, 
UNIT_REQUIRES, SPECIAL_SYSINIT_TARGET, NULL, true);
 if (r < 0)
-- 
1.8.5.3

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

[systemd-devel] [PATCH 1/2] Add an 'n' option to cgtop (equivalent to top).

[david]

From: David Strauss 

---
 src/cgtop/cgtop.c | 25 -
 1 file changed, 20 insertions(+), 5 deletions(-)

diff --git a/src/cgtop/cgtop.c b/src/cgtop/cgtop.c
index c3824c7..70570a8 100644
--- a/src/cgtop/cgtop.c
+++ b/src/cgtop/cgtop.c
@@ -55,6 +55,7 @@ typedef struct Group {
 } Group;
 
 static unsigned arg_depth = 3;
+static unsigned arg_iterations = 0;
 static usec_t arg_delay = 1*USEC_PER_SEC;
 
 static enum {
@@ -505,6 +506,7 @@ static void help(void) {
"  -m  Order by memory load\n"
"  -i  Order by IO load\n"
"  -d --delay=DELAYSpecify delay\n"
+   "  -n --iterations=N   Run for N iterations before exiting\n"
" --depth=DEPTHMaximum traversal depth (default: 2)\n",
program_invocation_short_name);
 }
@@ -516,10 +518,11 @@ static int parse_argv(int argc, char *argv[]) {
 };
 
 static const struct option options[] = {
-{ "help",  no_argument,   NULL, 'h'   },
-{ "delay", required_argument, NULL, 'd'   },
-{ "depth", required_argument, NULL, ARG_DEPTH },
-{ NULL,0, NULL, 0 }
+{ "help",   no_argument,   NULL, 'h'   },
+{ "delay",  required_argument, NULL, 'd'   },
+{ "iterations", required_argument, NULL, 'n'   },
+{ "depth",  required_argument, NULL, ARG_DEPTH },
+{ NULL, 0, NULL, 0 }
 };
 
 int c;
@@ -528,7 +531,7 @@ static int parse_argv(int argc, char *argv[]) {
 assert(argc >= 1);
 assert(argv);
 
-while ((c = getopt_long(argc, argv, "hptcmid:", options, NULL)) >= 0) {
+while ((c = getopt_long(argc, argv, "hptcmin:d:", options, NULL)) >= 
0) {
 
 switch (c) {
 
@@ -554,6 +557,15 @@ static int parse_argv(int argc, char *argv[]) {
 
 break;
 
+case 'n':
+r = safe_atou(optarg, &arg_iterations);
+if (r < 0) {
+log_error("Failed to parse iterations 
parameter.");
+return -EINVAL;
+}
+
+break;
+
 case 'p':
 arg_order = ORDER_PATH;
 break;
@@ -641,6 +653,9 @@ int main(int argc, char *argv[]) {
 if (r < 0)
 goto finish;
 
+if (arg_iterations && iteration >= arg_iterations)
+break;
+
 r = read_one_char(stdin, &key, last_refresh + arg_delay - t, 
NULL);
 if (r == -ETIMEDOUT)
 continue;
-- 
1.7.11.2

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

[systemd-devel] [PATCH 2/2] Add a 'b' option to cgtop, equivalent to the same option in top.

[david]

From: David Strauss 

---
 src/cgtop/cgtop.c | 30 +++---
 1 file changed, 23 insertions(+), 7 deletions(-)

diff --git a/src/cgtop/cgtop.c b/src/cgtop/cgtop.c
index 70570a8..b4454c54 100644
--- a/src/cgtop/cgtop.c
+++ b/src/cgtop/cgtop.c
@@ -66,6 +66,8 @@ static enum {
 ORDER_IO
 } arg_order = ORDER_CPU;
 
+bool arg_batch = false;
+
 static void group_free(Group *g) {
 assert(g);
 
@@ -507,6 +509,7 @@ static void help(void) {
"  -i  Order by IO load\n"
"  -d --delay=DELAYSpecify delay\n"
"  -n --iterations=N   Run for N iterations before exiting\n"
+   "  -b --batch  Run in batch mode, accepting no input\n"
" --depth=DEPTHMaximum traversal depth (default: 2)\n",
program_invocation_short_name);
 }
@@ -521,6 +524,7 @@ static int parse_argv(int argc, char *argv[]) {
 { "help",   no_argument,   NULL, 'h'   },
 { "delay",  required_argument, NULL, 'd'   },
 { "iterations", required_argument, NULL, 'n'   },
+{ "batch",  no_argument,   NULL, 'b'   },
 { "depth",  required_argument, NULL, ARG_DEPTH },
 { NULL, 0, NULL, 0 }
 };
@@ -531,7 +535,7 @@ static int parse_argv(int argc, char *argv[]) {
 assert(argc >= 1);
 assert(argv);
 
-while ((c = getopt_long(argc, argv, "hptcmin:d:", options, NULL)) >= 
0) {
+while ((c = getopt_long(argc, argv, "hptcmin:bd:", options, NULL)) >= 
0) {
 
 switch (c) {
 
@@ -566,6 +570,10 @@ static int parse_argv(int argc, char *argv[]) {
 
 break;
 
+case 'b':
+arg_batch = true;
+break;
+
 case 'p':
 arg_order = ORDER_PATH;
 break;
@@ -656,17 +664,25 @@ int main(int argc, char *argv[]) {
 if (arg_iterations && iteration >= arg_iterations)
 break;
 
-r = read_one_char(stdin, &key, last_refresh + arg_delay - t, 
NULL);
-if (r == -ETIMEDOUT)
-continue;
-if (r < 0) {
-log_error("Couldn't read key: %s", strerror(-r));
-goto finish;
+if (!arg_batch) {
+r = read_one_char(stdin, &key, last_refresh + 
arg_delay - t, NULL);
+if (r == -ETIMEDOUT)
+continue;
+if (r < 0) {
+log_error("Couldn't read key: %s", 
strerror(-r));
+goto finish;
+}
+}
+else {
+usleep(last_refresh + arg_delay - t);
 }
 
 fputs("\r \r", stdout);
 fflush(stdout);
 
+if (arg_batch)
+continue;
+
 switch (key) {
 
 case ' ':
-- 
1.7.11.2

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

[systemd-devel] [PATCH] Move path to the right to mitigate alignment issues with untruncated paths. Add --full option (like systemctl) to skip all truncation.

[david]

From: David Strauss 

---
 src/cgtop/cgtop.c | 35 ---
 1 file changed, 24 insertions(+), 11 deletions(-)

diff --git a/src/cgtop/cgtop.c b/src/cgtop/cgtop.c
index b4454c54..c3d2a28 100644
--- a/src/cgtop/cgtop.c
+++ b/src/cgtop/cgtop.c
@@ -67,6 +67,7 @@ static enum {
 } arg_order = ORDER_CPU;
 
 bool arg_batch = false;
+bool arg_full = false;
 
 static void group_free(Group *g) {
 assert(g);
@@ -447,13 +448,13 @@ static int display(Hashmap *a) {
 if (rows <= 0)
 rows = 25;
 
-printf("%s%-37s%s %s%7s%s %s%6s%s %s%8s%s %s%8s%s %s%8s%s\n\n",
-   arg_order == ORDER_PATH   ? ANSI_HIGHLIGHT_ON : "", "Path", 
arg_order == ORDER_PATH   ? ANSI_HIGHLIGHT_OFF : "",
+printf("%s%7s%s %s%6s%s %s%8s%s %s%8s%s %s%8s%s %s%-37s%s\n\n",
arg_order == ORDER_TASKS  ? ANSI_HIGHLIGHT_ON : "", "Tasks",
arg_order == ORDER_TASKS  ? ANSI_HIGHLIGHT_OFF : "",
arg_order == ORDER_CPU? ANSI_HIGHLIGHT_ON : "", "%CPU", 
arg_order == ORDER_CPU? ANSI_HIGHLIGHT_OFF : "",
arg_order == ORDER_MEMORY ? ANSI_HIGHLIGHT_ON : "", "Memory",   
arg_order == ORDER_MEMORY ? ANSI_HIGHLIGHT_OFF : "",
arg_order == ORDER_IO ? ANSI_HIGHLIGHT_ON : "", "Input/s",  
arg_order == ORDER_IO ? ANSI_HIGHLIGHT_OFF : "",
-   arg_order == ORDER_IO ? ANSI_HIGHLIGHT_ON : "", "Output/s", 
arg_order == ORDER_IO ? ANSI_HIGHLIGHT_OFF : "");
+   arg_order == ORDER_IO ? ANSI_HIGHLIGHT_ON : "", "Output/s", 
arg_order == ORDER_IO ? ANSI_HIGHLIGHT_OFF : "",
+   arg_order == ORDER_PATH   ? ANSI_HIGHLIGHT_ON : "", "Path", 
arg_order == ORDER_PATH   ? ANSI_HIGHLIGHT_OFF : "");
 
 for (j = 0; j < n; j++) {
 char *p;
@@ -464,14 +465,10 @@ static int display(Hashmap *a) {
 
 g = array[j];
 
-p = ellipsize(g->path, 37, 33);
-printf("%-37s", p ? p : g->path);
-free(p);
-
 if (g->n_tasks_valid)
-printf(" %7u", g->n_tasks);
+printf("%7u", g->n_tasks);
 else
-fputs("   -", stdout);
+fputs("  -", stdout);
 
 if (g->cpu_valid)
 printf(" %6.1f", g->cpu_fraction*100);
@@ -491,6 +488,15 @@ static int display(Hashmap *a) {
 } else
 fputs("--", stdout);
 
+if (arg_full) {
+printf(" %s", g->path);
+}
+else {
+p = ellipsize(g->path, 37, 33);
+printf(" %-37s", p ? p : g->path);
+free(p);
+}
+
 putchar('\n');
 }
 
@@ -510,14 +516,16 @@ static void help(void) {
"  -d --delay=DELAYSpecify delay\n"
"  -n --iterations=N   Run for N iterations before exiting\n"
"  -b --batch  Run in batch mode, accepting no input\n"
-   " --depth=DEPTHMaximum traversal depth (default: 2)\n",
+   " --depth=DEPTHMaximum traversal depth (default: 2)\n"
+   " --full   Don't ellipsize paths on output\n",
program_invocation_short_name);
 }
 
 static int parse_argv(int argc, char *argv[]) {
 
 enum {
-ARG_DEPTH = 0x100
+ARG_DEPTH = 0x100,
+ARG_FULL  = 0x101
 };
 
 static const struct option options[] = {
@@ -525,6 +533,7 @@ static int parse_argv(int argc, char *argv[]) {
 { "delay",  required_argument, NULL, 'd'   },
 { "iterations", required_argument, NULL, 'n'   },
 { "batch",  no_argument,   NULL, 'b'   },
+{ "full",   no_argument,   NULL, ARG_FULL  },
 { "depth",  required_argument, NULL, ARG_DEPTH },
 { NULL, 0, NULL, 0 }
 };
@@ -570,6 +579,10 @@ static int parse_argv(int argc, char *argv[]) {
 
 break;
 
+case ARG_FULL:
+arg_full = true;
+break;
+
 case 'b':
 arg_batch = true;
 break;
-- 
1.7.11.2

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

[systemd-devel] [PATCH] Fix title positions for dynamic column widths.

[david]

From: David Strauss 

---
 src/cgtop/cgtop.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/src/cgtop/cgtop.c b/src/cgtop/cgtop.c
index fde31b9..33e78b0 100644
--- a/src/cgtop/cgtop.c
+++ b/src/cgtop/cgtop.c
@@ -450,13 +450,13 @@ static int display(Hashmap *a) {
 if (path_columns < 10)
 path_columns = 10;
 
-printf("%s%-37s%s %s%7s%s %s%6s%s %s%8s%s %s%8s%s %s%8s%s\n\n",
-   arg_order == ORDER_PATH   ? ANSI_HIGHLIGHT_ON : "", "Path", 
arg_order == ORDER_PATH   ? ANSI_HIGHLIGHT_OFF : "",
-   arg_order == ORDER_TASKS  ? ANSI_HIGHLIGHT_ON : "", "Tasks",
arg_order == ORDER_TASKS  ? ANSI_HIGHLIGHT_OFF : "",
-   arg_order == ORDER_CPU? ANSI_HIGHLIGHT_ON : "", "%CPU", 
arg_order == ORDER_CPU? ANSI_HIGHLIGHT_OFF : "",
-   arg_order == ORDER_MEMORY ? ANSI_HIGHLIGHT_ON : "", "Memory",   
arg_order == ORDER_MEMORY ? ANSI_HIGHLIGHT_OFF : "",
-   arg_order == ORDER_IO ? ANSI_HIGHLIGHT_ON : "", "Input/s",  
arg_order == ORDER_IO ? ANSI_HIGHLIGHT_OFF : "",
-   arg_order == ORDER_IO ? ANSI_HIGHLIGHT_ON : "", "Output/s", 
arg_order == ORDER_IO ? ANSI_HIGHLIGHT_OFF : "");
+printf("%s%-*s%s %s%7s%s %s%6s%s %s%8s%s %s%8s%s %s%8s%s\n\n",
+   arg_order == ORDER_PATH   ? ANSI_HIGHLIGHT_ON : "", 
path_columns, "Path", arg_order == ORDER_PATH   ? ANSI_HIGHLIGHT_OFF : "",
+   arg_order == ORDER_TASKS  ? ANSI_HIGHLIGHT_ON : "", 
  "Tasks",arg_order == ORDER_TASKS  ? ANSI_HIGHLIGHT_OFF : "",
+   arg_order == ORDER_CPU? ANSI_HIGHLIGHT_ON : "", 
  "%CPU", arg_order == ORDER_CPU? ANSI_HIGHLIGHT_OFF : "",
+   arg_order == ORDER_MEMORY ? ANSI_HIGHLIGHT_ON : "", 
  "Memory",   arg_order == ORDER_MEMORY ? ANSI_HIGHLIGHT_OFF : "",
+   arg_order == ORDER_IO ? ANSI_HIGHLIGHT_ON : "", 
  "Input/s",  arg_order == ORDER_IO ? ANSI_HIGHLIGHT_OFF : "",
+   arg_order == ORDER_IO ? ANSI_HIGHLIGHT_ON : "", 
  "Output/s", arg_order == ORDER_IO ? ANSI_HIGHLIGHT_OFF : "");
 
 for (j = 0; j < n; j++) {
 char *p;
-- 
1.7.11.2

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

[systemd-devel] Unknown key name 'StopIdleSessionSec' in section 'Login'

[David]

Hello, from a novice at system administration and systemd.

A week ago, I installed Google Chrome on a Debian 11 VPS to get access to a 
headless browser. Soon afterward, ConfigServer (CSF) began sending alerts that 
2 processes were exceeding the limit. These 2 processes are:

/lib/systemd/systemd —user
(sd-pam)

The VPS only has two (reseller) users that these processes are running under.

Searching around, I found an article (*1) that seemed to address the situation. 
In another article (*2), I found the configuration file, incidentally, with 
every key commented out.

In this config file: /etc/systemd/logind.conf, I added 
'StopIdleSessionSec=600’, then restarted logind with:

# systemctl restart systemd-logind

And checked for status with:

# journalctl -u systemd-logind

wherein, the following lines are at the end:

Oct 23 11:35:39 vps.lan-software.com systemd[1]: Stopping User Login 
Management...
Oct 23 11:35:39 vps.lan-software.com systemd[1]: systemd-logind.service: 
Succeeded.
Oct 23 11:35:40 vps.lan-software.com systemd[1]: Stopped User Login Management.
Oct 23 11:35:41 vps.lan-software.com systemd[1]: Starting User Login 
Management...
Oct 23 11:35:41 vps.lan-software.com systemd-logind[94302]: 
/etc/systemd/logind.conf:43: Unknown key name 'StopIdleSessionSec' in section 
'Login', ignoring
Oct 23 11:35:41 vps.lan-software.com systemd-logind[94302]: System has 
/dev/tty0 but not /sys/class/tty/tty0/active which is broken, ignoring: No such 
file or directory
Oct 23 11:35:41 vps.lan-software.com systemd[1]: Started User Login Management.
Oct 23 11:35:41 vps.lan-software.com systemd-logind[94302]: New seat seat0.
Oct 23 11:35:41 vps.lan-software.com systemd-logind[94302]: New session 2266973 
of user root.

I think the Chrome installation did something that is causing systemd to start 
a session, but not close it.

How can I get these 2 processes to shutdown?  

Is this an issue with systemd or in the configuration of Chrome?

Trying to learn to be a better system admin,

David


*1 - 
https://www.admin-magazine.com/Archive/2024/79/Automatically-terminate-OpenSSH-sessions
*2 - https://manpages.debian.org/testing/systemd/logind.conf.5.en.html

Re: [systemd-devel] Xorg or Wayland Environment

[David Edmundson]

> What would be the proper way to get the DISPLAY environment varible use it as 
> opposed

Having someone else (your desktop) call
"dbus-update-activation-environment --systemd" on startup or an
equivalent
and ensure your service is started after that, such as being after
graphical-session.target

David

[systemd-devel] Unit shutdown order not always respected

[David Gubler]

Hi list,

I have a situation where I need to run a command and wait for its 
completion before unmounting a file system (/enc in my case). My problem 
is that systemd sometimes waits for the completion of the command, and 
sometimes doesn't.


So the setup is:
* /enc is a mounted encrypted (luks) volume
* /var/lib/mysql is a bind mount to /enc/mysql
* MariaDB is using /var/lib/mysql
* We've set up a "requires" and "after" dependency chain from MariaDB 
all the way to the luks volume. This works 100% reliably during startup, 
even if something takes too long, fails, or if we have to manually 
fiddle with stuff.

* Ubuntu 20.04 with systemd 245.4


The unit of the command that needs to run before unmounting /enc looks 
like this:



[Unit]
Description=server-secrets-prepare-reboot-enc service
After=network-online.target enc.mount
Requires=network-online.target
BindsTo=enc.mount

[Service]
ExecStart=/bin/true
ExecStop=/usr/local/sbin/server-secrets reboot "/enc"
Restart=no
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=server-secrets-prepare-reboot-enc
User=root
Type=oneshot
RemainAfterExit=yes

[Install]
WantedBy=enc.mount




I've added a 10s sleep to the "server-secrets" command in order to 
eliminate "works by chance" situations.


In normal circumstances everything works perfectly. I can reboot the 
server and systemd waits >10s with unmounting /enc until server-secrets 
is done. I can stop mariadb, umount /var/lib/mysql and /enc, and systemd 
runs server-secrets just fine. I can re-mount /enc, unmount it again, 
everything works.


Where things start to fall apart is when I reboot the server ("reboot" 
or "shutdown -r now") after manually stopping MariaDB. In this case 
systemd starts the server-secrets command before unmounting /enc, but 
does not wait for its completion, and immediately unmounts /enc, causing 
the command to fail.


Note that manually stopping MariaDB does not unmount anything, it 
just... stops MariaDB. But somehow it causes systemd to change its 
ordering behavior during shutdown.


Does this ring any bells?

Thank you!

Best regards,

David Gubler



--
David Gubler
System Engineer

VSHN AG | Neugasse 10 | CH-8005 Zürich
+41 44 545 53 00 | https://vshn.ch

Re: [systemd-devel] Setting up a VPN daemon as a Portable Service

[David Anderson]

Yeah, so far we (tailscale) haven't found a good way to run on the Steam Deck 
at bootup, and also survive the A/B OS updates. Systemd system extensions _can_ 
be activated during bootup, if you place the extension in one of the well-known 
locations (/var/lib/extensions would be the one to use on Deck, as iirc it 
survives A/B upgrades), and the systemd-sysext service is enabled.

I would check if systemd-sysext.service is enabled on the deck, and if not, 
file a request with Valve to enable that service in a future update. You should 
present it as enabling further customization of their platform.

Another possible reason that sysexts aren't working for you, is that the Deck's 
/etc/os-release doesn't define a SYSEXT_LEVEL, and the VERSION_ID changes with 
every OS update. Because of this, the system extension will refuse to activate 
after every update (either SYSEXT_LEVEL or VERSION_ID must match exactly), 
until you rebuild a new image with the right OS metadata. Asking Valve to set 
SYSEXT_LEVEL to a stable value would make it even easier to provide Deck OS 
extensions reliably :)

- Dave

On Thu, Oct 6, 2022, at 12:08, Arian van Putten wrote:
> Afaik Portable services run in an isolated root and dont have access to the 
> hosts rootfs.  You'd have go include iptables and all its dependencies in the 
> portable services directory. If you don't want to do that you'd have to use 
> BindReadOnlyPaths= to give the service access to the required host paths or 
> you'd have to use a system extension.
> 
> That's probably why they advice running as a system extension. 
> 
> I think there are mechanisms for setting up system extensions on startup but 
> I'm not familiar enough with the details. Maybe someone else in the list 
> knows.
> 
> 
> 
> 
> On Thu, 6 Oct 2022, 20:21 Duncan Gibson,  wrote:
>> Hi, everyone.
>> 
>> The high-level overview: I'm trying to install Tailscale 
>>  as a portable service on my Steam Deck. 
>> 
>> Tailscale is a point-to-point VPN service, essentially a wrapper around 
>> Wireguard that helps with network setup and management. The Steam Deck is 
>> Valve's handheld PC running SteamOS 3, which is derived from Arch. It uses 
>> an A/B partition system for system files, meaning you can't install a 
>> service the normal way.
>> 
>> There *is* a guide to do this , 
>> posted on their own blog, but it uses system extensions which aren't good 
>> for services that you want to run on startup. Indeed, following that guide 
>> puts me in a state where I have to manually start the daemon every time I 
>> reboot my Deck, even with the service enabled.
>> 
>> Let's move on to how I've started to do this.
>> 
>> Tailscale is available through most package managers, but they also publish 
>> static binaries with systemd unit files 
>> . 
>> 
>> This script grabs that binary, extracts it, and moves it into a portable 
>> service directory structure.
>> 
>> # download and extract Tailscale
>> tarball="$(curl -s 'https://pkgs.tailscale.com/stable/?mode=json' | jq -r 
>> .Tarballs.amd64)"
>> version="$(echo ${tarball} | cut -d_ -f2)"
>> tar_dir="$(echo ${tarball} | cut -d. -f1-3)"
>> curl -s "https://pkgs.tailscale.com/stable/${tarball}"; -o tailscale.tgz
>> tar xzf tailscale.tgz
>> test -d $tar_dir
>> 
>> # Set up our target directory structure
>> mkdir -p 
>> tailscaled/{usr/{bin,sbin,lib/systemd/system},etc,proc,sys,dev,run,/var/tmp}
>> 
>> # Copy tailscale-distributed files to the right place
>> cp -rf $tar_dir/tailscaled tailscaled/usr/sbin/tailscaled
>> cp -rf $tar_dir/systemd/tailscaled.service 
>> tailscaled/usr/lib/systemd/system/tailscaled.service
>> 
>> # Write service os-release file
>> source /etc/os-release
>> cp -rf /etc/os-release tailscaled/etc/os-release
>> 
>> Not automated yet is patching the provided unit file - you need to remove 
>> the EnvironmentFile line and "--port $PORT $FLAGS" options, and add 
>> [Exec]
>> Environment="PATH=/usr/bin"
>> 
>> Attach the portable service: sudo portablectl attach ./tailscaled 
>> --profile=trusted
>> and try starting it: sudo systemctl start tailscaled
>> 
>> It fails, leaving this in the logs:
>> 
>> `logtail started `
>> `Program starting: v1.30.2-t24c524c78-gc399ae6fa, Go 1.19.1-tsb13188dd36: 
>> []string{"/usr/sbin/tailscaled", 
>> "--state=/var/lib/tailscale/tailscaled.state", 
>> "--socket=/run/tailscale/tailscaled.sock"} `
>> `LogID: 0f59ed267a2b19cc28aac9ee7119914000ca478234af8d56893a025ae72cc647 `
>> `logpolicy: using $STATE_DIRECTORY, "/var/lib/tailscale" `
>> `wgengine.NewUserspaceEngine(tun "tailscale0") ... `
>> `wgengine.NewUserspaceEngine(tun "tailscale0") error: creating router: could 
>> not get iptables version: fork/exec /usr/bin/iptables: no such file or 
>> directory flushing log. `
>> `logger closing down `
>> `createEngine: creating router: could not get iptables version: fork/exec 
>> /usr/bin/iptables: no s

[systemd-devel] Unmountable mounts and systemd-fsck@.service conflicting with shutdown.target

[Valentin David]

Hello,

In Ubuntu Core, we have some mounts that cannot be unmounted until we have
switched root.

To simplify, this looks like that:

/ mounts a ro loop devices backed by /some/disk/some/path/image.img
/some/disk mounts a block device (let's say /dev/some-block0p1)

In this case, /some/disk cannot be unmounted.

We do not want to lazily unmount, we cannot get errors if something fails.
(Unless we had a lazy unmount that would only work when read-only)

We do remount /some/disk read-only on shutdown. And in the shutdown
intramfs, we unmount /oldroot/some/disk.

However, we get an error message with systemd trying to unmount it. While
functionally, it does not matter, it is still very problematic to have
error messages.

Using `DefaultDependencies=no` is not enough. I have tried to be clever and
add some-disk.mount to shutdown.target.wants so it would not try to unmount
it. But systemd got confused with conflicts and randomly kills stop jobs
until there is no conflict.

Debugging it, I have found that this is because some-disk.mount depends on
systemd-fsck@some\x2dblock0p1.service. And systemd-fsck@.service conflicts
with shutdown.target.

I wonder if having conflict on shutdown.target really needed. Could we
remove it? (And also add DefaultDepenencies=no to
system-systemd\x2dfsck.slice) With this, mounts with DefaultDependencie=no
do not get unmounted as part of shutdown.target. (They do during
systemd-shutdown)

Re: [systemd-devel] Unmountable mounts and systemd-fsck@.service conflicting with shutdown.target

[Valentin David]

It is a call to systemd-mount done from initramfs. It ends up in
/run/systemd/transient and survives the root switch. The generated unit
contains Requires=systemd-fsck@service.

Is the conflict on shutdown.target to make shutdown kill fsck if it is
running?

Generated systemd-cryptsetup@.service units have "DefaultDependencies=no"
and no conflict on shutdown. Maybe this is missing then. "cryptsetup
attach" might be running.


On Fri, Jan 6, 2023 at 1:34 PM Lennart Poettering 
wrote:

> On Do, 05.01.23 14:18, Valentin David (valentin.da...@canonical.com)
> wrote:
>
> > Hello,
> >
> > In Ubuntu Core, we have some mounts that cannot be unmounted until we
> have
> > switched root.
> >
> > To simplify, this looks like that:
> >
> > / mounts a ro loop devices backed by /some/disk/some/path/image.img
> > /some/disk mounts a block device (let's say /dev/some-block0p1)
> >
> > In this case, /some/disk cannot be unmounted.
> >
> > We do not want to lazily unmount, we cannot get errors if something
> fails.
> > (Unless we had a lazy unmount that would only work when read-only)
> >
> > We do remount /some/disk read-only on shutdown. And in the shutdown
> > intramfs, we unmount /oldroot/some/disk.
> >
> > However, we get an error message with systemd trying to unmount it. While
> > functionally, it does not matter, it is still very problematic to have
> > error messages.
> >
> > Using `DefaultDependencies=no` is not enough. I have tried to be clever
> and
> > add some-disk.mount to shutdown.target.wants so it would not try to
> unmount
> > it. But systemd got confused with conflicts and randomly kills stop jobs
> > until there is no conflict.
> >
> > Debugging it, I have found that this is because some-disk.mount depends
> on
> > systemd-fsck@some\x2dblock0p1.service. And systemd-fsck@.service
> conflicts
> > with shutdown.target.
> >
> > I wonder if having conflict on shutdown.target really needed. Could we
> > remove it? (And also add DefaultDepenencies=no to
> > system-systemd\x2dfsck.slice) With this, mounts with
> DefaultDependencie=no
> > do not get unmounted as part of shutdown.target. (They do during
> > systemd-shutdown)
>
> hmm, so we generally want system services to go away before
> shutdown. This is a very special case though. I wonder if we can just
> override systemd-fsck@….service for that specific case?
>
> How are those mounts established? i.e. by which unit is the
> systemd-fsck@.service instance pulled in? and how was that configured?
> fstab? ubuntu-own code?
>
> Lennart
>
> --
> Lennart Poettering, Berlin
>

[systemd-devel] Is journald RateLimitBurst multiplier applied when Storage=volatile or Storage=none?

[Chamberlain, David]

The journald.conf manual mentions that:

[...] the effective rate limit is multiplied with a factor derived from the 
available free disk space for the journal.

If Storage=persistent, then I think this would refer to the free space of 
whatever filesystem /var/log/journal is a part of. But how does this work if 
Storage=volatile or Storage=none? Is a multiplication factor still applied? If 
yes, then what "free disk space" is considered?

Thanks,
David Chamberlain

[systemd-devel] systemd-repart very slow creation of partitions with Encrypt=

[Valentin David]

I have been trying to create a root partition from initrd with
systemd-repart. The repart.d file for this partition is as follow:

[Partition]
Type=root
Label=root
Encrypt=tpm2
Format=ext4
FactoryReset=yes

I am just using systemd-repart.service in initrd, without modification
(that is, it finds the disk from /sysusr/usr). Even though this is working,
the problem I have is that it takes a very long time for the partition to
be created. Looking at the logs, it spends most of time in the reencryption.

For 11GB partition on a VM, it takes more than 2 minutes. On the bare metal
with a 512 GB nvme disk, it has been running for 3 hours. And it is still
not finished.

I do not think cryptsetup reencryption supports holes. Is it normal to have
a full reencryption of a disk that was just initialized with mkfs.ext4? If
so, could we at least move the effective reencryption after
systemd-repart.service, so that the rest of the system can continue to boot?

I am running:
systemd 253.4 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA
+SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2
+IDN2 -IDN -IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 +PWQUALITY +P11KIT
-QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMM
ON +UTMP +SYSVINIT default-hierarchy=unified)

Cryptsetup: v2.6.1

Re: [systemd-devel] systemd-repart very slow creation of partitions with Encrypt=

[Valentin David]

On Mon, Jun 5, 2023 at 9:56 AM Lennart Poettering 
wrote:

> On So, 04.06.23 14:25, Valentin David (valentin.da...@canonical.com)
> wrote:
>
> > I have been trying to create a root partition from initrd with
> > systemd-repart. The repart.d file for this partition is as follow:
> >
> > [Partition]
> > Type=root
> > Label=root
> > Encrypt=tpm2
> > Format=ext4
> > FactoryReset=yes
> >
> > I am just using systemd-repart.service in initrd, without modification
> > (that is, it finds the disk from /sysusr/usr). Even though this is
> working,
> > the problem I have is that it takes a very long time for the partition to
> > be created. Looking at the logs, it spends most of time in the
> > reencryption.
>
> reencryption? We don't do any reencrytion really. i.e. we do not
> actually support anything like "cryptsetup reencrypt" at all. All we
> do is the equivalent of "cryptsetup luksFormat". Are you suggesting
> that repart is slower at formatting a block device via LUKS than
> invoking cryptsetup directly would be? I'd find that very surprising...
>

This is what it looks like in src/partition/repart.c. Function
partition_encrypt calls sym_crypt_reencrypt_init_by_passphrase and
then sym_crypt_reencrypt.
And make_filesystem is called before partition_encrypt. So it must
reencrypt since mkfs was called before.


> > For 11GB partition on a VM, it takes more than 2 minutes. On the bare
> metal
> > with a 512 GB nvme disk, it has been running for 3 hours. And it is still
> > not finished.
>
> This is really strange. The LUKS formatting should just write a
> superlock onto the disk, which is just a couple of sectors, and should
> barely take any time.
>
> Or are you saying "mke2fs" takes that long?
>
> Note that we specify lazy_itable_init=1 during formatting ext4, hence
> it should actually be super fast too...
>

No. mkfs was done. In the logs it was all about reencryption. See
https://gitlab.gnome.org/-/snippets/5809/raw/main/snippetfile1.txt


>
> > I do not think cryptsetup reencryption supports holes. Is it normal to
> have
> > a full reencryption of a disk that was just initialized with mkfs.ext4?
> If
> > so, could we at least move the effective reencryption after
> > systemd-repart.service, so that the rest of the system can continue to
> boot?
> >
> > I am running:
> > systemd 253.4 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA
> > +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS
> +FIDO2
> > +IDN2 -IDN -IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 +PWQUALITY +P11KIT
> > -QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMM
> > ON +UTMP +SYSVINIT default-hierarchy=unified)
> >
> > Cryptsetup: v2.6.1
>
> I am a bit puzzled by this. WOuld be good to figure out what actually
> is so slow here? formatting luks? formatting ext4? discarding?
>
> Lennart
>
> --
> Lennart Poettering, Berlin
>

Re: [systemd-devel] systemd-repart very slow creation of partitions with Encrypt=

[Valentin David]

I think that behavior was introduced by
https://github.com/systemd/systemd/commit/48a09a8fff480aab9a68e95e95cc37f6b1438751

On Mon, Jun 5, 2023 at 10:41 AM Valentin David 
wrote:

>
>
> On Mon, Jun 5, 2023 at 9:56 AM Lennart Poettering 
> wrote:
>
>> On So, 04.06.23 14:25, Valentin David (valentin.da...@canonical.com)
>> wrote:
>>
>> > I have been trying to create a root partition from initrd with
>> > systemd-repart. The repart.d file for this partition is as follow:
>> >
>> > [Partition]
>> > Type=root
>> > Label=root
>> > Encrypt=tpm2
>> > Format=ext4
>> > FactoryReset=yes
>> >
>> > I am just using systemd-repart.service in initrd, without modification
>> > (that is, it finds the disk from /sysusr/usr). Even though this is
>> working,
>> > the problem I have is that it takes a very long time for the partition
>> to
>> > be created. Looking at the logs, it spends most of time in the
>> > reencryption.
>>
>> reencryption? We don't do any reencrytion really. i.e. we do not
>> actually support anything like "cryptsetup reencrypt" at all. All we
>> do is the equivalent of "cryptsetup luksFormat". Are you suggesting
>> that repart is slower at formatting a block device via LUKS than
>> invoking cryptsetup directly would be? I'd find that very surprising...
>>
>
> This is what it looks like in src/partition/repart.c. Function
> partition_encrypt calls sym_crypt_reencrypt_init_by_passphrase and then 
> sym_crypt_reencrypt.
> And make_filesystem is called before partition_encrypt. So it must
> reencrypt since mkfs was called before.
>
>
>> > For 11GB partition on a VM, it takes more than 2 minutes. On the bare
>> metal
>> > with a 512 GB nvme disk, it has been running for 3 hours. And it is
>> still
>> > not finished.
>>
>> This is really strange. The LUKS formatting should just write a
>> superlock onto the disk, which is just a couple of sectors, and should
>> barely take any time.
>>
>> Or are you saying "mke2fs" takes that long?
>>
>> Note that we specify lazy_itable_init=1 during formatting ext4, hence
>> it should actually be super fast too...
>>
>
> No. mkfs was done. In the logs it was all about reencryption. See
> https://gitlab.gnome.org/-/snippets/5809/raw/main/snippetfile1.txt
>
>
>>
>> > I do not think cryptsetup reencryption supports holes. Is it normal to
>> have
>> > a full reencryption of a disk that was just initialized with mkfs.ext4?
>> If
>> > so, could we at least move the effective reencryption after
>> > systemd-repart.service, so that the rest of the system can continue to
>> boot?
>> >
>> > I am running:
>> > systemd 253.4 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR
>> +IMA
>> > +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS
>> +FIDO2
>> > +IDN2 -IDN -IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 +PWQUALITY
>> +P11KIT
>> > -QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMM
>> > ON +UTMP +SYSVINIT default-hierarchy=unified)
>> >
>> > Cryptsetup: v2.6.1
>>
>> I am a bit puzzled by this. WOuld be good to figure out what actually
>> is so slow here? formatting luks? formatting ext4? discarding?
>>
>> Lennart
>>
>> --
>> Lennart Poettering, Berlin
>>
>

Re: [systemd-devel] systemd-repart very slow creation of partitions with Encrypt=

[Valentin David]

On Mon, Jun 5, 2023 at 11:09 AM Lennart Poettering 
wrote:

> On Mo, 05.06.23 10:41, Valentin David (valentin.da...@canonical.com)
> wrote:
>
> > On Mon, Jun 5, 2023 at 9:56 AM Lennart Poettering <
> lenn...@poettering.net>
> > wrote:
> >
> > > On So, 04.06.23 14:25, Valentin David (valentin.da...@canonical.com)
> > > wrote:
> > >
> > > > I have been trying to create a root partition from initrd with
> > > > systemd-repart. The repart.d file for this partition is as follow:
> > > >
> > > > [Partition]
> > > > Type=root
> > > > Label=root
> > > > Encrypt=tpm2
> > > > Format=ext4
> > > > FactoryReset=yes
> > > >
> > > > I am just using systemd-repart.service in initrd, without
> modification
> > > > (that is, it finds the disk from /sysusr/usr). Even though this is
> > > working,
> > > > the problem I have is that it takes a very long time for the
> partition to
> > > > be created. Looking at the logs, it spends most of time in the
> > > > reencryption.
> > >
> > > reencryption? We don't do any reencrytion really. i.e. we do not
> > > actually support anything like "cryptsetup reencrypt" at all. All we
> > > do is the equivalent of "cryptsetup luksFormat". Are you suggesting
> > > that repart is slower at formatting a block device via LUKS than
> > > invoking cryptsetup directly would be? I'd find that very surprising...
> > >
> >
> > This is what it looks like in src/partition/repart.c. Function
> > partition_encrypt calls sym_crypt_reencrypt_init_by_passphrase and
> > then sym_crypt_reencrypt.
> > And make_filesystem is called before partition_encrypt. So it must
> > reencrypt since mkfs was called before.
>
> Oh, fuck, yeah, Daan added that.
>
> This is a bug really.
>

I will open an issue on github then.

[systemd-devel] udev database cross-version compatibility

[Valentin David]

Hello,

Back in 2014 and again in 2020, there were discussions on the mailing-list 
related to udev database version safety. This was important to know if libudev 
from a container could access to /run/udev/data files safely. Given then 
libudev and systemd-udevd would be potentially different version.

The conclusion was that there was no guarantee. And based on that flatpak has 
not provided /run/udev/data to applications.

Later, the format changed in #16853 (udev: make uevents "sticky"). But this 
caused issue #17605 (Units with BindsTo= are being killed on upgrade 
from v246 to v247).

This was fixed by #17622 (sd-device: make sd_device_has_current_tag() 
compatible with udev database generated by older udevd).

It seems to me, because udev needs to handle upgrade and downgrade, that it 
will continue to handle some compatibility across versions.

Is it safe now for flatpak to provide /run/udev/data to containers?

(Also, snapd does it, oops)

--
Valentin David
m...@valentindavid.com

[systemd-devel] Detecting Systemd crash

[David Timber]

Systemd crashed on me the other day. I was writing up some Systemd units 
and testing them out by daemon-reload every time I wanted to test them 
out. Not the best way to go on about, I know. My bad abusing Systemd to 
the point of crashing. Perhaps it was just a bit flip that caused this.


   systemd[2368]: Assertion 'path_is_absolute(p)' failed at
   src/basic/chase.c:628, function chase(). Aborting.
   systemd[1]: Assertion 'path_is_absolute(p)' failed at
   src/basic/chase.c:628, function chase(). Aborting.
   systemd[1]: Caught  from our own process.
   systemd-coredump[32497]: Due to PID 1 having crashed coredump
   collection will now be turned off.
   systemd-coredump[32497]: [🡕] Process 32496 (systemd) of user 0
   dumped core.
   systemd[1]: Caught , dumped core as pid 32496.
   systemd[1]: Freezing execution.

   ...

   systemd-journald[871]: Failed to send stream file descriptor to
   service manager: Transport endpoint is not connected

I didn't even bother trying producing stack trace. I can get on that if 
anyone wants it. My machine started doing some weird things like Firefox 
not being able to do Ajax properly whilst being able to go to a new 
page, Chromium not being able to create a new tab whilst all the text 
editors worked just fine, all the systemctl commands timing out. So 
basically, I was using Linux without fork(). Anyway.
Well, I think any software can crash for any reason whatsoever. The 
problem with Systemd I realised from this incident is that I had no way 
of knowing that Systemd had crashed until I opened up the journal and 
kernel logs and saw that Systemd had crashed some time ago. In this 
particular incident, Systemd caught the signal and decided to just 
freeze. No idea why you'd want that because if it had just crashed, the 
kernel would have just panicked and I would have realised something went 
wrong.


1: So I decided that I need a some sort of "watchdog" that warns me when 
something like this happens. Using dbus to poll the status of the 
Systemd process, it could be a GUI app running under a seat, just a 
daemon that writes a warning message using `wall` or just send mail 
using a primed up MUA process. I wonder if someone already had the same 
idea and went on to make one.


2: How do I get Systemd to freeze to test such program? I mean, if I 
kill Systemd, the kernel would crash so I have to somehow tell Systemd 
to freeze?

[systemd-devel] ConditionNeedsUpdate, read-only /usr, and sysext

[Valentin David]

Hello everybody,

The behavior of ConditionNeedsUpdate is that if /etc/.updated is older than 
/usr/, then it is true.

I have some issues with this. But maybe I do not use it the right way.

First, when using a read-only /usr partition (updated through sysupdate), the 
time of /usr is of the build of that filesystem. In the case of GNOME OS, to 
ensure reproducibility bit by bit, we set all times to some time in 2011. So 
that does not work for us.

But now let's say we work-around that, and we make our system take a date that 
is reproducible, let's say the git commit of our metadata. Then we have a 
second issue.

Because of systemd-sysext, it might be that /usr is not anymore the time of the 
/usr filesystem, but the time of a directory created on the fly by 
systemd-sysext (or maybe it keeps the time from the / fileystem, I do not know, 
but for sure the time stamp is from when systemd-sysext was started). If 
systemd-update-done happens after systemd-sysext (and it effectively does on 
254), then the date of /etc/.updated will become the time when systemd-sysext 
started.

Let's imagine that I do not boot that machine often. My system is booting a new 
version. And there is already another new version available on the sysupdate 
server. My system will download a build of /usr that is likely to be older than 
the boot time. So next reboot, the condition will be false, even though I did 
have an update. And it will be false until I download a version that was built 
after the boot time of my last successful update.

So my question is, is there plan to replace time stamp comparison for 
ConditionNeedsUpdate with something that  works better with sysupdate and 
sysext? Maybe copying IMAGE_VERSION from /usr/lib/os-release into /etc/.updated 
for example?

Thanks,
--
Valentin David
m...@valentindavid.com

[systemd-devel] Periodic tasks on battery-powered devices

[David Strauss]

I could be missing something, but I think there's a gap in the
functionality for timers for periodic tasks on battery-powered devices.
Basically, I want to generate a security report (SCAP style) approximately
weekly but avoid doing so on battery.

Here's what I've tried or looked at:

- If I use ConditionACPower=true on the Type=OneShot service performing the
task, then systemd will not run the task while on battery, but it still
resets the timer. With a longer OnCalendar= interval, there's a significant
chance that the infrequent check will overlap with battery-mode operation,
causing the task to never run.

- If I use ConditionACPower=true on the timer, then the timer just won't
start if the machine boots on battery. This is also undesirable, as a
machine may only boot every few weeks.

- OnActiveSec= doesn't support persistence, so intervals of approximately a
week may never fire on some laptops that shutdown or reboot frequently.

- OnBootSec= would be too frequent for laptops that shutdown or reboot
frequently.

It seems the best I can do right now is use a shorter timer interval with
no AC power condition but have the Type=OneShot service exit early if it
last ran too recently, especially if currently on battery power. I'm also
looking at just using anacron.

What I would prefer is a [Timer] option like AvoidOnBatterySec= that causes
the timer to avoid firing on battery yet fire on restoration of AC power if
overdue. If the AvoidOnBatterySec= duration has elapsed since the last
firing, the timer fires regardless of whether the device is on battery.
This would allow easy configuration of periodic tasks that are power-hungry
but need to run eventually. Some of our laptops rarely run on AC aside from
when they're closed at night.

I would even consider a directive like WakeSystemSec= that specifies a
maximum interval that must elapse since the timer last fired before waking
up the system to fire the timer. Similarly to AvoidOnBatterySec=, it would
serve as a way to get more aggressive if a periodic task is too far overdue.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] connection failure

[David Anderson]

Hi! This is the wrong list for your question. You should ask this on the
help list for your linux distro, it looks like they've configured Docker
incorrectly, or there's some extra required setup that you're missing. You
can also consult `journalctl -u docker.service` to find clues on why Docker
won't start, but your distro's support community is where you should ask
for help.

This list can't help debug every OS distro, it's only for bugs or problems
in systemd itself. In this case, systemd is working perfectly: the docker
service is broken, and systemd tells you that it's broken :).

Good luck!
- Dave

On Tue, Jul 2, 2019 at 6:39 AM ABDUL MAJITH 
wrote:

> Hi all,
>
> I am trying to use the Docker in GNS3, when I try to launch it show the
> error as follows,
>
> -- The start-up result is done.
> Jul 02 15:21:55 reccon.irisa.fr systemd[1]: docker.service: Start request
> repeated too quickly.
> Jul 02 15:21:55 reccon.irisa.fr systemd[1]: docker.service: Failed with
> result 'exit-code'.
> Jul 02 15:21:55 reccon.irisa.fr systemd[1]: Failed to start Docker
> Application Container Engine.
> -- Subject: Unit docker.service has failed
> -- Defined-By: systemd
> -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> --
> -- Unit docker.service has failed.
> --
> -- The result is failed.
> Jul 02 15:21:55 reccon.irisa.fr systemd[1]: docker.socket: Failed with
> result 'service-start-limit-hit'.
> Jul 02 15:24:06 reccon.irisa.fr systemd[1]: Starting dnf makecache...
> -- Subject: Unit dnf-makecache.service has begun start-up
> -- Defined-By: systemd
> -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> --
> -- Unit dnf-makecache.service has begun starting up.
> Jul 02 15:24:07 reccon.irisa.fr dnf[18029]: Metadata timer caching
> disabled.
> Jul 02 15:24:07 reccon.irisa.fr systemd[1]: Started dnf makecache.
> -- Subject: Unit dnf-makecache.service has finished start-up
> -- Defined-By: systemd
> -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> --
> -- Unit dnf-makecache.service has finished starting up.
> --
> -- The start-up result is done.
> ...skipping...
> --
> -- The start-up result is done.
> Jul 02 15:21:55 reccon.irisa.fr systemd[1]: docker.service: Start request
> repeated too quickly.
> Jul 02 15:21:55 reccon.irisa.fr systemd[1]: docker.service: Failed with
> result 'exit-code'.
> Jul 02 15:21:55 reccon.irisa.fr systemd[1]: Failed to start Docker
> Application Container Engine.
> -- Subject: Unit docker.service has failed
> -- Defined-By: systemd
> -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> --
> -- Unit docker.service has failed.
> --
> -- The result is failed.
> Jul 02 15:21:55 reccon.irisa.fr systemd[1]: docker.socket: Failed with
> result 'service-start-limit-hit'.
> Jul 02 15:24:06 reccon.irisa.fr systemd[1]: Starting dnf makecache...
> -- Subject: Unit dnf-makecache.service has begun start-up
> -- Defined-By: systemd
> -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> --
> -- Unit dnf-makecache.service has begun starting up.
> Jul 02 15:24:07 reccon.irisa.fr dnf[18029]: Metadata timer caching
> disabled.
> Jul 02 15:24:07 reccon.irisa.fr systemd[1]: Started dnf makecache.
> -- Subject: Unit dnf-makecache.service has finished start-up
> -- Defined-By: systemd
> -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> --
> -- Unit dnf-makecache.service has finished starting up.
> --
> -- The start-up result is done.
>
> How to rectify this failure to start the docker application
>
> thanks in advance,
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] When will my timer next run?

[David Anderson]

Did you `systemctl enable rsync-Saruman.timer` to activate the timer?
Timers can be enabled and disabled just like services, you need to enable
it after creating.

- Dave

On Fri, Aug 30, 2019 at 8:05 PM Kenneth Porter 
wrote:

> I've created my service timer with the following:
>
> [Timer]
> # wait a bit after boot to let our victim catch up with its work
> OnBoot=13m
> # let the victim get some work done between backups
> # we use inactive to prevent back-to-back backups if they run long
> OnUnitInactiveSec=1h
>
> I then run list-timers but all the time columns for my service are n/a. I
> want my backup to run with an hour between backups, and with a pause after
> boot to let all the machines come up and finish overdue work from any long
> power outage. I started the timer unit and then see this:
>
> # systemctl  list-timers
> NEXT LEFT  LAST
> PASSED UNIT ACTIVATES
> n/a  n/a   n/a
> n/a
> rsync-Saruman.timer  rsync-Saruman.service
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] High CPU utilization by systemd process || Debian 8

[David Anderson]

Note that Debian 8 is very old. It runs systemd v215, which came out
in 2014. So, from upstream's perspective, unless it's a well-known
bug, the answer is probably "who knows? Use a more recent systemd."

I suggest filing a bug with Debian and asking them for help. Debian 8
is still supported for another 6 months, according to
https://wiki.debian.org/LTS ... Although it's by a team of volunteers,
so YMMV.

- Dave


On Wed, Dec 11, 2019 at 9:35 PM Md. Farhad Hasan Khan
 wrote:
>
> Hi,
>
> We are observing high CPU utilization by systemd process.
>
> 100% CPU utilize by systemd process when no user is being logged in to the 
> server  but CPU utilization became 0% while any user logged in to the server. 
>  What cloud be possible reason behind this issue and solution?
>
>
>
> Log collected via login to the server via ssh or console: (0% CPU utilization)
>
>
>
> top -b -n 1 | grep systemd | grep 612
>   612 root  20   0 3386692 2.051g   4932 T   0.0  6.5  22029:26 systemd
>
>
>
>
>
> Log collected without login to the server : (100% CPU utilization)
>
>
>
> # ssh user@192.168.18.11 top -b -n 1 | grep systemd | grep 612
> user@192.168.18.11's password:
>   612 root  20   0 3386692 2.051g   4932 S 789.2  6.5  22031:31 systemd
>
>
>
>
>
> Please find the server information:
>
>
>
> lsb_release -a
> No LSB modules are available.
> Distributor ID: Debian
> Description:Debian GNU/Linux 8.11 (jessie)
> Release:8.11
> Codename:   jessie
>
> uname -r
> 3.16.0-6-amd64
>
>
>
> Thanks & B’Rgds,
>
> Rony
>
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] sd_bus_add_match callback

[David J]

Question regarding sd_bus_add_match (sd-bus.c):



Is it acceptable (or recommended) to use the same callback for multiple signal 
match and then using the userdata parameter to distinguish among the different 
signals? See the sample code below for a reference of what I am trying to do.



/*Beginning=*/
int callback(sd_bus_message *message, void *userdata, sd_bus_error *error) {
  //there should be a lock applied here?
  if(get_signal_id(userdata) == 1) {
    //do something
  }
}

int main(...) {
  r = sd_bus_add_match(bus, &slot, "type='signal'", test_callback, userdata);
  int r;
  sd_bus *bus = NULL;
  sd_event *event = NULL;
  sd_bus_slot *slot = NULL;

  r = sd_bus_default_system(&bus);
  assert(r >= 0);

  r = sd_event_default(&event);
  assert(r >= 0);

  void *userdata1 = set_signal_id(1);
  r = sd_bus_add_match(bus, &slot, "type='signal',interface='org.interface2'", 
callback, userdata1);

  void *userdata2 = set_signal_id(2);
  r = sd_bus_add_match(bus, &slot, "type='signal',interface='org.interface1'", 
callback, userdata2);

  r = sd_event_loop(event);
  assert(r >= 0);
 
  bus = sd_bus_flush_close_unref(bus);
  slot = sd_bus_slot_unref(slot);
  event = sd_event_unref(event);
}


/*End =*/


I appreciate your help and your time.



Thank you,

David J (ema...@icloud.com)


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

Re: [systemd-devel] sd_bus_add_match callback

[David J]

Hello Systemd developers!

> I asked this question earlier but I haven’t gotten any reply so I thought 
> asking again.

> Question regarding sd_bus_add_match (sd-bus.c):
> 
> Is there any bad consequences to use the same callback for multiple signal 
> match and then using the userdata parameter to distinguish among the 
> different signals? See the sample code below for a reference of what I am 
> trying to do.
> 
> /*Beginning=*/
> int callback(sd_bus_message *message, void *userdata, sd_bus_error *error) {
>   //there should be a lock applied here?
>   if(get_signal_id(userdata) == 1) {
> //do something
>   }
> }
> 
> int main(...) {
>   r = sd_bus_add_match(bus, &slot, "type='signal'", test_callback, userdata);
>   int r;
>   sd_bus *bus = NULL;
>   sd_event *event = NULL;
>   sd_bus_slot *slot = NULL;
> 
>   r = sd_bus_default_system(&bus);
>   assert(r >= 0);
> 
>   r = sd_event_default(&event);
>   assert(r >= 0);
> 
>   void *userdata1 = set_signal_id(1);
>   r = sd_bus_add_match(bus, &slot, 
> "type='signal',interface='org.interface2'", callback, userdata1);
> 
>   void *userdata2 = set_signal_id(2);
>   r = sd_bus_add_match(bus, &slot, 
> "type='signal',interface='org.interface1'", callback, userdata2);
> 
>   r = sd_event_loop(event);
>   assert(r >= 0);
>  
>   bus = sd_bus_flush_close_unref(bus);
>   slot = sd_bus_slot_unref(slot);
>   event = sd_event_unref(event);
> }
> 
> /*End =*/
> 
> I appreciate your help and your time.
> 
> Thank you,
> David J (ema...@icloud.com)


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

Re: [systemd-devel] sd_bus_add_match callback

[David J]

Giacinto,
Thanks for further explaining my email. 

Lennart,
Thank you for your feedback. What I am doing is writing an sd-bus interface and 
a client code, which is only interested in specific signal information. So the 
interface has to offer minimal API’s. The interface has one callback to handle 
all the signal callbacks, processes the messages and populates the information 
for the client code. If you have a better resolution please share.

Side note: I really enjoyed using the sd-bus API’s! Thank you for the awesome 
library.

DJ

Sent from my iPhone

> On Apr 10, 2020, at 10:51 AM, Giacinto Cifelli  wrote:
> 
> hi Lennart,
> 
>> On Fri, Apr 10, 2020 at 2:14 PM Lennart Poettering
>>  wrote:
>> 
>>> On Do, 09.04.20 14:12, David J (ema...@icloud.com) wrote:
>>> 
>>> Hello Systemd developers!
>>> 
>>>> I asked this question earlier but I haven’t gotten any reply so I thought 
>>>> asking again.
>>> 
>>>> Question regarding sd_bus_add_match (sd-bus.c):
>>>> 
>>>> Is there any bad consequences to use the same callback for
>>>> multiple signal match and then using the userdata parameter to
>>>> distinguish among the different signals? See the sample code below
>>>> for a reference of what I am trying to do.
>> 
>> No sure why one would do that, but the userdata argument is something
>> you can use any way you like. Most people stick some context object
>> pointer in it, but it's entirely fine to place anything else there,
>> for example an enum that you cast to a pointer.
> 
> If I understand correctly David's question, he wants to know if he got
> triggered twice on the same event in a single client.
> I am also interested because it could be simple for some application
> to be triggered by two events instead than re-firing a message
> internally.
> 
>> 
>> Lennart
>> 
>> --
>> Lennart Poettering, Berlin
>> ___
>> systemd-devel mailing list
>> systemd-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 
> Thank you,
> Giacinto
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] sd-bus memory check

[David J]

Hello!



This is in regards to sd-bus function "sd_bus_open_system", where Valgrind 
reports possible memory leak. See the following code:



mem_test.c:



#include 
#include 
#include 

int main(int argc, char *argv[]) {
  sd_bus *bus = NULL;

  int r = sd_bus_open_system(&bus);
  if (r < 0) {
    fprintf(stderr, "sd_bus_open_system: %s\n", strerror(-r));
  }
  bus = sd_bus_unref(bus);
}


compile command: gcc mem_test.c -o mem_test `pkg-config --cflags --libs 
libsystemd`


Valgrind output:



==4452== Memcheck, a memory error detector
==4452== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==4452== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==4452== Command: ./mem_test
==4452==
==4452==
==4452== HEAP SUMMARY:
==4452== in use at exit: 7,736 bytes in 12 blocks
==4452==   total heap usage: 17 allocs, 5 frees, 8,045 bytes allocated
==4452==
==4452== LEAK SUMMARY:
==4452==    definitely lost: 0 bytes in 0 blocks
==4452==    indirectly lost: 0 bytes in 0 blocks
==4452==  possibly lost: 3,640 bytes in 11 blocks
==4452==    still reachable: 4,096 bytes in 1 blocks
==4452== suppressed: 0 bytes in 0 blocks



The question is am I doing anything wrong here? Why Valgrind thinks there "might" be 
memory leak? The interesting part is if I use "sd_bus_open_system", Valgrind is all happy 
and no warnings at all!



Thank you,

David J.






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

Re: [systemd-devel] sd-bus memory check

[David J]

Will,

thank you very much. I spent my Sunday debugging this thing! Using 
sd_bus_flush_close_unref() eliminated the memory leak!


Appreciate your help!


On April 12, 2020 at 9:20 PM, William Kennington  
wrote:


You are probably looking for sd_bus_flush_close_unref() for this usecase.


On Sun, Apr 12, 2020 at 11:00 AM David J  wrote:

Hello!



This is in regards to sd-bus function "sd_bus_open_system", where Valgrind 
reports possible memory leak. See the following code:



mem_test.c:



#include 
#include 
#include 

int main(int argc, char *argv[]) {
  sd_bus *bus = NULL;

  int r = sd_bus_open_system(&bus);
  if (r < 0) {
    fprintf(stderr, "sd_bus_open_system: %s\n", strerror(-r));
  }
  bus = sd_bus_unref(bus);
}


compile command: gcc mem_test.c -o mem_test `pkg-config --cflags --libs 
libsystemd`


Valgrind output:



==4452== Memcheck, a memory error detector
==4452== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==4452== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==4452== Command: ./mem_test
==4452==
==4452==
==4452== HEAP SUMMARY:
==4452== in use at exit: 7,736 bytes in 12 blocks
==4452==   total heap usage: 17 allocs, 5 frees, 8,045 bytes allocated
==4452==
==4452== LEAK SUMMARY:
==4452==    definitely lost: 0 bytes in 0 blocks
==4452==    indirectly lost: 0 bytes in 0 blocks
==4452==  possibly lost: 3,640 bytes in 11 blocks
==4452==    still reachable: 4,096 bytes in 1 blocks
==4452== suppressed: 0 bytes in 0 blocks



The question is am I doing anything wrong here? Why Valgrind thinks there "might" be 
memory leak? The interesting part is if I use "sd_bus_open_system", Valgrind is all happy 
and no warnings at all!



Thank you,

David J.







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

[systemd-devel] No signal sent to stop service

[David Cunningham]

Hello,

I'm developing a service called product_routed which is managed by systemd.
The service can normally be stopped with "service product_routed stop" or
"systemctl stop product_routed", however for some reason after the service
has been running for a while (a few days or more) the stop command no
longer works. Can anyone help me find why?

When the application stop works initially (for the first day or two) we see
a TERM signal sent to the application, as confirmed by logging in the
application itself (which is written in perl), and is reported by "strace
-p  -e 'trace=!all'". However once the problem starts no signal is
sent to the application at all when "service product_routed stop" or
"systemctl stop product_routed" is run.

The systemd file is as below, and we've confirmed that the PIDFile contains
the correct PID when the stop is attempted. Would anyone have any
suggestions on how to debug this? Thank you in advance.

# cat /etc/systemd/system/product_routed.service
[Unit]
Description=Product routing daemon
After=syslog.target network.target mysql.service

[Service]
Type=forking
ExecStart=/opt/product/current/bin/routed
PIDFile=/var/run/product/routed.pid
Restart=on-abnormal
RestartSec=1
LimitSTACK=infinity
LimitNOFILE=65535
LimitNPROC=65535

[Install]
WantedBy=multi-user.target


-- 
David Cunningham, Voisonics Limited
http://voisonics.com/
USA: +1 213 221 1092
New Zealand: +64 (0)28 2558 3782
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] No signal sent to stop service

[David Cunningham]

Hello Lennart and Michal,

Thank you for your replies. The cgroup file is below - can you please
advise what is the relevant part to check?

The problem is most likely with systemd thinking the program is stopped
because "systemctl status" reports:
Aug 10 03:57:32 myhost systemd[1]: product_routed.service: Main process
exited, code=exited, status=1/FAILURE
Aug 10 03:57:32 myhost systemd[1]: product_routed.service: Failed with
result 'exit-code'.

We will look into that, thank you.

# cat /proc/17824/cgroup
12:memory:/
11:pids:/user.slice/user-0.slice/session-623.scope
10:rdma:/
9:hugetlb:/
8:blkio:/
7:devices:/user.slice
6:cpuset:/
5:net_cls,net_prio:/
4:freezer:/
3:perf_event:/
2:cpu,cpuacct:/user.slice/user-0.slice/session-623.scope
1:name=systemd:/user.slice/user-0.slice/session-623.scope
0::/user.slice/user-0.slice/session-623.scope


On Tue, 11 Aug 2020 at 03:08, Lennart Poettering 
wrote:

> On Do, 06.08.20 13:59, David Cunningham (dcunning...@voisonics.com) wrote:
>
> > Hello,
> >
> > I'm developing a service called product_routed which is managed by
> systemd.
> > The service can normally be stopped with "service product_routed stop" or
> > "systemctl stop product_routed", however for some reason after the
> service
> > has been running for a while (a few days or more) the stop command no
> > longer works. Can anyone help me find why?
> >
> > When the application stop works initially (for the first day or two) we
> see
> > a TERM signal sent to the application, as confirmed by logging in the
> > application itself (which is written in perl), and is reported by "strace
> > -p  -e 'trace=!all'". However once the problem starts no signal is
> > sent to the application at all when "service product_routed stop" or
> > "systemctl stop product_routed" is run.
>
> Note that on systemd for a unit that is already stopped issuing
> another "systemctl stop" is a NOP and doesnt result in another SIGTERM
> to be sent
>
> So, when you issue your second "systemctl stop", is the service
> actually running in systemd's eyes? (i.e. what does "systemctl status"
> say about the service?)
>
> > The systemd file is as below, and we've confirmed that the PIDFile
> contains
> > the correct PID when the stop is attempted. Would anyone have any
> > suggestions on how to debug this? Thank you in advance.
> >
> > # cat /etc/systemd/system/product_routed.service
> > [Unit]
> > Description=Product routing daemon
> > After=syslog.target network.target mysql.service
> >
> > [Service]
> > Type=forking
> > ExecStart=/opt/product/current/bin/routed
> > PIDFile=/var/run/product/routed.pid
> > Restart=on-abnormal
> > RestartSec=1
> > LimitSTACK=infinity
> > LimitNOFILE=65535
> > LimitNPROC=65535
> >
> > [Install]
> > WantedBy=multi-user.target
>
> Please provide the "sytemctl status" output when this happens.
>
> Lennart
>
> --
> Lennart Poettering, Berlin
>


-- 
David Cunningham, Voisonics Limited
http://voisonics.com/
USA: +1 213 221 1092
New Zealand: +64 (0)28 2558 3782
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Confusing hwdb matching behaviour

[David Herrmann]

Hey!

On Wed, Aug 31, 2016 at 6:37 AM, Peter Hutterer
 wrote:
> The hwdb behaviour is a bit hard to predict when multiple matches with globs
> apply to a device so I'm wondering whether this is just an implementation
> result or intended behaviour.
>
> Example 1:
> $> cat 99-test.hwdb
> test:*
>  match=generic
>
> test:specific*
>  match=specific
>
> $> systemd-hwdb  query "test:specific_match"
> match=specific
>
> This is what I would expect from the hwdb entries. But if we have a rule where
> glob matches before specific, the generic one overwrites the specific one:
>
> Example 2:
> $> cat 99-test.hwdb
> test:*
>  match=generic
>
> test:*specific*
>  match=specific
>  match2=yep
>
> $> systemd-hwdb  query "test:specific_match"
> match=generic
> match2=yep
>
> Definitely not what I expected (note: the order of the entries
> doesn't matter). This is actually a problem for libinput because it means we
> can't overwrite generic matches with specific matches.
> But it gets even weirder once we start stacking more:
>
> Example 3:
> $> cat 99-test.hwdb
> test:*
>  match=generic
>
> test:*specific*
>  match=specific
>  match2=yep
>
> test:*specific_match
>  match=specific
>  match2=nope
>  match3=yep
>
> $> sudo systemd-hwdb  query "test:specific_match"
> match=generic
> match2=nope
> match3=yep
>
> It picks the most generic one last but the more specific one over the less
> specific one. This is confusing and hard to predict. But it gets worse:
>
> Example 4:
> $> cat 99-test.hwdb
> test:*
>  match=generic
>
> test:*specific*
>  match=specific
>  match2=yep
>
> test:*spe*match
>  match=specific
>  match2=nope
>  match3=yep
>
> test:*specific*match
>  match=specific
>  match2=oh
>  match3=what
>  match4=confused
>
> $> sudo systemd-hwdb  query "test:specific_match"
> match=generic
> match2=yep
> match3=what
> match4=confused
>
> And now I'm lost :)
> As a homework, try predicting what this one produces:
>
> Exercise:
> test:*
>  MATCH=generic
>
> # changing this to test:specific gives different results
> test:*specific*
>  MATCH=specific
>  MATCH2=yep
>
> test:*spe*match
>  MATCH=specific
>  MATCH2=nope
>  MATCH3=yep
>
> test:*specific_*
>  MATCH=specific
>  MATCH2=oh
>  MATCH3=crap
>  MATCH4=what?
>
> test:*specific*match
>  MATCH=specific
>  MATCH2=doh
>  MATCH3=what
>  MATCH4=confused
>  MATCH5=boo
>
>
> Solution:
> "generic, oh, crap, what?, boo" with the glob, without the glob it's
> "specific, yep, crap, what?, boo"
>
> So the question is: is this the intended behaviour (if so, we should
> document it and make it official) or is this a side-effect. If that, can we
> change it or is it set in stone? I think no-one but me is currently eagerly
> stacking hwdb snippets, so maybe there's room to move.

The matching order always matches children before a node itself, and
children in alphabetical order (ASCII). The trie is built based on
prefix-matches. So parsing order does not matter. Lets look at your
last example (with both possible scenarios):

test:*
test:specific
test:*specific*
test:*spe*match
test:*specific_*
test:*specific*match

This will be searched in this order:

test:*spe*match
test:*specific*match
test:*specific*
test:*specific_*
test:*
test:specific

(Ascii order: '*' < UPPER-CASE < '_' < LOWER-CASE)
(Later matches override properties of earlier matches)

I'm not saying this is a useful order, I'm just describing what the
code currently does.

> As for expected behaviour, I'd intuitively expect a more sequential matching,
> with an entry in 99-test.hwd overwriting whatever entry was in 10-test.hwdb.

If things are not stored in ASCII order, you break bsearch() and
lookup performance would drop.

A much easier solution would be to use multiple virtual tries: Prefix
your generic matches with "test-generic:*foobar*" and your specific
ones with "test-specific:*foobar*" and then always lookup both. This
obviously only works if the number of levels is static.

As a hack, I think you can use "**", "***", ... to change the ordering
to your needs.

We could also say each hwdb-source gets its own virtual trie and
they're searched in alphabetical order. This would break ABI, but
would make it a lot more powerful.

Not sure. Maybe Kay has some comments?
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] bus1, dbus(-daemon) and systemd

[David Herrmann]

Hey

On Sat, Oct 1, 2016 at 1:30 PM, Michael Biebl  wrote:
> Hi,
>
> I've been watching the bus1 presentation from this years systemd.conf
> (thanks a lot for the video team btw for doing a stellar job).
>
> What didn't become clear to me i, how bus1, dbus(-daemon) and systemd
> are supposed to fit together in the future.
>
> If I understood David correctly, bus1 is not meant as a drop-in
> replacement for dbus-daemon, but rather provide some simpler, lower
> level communication primitives.

Yes!

> In an earlier talk by Lennart, he mentioned that systemd will
> (re)implement dbus-daemon.
> Would this reimplmentation be based on bus1 or be a completely
> separate re-implementation *not* using bus1?

The idea of re-implementing dbus-daemon with sd-bus (in systemd) is
much older than bus1. I don't think we ever discussed it with bus1 in
mind.

> Such a hypothetical dbus-daemon replacement based on bus1, how would
> this look like and what would systemd's role be there?
>
> I would guess you already thought about that and you already have
> plans in that regard.
> Would be great if you can share them with us.

There are many issues with dbus-daemon. Some can be solved with a
simple re-implementation and fixing the known issues, others cannot.
The bus1 transport does not magically solve them, either. However, we
do have ideas how to make use of bus1 capabilities to allow direct
channels between peers, without breaking with dbus semantics.
Furthermore, we have discussed subscription-models over match-rules
that would even allow to do broadcasts/multicasts without requiring a
broker.

We are currently doing a reevaluation of our ideas and writing them
up. The intention is to get a dbus-daemon drop-in extended with
optional bus1 features.

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

Re: [systemd-devel] [PATCH] hostnamed: regard convertible chassis type as laptop

[David Herrmann]

Hey Jani!

On Fri, Feb 24, 2017 at 4:16 PM, Jani Nikula  wrote:
> On Fri, 24 Feb 2017, Jani Nikula  wrote:
>> While both the DMI and ACPI data are regarded as unreliable in hostnamed
>> source, consumers of the chassis type use it to make rather drastic
>> policy decisions.
>
> BTW, since the implementation seems to think the data is unreliable,
> perhaps it would be prudent to say so in hostnamectl documentation, so
> the consumers of the data might be more thoughtful about what to use it
> for?

Turned into a github PR [1]. Can we continue the discussion there?

Thanks
David

[1] https://github.com/systemd/systemd/pull/5475
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] 3CX PhoneSystem 01 Management Console won't start

[David Strauss]

This failure is not from systemd; systemd is only the messenger:

> Mar 07 11:08:09 3CX systemd[1]: 3CXPhoneSystemMC01.service start
operation timed out. Terminating.

Someone needs to troubleshoot why 3CXPhoneSystemMC01.service is hanging
when it tries to start, and this list can't answer that. You should contact
the vendor behind 3CX or check any log files the service might be creating
on its own.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd reboot problem

[David Strauss]

> But I don't want to wait for those services to shutdown.

Then there's no reason to interact with systemd if you want to force an
immediate, unclean reboot. You just want something like the reboot syscall
with LINUX_REBOOT_CMD_RESTART.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to unset "uaccess" tag in udev rule?

[David Herrmann]

Hi

On Tue, Mar 14, 2017 at 10:44 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Sun, Mar 12, 2017 at 07:38:13PM +0100, Manuel Reimer wrote:
>> Hello,
>>
>> my distributor sets the following rule in /usr/lib/udev/rules.d:
>>
>> KERNEL=="uinput", SUBSYSTEM=="misc", OPTIONS+="static_node=uinput",
>> TAG+="uaccess"
>>
>> I think this is not a good idea and that there is a good reason why
>> users can't create uinput devices, so I want to get rid of that
>> rule.
>>
>> So far I did this by creating an empty file with the same name in
>> /etc/udev/rules.d which works well, but for no reason the name was
>> changed some time ago which overrides my empty file and reactivates
>> the problematic rule.
> That's the only way. Tags cannot be unset.

Use TAG-="foobar".

Thanks
David


commit 8e3ba3772cadf6a8292b0da533062dd4d377af67
Author: David Herrmann 
Date:   Thu Sep 11 13:25:21 2014 +0200

udev: allow removing tags via TAG-="foobar"

This extends the udev parser to support OP_REMOVE (-=) and adds support
for TAG-= to remove previously set tags. We don't fail if the tag didn't
exist.

This is pretty handy if we ship default rules for seat-assignments and
users want to exclude specific devices from that. They can easily add
rules that drop any automatically added "seat" tags again.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to unset "uaccess" tag in udev rule?

[David Herrmann]

Hi

On Sun, Mar 26, 2017 at 8:07 PM, Manuel Reimer
 wrote:
> On 03/25/2017 05:16 PM, David Herrmann wrote:
>>>>
>>>> So far I did this by creating an empty file with the same name in
>>>> /etc/udev/rules.d which works well, but for no reason the name was
>>>> changed some time ago which overrides my empty file and reactivates
>>>> the problematic rule.
>>>
>>> That's the only way. Tags cannot be unset.
>>
>>
>> Use TAG-="foobar".
>
>
> I've tried that and it doesn't work.

The `-=' operator was introduced for exactly this use-case (which the
commit I quoted should explain). If it does not work, it has to be
fixed. Last time I checked, it worked.

Hence, if you need help using it, please give us as much information
as possible. Please verify the operator works with something that is
not already used (set some random TAG and remove it again, check with
`udevadm` whether it works).

If you have no clue how to debug it yourself, please specify _what_
you changed, what systemd version / distro / etc., you're running, so
we can reproduce it and help you further.

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

[systemd-devel] sd-bus: ObjectManager difference with gdbus

[David Härdeman]

Hi,

I'm implementing a server which creates an ObjectManager using the
sd-bus API and there seems to be some differences between how gdbus and
sd-bus implements the API.

I implemented a simple ObjectManager at /org/gnome/TestManager which
exports objects /org/gnome/TestManager/fooX with interface
org.gnome.TestManager.Device.

Under sd-bus, if an object is removed, the following signal is
generated:

signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
serial=90 path=/org/gnome/TestManager;
interface=org.freedesktop.DBus.ObjectManager;
member=InterfacesRemoved
   object path "/org/gnome/TestManager/foo0"
   array [
  string "org.freedesktop.DBus.Peer"
  string "org.freedesktop.DBus.Introspectable"
  string "org.freedesktop.DBus.Properties"
  string "org.freedesktop.DBus.ObjectManager"
  string "org.gnome.TestManager.Device"
   ]

If I implement the same simple server in gdbus, the signal is instead:

signal time=1492642227.714223 sender=:1.104 -> destination=(null destination) 
serial=90 path=/org/gnome/TestManager;
interface=org.freedesktop.DBus.ObjectManager;
member=InterfacesRemoved
   object path "/org/gnome/TestManager/foo0"
   array [
  string "org.gnome.TestManager.Device"
   ]

The corresponding signals are also generated when an object is added.

Beside simply being different, this difference seems to confuse gdbus.
If I create a test client, it will report that any object which is
already existing when I start the client has 1 interface and any object
which is added/removed subsequently is reported as having 5 interfaces,
4 of which are nameless (this would appear to be one or more gdbus
bug(s)).

This bug in gdbus also means that it doesn't correctly catch the removal
of an object which existed at the time the client was started (because
of the interface count mismatch).

Anyway, gdbus bugs aside, it seems that the interfaces reported by
sd-bus should match what gdbus does? (assuming, of course, that gdbus
can be considered the "reference" implementation).

Regards,
David

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

Re: [systemd-devel] sd-bus: ObjectManager difference with gdbus

[David Herrmann]

Hey

On Thu, Apr 20, 2017 at 12:06 PM, David Härdeman  wrote:
> Hi,
>
> I'm implementing a server which creates an ObjectManager using the
> sd-bus API and there seems to be some differences between how gdbus and
> sd-bus implements the API.
>
> I implemented a simple ObjectManager at /org/gnome/TestManager which
> exports objects /org/gnome/TestManager/fooX with interface
> org.gnome.TestManager.Device.
>
> Under sd-bus, if an object is removed, the following signal is
> generated:
>
> signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
> serial=90 path=/org/gnome/TestManager;
> interface=org.freedesktop.DBus.ObjectManager;
> member=InterfacesRemoved
>object path "/org/gnome/TestManager/foo0"
>array [
>   string "org.freedesktop.DBus.Peer"
>   string "org.freedesktop.DBus.Introspectable"
>   string "org.freedesktop.DBus.Properties"
>   string "org.freedesktop.DBus.ObjectManager"
>   string "org.gnome.TestManager.Device"
>]
>
> If I implement the same simple server in gdbus, the signal is instead:
>
> signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
> serial=90 path=/org/gnome/TestManager;
> interface=org.freedesktop.DBus.ObjectManager;
> member=InterfacesRemoved
>object path "/org/gnome/TestManager/foo0"
>array [
>   string "org.gnome.TestManager.Device"
>]
>
> The corresponding signals are also generated when an object is added.
>
> Beside simply being different, this difference seems to confuse gdbus.
> If I create a test client, it will report that any object which is
> already existing when I start the client has 1 interface and any object
> which is added/removed subsequently is reported as having 5 interfaces,
> 4 of which are nameless (this would appear to be one or more gdbus
> bug(s)).
>
> This bug in gdbus also means that it doesn't correctly catch the removal
> of an object which existed at the time the client was started (because
> of the interface count mismatch).
>
> Anyway, gdbus bugs aside, it seems that the interfaces reported by
> sd-bus should match what gdbus does? (assuming, of course, that gdbus
> can be considered the "reference" implementation).

Does the appended patch fix your issue?
(line-breaks might be screwed, sorry)

Thanks
David


diff --git a/src/libsystemd/sd-bus/bus-objects.c
b/src/libsystemd/sd-bus/bus-objects.c
index 9bd07ffca..b6f5afe1b 100644
--- a/src/libsystemd/sd-bus/bus-objects.c
+++ b/src/libsystemd/sd-bus/bus-objects.c
@@ -1057,6 +1057,22 @@ static int object_manager_serialize_path(
 if (r < 0)
 return r;

+r = sd_bus_message_append(reply, "{sa{sv}}",
"org.freedesktop.DBus.Peer", 0);
+if (r < 0)
+return r;
+
+r = sd_bus_message_append(reply, "{sa{sv}}",
"org.freedesktop.DBus.Introspectable", 0);
+if (r < 0)
+return r;
+
+r = sd_bus_message_append(reply, "{sa{sv}}",
"org.freedesktop.DBus.Properties", 0);
+if (r < 0)
+return r;
+
+r = sd_bus_message_append(reply, "{sa{sv}}",
"org.freedesktop.DBus.ObjectManager", 0);
+if (r < 0)
+return r;
+
 found_something = true;
 }
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sd-bus: ObjectManager difference with gdbus

[David Härdeman]

On Thu, Apr 20, 2017 at 02:19:22PM +0200, David Herrmann wrote:
>On Thu, Apr 20, 2017 at 12:06 PM, David Härdeman  wrote:
>> Hi,
>>
>> I'm implementing a server which creates an ObjectManager using the
>> sd-bus API and there seems to be some differences between how gdbus and
>> sd-bus implements the API.
>>
>> I implemented a simple ObjectManager at /org/gnome/TestManager which
>> exports objects /org/gnome/TestManager/fooX with interface
>> org.gnome.TestManager.Device.
>>
>> Under sd-bus, if an object is removed, the following signal is
>> generated:
>>
>> signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
>> serial=90 path=/org/gnome/TestManager;
>> interface=org.freedesktop.DBus.ObjectManager;
>> member=InterfacesRemoved
>>object path "/org/gnome/TestManager/foo0"
>>array [
>>   string "org.freedesktop.DBus.Peer"
>>   string "org.freedesktop.DBus.Introspectable"
>>   string "org.freedesktop.DBus.Properties"
>>   string "org.freedesktop.DBus.ObjectManager"
>>   string "org.gnome.TestManager.Device"
>>]
>>
>> If I implement the same simple server in gdbus, the signal is instead:
>>
>> signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
>> serial=90 path=/org/gnome/TestManager;
>> interface=org.freedesktop.DBus.ObjectManager;
>> member=InterfacesRemoved
>>object path "/org/gnome/TestManager/foo0"
>>array [
>>   string "org.gnome.TestManager.Device"
>>]
>>
>> The corresponding signals are also generated when an object is added.
>>
>> Beside simply being different, this difference seems to confuse gdbus.
>> If I create a test client, it will report that any object which is
>> already existing when I start the client has 1 interface and any object
>> which is added/removed subsequently is reported as having 5 interfaces,
>> 4 of which are nameless (this would appear to be one or more gdbus
>> bug(s)).
>>
>> This bug in gdbus also means that it doesn't correctly catch the removal
>> of an object which existed at the time the client was started (because
>> of the interface count mismatch).
>>
>> Anyway, gdbus bugs aside, it seems that the interfaces reported by
>> sd-bus should match what gdbus does? (assuming, of course, that gdbus
>> can be considered the "reference" implementation).
>
>Does the appended patch fix your issue?
>(line-breaks might be screwed, sorry)

Haven't tried it yet, but just from reading the patch...it seems to do
the opposite of what I'd expect? I.e. add *more* interfaces?

>diff --git a/src/libsystemd/sd-bus/bus-objects.c
>b/src/libsystemd/sd-bus/bus-objects.c
>index 9bd07ffca..b6f5afe1b 100644
>--- a/src/libsystemd/sd-bus/bus-objects.c
>+++ b/src/libsystemd/sd-bus/bus-objects.c
>@@ -1057,6 +1057,22 @@ static int object_manager_serialize_path(
> if (r < 0)
> return r;
>
>+r = sd_bus_message_append(reply, "{sa{sv}}",
>"org.freedesktop.DBus.Peer", 0);
>+if (r < 0)
>+return r;
>+
>+r = sd_bus_message_append(reply, "{sa{sv}}",
>"org.freedesktop.DBus.Introspectable", 0);
>+    if (r < 0)
>+return r;
>+
>+r = sd_bus_message_append(reply, "{sa{sv}}",
>"org.freedesktop.DBus.Properties", 0);
>+if (r < 0)
>+return r;
>+
>+r = sd_bus_message_append(reply, "{sa{sv}}",
>"org.freedesktop.DBus.ObjectManager", 0);
>+if (r < 0)
>+return r;
>+
> found_something = true;
> }

-- 
David Härdeman
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sd-bus: ObjectManager difference with gdbus

[David Herrmann]

Hi

On Fri, Apr 21, 2017 at 11:50 AM, David Härdeman  wrote:
> On Thu, Apr 20, 2017 at 02:19:22PM +0200, David Herrmann wrote:
>>On Thu, Apr 20, 2017 at 12:06 PM, David Härdeman  wrote:
>>> Hi,
>>>
>>> I'm implementing a server which creates an ObjectManager using the
>>> sd-bus API and there seems to be some differences between how gdbus and
>>> sd-bus implements the API.
>>>
>>> I implemented a simple ObjectManager at /org/gnome/TestManager which
>>> exports objects /org/gnome/TestManager/fooX with interface
>>> org.gnome.TestManager.Device.
>>>
>>> Under sd-bus, if an object is removed, the following signal is
>>> generated:
>>>
>>> signal time=1492642227.714223 sender=:1.104 -> destination=(null 
>>> destination)
>>> serial=90 path=/org/gnome/TestManager;
>>> interface=org.freedesktop.DBus.ObjectManager;
>>> member=InterfacesRemoved
>>>object path "/org/gnome/TestManager/foo0"
>>>array [
>>>   string "org.freedesktop.DBus.Peer"
>>>   string "org.freedesktop.DBus.Introspectable"
>>>   string "org.freedesktop.DBus.Properties"
>>>   string "org.freedesktop.DBus.ObjectManager"
>>>   string "org.gnome.TestManager.Device"
>>>]
>>>
>>> If I implement the same simple server in gdbus, the signal is instead:
>>>
>>> signal time=1492642227.714223 sender=:1.104 -> destination=(null 
>>> destination)
>>> serial=90 path=/org/gnome/TestManager;
>>> interface=org.freedesktop.DBus.ObjectManager;
>>> member=InterfacesRemoved
>>>object path "/org/gnome/TestManager/foo0"
>>>array [
>>>   string "org.gnome.TestManager.Device"
>>>]
>>>
>>> The corresponding signals are also generated when an object is added.
>>>
>>> Beside simply being different, this difference seems to confuse gdbus.
>>> If I create a test client, it will report that any object which is
>>> already existing when I start the client has 1 interface and any object
>>> which is added/removed subsequently is reported as having 5 interfaces,
>>> 4 of which are nameless (this would appear to be one or more gdbus
>>> bug(s)).
>>>
>>> This bug in gdbus also means that it doesn't correctly catch the removal
>>> of an object which existed at the time the client was started (because
>>> of the interface count mismatch).
>>>
>>> Anyway, gdbus bugs aside, it seems that the interfaces reported by
>>> sd-bus should match what gdbus does? (assuming, of course, that gdbus
>>> can be considered the "reference" implementation).
>>
>>Does the appended patch fix your issue?
>>(line-breaks might be screwed, sorry)
>
> Haven't tried it yet, but just from reading the patch...it seems to do
> the opposite of what I'd expect? I.e. add *more* interfaces?

This change makes sure all objects have the built-in interfaces
reported at all times. The GetManagedObjects() call didn't report them
so far.

Note that we really better report all interfaces an object supports. I
don't know why glib does not do this, but I think it should.

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

Re: [systemd-devel] sd-bus: ObjectManager difference with gdbus

[David Härdeman]

April 24, 2017 4:51 PM, "Lennart Poettering"  wrote:

> On Fri, 21.04.17 13:22, David Herrmann (dh.herrm...@gmail.com) wrote:
> 
>> Anyway, gdbus bugs aside, it seems that the interfaces reported by
>> sd-bus should match what gdbus does? (assuming, of course, that gdbus
>> can be considered the "reference" implementation).
>> 
>> Does the appended patch fix your issue?
>> (line-breaks might be screwed, sorry)
>> 
>> Haven't tried it yet, but just from reading the patch...it seems to do
>> the opposite of what I'd expect? I.e. add *more* interfaces?
>> 
>> This change makes sure all objects have the built-in interfaces
>> reported at all times. The GetManagedObjects() call didn't report them
>> so far.
>> 
>> Note that we really better report all interfaces an object supports. I
>> don't know why glib does not do this, but I think it should.
> 
> Yeah, I#d agree with that. I think we should provide complete
> information, and that means including built-in interfaces in all our
> messages, in particular as some of them are optional. It appears to
> me, that gdbus should be changed here, not sd-bus...

In that case, no changes are necessary to sd-bus since it already exposes all 
interfaces.

I've filed a bug report against gdbus:
https://bugzilla.gnome.org/show_bug.cgi?id=781524

Regards,
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sd-bus: ObjectManager difference with gdbus

[David Härdeman]

April 21, 2017 1:22 PM, "David Herrmann"  wrote:
> On Fri, Apr 21, 2017 at 11:50 AM, David Härdeman  wrote:
>> On Thu, Apr 20, 2017 at 02:19:22PM +0200, David Herrmann wrote:
>>> On Thu, Apr 20, 2017 at 12:06 PM, David Härdeman  wrote:
>> I'm implementing a server which creates an ObjectManager using the
>> sd-bus API and there seems to be some differences between how gdbus and
>> sd-bus implements the API.
>> 
>> I implemented a simple ObjectManager at /org/gnome/TestManager which
>> exports objects /org/gnome/TestManager/fooX with interface
>> org.gnome.TestManager.Device.
>> 
>> Under sd-bus, if an object is removed, the following signal is
>> generated:
>> 
>> signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
>> serial=90 path=/org/gnome/TestManager;
>> interface=org.freedesktop.DBus.ObjectManager;
>> member=InterfacesRemoved
>> object path "/org/gnome/TestManager/foo0"
>> array [
>> string "org.freedesktop.DBus.Peer"
>> string "org.freedesktop.DBus.Introspectable"
>> string "org.freedesktop.DBus.Properties"
>> string "org.freedesktop.DBus.ObjectManager"
>> string "org.gnome.TestManager.Device"
>> ]
>> 
>> If I implement the same simple server in gdbus, the signal is instead:
>> 
>> signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
>> serial=90 path=/org/gnome/TestManager;
>> interface=org.freedesktop.DBus.ObjectManager;
>> member=InterfacesRemoved
>> object path "/org/gnome/TestManager/foo0"
>> array [
>> string "org.gnome.TestManager.Device"
>> ]
>> 
>> The corresponding signals are also generated when an object is added.

>>> Does the appended patch fix your issue?
>>> (line-breaks might be screwed, sorry)
>> 
>> Haven't tried it yet, but just from reading the patch...it seems to do
>> the opposite of what I'd expect? I.e. add *more* interfaces?
> 
> This change makes sure all objects have the built-in interfaces
> reported at all times. The GetManagedObjects() call didn't report them
> so far.

Quite the contrary? If you look at the output from dbus-monitor above, you'll 
see that it is sd-bus that already *does* report all interfaces while gdbus 
doesnt?
 
> Note that we really better report all interfaces an object supports. I
> don't know why glib does not do this, but I think it should.

Maybe, I'm no dbus expert. And there does seem to be a bug in gdbus as well 
since the additional interfaces manage to confuse it. Anyway, it seems that 
either sd-bus should adapt the gdbus style or vice versa...maybe you could talk 
directly to the gdbus people?

Regards,
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sd-bus: ObjectManager difference with gdbus

[David Härdeman]

April 24, 2017 5:49 PM, "Dan Williams"  wrote:
> On Mon, 2017-04-24 at 16:50 +0200, Lennart Poettering wrote:
>> On Fri, 21.04.17 13:22, David Herrmann (dh.herrm...@gmail.com) wrote:
>> 
>>>>> Anyway, gdbus bugs aside, it seems that the interfaces
>>>>> reported by
>>>>> sd-bus should match what gdbus does? (assuming, of course,
>>>>> that gdbus
>>>>> can be considered the "reference" implementation).
>>>> 
>>>> Does the appended patch fix your issue?
>>>> (line-breaks might be screwed, sorry)
>>> 
>>> Haven't tried it yet, but just from reading the patch...it seems
>>> to do
>>> the opposite of what I'd expect? I.e. add *more* interfaces?
>> 
>> This change makes sure all objects have the built-in interfaces
>> reported at all times. The GetManagedObjects() call didn't report
>> them
>> so far.
>> 
>> Note that we really better report all interfaces an object
>> supports. I
>> don't know why glib does not do this, but I think it should.
>> 
>> Yeah, I#d agree with that. I think we should provide complete
>> information, and that means including built-in interfaces in all our
>> messages, in particular as some of them are optional. It appears to
>> me, that gdbus should be changed here, not sd-bus...
> 
> It's not clear that the GNOME side was implemented correctly yet.
> Would be nice to see the sample code.
> 
> Dan

My GNOME-based client was based on the gdbus-example-objectmanager-client.c so 
I hope it's correct, but sure, I'll try to pare down the GNOME/gdbus-based 
client code and the (sd-bus based) server code to two simple test cases and 
provide those later this week.

Regards,
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sd-bus: ObjectManager difference with gdbus

[David Herrmann]

Hi

On Tue, Apr 25, 2017 at 9:40 AM, David Härdeman  wrote:
> April 21, 2017 1:22 PM, "David Herrmann"  wrote:
>> On Fri, Apr 21, 2017 at 11:50 AM, David Härdeman  wrote:
>>> On Thu, Apr 20, 2017 at 02:19:22PM +0200, David Herrmann wrote:
>>>> On Thu, Apr 20, 2017 at 12:06 PM, David Härdeman  wrote:
>>> I'm implementing a server which creates an ObjectManager using the
>>> sd-bus API and there seems to be some differences between how gdbus and
>>> sd-bus implements the API.
>>>
>>> I implemented a simple ObjectManager at /org/gnome/TestManager which
>>> exports objects /org/gnome/TestManager/fooX with interface
>>> org.gnome.TestManager.Device.
>>>
>>> Under sd-bus, if an object is removed, the following signal is
>>> generated:
>>>
>>> signal time=1492642227.714223 sender=:1.104 -> destination=(null 
>>> destination)
>>> serial=90 path=/org/gnome/TestManager;
>>> interface=org.freedesktop.DBus.ObjectManager;
>>> member=InterfacesRemoved
>>> object path "/org/gnome/TestManager/foo0"
>>> array [
>>> string "org.freedesktop.DBus.Peer"
>>> string "org.freedesktop.DBus.Introspectable"
>>> string "org.freedesktop.DBus.Properties"
>>> string "org.freedesktop.DBus.ObjectManager"
>>> string "org.gnome.TestManager.Device"
>>> ]
>>>
>>> If I implement the same simple server in gdbus, the signal is instead:
>>>
>>> signal time=1492642227.714223 sender=:1.104 -> destination=(null 
>>> destination)
>>> serial=90 path=/org/gnome/TestManager;
>>> interface=org.freedesktop.DBus.ObjectManager;
>>> member=InterfacesRemoved
>>> object path "/org/gnome/TestManager/foo0"
>>> array [
>>> string "org.gnome.TestManager.Device"
>>> ]
>>>
>>> The corresponding signals are also generated when an object is added.
> 
>>>> Does the appended patch fix your issue?
>>>> (line-breaks might be screwed, sorry)
>>>
>>> Haven't tried it yet, but just from reading the patch...it seems to do
>>> the opposite of what I'd expect? I.e. add *more* interfaces?
>>
>> This change makes sure all objects have the built-in interfaces
>> reported at all times. The GetManagedObjects() call didn't report them
>> so far.
>
> Quite the contrary? If you look at the output from dbus-monitor above, you'll 
> see that it is sd-bus that already *does* report all interfaces while gdbus 
> doesnt?

No, it does not. sd-bus was inconsistent. See, there are 3 things
involved in the Object-Manager:

Signal: InterfacesAdded
Signal: InterfacesRemoved
Call: GetManagedObjects

The first two signals are used to add and remove objects (and their
respective interfaces) at runtime. The GetManagedObjects() call is
used to bootstrap, that is, to get the initial set of objects (and
their respective interfaces) when starting your application.

So far, sd-bus reported the builtin interfaces correctly via the
signals, but did not return that information in the
GetManagedObjects() call. My patch fixed this omission.
The effect of this is that objects added/removed at runtime work fine,
but if an object was there already when your application starts, then
it will never be removed, since gdbus will see an interface-count
mismatch (as you observed above).

Hence, the patch I provided fixes how sd-bus provides this
information. It does *not* change any policy.

I think the 2 underlying problems you saw are bugs in both gdbus and
sd-bus. The one in sd-bus I tried to fix above, the one in gdbus is
only about counting interfaces and properly detecting negative
interface-counts. The gdbus bug is non-severe, though, since it
originates in a buggy remote client. So there is no hard reason to
change gdbus there.

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

Re: [systemd-devel] sd-bus: ObjectManager difference with gdbus

[David Härdeman]

April 25, 2017 9:54 AM, "David Herrmann"  wrote:

> Hi
> 
> On Tue, Apr 25, 2017 at 9:40 AM, David Härdeman  wrote:
> 
>> April 21, 2017 1:22 PM, "David Herrmann"  wrote:
>>> On Fri, Apr 21, 2017 at 11:50 AM, David Härdeman  wrote:
>> 
>> On Thu, Apr 20, 2017 at 02:19:22PM +0200, David Herrmann wrote:
>> On Thu, Apr 20, 2017 at 12:06 PM, David Härdeman  wrote:
>> I'm implementing a server which creates an ObjectManager using the
>> sd-bus API and there seems to be some differences between how gdbus and
>> sd-bus implements the API.
>> 
>> I implemented a simple ObjectManager at /org/gnome/TestManager which
>> exports objects /org/gnome/TestManager/fooX with interface
>> org.gnome.TestManager.Device.
>> 
>> Under sd-bus, if an object is removed, the following signal is
>> generated:
>> 
>> signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
>> serial=90 path=/org/gnome/TestManager;
>> interface=org.freedesktop.DBus.ObjectManager;
>> member=InterfacesRemoved
>> object path "/org/gnome/TestManager/foo0"
>> array [
>> string "org.freedesktop.DBus.Peer"
>> string "org.freedesktop.DBus.Introspectable"
>> string "org.freedesktop.DBus.Properties"
>> string "org.freedesktop.DBus.ObjectManager"
>> string "org.gnome.TestManager.Device"
>> ]
>> 
>> If I implement the same simple server in gdbus, the signal is instead:
>> 
>> signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
>> serial=90 path=/org/gnome/TestManager;
>> interface=org.freedesktop.DBus.ObjectManager;
>> member=InterfacesRemoved
>> object path "/org/gnome/TestManager/foo0"
>> array [
>> string "org.gnome.TestManager.Device"
>> ]
>> 
>> The corresponding signals are also generated when an object is added.
>> 
>> Does the appended patch fix your issue?
>> (line-breaks might be screwed, sorry)
>> 
>> Haven't tried it yet, but just from reading the patch...it seems to do
>> the opposite of what I'd expect? I.e. add *more* interfaces?
>>> This change makes sure all objects have the built-in interfaces
>>> reported at all times. The GetManagedObjects() call didn't report them
>>> so far.
>> 
>> Quite the contrary? If you look at the output from dbus-monitor above, 
>> you'll see that it is sd-bus
>> that already *does* report all interfaces while gdbus doesnt?
> 
> No, it does not. sd-bus was inconsistent. See, there are 3 things
> involved in the Object-Manager:
> 
> Signal: InterfacesAdded
> Signal: InterfacesRemoved
> Call: GetManagedObjects
> 
> The first two signals are used to add and remove objects (and their
> respective interfaces) at runtime. The GetManagedObjects() call is
> used to bootstrap, that is, to get the initial set of objects (and
> their respective interfaces) when starting your application.
> 
> So far, sd-bus reported the builtin interfaces correctly via the
> signals, but did not return that information in the
> GetManagedObjects() call. My patch fixed this omission.
> The effect of this is that objects added/removed at runtime work fine,
> but if an object was there already when your application starts, then
> it will never be removed, since gdbus will see an interface-count
> mismatch (as you observed above).
> 
> Hence, the patch I provided fixes how sd-bus provides this
> information. It does *not* change any policy.

Oh, I see. Thanks. I'll try the patch ASAP.

Regards,
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sd-bus: ObjectManager difference with gdbus

[David Herrmann]

Hey

On Tue, Apr 25, 2017 at 10:05 AM, Lennart Poettering
 wrote:
> On Tue, 25.04.17 09:54, David Herrmann (dh.herrm...@gmail.com) wrote:
>
>> >> This change makes sure all objects have the built-in interfaces
>> >> reported at all times. The GetManagedObjects() call didn't report them
>> >> so far.
>> >
>> > Quite the contrary? If you look at the output from dbus-monitor above, 
>> > you'll see that it is sd-bus that already *does* report all interfaces 
>> > while gdbus doesnt?
>>
>> No, it does not. sd-bus was inconsistent. See, there are 3 things
>> involved in the Object-Manager:
>>
>> Signal: InterfacesAdded
>> Signal: InterfacesRemoved
>> Call: GetManagedObjects
>>
>> The first two signals are used to add and remove objects (and their
>> respective interfaces) at runtime. The GetManagedObjects() call is
>> used to bootstrap, that is, to get the initial set of objects (and
>> their respective interfaces) when starting your application.
>>
>> So far, sd-bus reported the builtin interfaces correctly via the
>> signals, but did not return that information in the
>> GetManagedObjects() call. My patch fixed this omission.
>> The effect of this is that objects added/removed at runtime work fine,
>> but if an object was there already when your application starts, then
>> it will never be removed, since gdbus will see an interface-count
>> mismatch (as you observed above).
>>
>> Hence, the patch I provided fixes how sd-bus provides this
>> information. It does *not* change any policy.
>>
>> I think the 2 underlying problems you saw are bugs in both gdbus and
>> sd-bus. The one in sd-bus I tried to fix above, the one in gdbus is
>> only about counting interfaces and properly detecting negative
>> interface-counts. The gdbus bug is non-severe, though, since it
>> originates in a buggy remote client. So there is no hard reason to
>> change gdbus there.
>
> Could you please send the sd-bus side fix as PR?

Now pending as #5799.

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

Re: [systemd-devel] sd-bus: ObjectManager difference with gdbus

[David Härdeman]

On Tue, Apr 25, 2017 at 09:54:45AM +0200, David Herrmann wrote:
>On Tue, Apr 25, 2017 at 9:40 AM, David Härdeman  wrote:
>> April 21, 2017 1:22 PM, "David Herrmann"  wrote:
>>> This change makes sure all objects have the built-in interfaces
>>> reported at all times. The GetManagedObjects() call didn't report them
>>> so far.
>>
>> Quite the contrary? If you look at the output from dbus-monitor above, 
>> you'll see that it is sd-bus that already *does* report all interfaces while 
>> gdbus doesnt?
>
>No, it does not. sd-bus was inconsistent. See, there are 3 things
>involved in the Object-Manager:
>
>Signal: InterfacesAdded
>Signal: InterfacesRemoved
>Call: GetManagedObjects
>
>The first two signals are used to add and remove objects (and their
>respective interfaces) at runtime. The GetManagedObjects() call is
>used to bootstrap, that is, to get the initial set of objects (and
>their respective interfaces) when starting your application.
>
>So far, sd-bus reported the builtin interfaces correctly via the
>signals, but did not return that information in the
>GetManagedObjects() call. My patch fixed this omission.
>The effect of this is that objects added/removed at runtime work fine,
>but if an object was there already when your application starts, then
>it will never be removed, since gdbus will see an interface-count
>mismatch (as you observed above).
>
>Hence, the patch I provided fixes how sd-bus provides this
>information. It does *not* change any policy.
>
>I think the 2 underlying problems you saw are bugs in both gdbus and
>sd-bus. The one in sd-bus I tried to fix above, the one in gdbus is
>only about counting interfaces and properly detecting negative
>interface-counts. The gdbus bug is non-severe, though, since it
>originates in a buggy remote client. So there is no hard reason to
>change gdbus there.

Ok, I've tried the patch. It seems to fix things insofar that
InterfacesAdded/InterfacesRemoved/GetManagedObjects all report 5
interfaces (checked with dbus-monitor).

gdbus still gets royally confused though. It seems to report 5
interfaces for objects which are added dynamically (i.e. signalled via
InterfacesAdded) and 1 interface for objects which are generated via
GetManagedObjects (even though the sd-bus server reports 5 interfaces).

I'll start working on a testcase...

-- 
David Härdeman
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sd-bus: ObjectManager difference with gdbus

[David Härdeman]

On Tue, Apr 25, 2017 at 09:21:19PM +0200, David Härdeman wrote:
>On Tue, Apr 25, 2017 at 09:54:45AM +0200, David Herrmann wrote:
>>No, it does not. sd-bus was inconsistent. See, there are 3 things
>>involved in the Object-Manager:
>>
>>Signal: InterfacesAdded
>>Signal: InterfacesRemoved
>>Call: GetManagedObjects
>>
>>The first two signals are used to add and remove objects (and their
>>respective interfaces) at runtime. The GetManagedObjects() call is
>>used to bootstrap, that is, to get the initial set of objects (and
>>their respective interfaces) when starting your application.
>>
>>So far, sd-bus reported the builtin interfaces correctly via the
>>signals, but did not return that information in the
>>GetManagedObjects() call. My patch fixed this omission.
>>The effect of this is that objects added/removed at runtime work fine,
>>but if an object was there already when your application starts, then
>>it will never be removed, since gdbus will see an interface-count
>>mismatch (as you observed above).
>>
>>Hence, the patch I provided fixes how sd-bus provides this
>>information. It does *not* change any policy.
>>
>>I think the 2 underlying problems you saw are bugs in both gdbus and
>>sd-bus. The one in sd-bus I tried to fix above, the one in gdbus is
>>only about counting interfaces and properly detecting negative
>>interface-counts. The gdbus bug is non-severe, though, since it
>>originates in a buggy remote client. So there is no hard reason to
>>change gdbus there.
>
>Ok, I've tried the patch. It seems to fix things insofar that
>InterfacesAdded/InterfacesRemoved/GetManagedObjects all report 5
>interfaces (checked with dbus-monitor).
>
>gdbus still gets royally confused though. It seems to report 5
>interfaces for objects which are added dynamically (i.e. signalled via
>InterfacesAdded) and 1 interface for objects which are generated via
>GetManagedObjects (even though the sd-bus server reports 5 interfaces).

Scratch that. With your patch gdbus seems to consistently report 5
interfaces. But there's still some confusion to address in gdbus (the
additional interfaces have no names for example).

-- 
David Härdeman
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sd-bus: ObjectManager difference with gdbus

[David Härdeman]

On Tue, Apr 25, 2017 at 09:47:24AM -0500, Dan Williams wrote:
>On Tue, 2017-04-25 at 07:45 +0000, David Härdeman wrote:
>> April 24, 2017 5:49 PM, "Dan Williams"  wrote:
>>> 
>>> It's not clear that the GNOME side was implemented correctly yet.
>>> Would be nice to see the sample code.
>>> 
>>> Dan
>> 
>> My GNOME-based client was based on the gdbus-example-objectmanager-
>> client.c so I hope it's correct, but sure, I'll try to pare down the
>> GNOME/gdbus-based client code and the (sd-bus based) server code to
>> two simple test cases and provide those later this week.
>
>Cool.  I'd be happy to take a look at it.  It may well turn out to be a
>gdbus bug, but without seeing the code it's not clear.

I've added test cases at:
https://github.com/Alphix/gdbus-sdbus-test

-- 
David Härdeman
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] rules: block - add dm devices to whitelist

[David Disseldorp]

Ceph relies on by-partuuid symlinks, in order to locate the journal
partition from a given OSD partition. For details, see
http://tracker.ceph.com/issues/19489.
---
 rules/60-persistent-storage.rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rules/60-persistent-storage.rules 
b/rules/60-persistent-storage.rules
index 5ab03fc27..bc0721f32 100644
--- a/rules/60-persistent-storage.rules
+++ b/rules/60-persistent-storage.rules
@@ -6,7 +6,7 @@
 ACTION=="remove", GOTO="persistent_storage_end"
 
 SUBSYSTEM!="block", GOTO="persistent_storage_end"
-KERNEL!="loop*|mmcblk*[0-9]|msblk*[0-9]|mspblk*[0-9]|nvme*|sd*|sr*|vd*|xvd*|bcache*|cciss*|dasd*",
 GOTO="persistent_storage_end"
+KERNEL!="loop*|mmcblk*[0-9]|msblk*[0-9]|mspblk*[0-9]|nvme*|sd*|sr*|vd*|xvd*|bcache*|cciss*|dasd*|dm*",
 GOTO="persistent_storage_end"
 
 # ignore partitions that span the entire disk
 TEST=="whole_disk", GOTO="persistent_storage_end"
-- 
2.12.3

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

Re: [systemd-devel] [PATCH] rules: block - add dm devices to whitelist

[David Disseldorp]

Thanks for the feedback, Lennart...

On Mon, 10 Jul 2017 10:38:38 +0200, Lennart Poettering wrote:

> On Wed, 05.07.17 13:01, David Disseldorp (dd...@suse.de) wrote:
> 
> > Ceph relies on by-partuuid symlinks, in order to locate the journal
> > partition from a given OSD partition. For details, see
> > http://tracker.ceph.com/issues/19489.  
> 
> This appears way too broad, as it would apply to all LVM and all other
> devices.
>
> It appears to me Ceph should do the same as LVM does for this, and
> ship its own set of rules, and be careful to only match against the
> actual devices it creates.

We can certainly do this in a Ceph specific manner via the existing
95-ceph-osd.rules, but my impression was that the by-partuuid symlinks
are "owned" by 60-persistent-storage.rules .

If you don't think the existence of these symlinks for dm paths will be
of use to others then I'll go ahead and propose it as a Ceph only
change.

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

Re: [systemd-devel] [PATCH] rules: block - add dm devices to whitelist

[David Disseldorp]

On Mon, 10 Jul 2017 12:47:24 +0200, Peter Rajnoha wrote:

> On 07/10/2017 12:14 PM, Peter Rajnoha wrote:
...
> > Yes, please, any rules for symlinks which should be created under
> > /dev/disk for DM devices (including all its subsystems like LVM,
> > mpath...) should go into 13-dm-disk.rules that is part of LVM/DM source
> > tree:
> > 
> > https://sourceware.org/git/?p=lvm2.git;a=blob;f=udev/13-dm-disk.rules.in
> > 
> > Now, when we create a partition over a DM device, there's a new mapping
> > created on top for each partition (either by calling kpartx manually or
> > by having it created by partitioning tool directly if it supports that).
> > So in this case, it's not the kernel directly who creates the
> > partitions, but they're simply another DM devices created on top of the
> > underlying DM device to represent these partitions. But I think that
> > doesn't matter - we should still create those symlinks for people to
> > still have a possibility to reference the device by its part uuid - I'll
> > fix 13-dm-disk.rules to include this.
> >   
> 
> Fixed here:
> 
> https://sourceware.org/git/?p=lvm2.git;a=commit;h=c48149cf80c6582c2369bc7f8a33d794021d9dae

Looks good and works for me - thanks Peter.

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

[systemd-devel] [ANNOUNCE] D-Bus Broker Project

[David Herrmann]

This is the first public release of dbus-broker.

Git Tag: v3
Archive: 
https://github.com/bus1/dbus-broker/archive/v3/dbus-broker-v3.tar.gz

The dbus-broker project is an implementation of a message bus as
defined by the D-Bus specification. Its aim is to provide high
performance and reliability, while keeping compatibility to the D-Bus
reference implementation. It is exclusively written for linux systems,
and makes use of many modern features provided by recent linux kernel
releases. Details are discussed in its introductory blog post:

https://dvdhrm.github.io/rethinking-the-dbus-message-bus/

The project is still experimental and not meant for production use,
yet. Packages are available for Fedora and Arch Linux. Other
distributions will follow.

DETAILS:
https://github.com/bus1/dbus-broker/wiki

BUG REPORTS:
https://github.com/bus1/dbus-broker/issues

GIT:
g...@github.com:bus1/dbus-broker.git
https://github.com/bus1/dbus-broker.git

PACKAGES:
https://copr.fedorainfracloud.org/coprs/g/bus1/dbus/package/dbus-broker/
https://aur.archlinux.org/packages/dbus-broker
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] udev

[David Henderson]

Good afternoon all!  I have been looking for the udev source code to
compile the library and utilities and it appears it is bundled in the
systemd software.  I have run autoreconf to generate a configure
script (using version 233 since I don't have meson), but could not see
a way to just compile this software.  How do I accomplish this?

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

Re: [systemd-devel] udev

[David Henderson]

lol thanks for the links Mike!  Using the build system I developed, I
more or less have hooks to external scripts that can be called to
perform various tasks during the build process.  Once I get the
profile built, I can give it to you if you are interested to see how
it works.  Compiling is as simple as:

builder -n udev -a i64

Dave


On 10/26/17, Mike Gilbert  wrote:
> On Thu, Oct 26, 2017 at 11:45 AM, Mantas Mikulėnas 
> wrote:
>> On Thu, Oct 26, 2017, 18:26 David Henderson 
>> wrote:
>>>
>>> Good afternoon all!  I have been looking for the udev source code to
>>> compile the library and utilities and it appears it is bundled in the
>>> systemd software.  I have run autoreconf to generate a configure
>>> script (using version 233 since I don't have meson), but could not see
>>> a way to just compile this software.  How do I accomplish this?
>>
>>
>> You could run `make systemd-udevd libudev.so`.
>>
>> I'm not sure how to package just udevd. Maybe take a look at how distros
>> like Gentoo achieve this.
>
> For reference:
>
> https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-fs/udev/udev-233.ebuild?id=2f9f0fbb62866409b8ae0252a2b280d148dd9d73
>
> It's pretty ugly. We build around a dozen targets, and (ab)use
> automake install targets to selectively install bits and pieces. See
> the multilib_src_compile and multilib_src_install functions.
>
> Here's the meson version, for comparison. It's still pretty ugly, and
> we have to install things manually since there are no partial install
> targets.
>
> https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-fs/udev/udev-235.ebuild?id=2f9f0fbb62866409b8ae0252a2b280d148dd9d73
>
> Anyway, if you have any questions, feel free to ping me (floppym) on
> Freenode.
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev

[David Henderson]

On 10/26/17, Mantas Mikulėnas  wrote:
> On Thu, Oct 26, 2017, 18:26 David Henderson 
> wrote:
>
>> Good afternoon all!  I have been looking for the udev source code to
>> compile the library and utilities and it appears it is bundled in the
>> systemd software.  I have run autoreconf to generate a configure
>> script (using version 233 since I don't have meson), but could not see
>> a way to just compile this software.  How do I accomplish this?
>>
>
> You could run `make systemd-udevd libudev.so`.
>
> I'm not sure how to package just udevd. Maybe take a look at how distros
> like Gentoo achieve this.
>
> Note that sooner or later you *will* need to install meson. The overall
> process will be similar though, with `ninja` also accepting individual
> targets to build.
>

Thanks for the tip Mantas!  So I suppose there is no 'make install
udevd libudev' style syntax to handle that aspect.  If not, no
worries.  I am creating a profile for a software builder I made that
can handle the installation of those files otherwise.

Currently I am building a software repository for a Linux distro I
have built (XiniX) that started as a fork of another distro, but their
own repo is a disaster.  Neither theirs nor mine has the meson
builder.  IIRC, I think I briefly looked at creating a package for it,
but ran into issues.  I'm sure you are aware that rebuilding a repo
from scratch is no small feat so I moved on to others since it does
not appear that a lot of software uses it.  I do have plans to add it
at some point, but in the instances that a software project does use
it, typically the prior version from the most current does not use it
(which is what I end up using).

Although I need to upload the latest version, if you're interested,
the builder can be found at:
https://sourceforge.net/projects/software-builder/?source=directory

XiniX OS:
https://sourceforge.net/projects/xinix/?source=navbar

Info about the repo:
https://forums.cliquesoft.org/index.php?topic=31.0

Thanks again for your help!
Dave
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev

[David Henderson]

So I am using the compile flags as suggested, however, I have noticed
two errors.  I tried passing '--enable-static' to 'configure' and end
up with:

checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
configure: error: --enable-static is not supported by systemd

Without it, I get passed that error in favor of another one:

checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking for intltool-merge... yes
checking whether NLS is requested... yes
checking for intltool >= 0.40.0... 0.51.0 found
checking for intltool-update... /usr/local/bin/intltool-update
checking for intltool-merge... /usr/local/bin/intltool-merge
checking for intltool-extract... /usr/local/bin/intltool-extract
checking for xgettext... /usr/local/bin/xgettext
checking for msgmerge... /usr/local/bin/msgmerge
checking for msgfmt... /usr/local/bin/msgfmt
checking for gmsgfmt... /usr/local/bin/msgfmt
/usr/local/bin/xgettext: error while loading shared libraries:
libgettextsrc-0.19.5.1.so: cannot open shared object file: No such
file or directory
/usr/local/bin/msgmerge: error while loading shared libraries:
libgettextsrc-0.19.5.1.so: cannot open shared object file: No such
file or directory
/usr/local/bin/msgfmt: error while loading shared libraries:
libgettextsrc-0.19.5.1.so: cannot open shared object file: No such
file or directory
configure: error: GNU gettext tools not found; required for intltool

However, I have verified that the file does in fact exist and is
located in /usr/local/lib.  I tried adding '-L/usr/local/lib' to the
LDFLAGS variable, but no change.  Is it an issue with needing to be a
newer version or something?

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

Re: [systemd-devel] udev

[David Henderson]

On 10/26/17, David Henderson  wrote:
> So I am using the compile flags as suggested, however, I have noticed
> two errors.  I tried passing '--enable-static' to 'configure' and end
> up with:
>
> checking if libtool supports shared libraries... yes
> checking whether to build shared libraries... yes
> checking whether to build static libraries... yes
> configure: error: --enable-static is not supported by systemd
>
> Without it, I get passed that error in favor of another one:
>
> checking if libtool supports shared libraries... yes
> checking whether to build shared libraries... yes
> checking whether to build static libraries... no
> checking for intltool-merge... yes
> checking whether NLS is requested... yes
> checking for intltool >= 0.40.0... 0.51.0 found
> checking for intltool-update... /usr/local/bin/intltool-update
> checking for intltool-merge... /usr/local/bin/intltool-merge
> checking for intltool-extract... /usr/local/bin/intltool-extract
> checking for xgettext... /usr/local/bin/xgettext
> checking for msgmerge... /usr/local/bin/msgmerge
> checking for msgfmt... /usr/local/bin/msgfmt
> checking for gmsgfmt... /usr/local/bin/msgfmt
> /usr/local/bin/xgettext: error while loading shared libraries:
> libgettextsrc-0.19.5.1.so: cannot open shared object file: No such
> file or directory
> /usr/local/bin/msgmerge: error while loading shared libraries:
> libgettextsrc-0.19.5.1.so: cannot open shared object file: No such
> file or directory
> /usr/local/bin/msgfmt: error while loading shared libraries:
> libgettextsrc-0.19.5.1.so: cannot open shared object file: No such
> file or directory
> configure: error: GNU gettext tools not found; required for intltool
>
> However, I have verified that the file does in fact exist and is
> located in /usr/local/lib.  I tried adding '-L/usr/local/lib' to the
> LDFLAGS variable, but no change.  Is it an issue with needing to be a
> newer version or something?
>

So it appears that the binaries were looking for the lib in /lib,
although they were actually in /usr/local/lib.  A few symlinks
corrected that issue.  However, I have no run into another issue:

checking for qemu-system-x86_64... no
checking for /usr/share/qemu/bios-ovmf.bin... no
checking for /usr/share/qemu-ovmf/bios.bin... no
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: error: cannot find input file: `po/Makefile.in.in'

Checking the config.log says:

## -- ##
## Running config.status. ##
## -- ##

This file was extended by systemd config.status 234, which was
generated by GNU Autoconf 2.69.  Invocation command line was

  CONFIG_FILES=
  CONFIG_HEADERS  =
  CONFIG_LINKS=
  CONFIG_COMMANDS =
  $ ./config.status

on b46de142dd54

config.status:1555: creating Makefile
config.status:1541: error: cannot find input file: `po/Makefile.in.in'


I have installed glib2-dev and gettext-dev and intltool which each has
a Makefile.in.in file:

/usr/local/share/gettext/po/Makefile.in.in
/usr/local/share/glib-2.0/gettext/po/Makefile.in.in
/usr/local/share/intltool/Makefile.in.in

It doesn't appear to be the last one since the file isn't located in
the 'po' directory.  Any thoughts?

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

Re: [systemd-devel] udev

[David Henderson]

Good morning all!  Just following up with this!

Thanks,
Dave


On 10/26/17, David Henderson  wrote:
> On 10/26/17, David Henderson  wrote:
>> So I am using the compile flags as suggested, however, I have noticed
>> two errors.  I tried passing '--enable-static' to 'configure' and end
>> up with:
>>
>> checking if libtool supports shared libraries... yes
>> checking whether to build shared libraries... yes
>> checking whether to build static libraries... yes
>> configure: error: --enable-static is not supported by systemd
>>
>> Without it, I get passed that error in favor of another one:
>>
>> checking if libtool supports shared libraries... yes
>> checking whether to build shared libraries... yes
>> checking whether to build static libraries... no
>> checking for intltool-merge... yes
>> checking whether NLS is requested... yes
>> checking for intltool >= 0.40.0... 0.51.0 found
>> checking for intltool-update... /usr/local/bin/intltool-update
>> checking for intltool-merge... /usr/local/bin/intltool-merge
>> checking for intltool-extract... /usr/local/bin/intltool-extract
>> checking for xgettext... /usr/local/bin/xgettext
>> checking for msgmerge... /usr/local/bin/msgmerge
>> checking for msgfmt... /usr/local/bin/msgfmt
>> checking for gmsgfmt... /usr/local/bin/msgfmt
>> /usr/local/bin/xgettext: error while loading shared libraries:
>> libgettextsrc-0.19.5.1.so: cannot open shared object file: No such
>> file or directory
>> /usr/local/bin/msgmerge: error while loading shared libraries:
>> libgettextsrc-0.19.5.1.so: cannot open shared object file: No such
>> file or directory
>> /usr/local/bin/msgfmt: error while loading shared libraries:
>> libgettextsrc-0.19.5.1.so: cannot open shared object file: No such
>> file or directory
>> configure: error: GNU gettext tools not found; required for intltool
>>
>> However, I have verified that the file does in fact exist and is
>> located in /usr/local/lib.  I tried adding '-L/usr/local/lib' to the
>> LDFLAGS variable, but no change.  Is it an issue with needing to be a
>> newer version or something?
>>
>
> So it appears that the binaries were looking for the lib in /lib,
> although they were actually in /usr/local/lib.  A few symlinks
> corrected that issue.  However, I have no run into another issue:
>
> checking for qemu-system-x86_64... no
> checking for /usr/share/qemu/bios-ovmf.bin... no
> checking for /usr/share/qemu-ovmf/bios.bin... no
> checking that generated files are newer than configure... done
> configure: creating ./config.status
> config.status: creating Makefile
> config.status: error: cannot find input file: `po/Makefile.in.in'
>
> Checking the config.log says:
>
> ## -- ##
> ## Running config.status. ##
> ## -- ##
>
> This file was extended by systemd config.status 234, which was
> generated by GNU Autoconf 2.69.  Invocation command line was
>
>   CONFIG_FILES=
>   CONFIG_HEADERS  =
>   CONFIG_LINKS=
>   CONFIG_COMMANDS =
>   $ ./config.status
>
> on b46de142dd54
>
> config.status:1555: creating Makefile
> config.status:1541: error: cannot find input file: `po/Makefile.in.in'
>
>
> I have installed glib2-dev and gettext-dev and intltool which each has
> a Makefile.in.in file:
>
> /usr/local/share/gettext/po/Makefile.in.in
> /usr/local/share/glib-2.0/gettext/po/Makefile.in.in
> /usr/local/share/intltool/Makefile.in.in
>
> It doesn't appear to be the last one since the file isn't located in
> the 'po' directory.  Any thoughts?
>
> Thanks,
> Dave
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev

[David Henderson]

Good afternoon all.  So is there another place I can get help for this problem?

Thanks,
Dave


On 10/30/17, David Henderson  wrote:
> Good morning all!  Just following up with this!
>
> Thanks,
> Dave
>
>
> On 10/26/17, David Henderson  wrote:
>> On 10/26/17, David Henderson  wrote:
>>> So I am using the compile flags as suggested, however, I have noticed
>>> two errors.  I tried passing '--enable-static' to 'configure' and end
>>> up with:
>>>
>>> checking if libtool supports shared libraries... yes
>>> checking whether to build shared libraries... yes
>>> checking whether to build static libraries... yes
>>> configure: error: --enable-static is not supported by systemd
>>>
>>> Without it, I get passed that error in favor of another one:
>>>
>>> checking if libtool supports shared libraries... yes
>>> checking whether to build shared libraries... yes
>>> checking whether to build static libraries... no
>>> checking for intltool-merge... yes
>>> checking whether NLS is requested... yes
>>> checking for intltool >= 0.40.0... 0.51.0 found
>>> checking for intltool-update... /usr/local/bin/intltool-update
>>> checking for intltool-merge... /usr/local/bin/intltool-merge
>>> checking for intltool-extract... /usr/local/bin/intltool-extract
>>> checking for xgettext... /usr/local/bin/xgettext
>>> checking for msgmerge... /usr/local/bin/msgmerge
>>> checking for msgfmt... /usr/local/bin/msgfmt
>>> checking for gmsgfmt... /usr/local/bin/msgfmt
>>> /usr/local/bin/xgettext: error while loading shared libraries:
>>> libgettextsrc-0.19.5.1.so: cannot open shared object file: No such
>>> file or directory
>>> /usr/local/bin/msgmerge: error while loading shared libraries:
>>> libgettextsrc-0.19.5.1.so: cannot open shared object file: No such
>>> file or directory
>>> /usr/local/bin/msgfmt: error while loading shared libraries:
>>> libgettextsrc-0.19.5.1.so: cannot open shared object file: No such
>>> file or directory
>>> configure: error: GNU gettext tools not found; required for intltool
>>>
>>> However, I have verified that the file does in fact exist and is
>>> located in /usr/local/lib.  I tried adding '-L/usr/local/lib' to the
>>> LDFLAGS variable, but no change.  Is it an issue with needing to be a
>>> newer version or something?
>>>
>>
>> So it appears that the binaries were looking for the lib in /lib,
>> although they were actually in /usr/local/lib.  A few symlinks
>> corrected that issue.  However, I have no run into another issue:
>>
>> checking for qemu-system-x86_64... no
>> checking for /usr/share/qemu/bios-ovmf.bin... no
>> checking for /usr/share/qemu-ovmf/bios.bin... no
>> checking that generated files are newer than configure... done
>> configure: creating ./config.status
>> config.status: creating Makefile
>> config.status: error: cannot find input file: `po/Makefile.in.in'
>>
>> Checking the config.log says:
>>
>> ## -- ##
>> ## Running config.status. ##
>> ## -- ##
>>
>> This file was extended by systemd config.status 234, which was
>> generated by GNU Autoconf 2.69.  Invocation command line was
>>
>>   CONFIG_FILES=
>>   CONFIG_HEADERS  =
>>   CONFIG_LINKS=
>>   CONFIG_COMMANDS =
>>   $ ./config.status
>>
>> on b46de142dd54
>>
>> config.status:1555: creating Makefile
>> config.status:1541: error: cannot find input file: `po/Makefile.in.in'
>>
>>
>> I have installed glib2-dev and gettext-dev and intltool which each has
>> a Makefile.in.in file:
>>
>> /usr/local/share/gettext/po/Makefile.in.in
>> /usr/local/share/glib-2.0/gettext/po/Makefile.in.in
>> /usr/local/share/intltool/Makefile.in.in
>>
>> It doesn't appear to be the last one since the file isn't located in
>> the 'po' directory.  Any thoughts?
>>
>> Thanks,
>> Dave
>>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev

[David Henderson]

On 11/1/17, Lennart Poettering  wrote:
> On Di, 31.10.17 14:49, David Henderson (dhender...@digital-pipe.com) wrote:
>
>> Good afternoon all.  So is there another place I can get help for
>> this problem?
>
> Sorry, but this isn't really the right forum for help regarding
> building your distribution. Most of us just base our work on the work
> established distributions already did for us in this regard. If that
> doesn't work for you, then please contact a community such as LFS,
> whose focus it explicitly is to build a distribution from scratch,
> without resuing any work from other distributions. I am pretty sure
> they have more experience with putting together their own working
> build tool chain than us.
>
> Sorry,
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>

Good morning Lennart, thanks for the follow-up!  At this point I am
only interested in building a particular program (udev) from the
systemD collection, not help building a distribution.  And I think if
I tried to contact LFS about this, they would direct me to this
communication channel since this is where the people who build and
support the programs are located.  As a side question, is there a
place to just acquire the udev portion without all the other parts or
did that get merged into this suite only?

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

Re: [systemd-devel] udev

[David Henderson]

On 11/1/17, Greg KH  wrote:
> On Wed, Nov 01, 2017 at 10:04:19AM -0400, David Henderson wrote:
>> Good morning Lennart, thanks for the follow-up!  At this point I am
>> only interested in building a particular program (udev) from the
>> systemD collection, not help building a distribution.  And I think if
>> I tried to contact LFS about this, they would direct me to this
>> communication channel since this is where the people who build and
>> support the programs are located.  As a side question, is there a
>> place to just acquire the udev portion without all the other parts or
>> did that get merged into this suite only?
>
> Again, I would look at how Gentoo does it in their build scripts.
> That's your best bet, and if that doesn't work, you really are on your
> own as the source code is not set up to only extract one program from
> the whole system, for obvious reasons.

Thanks for the reply Greg, I will check the Gentoo script again later
this afternoon.  I got a couple of other tips from others that I am
going to try also.  Is there a place to just get the udev code instead
of all of systemD?  I tried looking online, but it appears that the
only solo versions are old.  I guess this got merged into systemD for
some reason?

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

Re: [systemd-devel] udev

[David Henderson]

On 11/1/17, Greg KH  wrote:
> On Wed, Nov 01, 2017 at 10:36:16AM -0400, David Henderson wrote:
>> Is there a place to just get the udev code instead of all of systemD?
>
> No.
>
>> I tried looking online, but it appears that the only solo versions are
>> old.  I guess this got merged into systemD for some reason?
>
> Yes, it all got merged many many years ago for the obvious reasons that
> you will find out if you try to tear them apart :)

lol Thanks Greg, I will give it another shot later today to see if I
can get things resolved with some of the suggestions provided!

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

Re: [systemd-devel] udev

[David Henderson]

On 11/1/17, Mike Gilbert  wrote:
> On Wed, Nov 1, 2017 at 10:49 AM, David Henderson
>  wrote:
>> On 11/1/17, Greg KH  wrote:
>>> On Wed, Nov 01, 2017 at 10:36:16AM -0400, David Henderson wrote:
>>>> Is there a place to just get the udev code instead of all of systemD?
>>>
>>> No.
>>>
>>>> I tried looking online, but it appears that the only solo versions are
>>>> old.  I guess this got merged into systemD for some reason?
>>>
>>> Yes, it all got merged many many years ago for the obvious reasons that
>>> you will find out if you try to tear them apart :)
>>
>> lol Thanks Greg, I will give it another shot later today to see if I
>> can get things resolved with some of the suggestions provided!
>
> On the topic of ripping udev out of systemd:
>
> Some Gentoo people actually forked udev out of systemd a while ago.
> You might consider using their "eudev" fork if it meets your needs. We
> use this as the default udev implementation for Gentoo systems that do
> not use systemd. Just don't ask for support for it on this mailing
> list. ;-)
>
> https://wiki.gentoo.org/wiki/Project:Eudev
>
> https://github.com/gentoo/eudev
>

Thanks Mike, that might be a better solution for me than attempting
the systemD version!  I will give that a shot later today as well!

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

[systemd-devel] systemd-timesync and journalctl questions

[David Weinehall]

We're having two time/date related issues/questions:

First of all we'd need some counterpart to ntpdate.

We have a system that lacks an RTC battery--the clock is reasonably reliable 
once the system
has booted, but every time the device is restarted it loses system time. Due to 
the use of the
machine we cannot allow the ntp server to run (since we need the clock to be 
monotonic).
Clock skew is OK, jumps aren't.

For this purpose we'd want an equivalent to ntpdate to be able to sync the 
clock once on boot,
so we can keep systemd-timesync disabled during runtime.

So far both manual reading and googling has failed to turn up any such mode of 
operation.
Is there any? If not, would it be hard to implement?

The second time-related issue pertains to journalctl.

It seems that journalctl logs (or at least displays) events in date/clock 
order, not in
sequence order. While this is definitely useful when trying to correlate 
different logs
against each other, it also means that events that happen after a date 
adjustment might
end up before already existing entries, thus breaking the sequentialness of the 
log,
as follows:

Date incorrect set to 2023:

Log message 1
Log message 2

Date corrected to be 2018:

Log message 3
Log message 1
Log message 2

Typically this is not how we want our log to behave. Is there any way to
show the log in sequential order?


Kind regards, David Weinehall
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Multiple initrds in unified kernel images?

[David Anderson]

Hi,

I'm exploring systemd-boot and secure booting for an Arch Linux install. To
get secure boot working right, I need to build a unified kernel image that
I can sign. However, I also need to pass 2 initrd images into the boot
process (one for CPU microcode, and the proper OS iniramfs).

But, AFAICT from reading the EFI stub source code, I can only have one
".initrd" section in my unified binary.

Is it possible to have multiple initrds in a unified kernel image? If so,
how do I construct the unified image? If not, can you suggest an
alternative that gets me my microcode and my OS initramfs?

Thanks!
- Dave
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Multiple initrds in unified kernel images?

[David Anderson]

And of course, the law of asking questions on the internet is verified, and
I find the answer minutes after asking a thousand people. A Linux initramfs
is a concatenation of cpio archives, so I can just `cat microcode.img
initrd.gz >initrd`, embed that in my unified image, and everything should
just work.

Please let me know if I'm wrong, and otherwise - thanks for being my rubber
ducks!

- Dave

On Fri, Oct 5, 2018 at 12:02 AM David Anderson  wrote:

> Hi,
>
> I'm exploring systemd-boot and secure booting for an Arch Linux install.
> To get secure boot working right, I need to build a unified kernel image
> that I can sign. However, I also need to pass 2 initrd images into the boot
> process (one for CPU microcode, and the proper OS iniramfs).
>
> But, AFAICT from reading the EFI stub source code, I can only have one
> ".initrd" section in my unified binary.
>
> Is it possible to have multiple initrds in a unified kernel image? If so,
> how do I construct the unified image? If not, can you suggest an
> alternative that gets me my microcode and my OS initramfs?
>
> Thanks!
> - Dave
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Environment-variable security?

[David Parsley]

It's a fairly common practice to configure services and provide secrets
with environment variables. For instance, both Hubot (made by Github) and
Gopherbot (made by me) can get their Slack token from an environment
variable. In my case, github.com/lnxjedi/ansible-role-gopherbot stores the
Slack bot token with "Environtment=GOPHER_SLACK_TOKEN=xxx" in the systemd
unit file. I had hoped to keep this info to the robot user by marking the
unit file world-inaccessible. I was dismayed to see the log warning about
values being accessible via the API, though super glad that my unprivileged
user couldn't fetch it with a simple systemctl cat gopherbot. I know very
little about DBUS or any APIs for systemd, so wanted to ask - is there some
means by which a non-privileged user can access the values provided with
"Environment=..." lines? Can I disable this by disabling dbus-daemon on
server systems?

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

Re: [systemd-devel] Environment-variable security?

[David Parsley]

I already scrub the environment when executing external scripts, and I've
found that even after os.Unsetenv(...) the full environment is available to
all processes owned by the robot in /proc//environ. I'm fleshing out a
solution where the process consumes the environment then scrubs it from
proc w/ execve before starting the main loop that can run external scripts.

I don't know what mechanism made the environment available via API, so I
wasn't sure if using an EnvironmentFile protected against that same
mechanism. If effective, that would be a nice solution that parallels
operation of the dockerized version.

So, anybody know what API calls an unprivileged user can make to get that
information from the unit file? It'd be nice to test before and after to
make sure the measure is effective.

Regards,
-David

On Mon, Nov 12, 2018 at 4:23 PM aleivag  wrote:

> hi Reindl: I was protecting against "systemctl cat/show" disclosure of
> information, as stated in the question; but i agree with you, and there are
> always risk in passing credential in env variables, but you can always try
> to mitigate them (e.g. the main process can read the variables and then
> remove them from the env).
>
> El 12 nov. 2018 5:54 p. m., "Reindl Harald" 
> escribió:
>
>
>
> Am 12.11.18 um 21:41 schrieb aleivag:
>
> > You can define those secrets on /etc/robotsecret.txt, and then on your
> > unit you do `EnvironmentFile=/etc/robotsecret.txt`
> >
> > then you protect /etc/robotsecret.txt as you would normally do
>
> and how does that protect anything?
>
> on a webserver running php it's just a one-liner to get $_ENV which is
> why sensitive data don't belong there and should never exposed that way
> like passwords in teh commandline are plain wrong
>
>
> > On Mon, Nov 12, 2018 at 4:49 PM David Parsley  > <mailto:pars...@linuxjedi.org>> wrote:
> >
> > It's a fairly common practice to configure services and provide
> > secrets with environment variables. For instance, both Hubot (made
> > by Github) and Gopherbot (made by me) can get their Slack token from
> > an environment variable. In my case,
> > github.com/lnxjedi/ansible-role-gopherbot
> > <http://github.com/lnxjedi/ansible-role-gopherbot> stores the Slack
>
> > bot token with "Environtment=GOPHER_SLACK_TOKEN=xxx" in the systemd
> > unit file. I had hoped to keep this info to the robot user by
> > marking the unit file world-inaccessible. I was dismayed to see the
> > log warning about values being accessible via the API, though super
> > glad that my unprivileged user couldn't fetch it with a
> > simple |systemctl cat gopherbot|. I know very little about DBUS or
>
> > any APIs for systemd, so wanted to ask - is there some means by
> > which a non-privileged user can access the values provided with
> > "Environment=..." lines? Can I disable this by disabling dbus-daemon
> > on server systems?
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Environment-variable security?

[David Parsley]

I disagree; privacy of environment variables to individual users on the
system is as fundamental as Unix file permissions. If a privileged process
(systemd) is configured to start a service and provide environment
variables to an unprivileged service account, it is a reasonable
expectation that said environment is only available to root and the service
account (and it's child processes), and not other arbitrary
users/processes. From a system security engineering perspective, it would
be better if systemd didn't start a service at all with 0600 on the unit
file, rather than violate the principle of Unix environment privacy, and in
fact should actually just check the world-read bit.

Thanks aleivag; "systemctl show" was what I was looking for; unprivileged,
I was able to see the "Environment=" values, but not the contents of
/etc/gopherbot.env. I'm going to go ahead and update the Ansible role to
operate that way.

Regards,
-David

On Tue, Nov 13, 2018 at 5:18 AM Lennart Poettering 
wrote:

> On Mo, 12.11.18 17:41, aleivag (alei...@gmail.com) wrote:
>
> > You can define those secrets on /etc/robotsecret.txt, and then on your
> unit
> > you do `EnvironmentFile=/etc/robotsecret.txt`
> >
> > then you protect /etc/robotsecret.txt as you would normally do
>
> Don't do this. This is only partially secure, and that only by
> coincidence, not by design. env vars are generally not considered
> secrets, and will still propagate down the tree.
>
> If you have secrets pick a place where they are strictly access
> controlled, and where this access control is built into the concept
> itself. Files on disk work (with their age old UNIX access mode) and
> kernel keyrings work too (they have been designed just for this
> purpose). env vars do not qualify. Neither in understanding of its
> users, not in actual code.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Environment-variable security?

[David Parsley]

Google "twelve-factor app". Excerpt from a random article on medium.com:
"... most frameworks support the use of System Environment variables inside
configuration files. For instance, in the Spring Boot yaml file you can
write:
Security.oauth2.client.clientSecret: ${CL_SERVICE_PASSWORD}"

You're correct that's not a Unix security standard, and I couldn't find one
- it's just a fairly common practice because environment variables are easy
to use. Other systems engineers that I work with also rely on their
environment being private from other users on large, multi-user research
computing systems like the ones we manage. It's also a reasonable
expectation that an unprivileged process can't trivially obtain the
contents of a 0600:root:root file under /etc, or that a user-level exploit
of an unrelated service could also trivially obtain that data.

I'll just go ahead and concede that I'm wrong, and that GOPHER_SLACK_TOKEN
and HUBOT_SLACK_TOKEN shouldn't be in an env var, and that my co-workers
are also wrong to store a particular password in their environment.
Regardless, that doesn't make it OK for systemd to hand out the contents of
of that file or make service environment vars available to unprivileged
users. You can think I'm a stubborn damned ignoramus if you like - but I'd
be surprised if you think I'm the *only* damned ignoramus who thinks that
environment data should be private to the process owner and root. I'm just
one of the few who happened to notice the warning in the logs and
investigated it.

I think the real point here is the information disclosure vulnerability.
I'm going to suggest to my team that we consider making
/run/dbus/system_bus_socket 440 or 400 - no reason for these non-privileged
users to have access to that, anyway.

Thanks for giving this some thought.

Regards,

-David



On Tue, Nov 13, 2018 at 9:17 AM Lennart Poettering 
wrote:

> On Di, 13.11.18 07:49, David Parsley (pars...@linuxjedi.org) wrote:
>
> > I disagree; privacy of environment variables to individual users on the
> > system is as fundamental as Unix file permissions. If a privileged
> process
> > (systemd) is configured to start a service and provide environment
> > variables to an unprivileged service account, it is a reasonable
> > expectation that said environment is only available to root and the
> service
> > account (and it's child processes), and not other arbitrary
> > users/processes. From a system security engineering perspective, it would
> > be better if systemd didn't start a service at all with 0600 on the unit
> > file, rather than violate the principle of Unix environment privacy, and
> in
> > fact should actually just check the world-read bit.
>
> Well, you are of course welcome to ignore whatever I say, but again,
> environment blocks are leaky, they propagate down the process tree,
> and are *not* generally understood as being secret.
>
> You appear dead set on using env vars for this. It's a very bad choice
> however, it's a pity you ignore comments that don't fit in your view
> of the world though.
>
> Note that even docker got this right, and their "docker secrets"
> feature, stores them in a file, not in an env var:
>
> https://docs.docker.com/engine/swarm/secrets/#how-docker-manages-secrets
>
> I mean, there's a lot to complain in what Docker does, but the way it
> looks, at least that they did get right...
>
> > Thanks aleivag; "systemctl show" was what I was looking for;
> unprivileged,
> > I was able to see the "Environment=" values, but not the contents of
> > /etc/gopherbot.env. I'm going to go ahead and update the Ansible role to
> > operate that way.
>
> Urks. I really don't hope this catches on. You are doing it wrong.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Environment-variable security?

[David Parsley]

On Wed, Nov 14, 2018 at 3:43 AM Lennart Poettering 
wrote:

> I mean, seriously, people do lots of stuff. It doesn't mean that all
> what people do is actually a good idea or just safe.
>

Certainly agreed on this point. It is my belief, however, that system
software, where possible, should implement controls to head-off security
mistakes of this kind made by those people - like me. Right now I think
systemd doesn't go far enough - I was lucky that I saw that warning in the
logs, and the contents of my unit file were insecure when I thought it was
secured by file permissions. I still believe systemd should refuse to start
the service to draw attention to this error in thinking, and that the log
entry should probably reference the doc where the not-uncommon practice of
putting secrets in environment variables is discouraged - certainly with
systemd managed services.

The practice will continue, however; TravisCI, CircleCI, and my own
GopherCI all have mechanisms for providing e.g a GITHUB_PASSWORD
environment variable for automated build publishing. No shock that a DevOps
engineer might make the mistake of applying the same principle with systemd.

Regards,
-David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] terminal: fix prototypes after removal of |bus|

[David Herrmann]

Hi

On Wed, Apr 29, 2015 at 8:49 PM, Mantas Mikulėnas  wrote:
> Following commits fe506d569d82467f3186 and 190700621f95160d364f.
> ---
>  src/libsystemd-terminal/grdev-drm.c |  9 +++--
>  src/libsystemd-terminal/idev-evdev.c|  3 +--
>  src/libsystemd-terminal/idev-keyboard.c |  8 +++-
>  src/libsystemd-terminal/idev.c  |  6 ++
>  src/libsystemd-terminal/sysview.c   | 12 
>  5 files changed, 13 insertions(+), 25 deletions(-)

Thomas already applied a similar patch.

Thanks!
David

> diff --git a/src/libsystemd-terminal/grdev-drm.c 
> b/src/libsystemd-terminal/grdev-drm.c
> index 066a4d8..01a70fd 100644
> --- a/src/libsystemd-terminal/grdev-drm.c
> +++ b/src/libsystemd-terminal/grdev-drm.c
> @@ -2655,8 +2655,7 @@ static void managed_card_disable(grdev_card *card) {
>  grdrm_card_disable(&cm->card);
>  }
>
> -static int managed_card_pause_device_fn(sd_bus *bus,
> -sd_bus_message *signal,
> +static int managed_card_pause_device_fn(sd_bus_message *signal,
>  void *userdata,
>  sd_bus_error *ret_error) {
>  managed_card *cm = userdata;
> @@ -2744,8 +2743,7 @@ static int managed_card_pause_device_fn(sd_bus *bus,
>  return 0;
>  }
>
> -static int managed_card_resume_device_fn(sd_bus *bus,
> - sd_bus_message *signal,
> +static int managed_card_resume_device_fn(sd_bus_message *signal,
>   void *userdata,
>   sd_bus_error *ret_error) {
>  managed_card *cm = userdata;
> @@ -2847,8 +2845,7 @@ static int managed_card_setup_bus(managed_card *cm) {
>  return 0;
>  }
>
> -static int managed_card_take_device_fn(sd_bus *bus,
> -   sd_bus_message *reply,
> +static int managed_card_take_device_fn(sd_bus_message *reply,
> void *userdata,
> sd_bus_error *ret_error) {
>  managed_card *cm = userdata;
> diff --git a/src/libsystemd-terminal/idev-evdev.c 
> b/src/libsystemd-terminal/idev-evdev.c
> index 91ae507..64e703e 100644
> --- a/src/libsystemd-terminal/idev-evdev.c
> +++ b/src/libsystemd-terminal/idev-evdev.c
> @@ -527,8 +527,7 @@ static const idev_element_vtable unmanaged_evdev_vtable = 
> {
>   * you run inside a user session with exclusive device access.
>   */
>
> -static int managed_evdev_take_device_fn(sd_bus *bus,
> -sd_bus_message *reply,
> +static int managed_evdev_take_device_fn(sd_bus_message *reply,
>  void *userdata,
>  sd_bus_error *ret_error) {
>  managed_evdev *em = userdata;
> diff --git a/src/libsystemd-terminal/idev-keyboard.c 
> b/src/libsystemd-terminal/idev-keyboard.c
> index b5eb737..ef56ee2 100644
> --- a/src/libsystemd-terminal/idev-keyboard.c
> +++ b/src/libsystemd-terminal/idev-keyboard.c
> @@ -387,8 +387,7 @@ static const struct bus_properties_map 
> kbdctx_locale_map[] = {
>  { },
>  };
>
> -static int kbdctx_locale_get_all_fn(sd_bus *bus,
> -sd_bus_message *m,
> +static int kbdctx_locale_get_all_fn(sd_bus_message *m,
>  void *userdata,
>  sd_bus_error *ret_err) {
>  kbdctx *kc = userdata;
> @@ -404,7 +403,7 @@ static int kbdctx_locale_get_all_fn(sd_bus *bus,
>  return 0;
>  }
>
> -r = bus_message_map_all_properties(bus, m, kbdctx_locale_map, kc);
> +r = bus_message_map_all_properties(m, kbdctx_locale_map, kc);
>  if (r < 0) {
>  log_debug("idev-keyboard: erroneous GetAll() reply from 
> locale1");
>  return 0;
> @@ -448,8 +447,7 @@ error:
>  return log_debug_errno(r, "idev-keyboard: cannot send GetAll to 
> locale1: %m");
>  }
>
> -static int kbdctx_locale_props_changed_fn(sd_bus *bus,
> -  sd_bus_message *signal,
> +static int kbdctx_locale_props_changed_fn(sd_bus_message *signal,
>void *userdata,
>sd_bus_error *ret_err) {
>  kbdctx *kc = userdata;
> diff --git a/src/libsystemd-terminal/idev.c b/src/libsystemd-terminal/idev.c
> index 44be7c3..0ba2b28 100644
> --- a/src/libsystemd-terminal/idev.c
> +++ b/src/libsystemd-terminal/idev.c

Re: [systemd-devel] [PATCH] Add VARIANT as a standard value for /etc/os-release

[David Herrmann]

Hi

On Tue, May 5, 2015 at 4:15 PM, Stephen Gallagher  wrote:
>
>
> - Original Message -
>> From: "Lennart Poettering" 
>> To: "Stephen Gallagher" 
>> Sent: Tuesday, May 5, 2015 10:13:35 AM
>> Subject: Re: [systemd-devel] [PATCH] Add VARIANT as a standard value for 
>> /etc/os-release
>>
>> On Tue, 05.05.15 08:52, Stephen Gallagher (sgall...@redhat.com) wrote:
>>
>> > Sorry, I forgot to CC you directly on this, Lennart.
>>
>> Sorry for the delay, I am currently travelling (CoreOS fest), and I
>> haven't merged patches in a while due to that. But the patch looks
>> good to me, looks good to merge.
>>
>
>
> Thanks, I'm re-adding systemd-devel to the CC. (I removed it when CCing you 
> this morning so I didn't spam the list).
>
> If someone with commit privilege would merge this, I'd appreciate it. Thanks!

I fixed a typo and pushed it.

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

Re: [systemd-devel] [PATCH] udev: Restore udevadm settle timeout

[David Herrmann]

Hi

On Wed, May 6, 2015 at 4:31 AM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Mon, Apr 20, 2015 at 10:33:48AM +0200, David Herrmann wrote:
>> Hi
>>
>> On Sat, Apr 11, 2015 at 9:38 PM, Nir Soffer  wrote:
>> > On Sat, Apr 11, 2015 at 1:36 PM, David Herrmann  
>> > wrote:
>> >> > @@ -139,6 +142,9 @@ static int adm_settle(struct udev *udev, int argc, 
>> >> > char *argv[]) {
>> >> >  break;
>> >> >  }
>> >> >
>> >> > +if (now(CLOCK_MONOTONIC) >= deadline)
>> >> > +break;
>> >> > +
>> >>
>> >> Previous udevadm allowed timeout=0 to disable this. I added the condition.
>> >
>> > Hi David,
>> >
>> > I think the handling of timeout=0 is incorrect now. The manual says:
>> >
>> > A value of 0 will check if the queue is empty and always return
>> > immediately.
>> >
>> > In udev-147 (used on rhel6), this was the behavior. If timeout was 0,
>> > is_timeout was set and settle was returning with rc=1.
>> >
>> > This behavior changed in:
>> >
>> > http://git.kernel.org/cgit/linux/hotplug/udev.git/commit/?id=ead7c62ab7641e150c6d668f939c102a6771ce60
>> >
>> > After this commit, zero timeout results in unlimited wait. Since this
>> > patch did not
>> > change the manual or the online help, and the commit message says:
>> > "udevadm: settle - kill alarm()", I guess this was unintended change.
>> >
>> > I don't see the use case for disabling the timeout, so it seems that
>> > we should fix
>> > this, restoring the behavior before this commit.
>> >
>> > What do you think?
>>
>> Ok, this is on me, sorry for that. I tried to keep the behavior from
>> before the code-removal. I wasn't aware that this was not how it is
>> documented.
>>
>> I'm actually not sure whether that was an intended change. It does not
>> look like it was, indeed. Maybe Kay or Tom know more.. I have no idea
>> whether timeout=0 is used in the wild.
>>
>> I'll stall your further patches until we've decided on this.
> What's the status here?

This is already fixed in -git. Original behavior is restored.

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

Re: [systemd-devel] [PATCH] udev: Restore udevadm settle timeout

[David Herrmann]

Hi

On Thu, May 7, 2015 at 10:53 AM, Harald Hoyer  wrote:
> On 20.04.2015 10:33, David Herrmann wrote:
>> Hi
>>
>> On Sat, Apr 11, 2015 at 9:38 PM, Nir Soffer  wrote:
>>> On Sat, Apr 11, 2015 at 1:36 PM, David Herrmann  
>>> wrote:
>>>>> @@ -139,6 +142,9 @@ static int adm_settle(struct udev *udev, int argc, 
>>>>> char *argv[]) {
>>>>>  break;
>>>>>  }
>>>>>
>>>>> +if (now(CLOCK_MONOTONIC) >= deadline)
>>>>> +break;
>>>>> +
>>>>
>>>> Previous udevadm allowed timeout=0 to disable this. I added the condition.
>>>
>>> Hi David,
>>>
>>> I think the handling of timeout=0 is incorrect now. The manual says:
>>>
>>> A value of 0 will check if the queue is empty and always return
>>> immediately.
>>>
>>> In udev-147 (used on rhel6), this was the behavior. If timeout was 0,
>>> is_timeout was set and settle was returning with rc=1.
>>>
>>> This behavior changed in:
>>>
>>> http://git.kernel.org/cgit/linux/hotplug/udev.git/commit/?id=ead7c62ab7641e150c6d668f939c102a6771ce60
>>>
>>> After this commit, zero timeout results in unlimited wait. Since this
>>> patch did not
>>> change the manual or the online help, and the commit message says:
>>> "udevadm: settle - kill alarm()", I guess this was unintended change.
>>>
>>> I don't see the use case for disabling the timeout, so it seems that
>>> we should fix
>>> this, restoring the behavior before this commit.
>>>
>>> What do you think?
>>
>> Ok, this is on me, sorry for that. I tried to keep the behavior from
>> before the code-removal. I wasn't aware that this was not how it is
>> documented.
>>
>> I'm actually not sure whether that was an intended change. It does not
>> look like it was, indeed. Maybe Kay or Tom know more.. I have no idea
>> whether timeout=0 is used in the wild.
>>
>
>
> Oh, dracut makes use of "udevadm settle --timeout=0" all the time

--timeout was ignored for udevadm-settle since 213, effectively
running with an infinite timeout under all circumstances. This was a
regression of:
"udev: remove seqnum API and all assumptions about seqnums" (commit 9ea28c55)

The 3 fixes to make --timeout work properly again, are:
"udev: restore udevadm settle timeout" (commit 0736455b)
"udev: settle should return immediately when timeout is 0" (commit bf23b9f8)
"udev: Fix ping timeout when settle timeout is 0" (commit 7375b3c4)

All are queued up for 219.

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

Re: [systemd-devel] [PATCH] unit: Set KillMode=mixed for services which use sulogin

[David Herrmann]

Hi

On Fri, May 8, 2015 at 7:59 PM, Michael Biebl  wrote:
> 2015-05-08 17:43 GMT+02:00 Michael Biebl :
>> See http://lists.freedesktop.org/archives/systemd-devel/2015-May/031536.html
>>
>> We probably want to use KillMode=mixed, but let's start with the ones
>
> We probably want to use KillMode=mixed *as well for other units which
> spawn of child processes*, but ...

..and it should have been the default right from the beginning. I
think there're even plans to switch, but.. backwards compat..

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

Re: [systemd-devel] [PATCH] buildsys: *_la_CPPFLAGS takes $(AM_CPPFLAGS) not $(AM_CFLAGS)

[David Herrmann]

Hi

On Sat, May 9, 2015 at 7:08 PM, Cristian Rodríguez
 wrote:
> ---
>  Makefile.am | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

Nice catch. Applied!

Thanks
David

> diff --git a/Makefile.am b/Makefile.am
> index 1ec1e77..e4d00a8 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -6333,7 +6333,7 @@ libsystemd_journal_la_SOURCES = \
> src/compat-libs/libsystemd-journal.sym
>
>  libsystemd_journal_la_CPPFLAGS = \
> -   $(AM_CFLAGS) \
> +   $(AM_CPPFLAGS) \
> -imacros$(top_srcdir)/src/compat-libs/linkwarning.h
>
>  libsystemd_journal_la_LDFLAGS = \
> @@ -6351,7 +6351,7 @@ libsystemd_login_la_SOURCES = \
> src/compat-libs/libsystemd-login.sym
>
>  libsystemd_login_la_CPPFLAGS = \
> -   $(AM_CFLAGS) \
> +   $(AM_CPPFLAGS) \
> -imacros$(top_srcdir)/src/compat-libs/linkwarning.h
>
>  libsystemd_login_la_LDFLAGS = \
> @@ -6368,7 +6368,7 @@ libsystemd_id128_la_SOURCES = \
> src/compat-libs/libsystemd-id128.sym
>
>  libsystemd_id128_la_CPPFLAGS = \
> -   $(AM_CFLAGS) \
> +   $(AM_CPPFLAGS) \
> -imacros$(top_srcdir)/src/compat-libs/linkwarning.h
>
>  libsystemd_id128_la_LDFLAGS = \
> @@ -6385,7 +6385,7 @@ libsystemd_daemon_la_SOURCES = \
> src/compat-libs/libsystemd-daemon.sym
>
>  libsystemd_daemon_la_CPPFLAGS = \
> -   $(AM_CFLAGS) \
> +   $(AM_CPPFLAGS) \
> -imacros$(top_srcdir)/src/compat-libs/linkwarning.h
>
>  libsystemd_daemon_la_LDFLAGS = \
> --
> 2.3.7
>
> ___
> 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] [ANNOUNCE] Separating gudev from systemd

[David Herrmann]

Hi

We're about to remove gudev from the systemd repository, as it is in
no way related to the systemd code-base, nor used by the systemd
project. To preserve backwards compatibility, gudev was extracted into
a separate repository and is now managed on gnome.org:

Homepage: https://wiki.gnome.org/Projects/libgudev
Bugtracker: http://bugzilla.gnome.org/browse.cgi?product=libgudev
Releases: http://download.gnome.org/sources/libgudev/
Repository: http://git.gnome.org/browse/libgudev/

ArchLinux: https://aur.archlinux.org/packages/li/libgudev/PKGBUILD
Others: TBD

The new libgudev project is binary-compatible to gudev as provided by
systemd-219. Distributions are encouraged to pass --disable-gudev to
systemd and provide gudev via the libgudev project. We haven't decided
at which point gudev will be dropped from the systemd repository, but
chances are systemd-221 will not include it, anymore.

If there are any issues, please let me know.

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

Re: [systemd-devel] [PATCH] util: fix typo

[David Herrmann]

Hi

On Tue, May 19, 2015 at 2:26 PM,   wrote:
> From: Jan Synacek 
>
> ---
>  src/shared/util.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied!

Thanks
David

> diff --git a/src/shared/util.c b/src/shared/util.c
> index da6343f..fd837d9 100644
> --- a/src/shared/util.c
> +++ b/src/shared/util.c
> @@ -1697,7 +1697,7 @@ int loop_write(int fd, const void *buf, size_t nbytes, 
> bool do_poll) {
>
>  int parse_size(const char *t, off_t base, off_t *size) {
>
> -/* Soo, sometimes we want to parse IEC binary suffxies, and
> +/* Soo, sometimes we want to parse IEC binary suffixes, and
>   * sometimes SI decimal suffixes. This function can parse
>   * both. Which one is the right way depends on the
>   * context. Wikipedia suggests that SI is customary for
> --
> 2.1.0
>
> ___
> 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] [ANNOUNCE] Separating gudev from systemd

[David Herrmann]

Hi

On Wed, May 20, 2015 at 8:46 AM, Tom Gundersen  wrote:
> On Wed, May 20, 2015 at 8:24 AM, Martin Pitt  wrote:
>> Hey David,
>>
>> David Herrmann [2015-05-19 17:06 +0200]:
>>> We're about to remove gudev from the systemd repository, as it is in
>>> no way related to the systemd code-base, nor used by the systemd
>>> project.
>>
>> This makes sense indeed. gudev used to be a standalone project before
>> it was merged into udev, so the circle is complete now :-)
>>
>> For those of us who already packaged gudev from systemd 219, would it
>> be possible to bump the current release to 220, so that gudev can be
>> packaged without renaming the tarball and doing ugly version numbers?
>> Monotonously increasing version numbers and all.. (Yes, there are
>> "epochs" in Debian, and I'm sure RPM has these too, but they might not
>> be available everywhere and are generally frowned upon)
>
> While you are at it, why not bump it to 225 or something (just to
> guarantee that the last systemd release with gudev has a lower version
> number than gudev at that time, so people can switch over whenever
> they want without having to worry about going backwards).

I intend to apply patches to systemd-git until we finally removed it
there. Given that we had 0 patches so far this year, it'll probably
stay that way. Hence, there's no hurry in replacing gudev from systemd
with libgudev. It'd be enough to just drop the systemd sub-package and
provide a new libgudev package, even if that might not forcefully
update the package.

However, I see no reason not to bump it, so I'll gladly follow the
packager's demands:

https://github.com/systemd-devs/libgudev/commit/f6203336e5b1ccf896acc506b54ec895fdae98b4

@Bastien: At your convenience, can you cherry-pick this and do another
release? Should have done this right away, sorry!

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

Re: [systemd-devel] [PATCH] Remove accelerometer helper

[David Herrmann]

Hi

On Fri, May 22, 2015 at 5:10 PM, Bastien Nocera  wrote:
> On Fri, 2015-05-22 at 17:00 +0200, Tom Gundersen wrote:
>> On Fri, May 22, 2015 at 3:42 PM, Bastien Nocera 
>> wrote:
>> > It's moved to the iio-sensor-proxy D-Bus service.
>>
>> Nice! When was this released? Should we expect all distros to have
>> picked up this yet?
>
> It was released as 1.0 today, so, no, I don't expect all distros to
> have it, in fact, I don't expect any to have it ;)

Awesome! Much appreciated! I think we wanna do another systemd release
soon (with the sd-bus/event exports), we can apply this patch
afterwards then (with the gudev removal, too).

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

Re: [systemd-devel] [PATCH] fix typos in systemd-nspawn man page

[David Herrmann]

Hi

On Sat, May 23, 2015 at 5:11 AM, Jonathan Boulle
 wrote:
> ---
>  man/systemd-nspawn.xml | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Applied!

Thanks
David

> diff --git a/man/systemd-nspawn.xml b/man/systemd-nspawn.xml
> index 6a5db86cec3c..06285edc0bb3 100644
> --- a/man/systemd-nspawn.xml
> +++ b/man/systemd-nspawn.xml
> @@ -330,7 +330,7 @@
>  first host UID to assign to the container, the second
>  parameter specifies the number of host UIDs to assign to the
>  container. If the second parameter is omitted, 65536 UIDs are
> -assigned. If the first parameter is also ommitted (and hence
> +assigned. If the first parameter is also omitted (and hence
>  no parameter passed at all), the first UID assigned to the
>  container is read from the owner of the root directory of the
>  container's directory tree. By default no user namespacing is
> @@ -454,7 +454,7 @@
>  container port number in the range from 1 to 65535. The
>  protocol specifier and its separating colon may be omitted, in
>  which case tcp is assumed. The container
> -port number and its colon may be ommitted, in which case the
> +port number and its colon may be omitted, in which case the
>  same port as the host port is implied. This option is only
>  supported if private networking is used, such as
>  --network-veth or
> --
> 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

Re: [systemd-devel] What kdbus Version for systemd 220 ?

[David Herrmann]

Hi

On Sun, May 24, 2015 at 3:00 PM, Thomas Ritter  wrote:
> Dear group,
>
> Since a while I am experimenting with systemd and kdbus, till now with
> excellent results.
> Recently I tried to bump all versions to LATEST/HEAD, and ran into some
> issues.
>
> My short question:
> Is there a recommendation what kdbus version fits to the current systemd
> V220?
>
> Till now I was using kdbus from https://github.com/gregkh/kdbus, but the
> latest commit there is from Mar 6th  ?
> And with this version kdbus seems not working properly with V220 here (
> is_kdbus_available() in bus-util.c fails with ioctl KDBUS_CMD_BUS_MAKE).

There's an out-of-tree repository with an v4.0 and v4.1 branch (you
must pick a branch matching your kernel!):
https://github.com/systemd-devs/kdbus

The official kdbus branch is in Greg's kernel.org tree. However, due
to vacation it hasn't been updated, yet.

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

Re: [systemd-devel] Debian Bug#618862: systemd: ignores keyscript in crypttab - a possible solution

[David Härdeman]

On 2015-05-26 00:05, Alberto Bertogli wrote:
I hit this issue after upgrading a system that used keyscript to 
Jessie,

and it would no longer boot with systemd [1].

That led me to look into adding a password agent for my use case, 
and/or

creating a generic one that would invoke keyscripts as a workaround...



...

On Wed, Feb 05, 2014 at 12:16:00AM +0100, Lennart Poettering wrote:

On Thu, 30.01.14 10:40, David Härdeman (da...@hardeman.nu) wrote:
> b) the password agent implementation in systemd doesn't seem to
> handle binary strings (i.e. strings with '\0'), as can be seen by
> calls to e.g. "strlen()"...
>
> Whether making it binary safe would be a major change or not is
> something I haven't researched yet but it seems like a change that
> should be generally useful upstream...

I'd be OK with this, as discussed at FOSDEM, and I see you already
posted a ptach for this.


Has this been merged?


No, the last word was basically this thread:
http://lists.freedesktop.org/archives/systemd-devel/2014-July/021246.html

I don't have the time to implement a "complete" solution...


Is it safe for a password agent to write content with \0 back to the
socket?


Haven't checked but I'd be surprised if that was the case.

//David

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

[systemd-devel] bcache broke in udev 220

[David Mohr]

Hi,

udev 220 arrived in Debian sid and this update broke bcache support [1]: 
no /dev/disk/by-uuid/ symlink is being created for the filesystem on top 
of /dev/bcache*. That's because 60-persistent-storage now uses a 
whitelist instead of blacklist. The simple attached patch fixes this, 
could you please apply it?


Thanks,
~David

[1]: http://bugs.debian.org/787367--- lib/udev/rules.d/60-persistent-storage.rules.orig   2015-05-31 
13:30:08.327444638 -0600
+++ lib/udev/rules.d/60-persistent-storage.rules2015-05-31 
13:30:14.799448929 -0600
@@ -6,7 +6,7 @@
 ACTION=="remove", GOTO="persistent_storage_end"
 
 SUBSYSTEM!="block", GOTO="persistent_storage_end"
-KERNEL!="loop*|mmcblk*[0-9]|msblk*[0-9]|mspblk*[0-9]|nvme*|sd*|sr*|vd*", 
GOTO="persistent_storage_end"
+KERNEL!="loop*|mmcblk*[0-9]|msblk*[0-9]|mspblk*[0-9]|nvme*|sd*|sr*|vd*|bcache*",
 GOTO="persistent_storage_end"
 
 # ignore partitions that span the entire disk
 TEST=="whole_disk", GOTO="persistent_storage_end"
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel