[systemd-devel] Problem with shutdown and automount units

[Harald Hoyer]

Today I changed the dracut-shutdown.service [1] to do its job on ExecStop,
This was done, to order the action before local-fs.target is stopped. Mainly to
run before boot.automount / boot.mount is stopped.

Works so far, but, if boot was _not_ yet automounted on shutdown, the
boot.automount is blocked to mount in the transition to the shutdown.target.

So, if any ExecStop relies on a path, which is normally automounted, but not
yet used, it fails on execution.

[1]
http://git.kernel.org/cgit/boot/dracut/dracut.git/tree/modules.d/98systemd/dracut-shutdown.service
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] networkd: update manpage for optional Gateway=

[Mantas Mikulėnas]

Following commit 59580681f5f.
---
 man/systemd.network.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man/systemd.network.xml b/man/systemd.network.xml
index 11b4370..1edaa0b 100644
--- a/man/systemd.network.xml
+++ b/man/systemd.network.xml
@@ -429,7 +429,7 @@
 varlistentry
 
termvarnameGateway=/varname/term
 listitem
-paraAs in the 
literal[Network]/literal section. This key is mandatory./para
+paraAs in the 
literal[Network]/literal section./para
 /listitem
 /varlistentry
 varlistentry
-- 
2.2.0

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

[systemd-devel] [PATCH v5 1/4] bus: StartTransientUnit can have aux unit

[WaLyong Cho]

---
 src/core/dbus-manager.c | 98 +++--
 1 file changed, 86 insertions(+), 12 deletions(-)

diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
index 0994d7b..5fe06f9 100644
--- a/src/core/dbus-manager.c
+++ b/src/core/dbus-manager.c
@@ -615,6 +615,90 @@ static int method_set_unit_properties(sd_bus *bus, 
sd_bus_message *message, void
 return bus_unit_method_set_properties(bus, message, u, error);
 }
 
+static int transient_unit_from_message(
+Manager *m,
+sd_bus_message *message,
+const char *name,
+Unit **unit,
+sd_bus_error *error) {
+
+Unit *u;
+int r;
+
+assert(m);
+assert(message);
+assert(name);
+
+r = manager_load_unit(m, name, NULL, error, u);
+if (r  0)
+return r;
+
+if (u-load_state != UNIT_NOT_FOUND ||
+set_size(u-dependencies[UNIT_REFERENCED_BY])  0)
+return sd_bus_error_setf(error, BUS_ERROR_UNIT_EXISTS, Unit 
%s already exists., name);
+
+/* OK, the unit failed to load and is unreferenced, now let's
+ * fill in the transient data instead */
+r = unit_make_transient(u);
+if (r  0)
+return r;
+
+/* Set our properties */
+r = bus_unit_set_properties(u, message, UNIT_RUNTIME, false, error);
+if (r  0)
+return r;
+
+*unit = u;
+
+return 0;
+}
+
+static int transient_aux_units_from_message(
+Manager *m,
+sd_bus_message *message,
+sd_bus_error *error) {
+
+Unit *u;
+char *name = NULL;
+int r;
+
+assert(m);
+assert(message);
+
+r = sd_bus_message_enter_container(message, 'a', (sa(sv)));
+if (r  0)
+return r;
+
+while ((r = sd_bus_message_enter_container(message, 'r', sa(sv)))  
0) {
+if (r = 0)
+return r;
+
+r = sd_bus_message_read(message, s, name);
+if (r  0)
+return r;
+
+r = transient_unit_from_message(m, message, name, u, error);
+if (r  0  r != -EEXIST)
+return r;
+
+r = unit_load(u);
+if (r  0)
+return r;
+
+r = sd_bus_message_exit_container(message);
+if (r  0)
+return r;
+}
+if (r  0)
+return r;
+
+r = sd_bus_message_exit_container(message);
+if (r  0)
+return r;
+
+return 0;
+}
+
 static int method_start_transient_unit(sd_bus *bus, sd_bus_message *message, 
void *userdata, sd_bus_error *error) {
 const char *name, *smode;
 Manager *m = userdata;
@@ -652,21 +736,11 @@ static int method_start_transient_unit(sd_bus *bus, 
sd_bus_message *message, voi
 if (r  0)
 return r;
 
-r = manager_load_unit(m, name, NULL, error, u);
-if (r  0)
-return r;
-
-if (u-load_state != UNIT_NOT_FOUND || 
set_size(u-dependencies[UNIT_REFERENCED_BY])  0)
-return sd_bus_error_setf(error, BUS_ERROR_UNIT_EXISTS, Unit 
%s already exists., name);
-
-/* OK, the unit failed to load and is unreferenced, now let's
- * fill in the transient data instead */
-r = unit_make_transient(u);
+r = transient_unit_from_message(m, message, name, u, error);
 if (r  0)
 return r;
 
-/* Set our properties */
-r = bus_unit_set_properties(u, message, UNIT_RUNTIME, false, error);
+r = transient_aux_units_from_message(m, message, error);
 if (r  0)
 return r;
 
-- 
1.9.3

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

[systemd-devel] [PATCH v5 2/4] util: introduce new sec_to_stringa()

[WaLyong Cho]

---
 src/shared/time-util.c | 52 ++
 src/shared/time-util.h |  1 +
 src/test/test-time.c   | 20 +++
 3 files changed, 73 insertions(+)

diff --git a/src/shared/time-util.c b/src/shared/time-util.c
index d3404af..d94be7e 100644
--- a/src/shared/time-util.c
+++ b/src/shared/time-util.c
@@ -861,6 +861,58 @@ int parse_nsec(const char *t, nsec_t *nsec) {
 return 0;
 }
 
+int sec_to_stringa(const char *t, usec_t usec, const char **time) {
+static const struct {
+const char *suffix;
+usec_t usec;
+} table[] = {
+{ seconds, USEC_PER_SEC },
+{ second, USEC_PER_SEC },
+{ sec, USEC_PER_SEC },
+{ s, USEC_PER_SEC },
+{ minutes, USEC_PER_MINUTE },
+{ minute, USEC_PER_MINUTE },
+{ min, USEC_PER_MINUTE },
+{ months, USEC_PER_MONTH },
+{ month, USEC_PER_MONTH },
+{ msec, USEC_PER_MSEC },
+{ ms, USEC_PER_MSEC },
+{ m, USEC_PER_MINUTE },
+{ hours, USEC_PER_HOUR },
+{ hour, USEC_PER_HOUR },
+{ hr, USEC_PER_HOUR },
+{ h, USEC_PER_HOUR },
+{ days, USEC_PER_DAY },
+{ day, USEC_PER_DAY },
+{ d, USEC_PER_DAY },
+{ weeks, USEC_PER_WEEK },
+{ week, USEC_PER_WEEK },
+{ w, USEC_PER_WEEK },
+{ years, USEC_PER_YEAR },
+{ year, USEC_PER_YEAR },
+{ y, USEC_PER_YEAR },
+{ usec, 1ULL },
+{ us, 1ULL },
+{ , USEC_PER_SEC }, /* default is sec */
+};
+
+char *s = NULL;
+unsigned i;
+
+for (i = 0; i  ELEMENTSOF(table); i++) {
+if (streq(t, table[i].suffix)) {
+if (asprintf(s, %g%s, ((double) 
usec)/table[i].usec, t)  0)
+return -ENOMEM;
+
+*time = s;
+
+return 0;
+}
+}
+
+return -EINVAL;
+}
+
 bool ntp_synced(void) {
 struct timex txc = {};
 
diff --git a/src/shared/time-util.h b/src/shared/time-util.h
index b55a660..7d0eff9 100644
--- a/src/shared/time-util.h
+++ b/src/shared/time-util.h
@@ -100,6 +100,7 @@ int parse_timestamp(const char *t, usec_t *usec);
 
 int parse_sec(const char *t, usec_t *usec);
 int parse_nsec(const char *t, nsec_t *nsec);
+int sec_to_stringa(const char *t, usec_t usec, const char **time);
 
 bool ntp_synced(void);
 
diff --git a/src/test/test-time.c b/src/test/test-time.c
index 8cfc4cc..b57639a 100644
--- a/src/test/test-time.c
+++ b/src/test/test-time.c
@@ -86,6 +86,25 @@ static void test_parse_nsec(void) {
 assert_se(parse_nsec(.s , u)  0);
 }
 
+static void test_sec_to_stringa(void) {
+_cleanup_free_ const char *time1 = NULL, *time2 = NULL, *time3 = NULL, 
*time4 = NULL, *time5 = NULL;
+
+assert_se(sec_to_stringa(, 27314123, time1) = 0);
+puts(time1);
+
+assert_se(sec_to_stringa(sec, 27314123, time2) = 0);
+puts(time2);
+
+assert_se(sec_to_stringa(ms, 27314123, time3) = 0);
+puts(time3);
+
+assert_se(sec_to_stringa(days, 27314123, time4) = 0);
+puts(time4);
+
+assert_se(sec_to_stringa(years, 27314123, time5) = 0);
+puts(time5);
+}
+
 static void test_format_timespan_one(usec_t x, usec_t accuracy) {
 char *r;
 char l[FORMAT_TIMESPAN_MAX];
@@ -156,6 +175,7 @@ static void test_get_timezones(void) {
 int main(int argc, char *argv[]) {
 test_parse_sec();
 test_parse_nsec();
+test_sec_to_stringa();
 test_format_timespan(1);
 test_format_timespan(USEC_PER_MSEC);
 test_format_timespan(USEC_PER_SEC);
-- 
1.9.3

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

[systemd-devel] [PATCH v5 4/4] run: introduce timer support option

[WaLyong Cho]

Support timer options --on-active=, --on-boot=, --on-startup=,
--on-unit-active=, --on-unit-inactive=, --on-calendar=. Each options
corresponding with OnActiveSec=, OnBootSec=, OnStartupSec=,
OnUnitActiveSec=, OnUnitInactiveSec=, OnCalendar= of timer
respectively. And OnCalendar= and WakeSystem= supported by
--timer-property= option like --property= of systemd-run.
---
 man/systemd-run.xml  |  64 
 src/libsystemd/sd-bus/bus-util.c |  14 +-
 src/run/run.c| 619 +++
 3 files changed, 580 insertions(+), 117 deletions(-)

diff --git a/man/systemd-run.xml b/man/systemd-run.xml
index 28a9878..30e7783 100644
--- a/man/systemd-run.xml
+++ b/man/systemd-run.xml
@@ -210,6 +210,54 @@ along with systemd; If not, see 
http://www.gnu.org/licenses/.
   xi:include href=user-system-options.xml xpointer=host /
   xi:include href=user-system-options.xml xpointer=machine /
 
+  varlistentry
+termoption--on-active=/option/term
+termoption--on-boot=/option/term
+termoption--on-startup=/option/term
+termoption--on-unit-active=/option/term
+termoption--on-unit-inactive=/option/term
+
+listitemparaDefines monotonic timers relative to different
+starting points. Also see varnameOnActiveSec=/varname,
+varnameOnBootSec=/varname,
+varnameOnStartupSec=/varname,
+varnameOnUnitActiveSec=/varname and
+varnameOnUnitInactiveSec=/varname in
+
citerefentryrefentrytitlesystemd.timer/refentrytitlemanvolnum5/manvolnum/citerefentry.
 This
+option has no effect in conjunction with
+option--scope/option./para
+/listitem
+  /varlistentry
+
+  varlistentry
+termoption--on-calendar=/option/term
+
+listitemparaDefines realtime (i.e. wallclock) timers with
+calendar event expressions. Also see
+varnameOnCalendar=/varname in
+
citerefentryrefentrytitlesystemd.timer/refentrytitlemanvolnum5/manvolnum/citerefentry.
 This
+option has no effect in conjunction with
+option--scope/option./para
+/listitem
+  /varlistentry
+
+  varlistentry
+termoption--timer-property=/option/term
+
+listitemparaSets a timer unit property for the timer unit
+that is created. It is similar with
+option--property/option but only for created timer
+unit. This option only has effect in conjunction with
+option--on-active=/option, option--on-boot=/option,
+option--on-startup=/option,
+option--on-unit-active=/option,
+option--on-unit-inactive=/option,
+option--on-calendar=/option. This takes an assignment in
+the same format as
+
citerefentryrefentrytitlesystemctl/refentrytitlemanvolnum1/manvolnum/citerefentry's
+commandset-property/command command./para /listitem
+  /varlistentry
+
   xi:include href=standard-options.xml xpointer=help /
   xi:include href=standard-options.xml xpointer=version /
 /variablelist
@@ -250,6 +298,21 @@ Sep 08 07:37:21 bupkis env[19948]: 
BOOT_IMAGE=/vmlinuz-3.11.0-0.rc5.git6.2.fc20.
 property./para
 
 programlisting# systemd-run -p BlockIOWeight=10 updatedb/programlisting
+
+paraThe following command will touch a file after 10 seconds./para
+
+programlisting# date; systemd-run --on-active=30 
--timer-property=AccuracySec=100ms /bin/touch /tmp/foo
+Mon Dec  8 20:44:24 KST 2014
+Running as unit run-71.timer.
+Will run as unit run-71.service.
+# journalctl -b -u run-73.timer
+-- Logs begin at Fri 2014-12-05 19:09:21 KST, end at Mon 2014-12-08 20:44:54 
KST. --
+Dec 08 20:44:38 container systemd[1]: Starting /bin/touch /tmp/foo.
+Dec 08 20:44:38 container systemd[1]: Started /bin/touch /tmp/foo.
+# journalctl -b -u run-73.service
+-- Logs begin at Fri 2014-12-05 19:09:21 KST, end at Mon 2014-12-08 20:44:54 
KST. --
+Dec 08 20:44:48 container systemd[1]: Starting /bin/touch /tmp/foo...
+Dec 08 20:44:48 container systemd[1]: Started /bin/touch 
/tmp/foo./programlisting
   /refsect1
 
   refsect1
@@ -263,6 +326,7 @@ Sep 08 07:37:21 bupkis env[19948]: 
BOOT_IMAGE=/vmlinuz-3.11.0-0.rc5.git6.2.fc20.
   
citerefentryrefentrytitlesystemd.slice/refentrytitlemanvolnum5/manvolnum/citerefentry,
   
citerefentryrefentrytitlesystemd.exec/refentrytitlemanvolnum5/manvolnum/citerefentry,
   
citerefentryrefentrytitlesystemd.resource-control/refentrytitlemanvolnum5/manvolnum/citerefentry,
+  
citerefentryrefentrytitlesystemd.timer/refentrytitlemanvolnum5/manvolnum/citerefentry,
   
citerefentryrefentrytitlemachinectl/refentrytitlemanvolnum1/manvolnum/citerefentry
 /para
   /refsect1
diff --git a/src/libsystemd/sd-bus/bus-util.c b/src/libsystemd/sd-bus/bus-util.c
index bdaa449..0f1a89c 100644
--- a/src/libsystemd/sd-bus/bus-util.c
+++ b/src/libsystemd/sd-bus/bus-util.c
@@ -1372,7 +1372,8 @@ int bus_append_unit_property_assignment(sd_bus_message 

[systemd-devel] [PATCH v5 2/4] util: introduce new sec_to_stringa()

[WaLyong Cho]

---
 src/shared/time-util.c | 63 ++
 src/shared/time-util.h |  1 +
 src/test/test-time.c   | 20 
 3 files changed, 84 insertions(+)

diff --git a/src/shared/time-util.c b/src/shared/time-util.c
index d3404af..a45341d 100644
--- a/src/shared/time-util.c
+++ b/src/shared/time-util.c
@@ -861,6 +861,69 @@ int parse_nsec(const char *t, nsec_t *nsec) {
 return 0;
 }
 
+int sec_to_stringa(const char *t, usec_t usec, const char **time) {
+static const struct {
+const char *suffix;
+usec_t usec;
+} table[] = {
+{ seconds, USEC_PER_SEC },
+{ second, USEC_PER_SEC },
+{ sec, USEC_PER_SEC },
+{ s, USEC_PER_SEC },
+{ minutes, USEC_PER_MINUTE },
+{ minute, USEC_PER_MINUTE },
+{ min, USEC_PER_MINUTE },
+{ months, USEC_PER_MONTH },
+{ month, USEC_PER_MONTH },
+{ msec, USEC_PER_MSEC },
+{ ms, USEC_PER_MSEC },
+{ m, USEC_PER_MINUTE },
+{ hours, USEC_PER_HOUR },
+{ hour, USEC_PER_HOUR },
+{ hr, USEC_PER_HOUR },
+{ h, USEC_PER_HOUR },
+{ days, USEC_PER_DAY },
+{ day, USEC_PER_DAY },
+{ d, USEC_PER_DAY },
+{ weeks, USEC_PER_WEEK },
+{ week, USEC_PER_WEEK },
+{ w, USEC_PER_WEEK },
+{ years, USEC_PER_YEAR },
+{ year, USEC_PER_YEAR },
+{ y, USEC_PER_YEAR },
+{ usec, 1ULL },
+{ us, 1ULL },
+{ , USEC_PER_SEC }, /* default is sec */
+};
+
+char *s = NULL;
+unsigned i;
+
+assert(time);
+
+if (!t) {
+if (asprintf(s, %g, ((double) usec)/USEC_PER_SEC)  0)
+return -ENOMEM;
+
+*time = s;
+
+return 0;
+}
+
+for (i = 0; i  ELEMENTSOF(table); i++) {
+if (streq(t, table[i].suffix)) {
+if (asprintf(s, %g%s, ((double) 
usec)/table[i].usec, t)  0)
+return -ENOMEM;
+
+*time = s;
+
+return 0;
+}
+}
+
+return -EINVAL;
+}
+
 bool ntp_synced(void) {
 struct timex txc = {};
 
diff --git a/src/shared/time-util.h b/src/shared/time-util.h
index b55a660..7d0eff9 100644
--- a/src/shared/time-util.h
+++ b/src/shared/time-util.h
@@ -100,6 +100,7 @@ int parse_timestamp(const char *t, usec_t *usec);
 
 int parse_sec(const char *t, usec_t *usec);
 int parse_nsec(const char *t, nsec_t *nsec);
+int sec_to_stringa(const char *t, usec_t usec, const char **time);
 
 bool ntp_synced(void);
 
diff --git a/src/test/test-time.c b/src/test/test-time.c
index 8cfc4cc..09de8f0 100644
--- a/src/test/test-time.c
+++ b/src/test/test-time.c
@@ -86,6 +86,25 @@ static void test_parse_nsec(void) {
 assert_se(parse_nsec(.s , u)  0);
 }
 
+static void test_sec_to_stringa(void) {
+_cleanup_free_ const char *time1 = NULL, *time2 = NULL, *time3 = NULL, 
*time4 = NULL, *time5 = NULL;
+
+assert_se(sec_to_stringa(NULL, 27314123, time1) = 0);
+puts(time1);
+
+assert_se(sec_to_stringa(sec, 27314123, time2) = 0);
+puts(time2);
+
+assert_se(sec_to_stringa(ms, 27314123, time3) = 0);
+puts(time3);
+
+assert_se(sec_to_stringa(days, 27314123, time4) = 0);
+puts(time4);
+
+assert_se(sec_to_stringa(years, 27314123, time5) = 0);
+puts(time5);
+}
+
 static void test_format_timespan_one(usec_t x, usec_t accuracy) {
 char *r;
 char l[FORMAT_TIMESPAN_MAX];
@@ -156,6 +175,7 @@ static void test_get_timezones(void) {
 int main(int argc, char *argv[]) {
 test_parse_sec();
 test_parse_nsec();
+test_sec_to_stringa();
 test_format_timespan(1);
 test_format_timespan(USEC_PER_MSEC);
 test_format_timespan(USEC_PER_SEC);
-- 
1.9.3

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

Re: [systemd-devel] Problem with shutdown and automount units

[Harald Hoyer]

On 08.12.2014 14:21, Harald Hoyer wrote:
 On 08.12.2014 13:28, Dave Reisner wrote:

 On Dec 8, 2014 5:54 AM, Harald Hoyer har...@redhat.com
 mailto:har...@redhat.com wrote:

 Today I changed the dracut-shutdown.service [1] to do its job on ExecStop,
 This was done, to order the action before local-fs.target is stopped. 
 Mainly to
 run before boot.automount / boot.mount is stopped.

 Works so far, but, if boot was _not_ yet automounted on shutdown, the
 boot.automount is blocked to mount in the transition to the shutdown.target.

 In mkinitcpio, we implemented a feature to build directly into /run, rather
 than extracting any existing initramfs.
 
 Neat, might be a solution to think of.

While I can workaround it, the systemd problem is still there.

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

Re: [systemd-devel] systemd-nspawn old guests

[Lennart Poettering]

On Fri, 05.12.14 20:25, Thomas S Hatch (thatc...@gmail.com) wrote:

 I have been having trouble running nspawn containers that don't have
 systemd (centos 6, Ubuntu 14.04, debian wheezy etc), I imagine I am just
 not finding the solution online.
 The container seems to start without issue but never presents a login
 prompt. I added audit=0 to the kernel arguments as the manpage suggested
 but to no avail.
 
 I am using systemd 217 on Arch Linux.
 Any suggestions as to where I should look to solve this?

By default most old distributions assume that the venerable VT
subsystem is available when booting up, and will present gettys on
/dev/tty1, /dev/tty2 and so on, which nspawn cannot provide however.

To make those old distributions work you need to patch /etc/inittab
(or similar) to execute the getty on /dev/console (which spawn does
provide) instead of /dev/tty1, /dev/tty2, and so on.

When using a systemd-enabled distribution inside a container, then no
such manual changes to it are necessary, as systemd contains
appropriate provisions since a longer time to invoke a single getty on
/dev/console if the VT subsystem is not available.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Nspawn / getty restart loop

[Lennart Poettering]

On Sat, 06.12.14 09:49, Meech (meech...@gmail.com) wrote:

 Running Arch64 / Systemd 217.   I have a barebones container initialized
 with pacstrap.   The conatiner is stored in /var/lib and started via
 systemd (systemctl start systemd-nspawn@mycontainer)
 
 When nobody is logged in, the journal is spammed every 10 seconds with
 agetty errors.   How can I prevent this?   It seems like it's in a never
 ending restart loop until somebody is logged in.

Hmm, did you manually enable container-getty@.service in some way?
Do you see any symlink to it in /etc/systemd/system/ somewhere? The
only way that service should be instantiated is during runtime with
tools like machinectl login.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Nspawn / getty restart loop

[Lennart Poettering]

On Sun, 07.12.14 09:20, Meech (meech...@gmail.com) wrote:

 Disabling seems to have no effect, it's a static service:
 
 console-getty.service  disabled
 container-getty@.service   static
 getty@.service enabled
 serial-getty@.service  disabled

Well, something appears to pull it in, the question is what precisely
is it...

 
 However, I think adding this to the [unit] section seems to help:
 
 ConditionPathExists=/dev/pts/%I
 
 Still testing.  Thanks.

That'd just be a work-around to ensure the service is skipped when it
is pulled in incorrectly, but we really should figure out why it is
pulled in incorrectly in the first place, and fix that.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Problem with shutdown and automount units

[Lennart Poettering]

On Mon, 08.12.14 11:54, Harald Hoyer (har...@redhat.com) wrote:

 Today I changed the dracut-shutdown.service [1] to do its job on ExecStop,
 This was done, to order the action before local-fs.target is stopped. Mainly 
 to
 run before boot.automount / boot.mount is stopped.
 
 Works so far, but, if boot was _not_ yet automounted on shutdown, the
 boot.automount is blocked to mount in the transition to the shutdown.target.
 
 So, if any ExecStop relies on a path, which is normally automounted, but not
 yet used, it fails on execution.

Yes, this is correct, we refuse new triggers of busnames, sockets or
automount units if we area going down, so that the shutdown operation
is not reversed. This is known behaviour.

If you know that ExecStop= needs some resource, I'd recommend pulling
in the unit for it explicitly with Wants=, so that it is pulled in
already during start. In you case, pull in the .mount unit with Wants=
in [Unit] and all should be good?

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Nspawn / getty restart loop

[Meech]

I created a fresh container by following the steps here
https://wiki.archlinux.org/index.php/Arch_systemd_container using the
command

pacstrap -i -c -d ~/MyContainer base

Not sure what is pulling it in.  Nor how to find out.

If I start it via systemd, the journal is quiet until I log in (via
machinectl login) for the very first time.   Then after I logout the
service goes into a restart loop every 10 seconds.




On Mon, Dec 8, 2014 at 9:15 AM, Lennart Poettering lenn...@poettering.net
wrote:

 On Sun, 07.12.14 09:20, Meech (meech...@gmail.com) wrote:

  Disabling seems to have no effect, it's a static service:
 
  console-getty.service  disabled
  container-getty@.service   static
  getty@.service enabled
  serial-getty@.service  disabled

 Well, something appears to pull it in, the question is what precisely
 is it...

 
  However, I think adding this to the [unit] section seems to help:
 
  ConditionPathExists=/dev/pts/%I
 
  Still testing.  Thanks.

 That'd just be a work-around to ensure the service is skipped when it
 is pulled in incorrectly, but we really should figure out why it is
 pulled in incorrectly in the first place, and fix that.

 Lennart

 --
 Lennart Poettering, Red Hat

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

Re: [systemd-devel] /usr vs /etc for default distro units enablement

[Lennart Poettering]

On Sun, 07.12.14 09:39, Martin Pitt (martin.p...@ubuntu.com) wrote:

 Hello all,
 
 sorry for the late response.
 
 Andrei Borzenkov [2014-12-05 10:58 +0300]:
  That's not how I actually understood it. enable/disable still applies
  only to units with [Install] section as it is now. Just that
 
 Correct. I don't see any need to change the behaviour of static units,
 and I don't want to change the visible effect of systemctl/disable,
 nor the current semantics of changing wants/ symlinks in /etc.
 
  unit foo.service is disabled if
  [...[
  2. There are no links from [Install] in /usr/lib or /etc *OR* there are
  links in /usr/lib which are masked in /etc.
 
 Indeed the part after the OR is the only change that I propose. I. e.
 
  - systemctl enable: If /usr/.../wants/foo.service exists, remove the
/dev/null symlink in /etc/.../wants/foo.service if it exists (if
not, it's already enabled). Otherwise, behave as now.
 
  - systemctl disable: If /usr/.../wants/foo.service exists, create a
/dev/null symlink in /etc/.../wants/foo.service if it doesn't exist
yet (if it does, it's already disabled). Otherwise, behave as now.

Sounds OK, would merge a good patch for this.

Thanks,

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Problem with shutdown and automount units

[Harald Hoyer]

On 08.12.2014 15:24, Lennart Poettering wrote:
 On Mon, 08.12.14 11:54, Harald Hoyer (har...@redhat.com) wrote:
 
 Today I changed the dracut-shutdown.service [1] to do its job on ExecStop,
 This was done, to order the action before local-fs.target is stopped. Mainly 
 to
 run before boot.automount / boot.mount is stopped.

 Works so far, but, if boot was _not_ yet automounted on shutdown, the
 boot.automount is blocked to mount in the transition to the shutdown.target.

 So, if any ExecStop relies on a path, which is normally automounted, but not
 yet used, it fails on execution.
 
 Yes, this is correct, we refuse new triggers of busnames, sockets or
 automount units if we area going down, so that the shutdown operation
 is not reversed. This is known behaviour.
 
 If you know that ExecStop= needs some resource, I'd recommend pulling
 in the unit for it explicitly with Wants=, so that it is pulled in
 already during start. In you case, pull in the .mount unit with Wants=
 in [Unit] and all should be good?
 
 Lennart
 

That would defeat the purpose of automount, wouldn't it?
Are you sure, you want to have all units Wants=var.mount Wants=boot.mount
Wants=opt.mount Want=srv.mount, which need /var /boot /opt or /srv in ExecStop?
I know, this does not happen that often, that ExecStart does not need the very
same... just asking.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 2/3] coredump: use lz4frame api to compress coredumps

[Lennart Poettering]

On Sun, 07.12.14 19:32, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

 This converts the stream compression to use the new lz4frame api,
 compatible with lz4cat. Previous code used custom headers, so the
 compressed file was not compatible with lz4 command line tools.
 I considered this the last blocker to using lz4 by default.
 
 Speed seems to be reasonable, although a bit (a few percent) slower
 than the lz4 binary, even though compression is the same. I don't
 consider this important. It could be caused by the overhead of library
 calls, but is probably caused by slightly different buffer sizes or
 such. The code in this patch uses mmap, since since this allows the
 buffer to be reused while not making the code more complicated at all.
 In my testing, this version is noticably faster (~20%) than a naive
 single-buffered version. mmap can cause the program to be killed with
 SIGBUS, if the underlying file is truncated or a disk error occurs. We
 only use this from within coredump and coredumpctl, so I don't
 consider this an issue.
 
 Old decompression code is retained and is used if the new code fails
 indicating a format error. I have various coredumps in the old format
 and would be unhappy if they suddenly stopped working. We can remove
 the legacy code in a few versions.
 
 The way that blobs are compressed in the journal is not affected.
 
 Note that lz4 125 has not been released yet, so this patch should
 not be applied currently.

Looks all goot to me. What I wonder though is whether we should maybe
one day compress blobs on the client-side and pass the compressed to
the journal, instead of compress them inside journald, maybe as a
later protocol extension?

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Problem with shutdown and automount units

[Lennart Poettering]

On Mon, 08.12.14 15:34, Harald Hoyer (harald.ho...@gmail.com) wrote:

 On 08.12.2014 15:24, Lennart Poettering wrote:
  On Mon, 08.12.14 11:54, Harald Hoyer (har...@redhat.com) wrote:
  
  Today I changed the dracut-shutdown.service [1] to do its job on ExecStop,
  This was done, to order the action before local-fs.target is stopped. 
  Mainly to
  run before boot.automount / boot.mount is stopped.
 
  Works so far, but, if boot was _not_ yet automounted on shutdown, the
  boot.automount is blocked to mount in the transition to the 
  shutdown.target.
 
  So, if any ExecStop relies on a path, which is normally automounted, but 
  not
  yet used, it fails on execution.
  
  Yes, this is correct, we refuse new triggers of busnames, sockets or
  automount units if we area going down, so that the shutdown operation
  is not reversed. This is known behaviour.
  
  If you know that ExecStop= needs some resource, I'd recommend pulling
  in the unit for it explicitly with Wants=, so that it is pulled in
  already during start. In you case, pull in the .mount unit with Wants=
  in [Unit] and all should be good?
  
  Lennart
  
 
 That would defeat the purpose of automount, wouldn't it?
 Are you sure, you want to have all units Wants=var.mount Wants=boot.mount
 Wants=opt.mount Want=srv.mount, which need /var /boot /opt or /srv in 
 ExecStop?
 I know, this does not happen that often, that ExecStart does not need the very
 same... just asking.

Well, if we have to trigger the automounts anyway during shutdown it
doesn't really matter when we trigger them: early on, or only very
late... 

Automounts are useful for to things: (a) parallelizing start-up and
(b) avoiding triggering automounts which aren't used. Now, (a) is
unaffected by pulling in the .mount unit from your shutdown
service. And (b) doesn't apply if you need to access the directory
anyway... Hence I don't see why this would defeat the purpose of
automounts...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v5 2/4] util: introduce new sec_to_stringa()

[Lennart Poettering]

On Mon, 08.12.14 21:18, WaLyong Cho (walyong@samsung.com) wrote:

 +int sec_to_stringa(const char *t, usec_t usec, const char **time) {
 +static const struct {
 +const char *suffix;
 +usec_t usec;
 +} table[] = {
 +{ seconds, USEC_PER_SEC },
 +{ second, USEC_PER_SEC },
 +{ sec, USEC_PER_SEC },
 +{ s, USEC_PER_SEC },
 +{ minutes, USEC_PER_MINUTE },
 +{ minute, USEC_PER_MINUTE },
 +{ min, USEC_PER_MINUTE },
 +{ months, USEC_PER_MONTH },
 +{ month, USEC_PER_MONTH },
 +{ msec, USEC_PER_MSEC },
 +{ ms, USEC_PER_MSEC },
 +{ m, USEC_PER_MINUTE },
 +{ hours, USEC_PER_HOUR },
 +{ hour, USEC_PER_HOUR },
 +{ hr, USEC_PER_HOUR },
 +{ h, USEC_PER_HOUR },
 +{ days, USEC_PER_DAY },
 +{ day, USEC_PER_DAY },
 +{ d, USEC_PER_DAY },
 +{ weeks, USEC_PER_WEEK },
 +{ week, USEC_PER_WEEK },
 +{ w, USEC_PER_WEEK },
 +{ years, USEC_PER_YEAR },
 +{ year, USEC_PER_YEAR },
 +{ y, USEC_PER_YEAR },
 +{ usec, 1ULL },
 +{ us, 1ULL },
 +{ , USEC_PER_SEC }, /* default is sec */
 +};
 +
 +char *s = NULL;
 +unsigned i;
 +
 +for (i = 0; i  ELEMENTSOF(table); i++) {
 +if (streq(t, table[i].suffix)) {
 +if (asprintf(s, %g%s, ((double) 
 usec)/table[i].usec, t)  0)
 +return -ENOMEM;
 +
 +*time = s;
 +
 +return 0;
 +}
 +}
 +
 +return -EINVAL;
 +}

Why this call? format_timespan() already does this, no?


Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v5 2/4] util: introduce new sec_to_stringa()

[WaLyong Cho]

On 12/08/2014 11:41 PM, Lennart Poettering wrote:
 On Mon, 08.12.14 21:18, WaLyong Cho (walyong@samsung.com) wrote:
 
 +int sec_to_stringa(const char *t, usec_t usec, const char **time) {
 +static const struct {
 +const char *suffix;
 +usec_t usec;
 +} table[] = {
 +{ seconds, USEC_PER_SEC },
 +{ second, USEC_PER_SEC },
 +{ sec, USEC_PER_SEC },
 +{ s, USEC_PER_SEC },
 +{ minutes, USEC_PER_MINUTE },
 +{ minute, USEC_PER_MINUTE },
 +{ min, USEC_PER_MINUTE },
 +{ months, USEC_PER_MONTH },
 +{ month, USEC_PER_MONTH },
 +{ msec, USEC_PER_MSEC },
 +{ ms, USEC_PER_MSEC },
 +{ m, USEC_PER_MINUTE },
 +{ hours, USEC_PER_HOUR },
 +{ hour, USEC_PER_HOUR },
 +{ hr, USEC_PER_HOUR },
 +{ h, USEC_PER_HOUR },
 +{ days, USEC_PER_DAY },
 +{ day, USEC_PER_DAY },
 +{ d, USEC_PER_DAY },
 +{ weeks, USEC_PER_WEEK },
 +{ week, USEC_PER_WEEK },
 +{ w, USEC_PER_WEEK },
 +{ years, USEC_PER_YEAR },
 +{ year, USEC_PER_YEAR },
 +{ y, USEC_PER_YEAR },
 +{ usec, 1ULL },
 +{ us, 1ULL },
 +{ , USEC_PER_SEC }, /* default is sec */
 +};
 +
 +char *s = NULL;
 +unsigned i;
 +
 +for (i = 0; i  ELEMENTSOF(table); i++) {
 +if (streq(t, table[i].suffix)) {
 +if (asprintf(s, %g%s, ((double) 
 usec)/table[i].usec, t)  0)
 +return -ENOMEM;
 +
 +*time = s;
 +
 +return 0;
 +}
 +}
 +
 +return -EINVAL;
 +}
 
 Why this call? format_timespan() already does this, no?
 
I didn't know that. I will send change.

Thanks,
WaLyong

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

Re: [systemd-devel] networkd link state

[Lennart Poettering]

On Sun, 07.12.14 14:37, Tom Gundersen (t...@jklm.no) wrote:

 Hi David,
 
 We may want to introduce a mechanism for installed, but not enabled
 configuration snippets, but we haven't quite figured it out yet.
 
 In the meantime, you can give your files a custom suffix or keep them in a
 sub directory, then either move or symlink to enable. This is likely how
 the upstream blessed mechanism will look like, rather than having a boolean
 inside the config files.

Yeah, I think we should just suggest people to rename files they want
to disable. We should probably recommend a convention though, for
example .disabled as suffix. We should recommend the convention
simply because in some cases we want the option to place multiple file
types the same dir, and we need to make sure that whatever people
rename things to doesn't turn it into something we might consider a
valid file name later on again.

I am tempted to just say .disabled as suffix is the easiest option,
but maybe somebody has better ideas?

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH v6 2/3] timer: timer can be a transient unit

[WaLyong Cho]

---
 src/core/dbus-timer.c | 143 ++
 src/core/dbus-timer.h |   3 ++
 src/core/timer.c  |   4 ++
 3 files changed, 150 insertions(+)

diff --git a/src/core/dbus-timer.c b/src/core/dbus-timer.c
index f1f8c54..43e7852 100644
--- a/src/core/dbus-timer.c
+++ b/src/core/dbus-timer.c
@@ -24,6 +24,8 @@
 #include dbus-unit.h
 #include dbus-timer.h
 #include bus-util.h
+#include errno-list.h
+#include strv.h
 
 static BUS_DEFINE_PROPERTY_GET_ENUM(property_get_result, timer_result, 
TimerResult);
 
@@ -183,3 +185,144 @@ const sd_bus_vtable bus_timer_vtable[] = {
 SD_BUS_PROPERTY(WakeSystem, b, bus_property_get_bool, 
offsetof(Timer, wake_system), SD_BUS_VTABLE_PROPERTY_CONST),
 SD_BUS_VTABLE_END
 };
+
+static int bus_timer_set_transient_property(
+Timer *t,
+const char *name,
+sd_bus_message *message,
+UnitSetPropertiesMode mode,
+sd_bus_error *error) {
+
+int r;
+
+assert(t);
+assert(name);
+assert(message);
+
+if (STR_IN_SET(name,
+   OnActiveSec,
+   OnBootSec,
+   OnStartupSec,
+   OnUnitActiveSec,
+   OnUnitInactiveSec)) {
+
+TimerValue *v;
+TimerBase b = _TIMER_BASE_INVALID;
+usec_t u = 0;
+
+b = timer_base_from_string(name);
+if (b  0)
+return -EINVAL;
+
+r = sd_bus_message_read(message, t, u);
+if (r  0)
+return r;
+
+if (mode != UNIT_CHECK) {
+char time[FORMAT_TIMESPAN_MAX];
+
+unit_write_drop_in_private_format(UNIT(t), mode, name, 
%s=%s\n, name, format_timespan(time, sizeof(time), u, USEC_PER_MSEC));
+
+v = new0(TimerValue, 1);
+if (!v)
+return -ENOMEM;
+
+v-base = b;
+v-value = u;
+
+LIST_PREPEND(value, t-values, v);
+}
+
+return 1;
+
+} else if (streq(name, OnCalendar)) {
+
+TimerValue *v;
+CalendarSpec *c = NULL;
+const char *str;
+
+r = sd_bus_message_read(message, s, str);
+if (r  0)
+return r;
+
+if (mode != UNIT_CHECK) {
+r = calendar_spec_from_string(str, c);
+if (r  0)
+return r;
+
+unit_write_drop_in_private_format(UNIT(t), mode, name, 
%s=%s\n, name, str);
+
+v = new0(TimerValue, 1);
+if (!v) {
+if (c)
+calendar_spec_free(c);
+return -ENOMEM;
+}
+
+v-base = TIMER_CALENDAR;
+v-calendar_spec = c;
+
+LIST_PREPEND(value, t-values, v);
+}
+
+return 1;
+
+} else if (streq(name, AccuracySec)) {
+
+usec_t u = 0;
+
+r = sd_bus_message_read(message, t, u);
+if (r  0)
+return r;
+
+if (mode != UNIT_CHECK) {
+char time[FORMAT_TIMESPAN_MAX];
+
+t-accuracy_usec = u;
+unit_write_drop_in_private_format(UNIT(t), mode, name, 
%s=%s\n, name, format_timespan(time, sizeof(time), u, USEC_PER_MSEC));
+}
+
+return 1;
+
+} else if (streq(name, WakeSystem)) {
+
+int b;
+
+r = sd_bus_message_read(message, b, b);
+if (r  0)
+return r;
+
+if (mode != UNIT_CHECK) {
+t-wake_system = b;
+unit_write_drop_in_private_format(UNIT(t), mode, name, 
%s=%s\n, name, yes_no(t-wake_system));
+}
+
+return 1;
+
+}
+
+return 0;
+}
+
+int bus_timer_set_property(
+Unit *u,
+const char *name,
+sd_bus_message *message,
+UnitSetPropertiesMode mode,
+sd_bus_error *error) {
+
+Timer *t = TIMER(u);
+int r;
+
+assert(t);
+assert(name);
+assert(message);
+
+if (u-transient  u-load_state == UNIT_STUB) {
+r = bus_timer_set_transient_property(t, name, message, mode, 
error);
+if (r != 0)
+return r;
+}
+
+return 0;
+}
diff --git a/src/core/dbus-timer.h b/src/core/dbus-timer.h
index 

[systemd-devel] [PATCH v6 1/3] bus: StartTransientUnit can have aux unit

[WaLyong Cho]

---
 src/core/dbus-manager.c | 98 +++--
 1 file changed, 86 insertions(+), 12 deletions(-)

diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
index 0994d7b..5fe06f9 100644
--- a/src/core/dbus-manager.c
+++ b/src/core/dbus-manager.c
@@ -615,6 +615,90 @@ static int method_set_unit_properties(sd_bus *bus, 
sd_bus_message *message, void
 return bus_unit_method_set_properties(bus, message, u, error);
 }
 
+static int transient_unit_from_message(
+Manager *m,
+sd_bus_message *message,
+const char *name,
+Unit **unit,
+sd_bus_error *error) {
+
+Unit *u;
+int r;
+
+assert(m);
+assert(message);
+assert(name);
+
+r = manager_load_unit(m, name, NULL, error, u);
+if (r  0)
+return r;
+
+if (u-load_state != UNIT_NOT_FOUND ||
+set_size(u-dependencies[UNIT_REFERENCED_BY])  0)
+return sd_bus_error_setf(error, BUS_ERROR_UNIT_EXISTS, Unit 
%s already exists., name);
+
+/* OK, the unit failed to load and is unreferenced, now let's
+ * fill in the transient data instead */
+r = unit_make_transient(u);
+if (r  0)
+return r;
+
+/* Set our properties */
+r = bus_unit_set_properties(u, message, UNIT_RUNTIME, false, error);
+if (r  0)
+return r;
+
+*unit = u;
+
+return 0;
+}
+
+static int transient_aux_units_from_message(
+Manager *m,
+sd_bus_message *message,
+sd_bus_error *error) {
+
+Unit *u;
+char *name = NULL;
+int r;
+
+assert(m);
+assert(message);
+
+r = sd_bus_message_enter_container(message, 'a', (sa(sv)));
+if (r  0)
+return r;
+
+while ((r = sd_bus_message_enter_container(message, 'r', sa(sv)))  
0) {
+if (r = 0)
+return r;
+
+r = sd_bus_message_read(message, s, name);
+if (r  0)
+return r;
+
+r = transient_unit_from_message(m, message, name, u, error);
+if (r  0  r != -EEXIST)
+return r;
+
+r = unit_load(u);
+if (r  0)
+return r;
+
+r = sd_bus_message_exit_container(message);
+if (r  0)
+return r;
+}
+if (r  0)
+return r;
+
+r = sd_bus_message_exit_container(message);
+if (r  0)
+return r;
+
+return 0;
+}
+
 static int method_start_transient_unit(sd_bus *bus, sd_bus_message *message, 
void *userdata, sd_bus_error *error) {
 const char *name, *smode;
 Manager *m = userdata;
@@ -652,21 +736,11 @@ static int method_start_transient_unit(sd_bus *bus, 
sd_bus_message *message, voi
 if (r  0)
 return r;
 
-r = manager_load_unit(m, name, NULL, error, u);
-if (r  0)
-return r;
-
-if (u-load_state != UNIT_NOT_FOUND || 
set_size(u-dependencies[UNIT_REFERENCED_BY])  0)
-return sd_bus_error_setf(error, BUS_ERROR_UNIT_EXISTS, Unit 
%s already exists., name);
-
-/* OK, the unit failed to load and is unreferenced, now let's
- * fill in the transient data instead */
-r = unit_make_transient(u);
+r = transient_unit_from_message(m, message, name, u, error);
 if (r  0)
 return r;
 
-/* Set our properties */
-r = bus_unit_set_properties(u, message, UNIT_RUNTIME, false, error);
+r = transient_aux_units_from_message(m, message, error);
 if (r  0)
 return r;
 
-- 
1.9.3

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

Re: [systemd-devel] [RFC] [PATCH] core: avoid duplicate unit property set

[Lennart Poettering]

On Mon, 08.12.14 15:12, WaLyong Cho (walyong@samsung.com) wrote:

 Currently, unit property set apis set unit property and also make a
 dropin files in each dbus-xyz.c. And the dropin will set its
 properties again in unit_load().
 So don't need to set property immediatly. That will be set next
 unit_load(). Just write dropin files only.

Well, we there are two kinds of options currently:

a) the ones you can change any time, using systemctl
   set-property. Primarily these are cgroup options to change
   resource controls during runtime. When systemctl set-property is
   invoked, then the changes should be instantly applied.

b) The ones you can only change when creating a transient unit, which
   cannot be changed later on with systemctl set-property. 

Now, both kinds of properties can be set when creating transient
units, but only the properties of type (a) can be altered after
creating the units using systemctl set-property.

Now, unit_load() is only invoked when we create units, or on
systemctl daemon-reload. We write the drop-in snippets for these
cases. However, we also want to allow the properties of type (a) to be
effective *without* actually waiting for unit_load(), they should
apply instantly, hence we apply them also directly, without
unit_load().

Hope this makes sense?


Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] [PATCH] core: avoid duplicate unit property set

[Lennart Poettering]

On Mon, 08.12.14 15:32, WaLyong Cho (walyong@samsung.com) wrote:

 Hi,
 
 First, I'd like to ask unit property should be applied immediately when
 systemctl set-property is called?
 If yes, after systemctl set-property, why we can see the message for
 daemon-reload. I think that should be re-loaded automatically.
 If no, some of unit properties are set immediatly.
 
 See below:
 # systemctl set-property dbus.service CPUShares=1200
 # systemctl status dbus.service
 * dbus.service - D-Bus System Message Bus
Loaded: loaded (/usr/lib/systemd/system/dbus.service; enabled; vendor
 preset: disabled)
Active: active (running) since Mon 2014-12-08 14:59:12 KST; 1min 30s ago
  Docs: man:dbus-daemon(1)
  Main PID: 31 (dbus-daemon)
CGroup: /machine.slice/machine-container.scope/system.slice/dbus.service
`-31 /usr/bin/dbus-daemon --system --address=systemd:
 --nofork --nopidfile --systemd-activation
 
 Dec 08 14:59:12 container systemd[1]: Starting D-Bus System Message Bus...
 Dec 08 14:59:12 container systemd[1]: Started D-Bus System Message Bus.
 Dec 08 14:59:12 container dbus[31]: [system] Successfully activated
 service 'org.freedesktop.systemd1'
 
 Warning: Unit file changed on disk, 'systemctl daemon-reload' recommended.
 
 systemctl status saied systemctl daemon-reload is needed. It sound
 something is changed and to apply that daemon-reload is needed.
 But I can notice that property already applied.

Hmm, yeah, that message shouldn't be shown. Are you sure it was
triggered by the set-property call though? Maybe it was there already before?

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 2/3] coredump: use lz4frame api to compress coredumps

[Zbigniew Jędrzejewski-Szmek]

On Mon, Dec 08, 2014 at 03:36:15PM +0100, Lennart Poettering wrote:
 On Sun, 07.12.14 19:32, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
 
  This converts the stream compression to use the new lz4frame api,
  compatible with lz4cat. Previous code used custom headers, so the
  compressed file was not compatible with lz4 command line tools.
  I considered this the last blocker to using lz4 by default.
  
  Speed seems to be reasonable, although a bit (a few percent) slower
  than the lz4 binary, even though compression is the same. I don't
  consider this important. It could be caused by the overhead of library
  calls, but is probably caused by slightly different buffer sizes or
  such. The code in this patch uses mmap, since since this allows the
  buffer to be reused while not making the code more complicated at all.
  In my testing, this version is noticably faster (~20%) than a naive
  single-buffered version. mmap can cause the program to be killed with
  SIGBUS, if the underlying file is truncated or a disk error occurs. We
  only use this from within coredump and coredumpctl, so I don't
  consider this an issue.
  
  Old decompression code is retained and is used if the new code fails
  indicating a format error. I have various coredumps in the old format
  and would be unhappy if they suddenly stopped working. We can remove
  the legacy code in a few versions.
  
  The way that blobs are compressed in the journal is not affected.
  
  Note that lz4 125 has not been released yet, so this patch should
  not be applied currently.
 
 Looks all goot to me. What I wonder though is whether we should maybe
 one day compress blobs on the client-side and pass the compressed to
 the journal, instead of compress them inside journald, maybe as a
 later protocol extension?
We could do that. Nevertheless, for lz4 the compression speed is at
30% of memory speed on my machine, so the gains are not that significant.
But going the other way, and allowing the client to request compressed
data could be more useful. Sometimes they are only interested in partial
decompression, so this could provide significant memory and cpu savings.

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

Re: [systemd-devel] [RFC] [PATCH] core: avoid duplicate unit property set

[WaLyong Cho]

On 12/09/2014 12:10 AM, Lennart Poettering wrote:
 On Mon, 08.12.14 15:32, WaLyong Cho (walyong@samsung.com) wrote:
 
 Hi,

 First, I'd like to ask unit property should be applied immediately when
 systemctl set-property is called?
 If yes, after systemctl set-property, why we can see the message for
 daemon-reload. I think that should be re-loaded automatically.
 If no, some of unit properties are set immediatly.

 See below:
 # systemctl set-property dbus.service CPUShares=1200
 # systemctl status dbus.service
 * dbus.service - D-Bus System Message Bus
Loaded: loaded (/usr/lib/systemd/system/dbus.service; enabled; vendor
 preset: disabled)
Active: active (running) since Mon 2014-12-08 14:59:12 KST; 1min 30s ago
  Docs: man:dbus-daemon(1)
  Main PID: 31 (dbus-daemon)
CGroup: /machine.slice/machine-container.scope/system.slice/dbus.service
`-31 /usr/bin/dbus-daemon --system --address=systemd:
 --nofork --nopidfile --systemd-activation

 Dec 08 14:59:12 container systemd[1]: Starting D-Bus System Message Bus...
 Dec 08 14:59:12 container systemd[1]: Started D-Bus System Message Bus.
 Dec 08 14:59:12 container dbus[31]: [system] Successfully activated
 service 'org.freedesktop.systemd1'

 Warning: Unit file changed on disk, 'systemctl daemon-reload' recommended.

 systemctl status saied systemctl daemon-reload is needed. It sound
 something is changed and to apply that daemon-reload is needed.
 But I can notice that property already applied.
 
 Hmm, yeah, that message shouldn't be shown. Are you sure it was
 triggered by the set-property call though? Maybe it was there already before?

See this log:

[root@container ~]# systemctl status dbus.service
* dbus.service - D-Bus System Message Bus
   Loaded: loaded (/usr/lib/systemd/system/dbus.service; enabled; vendor
preset: disabled)
   Active: active (running) since Tue 2014-12-09 00:22:50 KST; 10s ago
 Docs: man:dbus-daemon(1)
 Main PID: 32 (dbus-daemon)
   CGroup: /machine.slice/machine-container.scope/system.slice/dbus.service
   `-32 /usr/bin/dbus-daemon --system --address=systemd:
--nofork --nopidfile --systemd-activation

Dec 09 00:22:50 container systemd[1]: Starting D-Bus System Message Bus...
Dec 09 00:22:50 container systemd[1]: Started D-Bus System Message Bus.
Dec 09 00:22:50 container dbus[32]: [system] Successfully activated
service 'org.freedesktop.systemd1'
[root@container ~]#
[root@container ~]# systemctl set-property dbus.service CPUShares=777
[root@container ~]#
[root@container ~]# systemctl status dbus.service
* dbus.service - D-Bus System Message Bus
   Loaded: loaded (/usr/lib/systemd/system/dbus.service; enabled; vendor
preset: disabled)
   Active: active (running) since Tue 2014-12-09 00:22:50 KST; 29s ago
 Docs: man:dbus-daemon(1)
 Main PID: 32 (dbus-daemon)
   CGroup: /machine.slice/machine-container.scope/system.slice/dbus.service
   `-32 /usr/bin/dbus-daemon --system --address=systemd:
--nofork --nopidfile --systemd-activation

Dec 09 00:22:50 container systemd[1]: Starting D-Bus System Message Bus...
Dec 09 00:22:50 container systemd[1]: Started D-Bus System Message Bus.
Dec 09 00:22:50 container dbus[32]: [system] Successfully activated
service 'org.freedesktop.systemd1'

Warning: Unit file changed on disk, 'systemctl daemon-reload' recommended.
[root@container ~]#
[root@container ~]# cat
/sys/fs/cgroup/cpu/machine.slice/machine-container.scope/system.slice/dbus.service/cpu.shares

777


set-property is applied immediately well. I will try to prepare patch
for this.

And if the property set should be applied immediately then it seems
there are duplicate property set by unit_load_dropin(). Should we skip
unit_load_dropin() if the unit is transient?

WaLyong

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

Re: [systemd-devel] [PATCH v6 2/3] timer: timer can be a transient unit

[Lennart Poettering]

On Tue, 09.12.14 00:03, WaLyong Cho (walyong@samsung.com) wrote:

Applied 1/3 and 2/3!

Thanks!

 ---
  src/core/dbus-timer.c | 143 
 ++
  src/core/dbus-timer.h |   3 ++
  src/core/timer.c  |   4 ++
  3 files changed, 150 insertions(+)
 
 diff --git a/src/core/dbus-timer.c b/src/core/dbus-timer.c
 index f1f8c54..43e7852 100644
 --- a/src/core/dbus-timer.c
 +++ b/src/core/dbus-timer.c
 @@ -24,6 +24,8 @@
  #include dbus-unit.h
  #include dbus-timer.h
  #include bus-util.h
 +#include errno-list.h
 +#include strv.h
  
  static BUS_DEFINE_PROPERTY_GET_ENUM(property_get_result, timer_result, 
 TimerResult);
  
 @@ -183,3 +185,144 @@ const sd_bus_vtable bus_timer_vtable[] = {
  SD_BUS_PROPERTY(WakeSystem, b, bus_property_get_bool, 
 offsetof(Timer, wake_system), SD_BUS_VTABLE_PROPERTY_CONST),
  SD_BUS_VTABLE_END
  };
 +
 +static int bus_timer_set_transient_property(
 +Timer *t,
 +const char *name,
 +sd_bus_message *message,
 +UnitSetPropertiesMode mode,
 +sd_bus_error *error) {
 +
 +int r;
 +
 +assert(t);
 +assert(name);
 +assert(message);
 +
 +if (STR_IN_SET(name,
 +   OnActiveSec,
 +   OnBootSec,
 +   OnStartupSec,
 +   OnUnitActiveSec,
 +   OnUnitInactiveSec)) {
 +
 +TimerValue *v;
 +TimerBase b = _TIMER_BASE_INVALID;
 +usec_t u = 0;
 +
 +b = timer_base_from_string(name);
 +if (b  0)
 +return -EINVAL;
 +
 +r = sd_bus_message_read(message, t, u);
 +if (r  0)
 +return r;
 +
 +if (mode != UNIT_CHECK) {
 +char time[FORMAT_TIMESPAN_MAX];
 +
 +unit_write_drop_in_private_format(UNIT(t), mode, 
 name, %s=%s\n, name, format_timespan(time, sizeof(time), u, USEC_PER_MSEC));
 +
 +v = new0(TimerValue, 1);
 +if (!v)
 +return -ENOMEM;
 +
 +v-base = b;
 +v-value = u;
 +
 +LIST_PREPEND(value, t-values, v);
 +}
 +
 +return 1;
 +
 +} else if (streq(name, OnCalendar)) {
 +
 +TimerValue *v;
 +CalendarSpec *c = NULL;
 +const char *str;
 +
 +r = sd_bus_message_read(message, s, str);
 +if (r  0)
 +return r;
 +
 +if (mode != UNIT_CHECK) {
 +r = calendar_spec_from_string(str, c);
 +if (r  0)
 +return r;
 +
 +unit_write_drop_in_private_format(UNIT(t), mode, 
 name, %s=%s\n, name, str);
 +
 +v = new0(TimerValue, 1);
 +if (!v) {
 +if (c)
 +calendar_spec_free(c);
 +return -ENOMEM;
 +}
 +
 +v-base = TIMER_CALENDAR;
 +v-calendar_spec = c;
 +
 +LIST_PREPEND(value, t-values, v);
 +}
 +
 +return 1;
 +
 +} else if (streq(name, AccuracySec)) {
 +
 +usec_t u = 0;
 +
 +r = sd_bus_message_read(message, t, u);
 +if (r  0)
 +return r;
 +
 +if (mode != UNIT_CHECK) {
 +char time[FORMAT_TIMESPAN_MAX];
 +
 +t-accuracy_usec = u;
 +unit_write_drop_in_private_format(UNIT(t), mode, 
 name, %s=%s\n, name, format_timespan(time, sizeof(time), u, USEC_PER_MSEC));
 +}
 +
 +return 1;
 +
 +} else if (streq(name, WakeSystem)) {
 +
 +int b;
 +
 +r = sd_bus_message_read(message, b, b);
 +if (r  0)
 +return r;
 +
 +if (mode != UNIT_CHECK) {
 +t-wake_system = b;
 +unit_write_drop_in_private_format(UNIT(t), mode, 
 name, %s=%s\n, name, yes_no(t-wake_system));
 +}
 +
 +return 1;
 +
 +}
 +
 +return 0;
 +}
 +
 +int bus_timer_set_property(
 +Unit *u,
 +const char *name,
 +sd_bus_message *message,
 +UnitSetPropertiesMode mode,
 +sd_bus_error *error) {
 +
 +Timer *t = TIMER(u);
 +int r;
 +
 +assert(t);
 +assert(name);
 +assert(message);
 +
 +if (u-transient  u-load_state == 

Re: [systemd-devel] [PATCH v6 3/3] run: introduce timer support option

[Lennart Poettering]

On Tue, 09.12.14 00:03, WaLyong Cho (walyong@samsung.com) wrote:

  } else {
  log_error(Unknown assignment %s., assignment);
  return -EINVAL;
 diff --git a/src/run/run.c b/src/run/run.c
 index 85eb052..e145784 100644
 --- a/src/run/run.c
 +++ b/src/run/run.c
 @@ -30,6 +30,7 @@
  #include env-util.h
  #include path-util.h
  #include bus-error.h
 +#include calendarspec.h
  
  static bool arg_scope = false;
  static bool arg_remain_after_exit = false;
 @@ -47,27 +48,45 @@ static int arg_nice = 0;
  static bool arg_nice_set = false;
  static char **arg_environment = NULL;
  static char **arg_property = NULL;
 +static bool with_timer = false;

Hmm, maybe we should turn this boolean into a function? I mean, static
variables are something we should keep at a minimum. We do them for
command line arguments, since they are kinda global anyway, but I
think we should otherwise avoid them, especially if they are
effectively redundant anyway.

Hence, my suggestions would be to turn this into a call:

static bool with_timer(void) {
return arg_on_active || arg_on_boot || arg_on_startup || 
arg_on_unit_active || arg_on_unit_inactive || arg_on_calendar;
}

Or so?

 +static int start_transient_service(
 +sd_bus *bus,
 +char **argv,
 +sd_bus_error *error) {
 +
 +_cleanup_bus_message_unref_ sd_bus_message *m = NULL;
 +_cleanup_free_ char *service = NULL;
 +char *state = NULL;
 +int r;
 +
 +assert(bus);
 +assert(argv);
 +
 +if (arg_unit) {
 +service = unit_name_mangle_with_suffix(arg_unit, 
 MANGLE_NOGLOB, .service);
 +if (!service)
 +return log_oom();
 +
 +if (get_unit_state_by_name(bus, service, state) == 0) {
 +log_error(Unit %s is already exist with %s state., 
 service, state);
 +return -EEXIST;
 +}

What's the rationale for checking the unit state here? I mean, PID 1
should fail anyway in this case, do we realy need to check this name
in advance? I mean, such a check is necessarily racy, since the unit
might appear while between our client-side check and the actual
execution of the service, no?

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-nspawn old guests

[Thomas S Hatch]

Thanks Lennart! That makes perfect sense, been a long time since I needed
to mess around with this stuff.
Keep up the fantastic work! I am a big fan!

Thomas S. Hatch  |  Founder, CTO

3400 N. Ashton Blvd, Suite 110 | Lehi, UT 84043
tha...@saltstack.com | www.saltstack.com http://saltstack.com/

On Mon, Dec 8, 2014 at 7:08 AM, Lennart Poettering lenn...@poettering.net
wrote:

 On Fri, 05.12.14 20:25, Thomas S Hatch (thatc...@gmail.com) wrote:

  I have been having trouble running nspawn containers that don't have
  systemd (centos 6, Ubuntu 14.04, debian wheezy etc), I imagine I am just
  not finding the solution online.
  The container seems to start without issue but never presents a login
  prompt. I added audit=0 to the kernel arguments as the manpage suggested
  but to no avail.
 
  I am using systemd 217 on Arch Linux.
  Any suggestions as to where I should look to solve this?

 By default most old distributions assume that the venerable VT
 subsystem is available when booting up, and will present gettys on
 /dev/tty1, /dev/tty2 and so on, which nspawn cannot provide however.

 To make those old distributions work you need to patch /etc/inittab
 (or similar) to execute the getty on /dev/console (which spawn does
 provide) instead of /dev/tty1, /dev/tty2, and so on.

 When using a systemd-enabled distribution inside a container, then no
 such manual changes to it are necessary, as systemd contains
 appropriate provisions since a longer time to invoke a single getty on
 /dev/console if the VT subsystem is not available.

 Lennart

 --
 Lennart Poettering, Red Hat

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

Re: [systemd-devel] libabc, sub-objects, and reference counting

[David Herrmann]

Hi

On Sun, Dec 7, 2014 at 2:39 AM, Josh Triplett j...@joshtriplett.org wrote:
 The sample libabc includes functions to get a thing, as a sample
 sub-object of the overall library context.  Each thing has a reference
 to the parent library context, and a function to return that reference.
 Given that, shouldn't abc_thing_new_from_string call abc_ref, and
 abc_thing_unref call abc_unref?

Sure! Sounds like an oversight in libabc.

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

Re: [systemd-devel] [PATCH v6 3/3] run: introduce timer support option

[WaLyong Cho]

On 12/09/2014 12:38 AM, Lennart Poettering wrote:
 On Tue, 09.12.14 00:03, WaLyong Cho (walyong@samsung.com) wrote:
 
  } else {
  log_error(Unknown assignment %s., assignment);
  return -EINVAL;
 diff --git a/src/run/run.c b/src/run/run.c
 index 85eb052..e145784 100644
 --- a/src/run/run.c
 +++ b/src/run/run.c
 @@ -30,6 +30,7 @@
  #include env-util.h
  #include path-util.h
  #include bus-error.h
 +#include calendarspec.h
  
  static bool arg_scope = false;
  static bool arg_remain_after_exit = false;
 @@ -47,27 +48,45 @@ static int arg_nice = 0;
  static bool arg_nice_set = false;
  static char **arg_environment = NULL;
  static char **arg_property = NULL;
 +static bool with_timer = false;
 
 Hmm, maybe we should turn this boolean into a function? I mean, static
 variables are something we should keep at a minimum. We do them for
 command line arguments, since they are kinda global anyway, but I
 think we should otherwise avoid them, especially if they are
 effectively redundant anyway.
 
 Hence, my suggestions would be to turn this into a call:
 
 static bool with_timer(void) {
 return arg_on_active || arg_on_boot || arg_on_startup || 
 arg_on_unit_active || arg_on_unit_inactive || arg_on_calendar;
 }
 
 Or so?

Yes, it should be.
 
 +static int start_transient_service(
 +sd_bus *bus,
 +char **argv,
 +sd_bus_error *error) {
 +
 +_cleanup_bus_message_unref_ sd_bus_message *m = NULL;
 +_cleanup_free_ char *service = NULL;
 +char *state = NULL;
 +int r;
 +
 +assert(bus);
 +assert(argv);
 +
 +if (arg_unit) {
 +service = unit_name_mangle_with_suffix(arg_unit, 
 MANGLE_NOGLOB, .service);
 +if (!service)
 +return log_oom();
 +
 +if (get_unit_state_by_name(bus, service, state) == 0) {
 +log_error(Unit %s is already exist with %s 
 state., service, state);
 +return -EEXIST;
 +}
 
 What's the rationale for checking the unit state here? I mean, PID 1
 should fail anyway in this case, do we realy need to check this name
 in advance? I mean, such a check is necessarily racy, since the unit
 might appear while between our client-side check and the actual
 execution of the service, no?

I had plan to generate transient timer unit for already existing
service. To do that I needed get_unit_state_by_name() and I used that
also here.

with_aux = get_unit_state_by_name(bus, service, state)
 0 ? true : false;

Above is to determine that. Honestly, some of codes are removed during
rebase. I will rework for that.

Anyway, as you said, it is role of server side not client. I will remove
on here.

WaLyong

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

Re: [systemd-devel] networkd link state

[Mantas Mikulėnas]

On Mon, Dec 8, 2014 at 5:02 PM, Lennart Poettering lenn...@poettering.net
wrote:

 Yeah, I think we should just suggest people to rename files they want
 to disable. We should probably recommend a convention though, for
 example .disabled as suffix. We should recommend the convention
 simply because in some cases we want the option to place multiple file
 types the same dir, and we need to make sure that whatever people
 rename things to doesn't turn it into something we might consider a
 valid file name later on again.

 I am tempted to just say .disabled as suffix is the easiest option,
 but maybe somebody has better ideas?


How about ignoring the file if fullname.masked exists? touch/rm is a bit
easier than renaming.

Was thinking earlier about suggesting that for generators (which can't
really be renamed).

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

Re: [systemd-devel] [PATCH] networkd: update manpage for optional Gateway=

[Zbigniew Jędrzejewski-Szmek]

On Mon, Dec 08, 2014 at 01:53:30PM +0200, Mantas Mikulėnas wrote:
 Following commit 59580681f5f.
 ---
  man/systemd.network.xml | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
Applied.

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

Re: [systemd-devel] /usr vs /etc for default distro units enablement

[Zbigniew Jędrzejewski-Szmek]

On Fri, Dec 05, 2014 at 05:55:39PM +0200, Uoti Urpala wrote:
 Just leaving the symlinks would not give good behavior even in the case
 where the admin wants to keep the old target: temporary disable + then
 re-enable would now change the target. Perhaps the recommended way to
 change targets in local configuration should be to override the
 [Install] section, instead of just leaving different symlinks?
That'd be quite annoying. Maybe instead systemd-delta should learn
to highlight symlinks which are not specified by [Install] section.

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

Re: [systemd-devel] [PATCH v6 3/3] run: introduce timer support option

[Lennart Poettering]

On Tue, 09.12.14 01:13, WaLyong Cho (walyong@samsung.com) wrote:
  What's the rationale for checking the unit state here? I mean, PID 1
  should fail anyway in this case, do we realy need to check this name
  in advance? I mean, such a check is necessarily racy, since the unit
  might appear while between our client-side check and the actual
  execution of the service, no?
 
 I had plan to generate transient timer unit for already existing
 service. 

This might make sense to add one day, but I'd really leave that out
for now.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] journal: Fix navigating backwards missing entries

[Lennart Poettering]

On Fri, 05.12.14 16:06, Olivier Brunel (j...@jjacky.com) wrote:

 With DIRECTION_UP (i.e. navigating backwards) in generic_array_bisect() when 
 the
 needle was found as the last item in the array, it wasn't actually processed 
 as
 match, resulting in entries being missed.
 
 https://bugs.freedesktop.org/show_bug.cgi?id=86855
 ---
 This was a good excuse for me to dive in and learn about journal's internals,
 but someone with actual knowledge of said internals should review this, in 
 case
 I missed something.

Patch looks correct! Thanks a ton for tracking this down! Much
appreciated!

Applied!

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Installing user unit files.

[Rüdiger Sonderfeld]

Hello,

I'm currently in the process of adding a service file to GNU Emacs: 
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16507#26

The major point of discussion is how and where to install that file.  Systemd 
has guidelines for system service files in daemon(7).  One could follow them 
for user service files by simply replacing `systemdsystemunitdir' with 
`systemduserunitdir'.  Which is basically what the patch does so far.  However 
this would cause problems when (a) installing several versions of GNU Emacs in 
parallel and (b) user installations.

(a) could be solved by applying `program_transform_name' (from autoconf's 
AC_ARG_PROGRAM) to the service file name.  E.g., turning emacs.service into 
emacs24.service.

I'm not sure how to solve (b).  For a system service it might not make sense 
to install it somewhere outside of /usr (or /usr/local) and simply following 
`systemdsystemunitdir' makes sense.  But for a user application like GNU Emacs 
it should be possible to install it to any $prefix (e.g., ~/usr) without 
requiring root access.  Right now, I'm thinking of either setting the default 
to not install the service file or installing it to `datadir'.

What is the best practice for user unit files?  How are other projects 
handling this?

Regards,
Rüdiger

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

Re: [systemd-devel] Installing user unit files.

[Zbigniew Jędrzejewski-Szmek]

On Mon, Dec 08, 2014 at 07:31:07PM +0100, Rüdiger Sonderfeld wrote:
 Hello,
 
 I'm currently in the process of adding a service file to GNU Emacs: 
 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16507#26
 
 The major point of discussion is how and where to install that file.  Systemd 
 has guidelines for system service files in daemon(7).  One could follow them 
 for user service files by simply replacing `systemdsystemunitdir' with 
 `systemduserunitdir'.  Which is basically what the patch does so far.  
 However 
 this would cause problems when (a) installing several versions of GNU Emacs 
 in 
 parallel and (b) user installations.
 
 (a) could be solved by applying `program_transform_name' (from autoconf's 
 AC_ARG_PROGRAM) to the service file name.  E.g., turning emacs.service into 
 emacs24.service.
Sound like the best option, if you really want to support multiple versions.
Otherwise you might cop out and say that whatever version gets the 'emacs'
name, wins, and will be used by the service file. Normally you wouldn't want
multiple versions except for development, so covering multiple versions might
be overkill for the final user.
 
 I'm not sure how to solve (b).  For a system service it might not make sense 
 to install it somewhere outside of /usr (or /usr/local) and simply following 
 `systemdsystemunitdir' makes sense.  But for a user application like GNU 
 Emacs 
 it should be possible to install it to any $prefix (e.g., ~/usr) without 
 requiring root access.  Right now, I'm thinking of either setting the default 
 to not install the service file or installing it to `datadir'.
This destination must be know to systemd. So anything generic like ~/usr
is unlikely to work, unless systemd is modified to check that directory too.
When installed as a user, it should go to $HOME/.local/share/systemd/user/.
Please see [1] for an up-to-date list of directories where user units are
loaded from. The ones in $XDG_CONFIG_HOME are for user overrides, so
.local/share/ seems the most appropriate.

[1] 
http://www.freedesktop.org/software/systemd/man/systemd.unit.html#Unit%20Load%20Path

 What is the best practice for user unit files?  How are other projects 
 handling this?
This is all still new, so the best practices are still being developed ;)

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

Re: [systemd-devel] [PATCH] fstab-generator: Allow mount.usr without mount.usrflags, honor rw/ro

[Michael Marineau]

On Sun, Dec 7, 2014 at 4:51 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Sat, Dec 06, 2014 at 02:47:51PM -0800, Michael Marineau wrote:
 There is no need to require mount.usrflags. The original implementation
 assumed that a btrfs subvolume would always be needed but that is not
 applicable to systems that do not use btrfs for /usr.

 Similar to using rootflags= for the default of mount.usrflags=, append
 the classic 'ro' and 'rw' flags to the mount options.
 ---
  src/fstab-generator/fstab-generator.c | 11 +--
  1 file changed, 9 insertions(+), 2 deletions(-)

 diff --git a/src/fstab-generator/fstab-generator.c 
 b/src/fstab-generator/fstab-generator.c
 index e8a21f7..236fb37 100644
 --- a/src/fstab-generator/fstab-generator.c
 +++ b/src/fstab-generator/fstab-generator.c
 @@ -476,7 +476,7 @@ static int add_usr_mount(void) {
  return log_oom();
  }

 -if (!arg_usr_what || !arg_usr_options)
 +if (!arg_usr_what)
  return 0;

  what = fstab_node_to_udev_node(arg_usr_what);
 @@ -485,7 +485,14 @@ static int add_usr_mount(void) {
  return -1;
  }

 -opts = arg_usr_options;
 +if (!arg_usr_options)
 +opts = arg_root_rw  0 ? rw : ro;
 +else if (arg_root_rw = 0 ||
 + (!mount_test_option(arg_usr_options, ro) 
 +  !mount_test_option(arg_usr_options, rw)))
 This condition looks wrong. rw or ro will be always appended when
 arg_root_rw is set. Is the intent to override arg_usr_options?

 Zbyszek

Hm, yes. I read this wrong when coping it from add_root_mount,
assuming that 'rootflags=' had precedence over the bare 'ro' and 'rw'
options but it apparently is the other way around. For /usr we can
just drop the 'arg_root_rw = 0 ||' bit so 'mount.usrflags=' has
precedence. Will resend the patch.


 +opts = strappenda(arg_usr_options, ,, arg_root_rw  0 ? 
 rw : ro);
 +else
 +opts = arg_usr_options;

  log_debug(Found entry what=%s where=/sysroot/usr type=%s, what, 
 strna(arg_usr_fstype));
  return add_mount(what,
 --
 2.0.4

 ___
 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] Installing user unit files.

[Zbigniew Jędrzejewski-Szmek]

On Mon, Dec 08, 2014 at 07:31:07PM +0100, Rüdiger Sonderfeld wrote:
 Hello,
 
 I'm currently in the process of adding a service file to GNU Emacs: 
 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16507#26
To comment on the unit file itself:

 Description=Emacs: the extensible, customizable text editor - and more.
I think something which hints that this provides a shared instance
of emacs would be better than this generic blurb.
Maybe say something like 'Emacs in shared mode' or something. Also
keep in mind that this string is used in 'Starting %s...', 'Started %s.'
messages, so there should not be a dot a the end, and it really should
be a single phrase.

Would it be possible to make emacs socket-activated? This would be
a nice optimization, and the daemon could be configured to start
lazily, on first connection.

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

[systemd-devel] [PATCH v2] fstab-generator: Allow mount.usr without mount.usrflags, honor rw/ro

[Michael Marineau]

There is no need to require mount.usrflags. The original implementation
assumed that a btrfs subvolume would always be needed but that is not
applicable to systems that do not use btrfs for /usr.

Similar to using rootflags= for the default of mount.usrflags=, append
the classic 'ro' and 'rw' flags to the mount options.
---
 src/fstab-generator/fstab-generator.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/fstab-generator/fstab-generator.c 
b/src/fstab-generator/fstab-generator.c
index e8a21f7..c8d3ac0 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -476,7 +476,7 @@ static int add_usr_mount(void) {
 return log_oom();
 }
 
-if (!arg_usr_what || !arg_usr_options)
+if (!arg_usr_what)
 return 0;
 
 what = fstab_node_to_udev_node(arg_usr_what);
@@ -485,7 +485,13 @@ static int add_usr_mount(void) {
 return -1;
 }
 
-opts = arg_usr_options;
+if (!arg_usr_options)
+opts = arg_root_rw  0 ? rw : ro;
+else if (!mount_test_option(arg_usr_options, ro) 
+ !mount_test_option(arg_usr_options, rw))
+opts = strappenda(arg_usr_options, ,, arg_root_rw  0 ? rw 
: ro);
+else
+opts = arg_usr_options;
 
 log_debug(Found entry what=%s where=/sysroot/usr type=%s, what, 
strna(arg_usr_fstype));
 return add_mount(what,
-- 
2.0.4

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

Re: [systemd-devel] forever loop during garbage collection

[Lennart Poettering]

On Sun, 30.11.14 14:38, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

 Hi,
 
 We are experiencing an unbreakable loop in manager_dispatch_gc_queue.
 Problem happens when systemd runs in sysV compatibility mode (Porky
 enables this).
 
 Seems like manager_dispatch_gc_queue's while loop gets stuck and seems
 like unit_gc_sweep cannot make a decision about the unit. As a result,
 it marks the unit with offset_unsure and adds the unit back to gc
 queue.
 
 If I am reading the code correctly recursive unit_gc_sweep will never
 be able to remove the unit from the gc queue if it is referenced by
 another unit and if another unit is referenced by the unit.
 
 A is referenced by B
 B is referenced by A

So in this case first A will be processed by the GC sweep, it will
follow the link to B while setting the state to IN_PATH and invoke the
GC sweep on that. B will then be set to IN_PATH too. GC sweep now
follows its link back, and up at A again, but this time return quickly
because its state is set to IN_PATH. Due to this, it will then set B's
state to UNSURE, and return to A, which in effect will now be set to
UNSURE too. Now, we return into GC queue dispatch call, which will
notice that it is UNSURE and uprgade that to BAD, and kill it because
there's nothin in the unit's dependency network that is clearly a
GOOD, and hence should be removed.

The essence of cycle breaking here is really in
manager_dispatch_gc_queue() which uprgades UNSURE to BAD in the end. I
am not seeing how this could end up in an endless loop hence. 

 
 We have this circular referenced by dependency between units and I am
 quite sure they are due to sysV compatibility.
 
 I know that systemd does not allow circular dependency between units
 (ex, wants, or after) but do we allow circular referenced by
 dependency? If so, then it is expected that manager_dispatch_gc_queue
 gets stuck.
 
 We can reproduce it on 216/217 when we isolate a target.
 
 Note: Line 
 http://cgit.freedesktop.org/systemd/systemd/tree/src/core/manager.c?id=941a643569dc6b53d0b334276d2a3cc0ed159e88#n875
 should be before
 http://cgit.freedesktop.org/systemd/systemd/tree/src/core/manager.c?id=941a643569dc6b53d0b334276d2a3cc0ed159e88#n872
 since unit_gc_sweep() sets the u-in_gc_queue = true if it cannot make
 a decision and we set it back to false.

This is intended. After the sweep returned back to the anchor we can
make our decision: either add the unit to the cleanup queue in which
case it should removed from the GC queue, or it is reinstantated as
a good unit that should continue to exist, in which case it should be
removed from the GC queue too.

Can't see a bug here...

Can you elaborate on how precisely you are encountering the GC loop?

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v2 5/5] mount: auto-detect iSCSI and FCoE as requiring network

[Lennart Poettering]

On Fri, 05.12.14 15:54, Karel Zak (k...@redhat.com) wrote:

 On Fri, Dec 05, 2014 at 01:46:06AM +0100, Lennart Poettering wrote:
  With such an API you have the liberty to change later on what
  precisely you expose there. The fact that you watch a file would be
  entirely opaque, it could one day be a pipe or socket, or even an fd
  on some kernel fd, where you just tell us the kind of events you want
  the user code to listen on.
  
  This is how we wrap a lot of our own APIs, to allow integration into
  arbitrary main loops, without restricting us to decide how precisely
  the event is generated.
  
  Does this make sense?
 
 Yep.
 
  Would love to get an API in place for this in libmount, because I
  don't really want to release systemd with the current code.
 
 Implemented.
 
 I have added struct libmnt_monitor to make this new interface easy to
 extend and usable for more resources (I'll probably also add mountinfo
 fd for findmnt(8), but this is irrelevant for systemd;-)
 
 All you need is:
 
 mn = mnt_new_monitor();
 fd = mnt_monitor_userspace_get_fd(mn, NULL);/* utab monitor fd */
 
 mnt_monitor_get_events(mn, fd, ev.events); /* EPOLLIN ... */
 
 efd = epoll_create1(EPOLL_CLOEXEC);
   epoll_ctl(efd, EPOLL_CTL_ADD, fd, ev);
 
 
 n = epoll_wait(efd, events, 1, -1);
 id (n == 1  mnt_monitor_is_changed(mn, fd) == 1)
   printf(%s: change detected\n, mnt_monitor_get_filename(mn, 
 fd));
 
 
 mnt_unref_monitor(mn);
 close(efd);
 
 
 I guess it's enough to add the 'fd' to systmed sd_event_add_io() and
 call mnt_table_parse_mtab() when a change is detected. (As already
 implemeted in the original Chris' patch.)
 
 usable example:
 
 https://github.com/karelzak/util-linux/blob/master/libmount/src/monitor.c#L345

Any idea when you intend to realease this new API in a release or even
in a stable one?

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Installing user unit files.

[Rüdiger Sonderfeld]

On Monday 08 December 2014 19:46:18 Zbigniew Jędrzejewski-Szmek wrote:
 I think something which hints that this provides a shared instance
 of emacs would be better than this generic blurb.
 Maybe say something like 'Emacs in shared mode' or something. Also
 keep in mind that this string is used in 'Starting %s...', 'Started %s.'
 messages, so there should not be a dot a the end, and it really should
 be a single phrase.

Thanks for the suggestion.  I think I'll pick 'Emacs in daemon mode' or 'Emacs 
in server mode'.

 Would it be possible to make emacs socket-activated? This would be
 a nice optimization, and the daemon could be configured to start
 lazily, on first connection.

It should be possible.  But I don't think it's necessarily what most Emacs 
users want or expect.  Maybe it could be added in a future addition or both 
ways could be added, so the users can choose.  The current service file is 
based on the various service files for Emacs I've seen floating around 
(Emacswiki, Arch, wish-list reports).

Thanks for your comments!

Regards,
Rüdiger

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

Re: [systemd-devel] Installing user unit files.

[Rüdiger Sonderfeld]

On Monday 08 December 2014 19:40:14 Zbigniew Jędrzejewski-Szmek wrote:
 This destination must be know to systemd. So anything generic like ~/usr
 is unlikely to work, unless systemd is modified to check that directory too.
 When installed as a user, it should go to $HOME/.local/share/systemd/user/.
 Please see [1] for an up-to-date list of directories where user units are
 loaded from. The ones in $XDG_CONFIG_HOME are for user overrides, so
 .local/share/ seems the most appropriate.
 
 [1]
 http://www.freedesktop.org/software/systemd/man/systemd.unit.html#Unit%20Lo
 ad%20Path

It would then be up to the user to either adjust the install path or copy the 
file or adjust their systemd configuration.  But it would avoid the trouble of 
writing outside the user specified $prefix.

The options could be:

- prefix (meaning install it to the datadir)
- auto (meaning install it to whatever pkg-config says)
- no (don't install it)
- path (install it to that path)

With prefix being the default.  That would probably be the least surprising 
way for users.  But of course it would make the feature a bit harder to 
discover and require the user to do additional steps during installation and 
potentially during removal as well.

Regards,
Rüdiger
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Installing user unit files.

[Zbigniew Jędrzejewski-Szmek]

On Mon, Dec 08, 2014 at 08:51:43PM +0100, Rüdiger Sonderfeld wrote:
 On Monday 08 December 2014 19:40:14 Zbigniew Jędrzejewski-Szmek wrote:
  This destination must be know to systemd. So anything generic like ~/usr
  is unlikely to work, unless systemd is modified to check that directory too.
  When installed as a user, it should go to $HOME/.local/share/systemd/user/.
  Please see [1] for an up-to-date list of directories where user units are
  loaded from. The ones in $XDG_CONFIG_HOME are for user overrides, so
  .local/share/ seems the most appropriate.
  
  [1]
  http://www.freedesktop.org/software/systemd/man/systemd.unit.html#Unit%20Lo
  ad%20Path
 
 It would then be up to the user to either adjust the install path or copy the 
 file or adjust their systemd configuration.
This part of systemd configuration can only be done be recompling, and
systemd --user instances use the binary installed in /usr/lib/systemd/,
so changing the directory is not possible without root privileges anyway.

 But it would avoid the trouble of 
 writing outside the user specified $prefix.
Yes, but it would require manual fixups and would make the installed file
useless without further steps. It's a tradeoff ;)

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

Re: [systemd-devel] libabc, sub-objects, and reference counting

[Josh Triplett]

On Mon, Dec 08, 2014 at 05:09:17PM +0100, David Herrmann wrote:
 On Sun, Dec 7, 2014 at 2:39 AM, Josh Triplett j...@joshtriplett.org wrote:
  The sample libabc includes functions to get a thing, as a sample
  sub-object of the overall library context.  Each thing has a reference
  to the parent library context, and a function to return that reference.
  Given that, shouldn't abc_thing_new_from_string call abc_ref, and
  abc_thing_unref call abc_unref?
 
 Sure! Sounds like an oversight in libabc.

I'll send in a patch.

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

[systemd-devel] [PATCH] libabc: Make things hold a reference to their context

[Josh Triplett]

The sample libabc includes functions to get a thing, as a sample
sub-object of the overall library context.  Each thing has a reference
to the parent library context, and a function to return that reference.
Given that, abc_thing_new_from_string should call abc_ref, and
abc_thing_unref should call abc_unref when freeing a thing.
---
 src/libabc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/libabc.c b/src/libabc.c
index d6ef0b4..21e434b 100644
--- a/src/libabc.c
+++ b/src/libabc.c
@@ -251,6 +251,7 @@ ABC_EXPORT struct abc_thing *abc_thing_unref(struct 
abc_thing *thing)
 if (thing-refcount  0)
 return NULL;
 dbg(thing-ctx, context %p released\n, thing);
+abc_unref(thing-ctx);
 free(thing);
 return NULL;
 }
@@ -269,7 +270,7 @@ ABC_EXPORT int abc_thing_new_from_string(struct abc_ctx 
*ctx, const char *string
 return -ENOMEM;
 
 t-refcount = 1;
-t-ctx = ctx;
+t-ctx = abc_ref(ctx);
 *thing = t;
 return 0;
 }
-- 
2.1.3

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

Re: [systemd-devel] Nspawn / getty restart loop

[Lennart Poettering]

On Mon, 08.12.14 09:29, Meech (meech...@gmail.com) wrote:

 I created a fresh container by following the steps here
 https://wiki.archlinux.org/index.php/Arch_systemd_container using the
 command
 
 pacstrap -i -c -d ~/MyContainer base
 
 Not sure what is pulling it in.  Nor how to find out.
 
 If I start it via systemd, the journal is quiet until I log in (via
 machinectl login) for the very first time.   Then after I logout the
 service goes into a restart loop every 10 seconds.

Hmm, your proposoed fix with ConditionPathExists= is actually right,
after all, sorry for my earlier confusion.

We should restart the getty as long as the pts device is around, but
not do so anymore as soon as it is gone (which happens when
machinectl login dies). ConditionPathExists= is a nice way to
implement this.

I have now applied a patch that makes that change.

Thanks for tracking this down, and sorry for the confusion!

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] networkd link state

[Lennart Poettering]

On Mon, 08.12.14 18:55, Mantas Mikulėnas (graw...@gmail.com) wrote:

 On Mon, Dec 8, 2014 at 5:02 PM, Lennart Poettering lenn...@poettering.net
 wrote:
 
  Yeah, I think we should just suggest people to rename files they want
  to disable. We should probably recommend a convention though, for
  example .disabled as suffix. We should recommend the convention
  simply because in some cases we want the option to place multiple file
  types the same dir, and we need to make sure that whatever people
  rename things to doesn't turn it into something we might consider a
  valid file name later on again.
 
  I am tempted to just say .disabled as suffix is the easiest option,
  but maybe somebody has better ideas?
 
 How about ignoring the file if fullname.masked exists? touch/rm is a bit
 easier than renaming.

The word masking I'd really not overload for this, that should be
exclusively used for /de/null symlinks...

I think I find the renaming thing a bitmore intuitive, as it doesn't
create the question what to put in the files to create...

 Was thinking earlier about suggesting that for generators (which can't
 really be renamed).


Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v2] fstab-generator: Allow mount.usr without mount.usrflags, honor rw/ro

[Lennart Poettering]

On Mon, 08.12.14 11:05, Michael Marineau (michael.marin...@coreos.com) wrote:

 There is no need to require mount.usrflags. The original implementation
 assumed that a btrfs subvolume would always be needed but that is not
 applicable to systems that do not use btrfs for /usr.
 
 Similar to using rootflags= for the default of mount.usrflags=, append
 the classic 'ro' and 'rw' flags to the mount options.

Looks good! Applied!

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] cgroup: Handle error when destroying cgroup

[Lennart Poettering]

On Sat, 29.11.14 15:27, Ross Lagerwall (rosslagerw...@gmail.com) wrote:

 If a cgroup fails to be destroyed (most likely because there are still
 processes running as part of a service after the main pid exits), don't
 free and remove the cgroup unit from the manager.  This fixes a
 regression introduced by the cgroup rework in v205 where systemd would
 forget about processes still running after the unit becomes inactive.
 (This can happen when the main pid exits and KillMode=process or none).
 ---
 
 Not sure if this is the correct fix but it seems to fix the issue I reported.
 When the issue occurs, this notice is visible in the logs:
 Nov 28 22:11:32 centi7 systemd[1]: Failed to destroy cgroup 
 /system.slice/tester.service: Device or resource busy

Patch looks great actually. Applied! Thanks for tracking this down and
prepping a patch.

After applying it I renamed the unit_destroy_cgroup() call to
unit_destroy_cgroup_if_empty() since it is now much less destructive
than it used to be.

Thanks,

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [WIP PATCH] Do not realize and migrate cgroups multiple times

[Lennart Poettering]

On Mon, 01.12.14 12:06, Martin Pitt (martin.p...@ubuntu.com) wrote:

 Hello all,
 
 In my efforts to make user LXC containers work I noticed that under a
 real desktop (not just nspawn with VT login or ssh logins) my
 carefully set up cgroups in the non-systemd controllers get reverted.
 I. e. I put the session leader (and all other pids) of logind sessions
 (/user.slice/user-1000.slice/session-XX.scope) into all cgroup
 controllers, but a second after they are all back in the / cgroups (or
 sometimes in /user.slice). After some days of debugging (during which
 I learned a lot about the innards of systemd :-) I finally found out
 why:
 
 During unit cgroup initialization (unit_realize_cgroup), sibling
 cgroups are queued instead of initialized immediately.
 unit_create_cgroups() makes an attempt to avoid initializing and
 migrating a cgroup more than once:
 
path = unit_default_cgroup_path(u);
[...]
r = hashmap_put(u-manager-cgroup_unit, path, u);
 if (r  0) {
 log_error(r == -EEXIST ? cgroup %s exists already: %s : 
 hashmap_put failed for %s: %s, path, strerror(-r));
 return r;
 }
 
 But this doesn't work: path always gets allocated freshly in that
 function, so the pointer is never in the hashmap and the -EEXISTS
 never actually hits. This causes -.slice to be initialized and
 recursively migrated a gazillion times, which explains the random
 punting of sub-cgroup PIDs back to /.

hashmap_put() will actually compare the string, not the pointer to
it. Our hashmap implementation gets a hash function pointer as well as
an element comparison function as input, to ensure that that works
correctly.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] journalctl: respect --after-cursor semantics with --follow in all cases

[Lennart Poettering]

On Sun, 30.11.14 23:27, Wesley Dawson (w...@mozilla.com) wrote:

 In the case where no entries have been added to the journal after the 
 specified
 cursor, set need_seek before the main loop to prevent display of the entry at
 said cursor.

Looks good! Applied!

 ---
  src/journal/journalctl.c | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)
 
 diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c
 index 5c2a56d..3cec9a0 100644
 --- a/src/journal/journalctl.c
 +++ b/src/journal/journalctl.c
 @@ -1934,9 +1934,13 @@ int main(int argc, char *argv[]) {
  else
  r = sd_journal_previous_skip(j, 1 + 
 !!arg_after_cursor);
  
 -if (arg_after_cursor  r  2  !arg_follow)
 +if (arg_after_cursor  r  2) {
  /* We couldn't find the next entry after the cursor. 
 */
 -arg_lines = 0;
 +if (arg_follow)
 +need_seek = true;
 +else
 +arg_lines = 0;
 +}
  
  } else if (arg_since_set  !arg_reverse) {
  r = sd_journal_seek_realtime_usec(j, arg_since);
 -- 
 1.9.3
 
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH v7] run: introduce timer support option

[WaLyong Cho]

Support timer options --on-active=, --on-boot=, --on-startup=,
--on-unit-active=, --on-unit-inactive=, --on-calendar=. Each options
corresponding with OnActiveSec=, OnBootSec=, OnStartupSec=,
OnUnitActiveSec=, OnUnitInactiveSec=, OnCalendar= of timer
respectively. And OnCalendar= and WakeSystem= supported by
--timer-property= option like --property= of systemd-run.

And if --unit= option and timer options are specified the command can
be omitted. In this case, systemd-run assumes the target service is
already loaded. And just try to generate transient timer unit only.
---
 man/systemd-run.xml  |  94 +-
 src/core/dbus-manager.c  |   8 +-
 src/libsystemd/sd-bus/bus-util.c |  14 +-
 src/run/run.c| 628 ++-
 4 files changed, 596 insertions(+), 148 deletions(-)

diff --git a/man/systemd-run.xml b/man/systemd-run.xml
index 28a9878..b9cec91 100644
--- a/man/systemd-run.xml
+++ b/man/systemd-run.xml
@@ -45,7 +45,7 @@ along with systemd; If not, see 
http://www.gnu.org/licenses/.
 
   refnamediv
 refnamesystemd-run/refname
-refpurposeRun programs in transient scope or service units/refpurpose
+refpurposeRun programs in transient scope or service or timer 
units/refpurpose
   /refnamediv
 
   refsynopsisdiv
@@ -56,15 +56,23 @@ along with systemd; If not, see 
http://www.gnu.org/licenses/.
   arg choice=opt rep=repeatARGS/arg
   /arg
 /cmdsynopsis
+cmdsynopsis
+  commandsystemd-run/command
+  arg choice=opt rep=repeatOPTIONS/arg
+  arg choice=opt rep=repeatTIMER OPTIONS/arg
+  arg choice=reqreplaceableCOMMAND/replaceable/arg
+  arg choice=opt rep=repeatARGS/arg
+/cmdsynopsis
   /refsynopsisdiv
 
   refsect1
 titleDescription/title
 
-paracommandsystemd-run/command may be used to create and start
-a transient filename.service/filename or a
-filename.scope/filename unit and run the specified
-replaceableCOMMAND/replaceable in it./para
+paracommandsystemd-run/command may be used to create and
+start a transient filename.service/filename or a transient
+filename.timer/filename or a filename.scope/filename unit
+and run the specified replaceableCOMMAND/replaceable in
+it./para
 
 paraIf a command is run as transient service unit, it will be
 started and managed by the service manager like any other service,
@@ -74,6 +82,18 @@ along with systemd; If not, see 
http://www.gnu.org/licenses/.
 will start the service asynchronously in the background and
 immediately return./para
 
+paraIf a command is run with timer options, transient timer unit
+also be created with transient service unit. But the transient
+timer unit is only started immediately. The transient service unit
+will be started when the transient timer is elapsed. If
+option--unit=/option is specified with timer options, the
+replaceableCOMMAND/replaceable can be omitted. In this case,
+commandsystemd-run/command assumes service unit is already
+loaded and creates transient timer unit only. To successfully
+create timer unit, already loaded service unit should be specified
+with option--unit=/option. This transient timer unit can
+activate the existing service unit like any other timer./para
+
 paraIf a command is run as transient scope unit, it will be
 started directly by commandsystemd-run/command and thus
 inherit the execution environment of the caller. It is however
@@ -210,6 +230,54 @@ along with systemd; If not, see 
http://www.gnu.org/licenses/.
   xi:include href=user-system-options.xml xpointer=host /
   xi:include href=user-system-options.xml xpointer=machine /
 
+  varlistentry
+termoption--on-active=/option/term
+termoption--on-boot=/option/term
+termoption--on-startup=/option/term
+termoption--on-unit-active=/option/term
+termoption--on-unit-inactive=/option/term
+
+listitemparaDefines monotonic timers relative to different
+starting points. Also see varnameOnActiveSec=/varname,
+varnameOnBootSec=/varname,
+varnameOnStartupSec=/varname,
+varnameOnUnitActiveSec=/varname and
+varnameOnUnitInactiveSec=/varname in
+
citerefentryrefentrytitlesystemd.timer/refentrytitlemanvolnum5/manvolnum/citerefentry.
 This
+options have no effect in conjunction with
+option--scope/option./para
+/listitem
+  /varlistentry
+
+  varlistentry
+termoption--on-calendar=/option/term
+
+listitemparaDefines realtime (i.e. wallclock) timers with
+calendar event expressions. Also see
+varnameOnCalendar=/varname in
+
citerefentryrefentrytitlesystemd.timer/refentrytitlemanvolnum5/manvolnum/citerefentry.
 This
+option has no effect in conjunction with
+option--scope/option./para
+/listitem
+  /varlistentry
+
+  varlistentry
+