date:20150128

Lennart Poettering [2015-01-28  1:03 +0100]:
 I implemented a different logic now:
 
 http://cgit.freedesktop.org/systemd/systemd/commit/?id=37cf8fee46025d704660a9fc1d1349fe7d0b139d
 
 With this change we'll now dispatch only one mkswap per device node,
 regardless which symlinked alias is used to refer to it. I have only
 given this very light testing, and I am not sure this solves the
 original problem you reported, hence I'd be thankful if you could
 check if this makes the problem go away.

I built a package with this for Debian and Ubuntu. The Debian reporter
in https://bugs.debian.org/772182 confirmed that this is working, I
think/hope the Ubuntu reporter in
https://bugs.launchpad.net/bugs/1399595 is also usually very
responsive, I think he'll report back soon too. So it fixes that
problem, thanks!

However, in my VM with no GPT, but a simple fstab entry for the swap
booting now hangs forever, swap.target doesn't become active any more.
I don't have time right now to investigate this further, but I suppose
this should be fairly easy to reproduce.

Thanks,

Martin

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

Re: [systemd-devel] failing boot start jobs delay reboot

On Tue, 27.01.15 22:00, Felix Miata (mrma...@earthlink.net) wrote:

 Lennart Poettering composed on 2015-01-28 02:33 (UTC+0100):
 
  Felix Miata wrote
 ...
  So, I actually implemented this now. Or actually, I only implemented
  the part about C-A-D triggering a reboot. I picked 7x per 2s as limit
  though, seemed easier to me.
 
  It should be easy to extend this to show information about running
  jobs after 3x too.
 
  http://cgit.freedesktop.org/systemd/systemd/commit/?id=2e5c94b9aaefce46835b623e800cfc168995ea3f
 
  Hope this is useful,
 
 No objection from this non-programmer. Thanks. :-)
 
 Out of curiosity, I looked at that URL, little there I understand, but I did
 notice a comment string that seemed like might include a typo: C-A-D too 
 more.

Thanks for the pointer. Will fix.

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 10/12] Add fsckd service and socket, retarget systemd-fsck



From 000f1b6ff4f5f80a2a13309590d255de6d6526ec Mon Sep 17 00:00:00 2001
From: Didier Roche didro...@ubuntu.com
Date: Mon, 26 Jan 2015 17:30:00 +0100
Subject: [PATCH 10/12] Add fsckd service and socket, retarget systemd-fsck

systemd-fsckd can be socket-activated by systemd-fsck process. Reflect that
in the different unit files.
---
 Makefile.am|  3 +++
 units/.gitignore   |  1 +
 units/systemd-fsck-root.service.in |  4 +++-
 units/systemd-f...@.service.in |  5 +++--
 units/systemd-fsckd.service.in | 16 
 units/systemd-fsckd.socket | 15 +++
 6 files changed, 41 insertions(+), 3 deletions(-)
 create mode 100644 units/systemd-fsckd.service.in
 create mode 100644 units/systemd-fsckd.socket

diff --git a/Makefile.am b/Makefile.am
index a9d61f1..1eeba4f 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -492,6 +492,7 @@ dist_systemunit_DATA = \
 	units/slices.target \
 	units/system.slice \
 	units/x-.slice \
+	units/systemd-fsckd.socket \
 	units/systemd-initctl.socket \
 	units/systemd-shutdownd.socket \
 	units/syslog.socket \
@@ -543,6 +544,7 @@ nodist_systemunit_DATA = \
 	units/systemd-kexec.service \
 	units/systemd-fsck@.service \
 	units/systemd-fsck-root.service \
+	units/systemd-fsckd.service \
 	units/systemd-machine-id-commit.service \
 	units/systemd-udevd.service \
 	units/systemd-udev-trigger.service \
@@ -596,6 +598,7 @@ EXTRA_DIST += \
 	units/user/systemd-exit.service.in \
 	units/systemd-f...@.service.in \
 	units/systemd-fsck-root.service.in \
+	units/systemd-fsckd.service.in \
 	units/systemd-machine-id-commit.service.in \
 	units/u...@.service.m4.in \
 	units/debug-shell.service.in \
diff --git a/units/.gitignore b/units/.gitignore
index 6fdb629..26ae965 100644
--- a/units/.gitignore
+++ b/units/.gitignore
@@ -28,6 +28,7 @@
 /systemd-firstboot.service
 /systemd-fsck-root.service
 /systemd-fsck@.service
+/systemd-fsckd.service
 /systemd-machine-id-commit.service
 /systemd-halt.service
 /systemd-hibernate.service
diff --git a/units/systemd-fsck-root.service.in b/units/systemd-fsck-root.service.in
index 6d76578..bd3bdbc 100644
--- a/units/systemd-fsck-root.service.in
+++ b/units/systemd-fsck-root.service.in
@@ -9,12 +9,14 @@
 Description=File System Check on Root Device
 Documentation=man:systemd-fsck-root.service(8)
 DefaultDependencies=no
+Wants=systemd-fsckd.socket
 Before=local-fs.target shutdown.target
+After=systemd-fsckd.socket
 ConditionPathIsReadWrite=!/
 
 [Service]
 Type=oneshot
 RemainAfterExit=yes
 ExecStart=@rootlibexecdir@/systemd-fsck
-StandardOutput=journal+console
+StandardOutput=journal
 TimeoutSec=0
diff --git a/units/systemd-f...@.service.in b/units/systemd-f...@.service.in
index 857e625..3ceb5f2 100644
--- a/units/systemd-f...@.service.in
+++ b/units/systemd-f...@.service.in
@@ -10,12 +10,13 @@ Description=File System Check on %f
 Documentation=man:systemd-fsck@.service(8)
 DefaultDependencies=no
 BindsTo=%i.device
-After=%i.device systemd-fsck-root.service local-fs-pre.target
+Wants=systemd-fsckd.socket
+After=%i.device systemd-fsck-root.service local-fs-pre.target systemd-fsckd.socket
 Before=shutdown.target
 
 [Service]
 Type=oneshot
 RemainAfterExit=yes
 ExecStart=@rootlibexecdir@/systemd-fsck %f
-StandardOutput=journal+console
+StandardOutput=journal
 TimeoutSec=0
diff --git a/units/systemd-fsckd.service.in b/units/systemd-fsckd.service.in
new file mode 100644
index 000..27c325f
--- /dev/null
+++ b/units/systemd-fsckd.service.in
@@ -0,0 +1,16 @@
+#  This file is part of systemd.
+#
+#  systemd is free software; you can redistribute it and/or modify it
+#  under the terms of the GNU Lesser General Public License as published by
+#  the Free Software Foundation; either version 2.1 of the License, or
+#  (at your option) any later version.
+
+[Unit]
+Description=File System Check Daemon to report status
+DefaultDependencies=no
+Requires=systemd-fsckd.socket
+Before=shutdown.target
+
+[Service]
+ExecStart=@rootlibexecdir@/systemd-fsckd
+StandardOutput=journal+console
diff --git a/units/systemd-fsckd.socket b/units/systemd-fsckd.socket
new file mode 100644
index 000..96a034a
--- /dev/null
+++ b/units/systemd-fsckd.socket
@@ -0,0 +1,15 @@
+#  This file is part of systemd.
+#
+#  systemd is free software; you can redistribute it and/or modify it
+#  under the terms of the GNU Lesser General Public License as published by
+#  the Free Software Foundation; either version 2.1 of the License, or
+#  (at your option) any later version.
+
+[Unit]
+Description=fsck to fsckd communication Socket
+Documentation=man:systemd-fsck@.service(8) man:systemd-fsck-root.service(8)
+DefaultDependencies=no
+Before=sockets.target
+
+[Socket]
+ListenStream=/run/systemd/fsckd
-- 
2.1.4

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

[systemd-devel] [PATCH 12/12] Add mock fsck process



From aefe0667ed62d5d7e17193c0f5ae302ed57e4727 Mon Sep 17 00:00:00 2001
From: Didier Roche didro...@ubuntu.com
Date: Mon, 26 Jan 2015 17:46:36 +0100
Subject: [PATCH 12/12] Add mock fsck process

---
 test/mocks/fsck | 27 +++
 1 file changed, 27 insertions(+)
 create mode 100755 test/mocks/fsck

diff --git a/test/mocks/fsck b/test/mocks/fsck
new file mode 100755
index 000..77b50d7
--- /dev/null
+++ b/test/mocks/fsck
@@ -0,0 +1,27 @@
+#!/bin/bash
+fd=0
+
+OPTIND=1
+while getopts C:aTlM opt; do
+case $opt in
+C)
+fd=$OPTARG
+;;
+\?);;
+esac
+done
+
+shift $((OPTIND-1))
+device=$1
+
+echo Running fake fsck on $device
+
+declare -a maxpass=(30 5 2 30 60)
+
+for pass in {1..5}; do
+maxprogress=${maxpass[$((pass-1))]}
+for (( current=0; current=${maxprogress}; current++)); do
+echo $pass $current $maxprogress $device$fd
+sleep 0.1
+done
+done
-- 
2.1.4

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

Re: [systemd-devel] [PATCH] sysv-generator: Replace Provides: symlinks with real units

On Wed, Jan 28, 2015 at 02:56:17PM +0100, Michael Biebl wrote:
 2015-01-28 1:44 GMT+01:00 Lennart Poettering lenn...@poettering.net:
  I am not a fan of this stuff either. I really don't like the TOCTOU
  behaviour I must say...
 
  If this is really just about .bak, then we can add it to the list of
  suffixes in hidden_files()...
 
 Martin already committed an update [1] to at least ignore all the
 temporary files created by dpkg and dpkg-related helper tools.
 
 While adding .bak would probably not be wrong, I don't think it would
 solve this particular issue in a robust way.
 People are very inventive when it comes to such names. In the Debian
 bug report which triggered this patch, the user had a file named
 networking.save [2]. Most likely, this had been created by himself and
 later on he forgot to remove it.
 
  I think a much better fix for all of this would be to first read in
  all sysv scripts, and only then start creating aliases.
 
 I guess with read in, you actually mean read and parse all init
 scripts *and* generate all unit files. After that create the symlinks.
Actually this will not help for the TOCTOU race, IIUC.
systemd-sysv-generator does not race with itself, but with other
generators. But it seems fairly unlikely that a different generator
would create a symlink in generators.early, and if they do, that's
pretty much undefined behaviour who wins.

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

[systemd-devel] [PATCH 06/12] Support cancellation of fsck in progress



From 104cf82ba28941e907f277a713f834ceb3d909f0 Mon Sep 17 00:00:00 2001
From: Didier Roche didro...@ubuntu.com
Date: Mon, 26 Jan 2015 16:40:52 +0100
Subject: [PATCH 06/12] Support cancellation of fsck in progress

Grab in fsckd plymouth watch key for C or c, and propagate this cancel request
to systemd-fsck which will terminate fsck.

Send a message to signal to user what key we are grabbing for fsck cancel.

Message is: fsckd-cancel-msg:string
Where string is a translated string ready to be displayed by the plymouth theme
indicating that c or C can be used to cancel current checks. It can be
overriden (matching only fsckd-cancel-msg prefix) for themes supporting i18n.
---
 src/fsck/fsck.c   | 29 +
 src/fsckd/fsckd.c | 43 +++
 src/fsckd/fsckd.h |  5 +
 3 files changed, 69 insertions(+), 8 deletions(-)

diff --git a/src/fsck/fsck.c b/src/fsck/fsck.c
index f5dd546..0b42e3b 100644
--- a/src/fsck/fsck.c
+++ b/src/fsck/fsck.c
@@ -47,6 +47,8 @@
 static bool arg_skip = false;
 static bool arg_force = false;
 static const char *arg_repair = -a;
+static pid_t fsck_pid;
+static bool cancel_requested = false;
 
 static void start_target(const char *target) {
 _cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
@@ -165,6 +167,7 @@ static int process_progress(int fd) {
 ssize_t n;
 usec_t t;
 FsckProgress progress;
+FsckdMessage fsckd_message;
 
 if (fscanf(f, %i %lu %lu %ms, pass, cur, max, device) != 4)
 break;
@@ -185,6 +188,16 @@ static int process_progress(int fd) {
 n = send(fsckd_fd, progress, sizeof(FsckProgress), 0);
 if (n  0 || (size_t) n  sizeof(FsckProgress))
 log_warning_errno(n, Cannot communicate fsck progress to fsckd: %m);
+
+/* get fsckd requests */
+n = recv(fsckd_fd, fsckd_message, sizeof(FsckdMessage), 0);
+if (n  0) {
+if (fsckd_message.cancel) {
+log_warning(Request to cancel fsck from fsckd);
+cancel_requested = true;
+kill(fsck_pid, SIGTERM);
+}
+}
 }
 
 return 0;
@@ -193,7 +206,6 @@ static int process_progress(int fd) {
 int main(int argc, char *argv[]) {
 const char *cmdline[9];
 int i = 0, r = EXIT_FAILURE, q;
-pid_t pid;
 siginfo_t status;
 _cleanup_udev_unref_ struct udev *udev = NULL;
 _cleanup_udev_device_unref_ struct udev_device *udev_device = NULL;
@@ -321,11 +333,11 @@ int main(int argc, char *argv[]) {
 cmdline[i++] = device;
 cmdline[i++] = NULL;
 
-pid = fork();
-if (pid  0) {
+fsck_pid = fork();
+if (fsck_pid  0) {
 log_error_errno(errno, fork(): %m);
 goto finish;
-} else if (pid == 0) {
+} else if (fsck_pid == 0) {
 /* Child */
 if (progress_pipe[0] = 0)
 safe_close(progress_pipe[0]);
@@ -340,7 +352,7 @@ int main(int argc, char *argv[]) {
 progress_pipe[0] = -1;
 }
 
-q = wait_for_terminate(pid, status);
+q = wait_for_terminate(fsck_pid, status);
 if (q  0) {
 log_error_errno(q, waitid(): %m);
 goto finish;
@@ -348,11 +360,11 @@ int main(int argc, char *argv[]) {
 
 if (status.si_code != CLD_EXITED || (status.si_status  ~1)) {
 
-if (status.si_code == CLD_KILLED || status.si_code == CLD_DUMPED)
+if ((!cancel_requested  status.si_code == CLD_KILLED) || status.si_code == CLD_DUMPED)
 log_error(fsck terminated by signal %s., signal_to_string(status.si_status));
 else if (status.si_code == CLD_EXITED)
 log_error(fsck failed with error code %i., status.si_status);
-else
+else if (!cancel_requested)
 log_error(fsck failed due to unknown reason.);
 
 if (status.si_code == CLD_EXITED  (status.si_status  2)  root_directory)
@@ -363,7 +375,8 @@ int main(int argc, char *argv[]) {
 start_target(SPECIAL_EMERGENCY_TARGET);
 else {
 r = EXIT_SUCCESS;
-log_warning(Ignoring error.);
+if (!cancel_requested)
+log_warning(Ignoring error.);
 }
 
 } else
diff --git a/src/fsckd/fsckd.c b/src/fsckd/fsckd.c
index b516193..5760916 100644
--- a/src/fsckd/fsckd.c
+++ b/src/fsckd/fsckd.c
@@ -57,10 +57,15 @@ typedef struct Clients {
 unsigned long max;
 int pass;
 double percent;
+bool

[systemd-devel] [PATCH 07/12] Add gettext support



From a56e70d026565b4da79acfdad1d83d6521ec42f5 Mon Sep 17 00:00:00 2001
From: Didier Roche didro...@ubuntu.com
Date: Mon, 26 Jan 2015 16:51:05 +0100
Subject: [PATCH 07/12] Add gettext support

---
 configure.ac  | 1 +
 src/shared/util.c | 8 
 src/shared/util.h | 2 ++
 3 files changed, 11 insertions(+)

diff --git a/configure.ac b/configure.ac
index 62f1eef..add45fc 100644
--- a/configure.ac
+++ b/configure.ac
@@ -75,6 +75,7 @@ AS_IF([test -z $INTLTOOL_POLICY_RULE], [
 
 GETTEXT_PACKAGE=systemd
 AC_SUBST(GETTEXT_PACKAGE)
+AC_DEFINE_UNQUOTED(GETTEXT_PACKAGE, $GETTEXT_PACKAGE, [systemd])
 
 AC_PROG_MKDIR_P
 AC_PROG_LN_S
diff --git a/src/shared/util.c b/src/shared/util.c
index 3002224..1c6891d 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -25,6 +25,8 @@
 #include errno.h
 #include stdlib.h
 #include signal.h
+#include libintl.h
+#include locale.h
 #include stdio.h
 #include syslog.h
 #include sched.h
@@ -70,6 +72,7 @@
 #include sys/auxv.h
 #endif
 
+#include config.h
 #include macro.h
 #include util.h
 #include ioprio.h
@@ -5769,6 +5772,11 @@ void *xbsearch_r(const void *key, const void *base, size_t nmemb, size_t size,
 return NULL;
 }
 
+void init_gettext(void) {
+setlocale(LC_ALL, );
+textdomain(GETTEXT_PACKAGE);
+}
+
 bool is_locale_utf8(void) {
 const char *set;
 static int cached_answer = -1;
diff --git a/src/shared/util.h b/src/shared/util.h
index 2cdc419..6c0e561 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -738,6 +738,8 @@ void *xbsearch_r(const void *key, const void *base, size_t nmemb, size_t size,
  int (*compar) (const void *, const void *, void *),
  void *arg);
 
+#define _(String) gettext (String)
+void init_gettext(void);
 bool is_locale_utf8(void);
 
 typedef enum DrawSpecialChar {
-- 
2.1.4

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

[systemd-devel] [PATCH 08/12] Translate fsckd messages for plymouth



From cb822ca631b8cddfe03930ef68a12c97372bb8c1 Mon Sep 17 00:00:00 2001
From: Didier Roche didro...@ubuntu.com
Date: Mon, 26 Jan 2015 17:12:54 +0100
Subject: [PATCH 08/12] Translate fsckd messages for plymouth

For plymouth themes not supporting i18n (like .script), send translated
messages to display to user, which is equivalent to the sent machine
readable data.
---
 po/POTFILES.in|  1 +
 src/fsckd/fsckd.c | 10 +++---
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/po/POTFILES.in b/po/POTFILES.in
index b4c1121..70e7594 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -5,3 +5,4 @@ src/locale/org.freedesktop.locale1.policy.in
 src/login/org.freedesktop.login1.policy.in
 src/machine/org.freedesktop.machine1.policy.in
 src/timedate/org.freedesktop.timedate1.policy.in
+src/fsckd/fsckd.c
diff --git a/src/fsckd/fsckd.c b/src/fsckd/fsckd.c
index 5760916..b07760d 100644
--- a/src/fsckd/fsckd.c
+++ b/src/fsckd/fsckd.c
@@ -24,6 +24,7 @@
 
 #include getopt.h
 #include errno.h
+#include libintl.h
 #include linux/limits.h
 #include math.h
 #include stdbool.h
@@ -101,7 +102,7 @@ static int handle_requests(int socket_fd) {
 const char *plymouth_cancel_message;
 bool cancel_message_plymouth_sent = false;
 
-plymouth_cancel_message = strappenda(fsckd-cancel-msg:, Press C to cancel all checks in progress);
+plymouth_cancel_message = strappenda(fsckd-cancel-msg:, _(Press C to cancel all checks in progress));
 #endif
 
 console = fopen(/dev/console, we);
@@ -192,7 +193,9 @@ static int handle_requests(int socket_fd) {
 numdevices = current_numdevices;
 percent = current_percent;
 
-asprintf(console_message, Checking in progress on %d disks (%3.1f%% complete),
+asprintf(console_message,
+ ngettext(Checking in progress on %d disk (%3.1f%% complete),
+  Checking in progress on %d disks (%3.1f%% complete), numdevices),
  numdevices, percent);
 #ifdef HAVE_PLYMOUTH
 asprintf(fsck_message, fsckd:%d:%3.1f:%s, numdevices, percent, console_message);
@@ -208,7 +211,7 @@ static int handle_requests(int socket_fd) {
 /* send to plymouth */
 if (!cancel_message_plymouth_sent) {
 cancel_message_plymouth_sent = \
-plymouth_watch_key(Cc, plymouth_cancel_message, cancel_requested);
+plymouth_watch_key(_(Cc), plymouth_cancel_message, cancel_requested);
 }
 plymouth_update(fsck_message);
 #endif
@@ -341,6 +344,7 @@ int main(int argc, char *argv[]) {
 log_set_target(LOG_TARGET_AUTO);
 log_parse_environment();
 log_open();
+init_gettext();
 
 r = parse_argv(argc, argv);
 if (r = 0)
-- 
2.1.4

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

Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)

On Wed, 28.01.15 14:16, Martin Pitt (martin.p...@ubuntu.com) wrote:

 Hey Lennart,
 
 Lennart Poettering [2015-01-28 14:06 +0100]:
  Ah, thanks! That was helpful.
  
  I apparently fucked up the new linked list iteration macro I added for
  this. I think this should make it work:
  
  http://cgit.freedesktop.org/systemd/systemd/commit/?id=cdda4aa8d20c2679cc937d40e793abe7806f17cb
  
  Can you check?
 
 Boots fine again, thanks! I suppose this could do with an unit test? :-)

Well, there is one actually, except it didn't check for the one
corner case that mattered here. I have already queued up a patch that
duplicates the test cases for these corner cases. It's actually what I
did my testing with to track this down...

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] failing boot start jobs delay reboot

2015-01-28 Thread Michael Biebl

2015-01-28 2:05 GMT+01:00 Lennart Poettering lenn...@poettering.net:
 On Tue, 20.01.15 11:24, Andrei Borzenkov (arvidj...@gmail.com) wrote:
 - stop in emergency shell when mount fails
 - fix /etc/fstab
 - ^D to continue boot

 no more works, because /etc/fstab is not reevaluated so systemd will
 still try the same broken mount again.

 Yeah, systemd will require a systemctl daemon-reload first. It might
 be a good idea if distros would mention that in a comment in the
 default fstab file they install.


Hm, I vaguely remember that we discussed quite a while ago. Wasn't the
idea to trigger the daemon-reload automatically when exiting the
emergency/rescue shell?

Could be as simple as changing emergency.service from

 ExecStart=-/bin/sh -c /sbin/sulogin; /bin/systemctl --fail --no-block default

to
 ExecStart=-/bin/sh -c /sbin/sulogin; /bin/systemctl daemon-reload;
/bin/systemctl --fail --no-block default


Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] sysv-generator: Handle .sh suffixes when translating Provides:

On Wed, 28.01.15 14:25, Martin Pitt (martin.p...@ubuntu.com) wrote:

 Hello Lennart,
 
 Lennart Poettering [2015-01-28 14:19 +0100]:
  I really don't follow. Why do we need the add_alias() equality check
  now? I mean, if sysv_translate_facility() now detects if we translate
  facilities listed in Provides: as pointing to the script itself, and
  handles .sh properly, why do we need to check in add_alias() a second
  time if we try to create a symlink to oursevlves?
  
  The latter can go no, can't it?
 
 This should indeed not happen now with the recent fixes. This was
 merely a defensive check if this situation happens with some other
 corner case after committing 29e0e6d8c. But the later commit 77354c is
 a stronger hammer for this, so this check is now indeed not that
 important any more.
 
 Chances are that the TOCTOU unlink will be rewritten at some point to
 what you suggested (collecting the aliases in memory and writing them
 after synthesizing all the units), at which point the defensiveness
 might be a tad more important again, but at least now we have a rather
 comprehensive test suite which ought to catch all this (like the
 regression in 4e48855534 ☺ ).
 
 So in short: if you don't like it, I'm happy to remove this.

OK, removed it now. Tried to be more careful this time, and make
check still works.

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] root= ignored

2015-01-28 Thread Felix Miata

Chris Murphy composed on 2015-01-27 23:29 (UTC-0700):

 Felix Miata wrote:

 Lennart Poettering composed on 2015-01-28 02:03 (UTC+0100):

 Hmm, Fedora doesn't obey root=? That sounds like a bug.

 I'm not sure what it means, Fedora doesn't obey root=. Since a long
 time it uses root=UUID= and this has worked for me.

All current distros whose bootloaders I've used include a root= in each of
their bootloader stanzas. AFAIK, root=UUID= is used in Fedora's Grub2
stanzas. Maybe it went into Fedora's Grub Legacy cmdlines before the switch
to Grub2. I don't remember. I haven't installed any of Fedora's bootloaders
since Fedora dropped Grub Legacy, so don't have first-hand experience from
which to know otherwise.

Most distros do not require use of their own bootloaders to successfully
boot. I've been using openSUSE's Grub Legacy for booting all distros
installed on my own systems ever since Grub2 started becoming distros'
default bootloader. This has worked for all, except as described below.

In the pre-libata days, as I remember, any syntactically correct root= on
cmdline was what would be used to find /etc/fstab and get the root filesystem
up. Included among the possibles valid with post-libata distros have been:

root=/dev/sdX
root=/dev/disk/by-label/...
root=LABEL=...
root=/dev/disk/by-uuid/...
root=UUID=...

What it means is that traditional cmdline root= option still works with
openSUSE's configured-by-default initrds, but not with Fedora's
configured-by-default initrds. Translated, this means the following process
that works with non-Fedora root partitions fails with Fedora's root partitions:

1-boot anything other than intended logical source partition on a BIOS
multiboot system with 1 HD only
2-clone an existing unmounted logical source/root partition to some other
unmounted partition
3-configure a unique UUID and volume label on the clone
4-mount the clone and adjust its fstab appropriately
5-in the HD's bootloader menu (not the boot menu on the clone), clone the
source stanza and adjust it appropriately to use for the clone, using any of
the above listed (legal) root= forms.

When Fedora is the source and clone, attempting boot of clone using default
initrd produces an emergency shell, unlike openSUSE. To boot a Fedora clone
normally requires a chroot rescue (what I usually do) or a
/boot/initramfs-0-rescue*.img boot to rebuild its normal initrd(s). This
Fedora characteristic in effect produces an undesirable, and likely
unforeseeable by most, stumbling block to at least one backup/restore
scenario that involves no change of hardware that Fedora's Dracut hostonly
configuration seems to suggest would be safe.
-- 
The wise are known for their understanding, and pleasant
words are persuasive. Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] full reset of reset network state with networkd

2015-01-28 Thread Igor Bukanov

If during the boot the network is configured with DHCP but later is
configured with a static address with a new .network file, then
systemctl restart networkd still keeps the old address obtained with
DHCP.  This is expected according to documentation. Is there a way to
force with networkd to fully reset the network configuration so it
matches the one defined by unit files  and avoid manual removal of the
older IP without doing the reboot?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)

Hey Lennart,

Lennart Poettering [2015-01-28 14:06 +0100]:
 Ah, thanks! That was helpful.
 
 I apparently fucked up the new linked list iteration macro I added for
 this. I think this should make it work:
 
 http://cgit.freedesktop.org/systemd/systemd/commit/?id=cdda4aa8d20c2679cc937d40e793abe7806f17cb
 
 Can you check?

Boots fine again, thanks! I suppose this could do with an unit test? :-)

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


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

[systemd-devel] [PATCH 03/12] systemd-fsck: always connect to systemd-fsckd



From feb8f332313c3ac2542f618028f8a6a6a36daf50 Mon Sep 17 00:00:00 2001
From: Didier Roche didro...@ubuntu.com
Date: Mon, 26 Jan 2015 16:01:11 +0100
Subject: [PATCH 03/12] systemd-fsck: always connect to systemd-fsckd

Remove the plymouth running or show-status checks from systemd-fsck. Instead,
always connect to systemd-fsckd socket, and let this one decide if we display
progress or not.
---
 src/fsck/fsck.c   | 12 
 src/fsckd/fsckd.c | 12 ++--
 2 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/src/fsck/fsck.c b/src/fsck/fsck.c
index 91dff5c..f5dd546 100644
--- a/src/fsck/fsck.c
+++ b/src/fsck/fsck.c
@@ -46,7 +46,6 @@
 
 static bool arg_skip = false;
 static bool arg_force = false;
-static bool arg_show_progress = false;
 static const char *arg_repair = -a;
 
 static void start_target(const char *target) {
@@ -132,8 +131,6 @@ static void test_files(void) {
 }
 #endif
 
-if (access(/run/systemd/show-status, F_OK) = 0 || plymouth_running())
-arg_show_progress = true;
 }
 
 static int process_progress(int fd) {
@@ -293,11 +290,10 @@ int main(int argc, char *argv[]) {
 log_warning_errno(r, fsck.%s cannot be used for %s: %m, type, device);
 }
 
-if (arg_show_progress)
-if (pipe(progress_pipe)  0) {
-log_error_errno(errno, pipe(): %m);
-return EXIT_FAILURE;
-}
+if (pipe(progress_pipe)  0) {
+log_error_errno(errno, pipe(): %m);
+return EXIT_FAILURE;
+}
 
 cmdline[i++] = /sbin/fsck;
 cmdline[i++] =  arg_repair;
diff --git a/src/fsckd/fsckd.c b/src/fsckd/fsckd.c
index 3059c68..e27cd6d 100644
--- a/src/fsckd/fsckd.c
+++ b/src/fsckd/fsckd.c
@@ -45,6 +45,8 @@
 
 #define IDLE_TIME_MINUTES 1
 
+static bool show_progress = false;
+
 typedef struct Clients {
 int fd;
 char device[PATH_MAX];
@@ -155,8 +157,10 @@ static int handle_requests(int socket_fd) {
  numdevices, percent);
 
 /* write to console */
-fprintf(console, \r%s\r%n, console_message, m);
-fflush(console);
+if (show_progress) {
+fprintf(console, \r%s\r%n, console_message, m);
+fflush(console);
+}
 
 if (m  clear)
 clear = m;
@@ -291,5 +295,9 @@ int main(int argc, char *argv[]) {
 if (fd = 0)
 return EXIT_FAILURE;
 }
+
+if (access(/run/systemd/show-status, F_OK) = 0)
+show_progress = true;
+
 return handle_requests(fd)  0 ? EXIT_FAILURE : EXIT_SUCCESS;
 }
-- 
2.1.4

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

[systemd-devel] [PATCH 04/12] Add some plymouth functionality to connect and send, messages



From 7afe9270e3210668053089caaff8a1dd790a48f5 Mon Sep 17 00:00:00 2001
From: Didier Roche didro...@ubuntu.com
Date: Mon, 26 Jan 2015 17:07:32 +0100
Subject: [PATCH 04/12] Add some plymouth functionality to connect and send
 messages

Connect to plymouth (if running).
Automatic reconnect if plymouth was disconnected (or respawned)
when trying to send a subsequent message.
---
 Makefile.am   |  2 ++
 configure.ac  | 12 
 src/shared/plymouth.c | 83 +++
 src/shared/plymouth.h |  8 +
 4 files changed, 105 insertions(+)

diff --git a/Makefile.am b/Makefile.am
index 18be607..a9d61f1 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -929,10 +929,12 @@ libsystemd_shared_la_CFLAGS = \
 	$(AM_CFLAGS) \
 	$(CAP_CFLAGS) \
 	$(SECCOMP_CFLAGS) \
+	$(PLYMOUTH_CFLAGS) \
 	-pthread
 
 libsystemd_shared_la_LIBADD = \
 	$(CAP_LIBS) \
+	$(PLYMOUTH_LIBS) \
 	-lm
 
 # --
diff --git a/configure.ac b/configure.ac
index 12e4ab2..62f1eef 100644
--- a/configure.ac
+++ b/configure.ac
@@ -857,6 +857,18 @@ fi
 AM_CONDITIONAL(HAVE_MICROHTTPD, [test $have_microhttpd = yes])
 
 # --
+have_plymouth=no
+AC_ARG_ENABLE(plymouth, AS_HELP_STRING([--disable-plymouth], [disable plymouth integration]))
+if test x$enable_plymouth != xno; then
+PKG_CHECK_MODULES([PLYMOUTH], [ply-boot-client = 0.8.0],
+[AC_DEFINE(HAVE_PLYMOUTH, 1, [Define if plymouth is available]) have_plymouth=yes], have_plymouth=no)
+if test x$have_plymouth = xno -a x$enable_plymouth = xyes; then
+AC_MSG_ERROR([*** plymouth integration requested but libraries not found])
+fi
+fi
+AM_CONDITIONAL(HAVE_PLYMOUTH, [test $have_plymouth = yes])
+
+# --
 have_gnutls=no
 AC_ARG_ENABLE(gnutls, AS_HELP_STRING([--disable-gnutls], [disable gnutls support]))
 if test x$enable_gnutls != xno; then
diff --git a/src/shared/plymouth.c b/src/shared/plymouth.c
index c4865dd..f7155c4 100644
--- a/src/shared/plymouth.c
+++ b/src/shared/plymouth.c
@@ -19,13 +19,96 @@
   along with systemd; If not, see http://www.gnu.org/licenses/.
 ***/
 
+#ifdef HAVE_PLYMOUTH
+#include ply-boot-client.h
+#endif
+
 #include stdbool.h
 #include stdio.h
 #include stdlib.h
 #include unistd.h
 
+#include log.h
 #include plymouth.h
 
+#ifdef HAVE_PLYMOUTH
+void plymouth_disconnected (void *user_data, ply_boot_client_t *client);
+void plymouth_update_failed(void *user_data, ply_boot_client_t *client);
+
+static ply_boot_client_t *plymouth_client = NULL;
+static ply_event_loop_t *plymouth_event_loop = NULL;
+#endif
+
 bool plymouth_running(void) {
 return access(/run/plymouth/pid, F_OK) = 0;
 }
+
+#ifdef HAVE_PLYMOUTH
+bool plymouth_connect(void) {
+
+/* Keep existing connection */
+if (plymouth_client)
+return true;
+
+/* Create the event loop */
+if (!plymouth_event_loop)
+plymouth_event_loop = ply_event_loop_new();
+
+if (!plymouth_event_loop) {
+log_error(Couldn't create event loop for plymouth);
+return false;
+}
+
+plymouth_client = ply_boot_client_new();
+
+if (!ply_boot_client_connect(plymouth_client, plymouth_disconnected, NULL)) {
+log_error(Couldn't connect to plymouth);
+ply_boot_client_free(plymouth_client);
+plymouth_client = NULL;
+plymouth_event_loop = NULL;
+return false;
+}
+
+/* attach event loop after being connected to plymouth or the disconnect handler won't be registered
+   and flush all events that may exists from an older connection if we are reconnected */
+ply_boot_client_attach_to_event_loop(plymouth_client, plymouth_event_loop);
+ply_boot_client_flush(plymouth_client);
+
+return true;
+}
+
+void plymouth_disconnect(void) {
+if (!plymouth_client)
+ return;
+ply_boot_client_disconnect(plymouth_client);
+ply_boot_client_flush(plymouth_client);
+}
+
+void plymouth_update(const char *message) {
+if (!plymouth_running() || !plymouth_connect())
+return;
+
+ply_boot_client_update_daemon(plymouth_client, message, NULL, NULL, NULL);
+ply_boot_client_flush(plymouth_client);
+}
+
+void plymouth_delete_message(void) {
+if (!plymouth_running() || !plymouth_client)
+return;
+
+ply_boot_client_tell_daemon_to_display_message (plymouth_client, , NULL, plymouth_update_failed, NULL);
+ply_boot_client_flush(plymouth_client);
+}
+
+void plymouth_update_failed(void *user_data, ply_boot_client_t *client) {
+log_error(Couldn't send message to plymouth);
+}
+
+void plymouth_disconnected

[systemd-devel] [PATCH 05/12] Connect and send to plymouth progress report



From c60d4f41e279dd5ed7134d97d95549aac1f38e69 Mon Sep 17 00:00:00 2001
From: Didier Roche didro...@ubuntu.com
Date: Mon, 26 Jan 2015 16:29:30 +0100
Subject: [PATCH 05/12] Connect and send to plymouth progress report

Try to connect and send to plymouth (if running) some check report progress,
using libplymouth.

Update message is the following:
fsckd:num_devices:progress:string

* num_devices corresponds to the current number of devices being checked (int)
* progress corresponds to the current minimum percentage of all devices being
  checking (float, from 0 to 100)
* string is a translated message ready to be displayed by the plymouth theme
  displaying the information above. It can be overriden by plymouth themes
  supporting i18n.
---
 src/fsckd/fsckd.c | 23 ++-
 src/shared/plymouth.c | 15 +++
 src/shared/plymouth.h |  2 ++
 3 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/src/fsckd/fsckd.c b/src/fsckd/fsckd.c
index e27cd6d..b516193 100644
--- a/src/fsckd/fsckd.c
+++ b/src/fsckd/fsckd.c
@@ -39,6 +39,9 @@
 #include log.h
 #include list.h
 #include macro.h
+#ifdef HAVE_PLYMOUTH
+#include plymouth.h
+#endif
 #include sd-daemon.h
 #include time-util.h
 #include util.h
@@ -95,6 +98,9 @@ static int handle_requests(int socket_fd) {
 int new_client_fd = 0;
 Clients *current;
 _cleanup_free_ char *console_message = NULL;
+#ifdef HAVE_PLYMOUTH
+_cleanup_free_ char *fsck_message = NULL;
+#endif
 double current_percent = 100;
 int current_numdevices = 0, m = 0;
 usec_t t;
@@ -155,6 +161,9 @@ static int handle_requests(int socket_fd) {
 
 asprintf(console_message, Checking in progress on %d disks (%3.1f%% complete),
  numdevices, percent);
+#ifdef HAVE_PLYMOUTH
+asprintf(fsck_message, fsckd:%d:%3.1f:%s, numdevices, percent, console_message);
+#endif
 
 /* write to console */
 if (show_progress) {
@@ -162,6 +171,11 @@ static int handle_requests(int socket_fd) {
 fflush(console);
 }
 
+#ifdef HAVE_PLYMOUTH
+/* send to plymouth */
+plymouth_update(fsck_message);
+#endif
+
 if (m  clear)
 clear = m;
 }
@@ -187,6 +201,9 @@ static int handle_requests(int socket_fd) {
 fputc('\r', console);
 fflush(console);
 }
+#ifdef HAVE_PLYMOUTH
+plymouth_disconnect();
+#endif
 
 return 0;
 }
@@ -218,7 +235,11 @@ static int create_socket(void) {
 
 static void help(void) {
 printf(%s [OPTIONS...]\n\n
-   Capture fsck progress and forward one stream to plymouth\n\n
+#ifdef HAVE_PLYMOUTH
+   Capture fsck progress, log to console and forward one stream to plymouth\n\n
+#else
+   Capture fsck progress and log to console\n\n
+#endif
  -h --help Show this help\n
 --version  Show package version\n,
program_invocation_short_name);
diff --git a/src/shared/plymouth.c b/src/shared/plymouth.c
index f7155c4..b43d355 100644
--- a/src/shared/plymouth.c
+++ b/src/shared/plymouth.c
@@ -92,6 +92,21 @@ void plymouth_update(const char *message) {
 ply_boot_client_flush(plymouth_client);
 }
 
+static void plymouth_key_pressed(void *callback, const char *pressed_key, ply_boot_client_t *client) {
+((keypress_callback)callback)();
+}
+
+bool plymouth_watch_key(const char *keys, const char *message, keypress_callback callback) {
+if (!plymouth_running() || !plymouth_connect())
+return false;
+
+ply_boot_client_tell_daemon_to_display_message (plymouth_client, message, NULL,
+plymouth_update_failed, NULL);
+ply_boot_client_ask_daemon_to_watch_for_keystroke (plymouth_client, keys, plymouth_key_pressed,
+   NULL, callback);
+return true;
+}
+
 void plymouth_delete_message(void) {
 if (!plymouth_running() || !plymouth_client)
 return;
diff --git a/src/shared/plymouth.h b/src/shared/plymouth.h
index 15cecb7..f5ea00c 100644
--- a/src/shared/plymouth.h
+++ b/src/shared/plymouth.h
@@ -30,5 +30,7 @@ bool plymouth_connect(void);
 void plymouth_disconnect(void);
 void plymouth_update(const char *message);
 
+typedef void (*keypress_callback)(void);
 void plymouth_delete_message(void);
+bool plymouth_watch_key(const char *keys, const char *message, keypress_callback callback);
 #endif
-- 
2.1.4

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org

Re: [systemd-devel] [PATCH] sysv-generator: Handle .sh suffixes when translating Provides:

Hello Lennart,

Lennart Poettering [2015-01-28 14:19 +0100]:
 I really don't follow. Why do we need the add_alias() equality check
 now? I mean, if sysv_translate_facility() now detects if we translate
 facilities listed in Provides: as pointing to the script itself, and
 handles .sh properly, why do we need to check in add_alias() a second
 time if we try to create a symlink to oursevlves?
 
 The latter can go no, can't it?

This should indeed not happen now with the recent fixes. This was
merely a defensive check if this situation happens with some other
corner case after committing 29e0e6d8c. But the later commit 77354c is
a stronger hammer for this, so this check is now indeed not that
important any more.

Chances are that the TOCTOU unlink will be rewritten at some point to
what you suggested (collecting the aliases in memory and writing them
after synthesizing all the units), at which point the defensiveness
might be a tad more important again, but at least now we have a rather
comprehensive test suite which ought to catch all this (like the
regression in 4e48855534 ☺ ).

So in short: if you don't like it, I'm happy to remove this.

Martin

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

[systemd-devel] [PATCH 11/12] Add man page and references to it.



From 6b13d8fb248bf4176f1ad7e1d4736683462bf196 Mon Sep 17 00:00:00 2001
From: Didier Roche didro...@ubuntu.com
Date: Mon, 26 Jan 2015 17:34:59 +0100
Subject: [PATCH 11/12] Add man page and references to it.

Add man page explaining the plymouth theme protocol, usage of the daemon
as well as the socket activation part.
Adapt existing fsck man page.
---
 Makefile-man.am|  12 +++
 man/systemd-f...@.service.xml  |   6 +-
 man/systemd-fsckd.service.xml  | 170 +
 units/systemd-fsckd.service.in |   1 +
 units/systemd-fsckd.socket |   2 +-
 5 files changed, 188 insertions(+), 3 deletions(-)
 create mode 100644 man/systemd-fsckd.service.xml

diff --git a/Makefile-man.am b/Makefile-man.am
index 105853e..f2e13e8 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -67,6 +67,7 @@ MANPAGES += \
 	man/systemd-escape.1 \
 	man/systemd-firstboot.1 \
 	man/systemd-fsck@.service.8 \
+	man/systemd-fsckd.service.8 \
 	man/systemd-fstab-generator.8 \
 	man/systemd-getty-generator.8 \
 	man/systemd-gpt-auto-generator.8 \
@@ -210,6 +211,8 @@ MANPAGES_ALIAS += \
 	man/systemd-firstboot.service.1 \
 	man/systemd-fsck-root.service.8 \
 	man/systemd-fsck.8 \
+	man/systemd-fsckd.8 \
+	man/systemd-fsckd.socket.8 \
 	man/systemd-hibernate-resume.8 \
 	man/systemd-hibernate.service.8 \
 	man/systemd-hybrid-sleep.service.8 \
@@ -323,6 +326,8 @@ man/systemd-ask-password-wall.service.8: man/systemd-ask-password-console.servic
 man/systemd-firstboot.service.1: man/systemd-firstboot.1
 man/systemd-fsck-root.service.8: man/systemd-fsck@.service.8
 man/systemd-fsck.8: man/systemd-fsck@.service.8
+man/systemd-fsckd.8: man/systemd-fsckd.service.8
+man/systemd-fsckd.socket.8: man/systemd-fsckd.service.8
 man/systemd-hibernate-resume.8: man/systemd-hibernate-resume@.service.8
 man/systemd-hibernate.service.8: man/systemd-suspend.service.8
 man/systemd-hybrid-sleep.service.8: man/systemd-suspend.service.8
@@ -606,6 +611,12 @@ man/systemd-fsck-root.service.html: man/systemd-f...@.service.html
 man/systemd-fsck.html: man/systemd-f...@.service.html
 	$(html-alias)
 
+man/systemd-fsckd.html: man/systemd-fsckd.service.html
+	$(html-alias)
+
+man/systemd-fsckd.socket.html: man/systemd-fsckd.service.html
+	$(html-alias)
+
 man/systemd-hibernate-resume.html: man/systemd-hibernate-res...@.service.html
 	$(html-alias)
 
@@ -1732,6 +1743,7 @@ EXTRA_DIST += \
 	man/systemd-escape.xml \
 	man/systemd-firstboot.xml \
 	man/systemd-f...@.service.xml \
+	man/systemd-fsckd.service.xml \
 	man/systemd-fstab-generator.xml \
 	man/systemd-getty-generator.xml \
 	man/systemd-gpt-auto-generator.xml \
diff --git a/man/systemd-f...@.service.xml b/man/systemd-f...@.service.xml
index ee66f37..d366712 100644
--- a/man/systemd-f...@.service.xml
+++ b/man/systemd-f...@.service.xml
@@ -87,8 +87,9 @@
 check, number of mounts, unclean unmount, etc./para
 
 parafilenamesystemd-fsck/filename will forward
-file system checking progress to the console. If a
-file system check fails for a service without
+file system checking progress to
+filenamesystemd-fsckd.service/filename
+socket. If a file system check fails for a service without
 optionnofail/option, emergency mode is activated,
 by isolating to
 filenameemergency.target/filename./para
@@ -142,6 +143,7 @@
 para
 citerefentryrefentrytitlesystemd/refentrytitlemanvolnum1/manvolnum/citerefentry,
 citerefentryrefentrytitlefsck/refentrytitlemanvolnum8/manvolnum/citerefentry,
+citerefentryrefentrytitlesystemd-fsckd.service/refentrytitlemanvolnum8/manvolnum/citerefentry,
 citerefentryrefentrytitlesystemd-quotacheck.service/refentrytitlemanvolnum8/manvolnum/citerefentry,
 citerefentryrefentrytitlefsck.btrfs/refentrytitlemanvolnum8/manvolnum/citerefentry,
 citerefentryrefentrytitlefsck.cramfs/refentrytitlemanvolnum8/manvolnum/citerefentry,
diff --git a/man/systemd-fsckd.service.xml b/man/systemd-fsckd.service.xml
new file mode 100644
index 000..befcc45
--- /dev/null
+++ b/man/systemd-fsckd.service.xml
@@ -0,0 +1,170 @@
+?xml version=1.0?
+!--*-nxml-*--
+!DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook XML V4.2//EN http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;
+!--
+  This file is part of systemd.
+
+  Copyright 2015 Canonical
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A

Re: [systemd-devel] [PATCH] systemd-udevd.service: restore mount propagation

On Wed, 28.01.15 14:09, Martin Pitt (martin.p...@ubuntu.com) wrote:

 From 0cc891bcd8d3fa9967dd733292caf86a43dd3503 Mon Sep 17 00:00:00 2001
 From: Martin Pitt martin.p...@ubuntu.com
 Date: Wed, 28 Jan 2015 13:57:47 +0100
 Subject: [PATCH 2/2] rules: clean up stale CD drive mounts after ejection
 
 Ejecting a CD with the hardware drive button only causes a change uevent, but
 the device node stays around (just without a medium). Pick up these uevents 
 and
 mark the device as SYSTEMD_READY=0 on ejection, so that systemd stops the
 device unit and consequently all mount units on it.
 
 On media insertion, mark the device as SYSTEMD_READY=1 again.
 
 https://bugs.freedesktop.org/show_bug.cgi?id=72206
 https://bugzilla.opensuse.org/show_bug.cgi?id=909418
 https://bugs.archlinux.org/task/42071
 https://bugs.launchpad.net/bugs/1168742
 ---
  rules/60-cdrom_id.rules | 6 ++
  1 file changed, 6 insertions(+)
 
 diff --git a/rules/60-cdrom_id.rules b/rules/60-cdrom_id.rules
 index 6eaf76a..7bfb12e 100644
 --- a/rules/60-cdrom_id.rules
 +++ b/rules/60-cdrom_id.rules
 @@ -15,6 +15,12 @@ ENV{DISK_EJECT_REQUEST}==?*, RUN+=cdrom_id 
 --eject-media $devnode, GOTO=cdr
  # enable the receiving of media eject button events
  IMPORT{program}=cdrom_id --lock-media $devnode
  
 +# ejecting a CD does not remove the device node, so mark the systemd device
 +# unit as inactive while there is no medium; this automatically cleans up of
 +# stale mounts after ejecting
 +ENV{DISK_MEDIA_CHANGE}==?*, ENV{ID_CDROM_MEDIA}!=?*, 
 ENV{SYSTEMD_READY}=0
 +ENV{DISK_MEDIA_CHANGE}==?*, ENV{ID_CDROM_MEDIA}==?*, 
 ENV{SYSTEMD_READY}=1

Hmm, we probably should do the same for USB memory card drives. No
idea how media sensing works there. Any chance you can look into that
too?

Lennart

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

Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd

2015-01-28 Thread Andrei Borzenkov

On Wed, Jan 28, 2015 at 3:40 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Wed, 28.01.15 10:13, Rauta, Alin (alin.ra...@intel.com) wrote:

 Lennart, on a switch I should be able to configure more than one UFD
 group.

 What precisely does this mean? WOuld those groups be orthogonal?


No. You have two different VLANs; uplink group 1 connects to to VLAN1,
uplink group 2 connects to VLAN2. They are not orthogonal in any way
and exist at the same time. If group 1 goes down, it does not affect
group 2 in any way.

 I really would like to avoid introdcuing the tags concept for
 now. Would a solution where you give the uplinks appropriate names
 (like uplink0, uplinkXYZ, uplink_waldo and so on) suffice, when
 you can then refer to them in a .network file you apply to the
 downlinks as BindCarrier=uplink*?

 BindCarrier= would take a list of interface names, possibly with
 globs. If you want to up and down a link foo if at least one of the
 links bar, quux, piep, miau1, miau2 are up, you could write
 this as BindCarrier=bar quux piep miau*.

 What would introducing the tag concept give you beyond this very
 simple schreme described above?

 Lennart

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

Re: [systemd-devel] [PATCH 01/12] fsckd daemon for inter-fsckd communication

On Wed, Jan 28, 2015 at 02:20:40PM +0100, Didier Roche wrote:
 

 From d0f49b4e0994b9a1dd2738da18c5a2a6708b444f Mon Sep 17 00:00:00 2001
 From: Didier Roche didro...@ubuntu.com
 Date: Mon, 26 Jan 2015 15:35:50 +0100
 Subject: [PATCH 01/12] fsckd daemon for inter-fsckd communication
 
 Add systemd-fsckd multiplexer which accept multiple systemd-fsck
accepts

 instances to connect to it and send progress report. systemd-fsckd then
sends

 computes and writes to /dev/console the number of devices currently being
 checked and the minimum fsck progress. This will be used for interactive
 progress report and cancelling in plymouth.
 
 systemd-fsckd stops on idling when no systemd-fsck is connected.
idle

 
 Make the necessary changes to systemd-fsck to connect to systemd-fsckd socket.
to connect to the

 ---
  .gitignore |   1 +
  Makefile.am|  11 ++
  src/fsck/fsck.c|  82 ++-
  src/fsckd/Makefile |   1 +
  src/fsckd/fsckd.c  | 295 
 +
  src/fsckd/fsckd.h  |  34 ++
  6 files changed, 373 insertions(+), 51 deletions(-)
  create mode 12 src/fsckd/Makefile
  create mode 100644 src/fsckd/fsckd.c
  create mode 100644 src/fsckd/fsckd.h
 
 diff --git a/.gitignore b/.gitignore
 index ab6d9d1..9400e75 100644
 --- a/.gitignore
 +++ b/.gitignore
 @@ -74,6 +74,7 @@
  /systemd-evcat
  /systemd-firstboot
  /systemd-fsck
 +/systemd-fsckd
  /systemd-fstab-generator
  /systemd-getty-generator
  /systemd-gnome-ask-password-agent
 diff --git a/Makefile.am b/Makefile.am
 index c463f23..f782e66 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -389,6 +389,7 @@ rootlibexec_PROGRAMS = \
   systemd-remount-fs \
   systemd-reply-password \
   systemd-fsck \
 + systemd-fsckd \
   systemd-machine-id-commit \
   systemd-ac-power \
   systemd-sysctl \
 @@ -2355,6 +2356,16 @@ systemd_fsck_LDADD = \
   libsystemd-shared.la
  
  # 
 --
 +systemd_fsckd_SOURCES = \
 + src/fsckd/fsckd.c \
 + $(NULL)
 +
 +systemd_fsckd_LDADD = \
 + libsystemd-internal.la \
 + libsystemd-shared.la \
 + $(NULL)
 +
 +# 
 --
  systemd_machine_id_commit_SOURCES = \
   src/machine-id-commit/machine-id-commit.c \
   src/core/machine-id-setup.c \
 diff --git a/src/fsck/fsck.c b/src/fsck/fsck.c
 index 20b7940..4c4e150 100644
 --- a/src/fsck/fsck.c
 +++ b/src/fsck/fsck.c
 @@ -26,6 +26,7 @@
  #include errno.h
  #include unistd.h
  #include fcntl.h
 +#include linux/limits.h
  #include sys/file.h
  
  #include sd-bus.h
 @@ -39,6 +40,8 @@
  #include fileio.h
  #include udev-util.h
  #include path-util.h
 +#include socket-util.h
 +#include fsckd/fsckd.h
  
  static bool arg_skip = false;
  static bool arg_force = false;
 @@ -132,58 +135,42 @@ static void test_files(void) {
  arg_show_progress = true;
  }
  
 -static double percent(int pass, unsigned long cur, unsigned long max) {
 -/* Values stolen from e2fsck */
 -
 -static const int pass_table[] = {
 -0, 70, 90, 92, 95, 100
 -};
 -
 -if (pass = 0)
 -return 0.0;
 -
 -if ((unsigned) pass = ELEMENTSOF(pass_table) || max == 0)
 -return 100.0;
 -
 -return (double) pass_table[pass-1] +
 -((double) pass_table[pass] - (double) pass_table[pass-1]) *
 -(double) cur / (double) max;
 -}
 -
  static int process_progress(int fd) {
 -_cleanup_fclose_ FILE *console = NULL, *f = NULL;
 +_cleanup_fclose_ FILE *f = NULL;
  usec_t last = 0;
 -bool locked = false;
 -int clear = 0;
 +_cleanup_close_ int fsckd_fd;
 +static const union sockaddr_union sa = {
 +.un.sun_family = AF_UNIX,
 +.un.sun_path = FSCKD_SOCKET_PATH,
 +};
 +
 +fsckd_fd = socket(AF_UNIX, SOCK_STREAM | SOCK_NONBLOCK, 0);
 +if (fsckd_fd  0) {
 +log_warning_errno(errno, Cannot open fsckd socket, we won't 
 report fsck progress: %m);
 +return -errno;
 +}
 +if (connect(fsckd_fd, sa.sa, offsetof(struct sockaddr_un, sun_path) 
 + strlen(sa.un.sun_path))  0) {
 +log_warning_errno(errno, Cannot connect to fsckd socket, we 
 won't report fsck progress: %m);
 +return -errno;
 +}
  
  f = fdopen(fd, r);
  if (!f) {
 -safe_close(fd);
 +log_warning_errno(errno, Cannot connect to fsck, we won't 
 report fsck progress: %m);
  return -errno;
  }

There's a double close now, since both f and fsckd_fd refer to the same fd.

  
 -console = fopen(/dev/console, we);
 -if (!console)
 -return -ENOMEM;
 -
  while (!feof(f)) {
 -int pass, m;
 +

Re: [systemd-devel] [PATCH] sysv-generator: Handle .sh suffixes when translating Provides:

On Wed, 28.01.15 09:05, Martin Pitt (martin.p...@ubuntu.com) wrote:

 Hey Lennart,
 
 Lennart Poettering [2015-01-27 23:09 +0100]:
  Hmm, we already had code that checks this in place, didn#t we?
 
 We only previously had this .sh stripping in sysv_translate_name(),
 but that translates and init script name like foo.sh to
 foo.service. But that's not what we need in
 sysv_translate_facility() to filter out the Provides: item which
 refers to itself.

I really don't follow. Why do we need the add_alias() equality check
now? I mean, if sysv_translate_facility() now detects if we translate
facilities listed in Provides: as pointing to the script itself, and
handles .sh properly, why do we need to check in add_alias() a second
time if we try to create a symlink to oursevlves?

The latter can go no, can't it?

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] Adding fsck integration to plymouth


Hi,

Here is a suite of patches up to review to add fsckd integration to 
plymouth. This work is mostly based on Lennart's suggestion on an email 
thread few years ago 
(http://lists.freedesktop.org/archives/systemd-devel/2011-April/002063.html) 
where the proposal was to add a systemd-fsckd daemon.


The daemon is socket-activated, each systemd-fsck instances binds and 
communicate its own fsck data to it. systemd-fsckd then agglomerates the 
results and write to /dev/console as well as propagate those values to 
plymouth.


The protocole to communicate with the plymouth theme is described in the 
man page. I've modified ubuntu plymouth theme (which is a .script) to 
display the progress. There is as well a cancel option in case some 
people run on a rotational disks, hit the mount limit and need to give a 
talk right away (not my use case, but have seen that in practice 
recently) :)


The plymouth integration is optional, otherwise, only /dev/console (if 
show-status is enabled) is written.


I'm opened to any question and suggested enhancements.
Cheers,
Didier
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH 01/12] fsckd daemon for inter-fsckd communication



From d0f49b4e0994b9a1dd2738da18c5a2a6708b444f Mon Sep 17 00:00:00 2001
From: Didier Roche didro...@ubuntu.com
Date: Mon, 26 Jan 2015 15:35:50 +0100
Subject: [PATCH 01/12] fsckd daemon for inter-fsckd communication

Add systemd-fsckd multiplexer which accept multiple systemd-fsck
instances to connect to it and send progress report. systemd-fsckd then
computes and writes to /dev/console the number of devices currently being
checked and the minimum fsck progress. This will be used for interactive
progress report and cancelling in plymouth.

systemd-fsckd stops on idling when no systemd-fsck is connected.

Make the necessary changes to systemd-fsck to connect to systemd-fsckd socket.
---
 .gitignore |   1 +
 Makefile.am|  11 ++
 src/fsck/fsck.c|  82 ++-
 src/fsckd/Makefile |   1 +
 src/fsckd/fsckd.c  | 295 +
 src/fsckd/fsckd.h  |  34 ++
 6 files changed, 373 insertions(+), 51 deletions(-)
 create mode 12 src/fsckd/Makefile
 create mode 100644 src/fsckd/fsckd.c
 create mode 100644 src/fsckd/fsckd.h

diff --git a/.gitignore b/.gitignore
index ab6d9d1..9400e75 100644
--- a/.gitignore
+++ b/.gitignore
@@ -74,6 +74,7 @@
 /systemd-evcat
 /systemd-firstboot
 /systemd-fsck
+/systemd-fsckd
 /systemd-fstab-generator
 /systemd-getty-generator
 /systemd-gnome-ask-password-agent
diff --git a/Makefile.am b/Makefile.am
index c463f23..f782e66 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -389,6 +389,7 @@ rootlibexec_PROGRAMS = \
 	systemd-remount-fs \
 	systemd-reply-password \
 	systemd-fsck \
+	systemd-fsckd \
 	systemd-machine-id-commit \
 	systemd-ac-power \
 	systemd-sysctl \
@@ -2355,6 +2356,16 @@ systemd_fsck_LDADD = \
 	libsystemd-shared.la
 
 # --
+systemd_fsckd_SOURCES = \
+	src/fsckd/fsckd.c \
+	$(NULL)
+
+systemd_fsckd_LDADD = \
+	libsystemd-internal.la \
+	libsystemd-shared.la \
+	$(NULL)
+
+# --
 systemd_machine_id_commit_SOURCES = \
 	src/machine-id-commit/machine-id-commit.c \
 	src/core/machine-id-setup.c \
diff --git a/src/fsck/fsck.c b/src/fsck/fsck.c
index 20b7940..4c4e150 100644
--- a/src/fsck/fsck.c
+++ b/src/fsck/fsck.c
@@ -26,6 +26,7 @@
 #include errno.h
 #include unistd.h
 #include fcntl.h
+#include linux/limits.h
 #include sys/file.h
 
 #include sd-bus.h
@@ -39,6 +40,8 @@
 #include fileio.h
 #include udev-util.h
 #include path-util.h
+#include socket-util.h
+#include fsckd/fsckd.h
 
 static bool arg_skip = false;
 static bool arg_force = false;
@@ -132,58 +135,42 @@ static void test_files(void) {
 arg_show_progress = true;
 }
 
-static double percent(int pass, unsigned long cur, unsigned long max) {
-/* Values stolen from e2fsck */
-
-static const int pass_table[] = {
-0, 70, 90, 92, 95, 100
-};
-
-if (pass = 0)
-return 0.0;
-
-if ((unsigned) pass = ELEMENTSOF(pass_table) || max == 0)
-return 100.0;
-
-return (double) pass_table[pass-1] +
-((double) pass_table[pass] - (double) pass_table[pass-1]) *
-(double) cur / (double) max;
-}
-
 static int process_progress(int fd) {
-_cleanup_fclose_ FILE *console = NULL, *f = NULL;
+_cleanup_fclose_ FILE *f = NULL;
 usec_t last = 0;
-bool locked = false;
-int clear = 0;
+_cleanup_close_ int fsckd_fd;
+static const union sockaddr_union sa = {
+.un.sun_family = AF_UNIX,
+.un.sun_path = FSCKD_SOCKET_PATH,
+};
+
+fsckd_fd = socket(AF_UNIX, SOCK_STREAM | SOCK_NONBLOCK, 0);
+if (fsckd_fd  0) {
+log_warning_errno(errno, Cannot open fsckd socket, we won't report fsck progress: %m);
+return -errno;
+}
+if (connect(fsckd_fd, sa.sa, offsetof(struct sockaddr_un, sun_path) + strlen(sa.un.sun_path))  0) {
+log_warning_errno(errno, Cannot connect to fsckd socket, we won't report fsck progress: %m);
+return -errno;
+}
 
 f = fdopen(fd, r);
 if (!f) {
-safe_close(fd);
+log_warning_errno(errno, Cannot connect to fsck, we won't report fsck progress: %m);
 return -errno;
 }
 
-console = fopen(/dev/console, we);
-if (!console)
-return -ENOMEM;
-
 while (!feof(f)) {
-int pass, m;
+int pass;
 unsigned long cur, max;
 _cleanup_free_ char *device = NULL;
-double p;
+ssize_t n;
 usec_t t;
+FsckProgress progress;
 
 if (fscanf(f, %i %lu %lu %ms, pass, cur, max, device) != 4)
 break;
 
-/* Only show one progress

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

On Wed, Jan 28, 2015 at 01:11:55PM +0100, Lennart Poettering wrote:
 On Wed, 28.01.15 04:04, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
 
  On Wed, Jan 28, 2015 at 03:50:42AM +0100, Lennart Poettering wrote:
   On Wed, 28.01.15 03:47, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) 
   wrote:
   
On Wed, Jan 28, 2015 at 01:53:17AM +0100, Lennart Poettering wrote:
 On Mon, 19.01.15 10:43, Zbigniew Jędrzejewski-Szmek 
 (zbys...@kemper.freedesktop.org) wrote:
 
   src/journal/journalctl.c |   28 ++--
   1 file changed, 14 insertions(+), 14 deletions(-)
  
  New commits:
  commit 40f0b71b063da6a36b8d7ec75ef20103abd18243
  Author: Zbigniew J??drzejewski-Szmek zbys...@in.waw.pl
  Date:   Mon Jan 19 13:42:34 2015 -0500
  
  journalctl: trim --help to fit in 80 columns
  
  Terminals tend to be 80 columns wide by default, and the help
  text is only supposed to be a terse reminder anyway.
  
 
 Hmm, maybe we should add a test target to the makefile that runs all
 our tools with --help and checks that the output it generates is
 identical to the output pssed through fold -w 79 or so?
 
 (I added this to the TODO list for now)

Done.
   
   Hmm, your commit checks for 80 chars, right? Shouldn't we rather check
   for 79? Many terminals that are 80 chars wide will leave one line free
   if you output 80 consecutive chars plus one newline...
  Are you sure? I though this was fixed already.
  A quick test with the linux console, urxvt, konsole, systemd-subterm,
  and xterm all DTRT.
 
 I know for sure that the old MS-DOS 5.0 console certainly wasn't happy
 with 80ch lines... Because I remember this issue from when I started
 programming back on those machines...

Your concern for backwards compat is touching :)

Zbyszek

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

Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd

On Wed, 28.01.15 16:48, Andrei Borzenkov (arvidj...@gmail.com) wrote:

 On Wed, Jan 28, 2015 at 3:40 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Wed, 28.01.15 10:13, Rauta, Alin (alin.ra...@intel.com) wrote:
 
  Lennart, on a switch I should be able to configure more than one UFD
  group.
 
  What precisely does this mean? WOuld those groups be orthogonal?
 
 
 No. You have two different VLANs; uplink group 1 connects to to VLAN1,
 uplink group 2 connects to VLAN2. They are not orthogonal in any way
 and exist at the same time. If group 1 goes down, it does not affect
 group 2 in any way.

Hmm, if they don't affect each other, then they *are* orthogonal.

Now I am really confused...

 
  I really would like to avoid introdcuing the tags concept for
  now. Would a solution where you give the uplinks appropriate names
  (like uplink0, uplinkXYZ, uplink_waldo and so on) suffice, when
  you can then refer to them in a .network file you apply to the
  downlinks as BindCarrier=uplink*?
 
  BindCarrier= would take a list of interface names, possibly with
  globs. If you want to up and down a link foo if at least one of the
  links bar, quux, piep, miau1, miau2 are up, you could write
  this as BindCarrier=bar quux piep miau*.
 
  What would introducing the tag concept give you beyond this very
  simple schreme described above?
 
  Lennart
 
  --
  Lennart Poettering, Red Hat
  ___
  systemd-devel mailing list
  systemd-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Lennart

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

Re: [systemd-devel] [PATCH] sysv-generator: Replace Provides: symlinks with real units

2015-01-28 Thread Michael Biebl

2015-01-28 1:44 GMT+01:00 Lennart Poettering lenn...@poettering.net:
 I am not a fan of this stuff either. I really don't like the TOCTOU
 behaviour I must say...

 If this is really just about .bak, then we can add it to the list of
 suffixes in hidden_files()...

Martin already committed an update [1] to at least ignore all the
temporary files created by dpkg and dpkg-related helper tools.

While adding .bak would probably not be wrong, I don't think it would
solve this particular issue in a robust way.
People are very inventive when it comes to such names. In the Debian
bug report which triggered this patch, the user had a file named
networking.save [2]. Most likely, this had been created by himself and
later on he forgot to remove it.

 I think a much better fix for all of this would be to first read in
 all sysv scripts, and only then start creating aliases.

I guess with read in, you actually mean read and parse all init
scripts *and* generate all unit files. After that create the symlinks.

So far we read
 everything in, and while doing so already create symlinks, while
 defering creation of the unit files to the end. If we moevd the
 symlink creation part to the end too we could easily check in the sysv
 script hashtable if we have a real script for a name before writing
 out an alias symlink for this.

I agree here and incidentally mentioned that in [3].
Martin and I briefly discussed that in #debian-systemd and IIRC, the
reason why Martin did it this way was simply because it was less work.

Michael

[1] c7088e4999f2e5dd33259948c806f4e2706e77ce
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775404#15
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775404#54
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] failing boot start jobs delay reboot

On Wed, 28.01.15 15:12, Michael Biebl (mbi...@gmail.com) wrote:

 2015-01-28 2:05 GMT+01:00 Lennart Poettering lenn...@poettering.net:
  On Tue, 20.01.15 11:24, Andrei Borzenkov (arvidj...@gmail.com) wrote:
  - stop in emergency shell when mount fails
  - fix /etc/fstab
  - ^D to continue boot
 
  no more works, because /etc/fstab is not reevaluated so systemd will
  still try the same broken mount again.
 
  Yeah, systemd will require a systemctl daemon-reload first. It might
  be a good idea if distros would mention that in a comment in the
  default fstab file they install.
 
 
 Hm, I vaguely remember that we discussed quite a while ago. Wasn't the
 idea to trigger the daemon-reload automatically when exiting the
 emergency/rescue shell?
 
 Could be as simple as changing emergency.service from
 
  ExecStart=-/bin/sh -c /sbin/sulogin; /bin/systemctl --fail --no-block 
 default
 
 to
  ExecStart=-/bin/sh -c /sbin/sulogin; /bin/systemctl daemon-reload;
 /bin/systemctl --fail --no-block default

I am not convinced this would be a good idea. I mean, I fail to see
why we should add an automatism in this specific case while we don't
have any automatism when you edit the file in any other context, for
example when the system is fully up.

I think this is really a documentation issue: the fstab file should
contain a nice hint to run systemctl daemon-reload to make systemd
consider it. And we could even update the rescue mode help text that
is shown right before sulogin to say the same. But otherwise, I am not
convinced anything should happen automatically here...

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] network-online.target is not down when a physical network is down

2015-01-28 Thread Igor Bukanov

Just for references. With the the following script placed in
/etc/NetworkManager/dispatcher.d/90-online-monitor everything works.
As the service is started explicitly the unit file needs no Install
section.

#!/bin/sh
status=$(nmcli -f STATE -t g)
if [ _$status = _connected -o _$status = _connected (site only) ]; then
systemctl start my-service
else
systemctl stop my-service
fi


On 22 January 2015 at 19:42, Dan Williams d...@redhat.com wrote:
 On Thu, 2015-01-22 at 19:51 +0300, Andrei Borzenkov wrote:
 В Thu, 22 Jan 2015 16:44:52 +0100
 Igor Bukanov i...@mir2.org пишет:

  For a service that should be shutdown when network is not available, I
  tried to use Requires=network-online.target . However, on Fedora 21
  with NetworkManager that does not work. When I switch off WiFi, the
  only connection on my laptop that can configure default IP route and
  setup /etc/resolv.conf, network-online.target still stays active and
  my service continues to run. Is it a bug in Fedora? If not, what is a
  canonical way to implement such dependency?


 No, it is not a bug. network-online was never intended to be used this
 way. It was intended to be used only during startup; when initial
 startup is finished, state of this service is largely irrelevant.

 network-online.target itself does absolutely nothing. It is provided as
 well known name for other services to order itself after; and you need
 to provide implementation that orders itself before.

 For NM implementation would be NetworkManager-wait-online.service that
 basically does nothing more than calling nm-online.

 Note that network down does not cause any change state in systemd.
 NetworkManager still runs. systemd itself does not watch or manages
 network, so it cannot initiate any actions here. I suppose you really
 want to hook systemctl stop/systemctl start in NetworkManager
 dispatcher framework.

 Yeah, a dispatcher script (man NetworkManager has more info) will be
 executed whenever any network interface is deconfigured by
 NetworkManager.  You could use this, in combination with 'nmcli -f STATE
 -t g' (which reports the NM state as a single word, eg connected or
 disconnected or connecting), to determine when no network
 connections are active, and then run 'systemctl stop your-service.

 See also
 http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/dispatcher

 Dan

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

Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd

2015-01-28 Thread Rauta, Alin

Hi Tom, Lennart,

Thanks for the answers.

The UFD is not only about configuration. It's about run-time monitoring of 
interfaces.
The Uplink failure detection daemon listens for RTM_NEWLINK and RTM_DELLINK 
events from kernel the same way networkd manager listens. Then by run-time 
monitoring the uplinks, the daemon controls the downlinks. When all uplinks are 
down, the failure is propagated to the downlinks (the interfaces are brought 
down). When at least one uplink has carrier, the downlinks are brought up. 

Due to monitoring functionality, I think I should bind the interfaces to 
something, for example to a netdev. It's not mapped to the kernel, but it's 
mapped to systemd internally.
Then for uplinks, I should use Tag= in the .network files and for downlinks 
BindCarrier=.

So, an implementation according to your comments would look like: 

For the netdev:
[NetDev]
Name=ufd1
Kind=tag

[Tag]
Id=45

For an uplink mapped to ufd1, I'll need to add in the .network file:
[Network]
Tag=ufd1
 
For a downlink mapped to ufd1, I'll need to add in the .network file:
[Network]
BindCarrier=ufd1

Am I right or do I miss something ?

Still the configuration of the group is spread through different files which 
makes it heavier to read and create.

To comment on Holger's email about BFD, UFD and BFD can coexist on switches, 
I've checked some release notes on internet. Moreover, BFD is a layer 3 feature 
(protocol). 

 Could you comment a bit on how you decide when an uplink should be considered 
 failed?
 Is it jut when it does not have a carrier?
 Is this the end of the story, or do you imagine extending this with other 
 notions in the future?

A link is considered failed when it's operational down (has no carrier) or it's 
admin down (interface down). About future extensions, I don't know about any 
plans right now, but you never know. Maybe someone else will want to add 
something more.

Lennart, on a switch I should be able to configure more than one UFD group. 
This being said and also due to the monitoring functionality of the UFD daemon, 
do you still think we can use only BindCarrier= ?

Please let me know what you think.

Best Regards,
Alin

-Original Message-
From: Lennart Poettering [mailto:lenn...@poettering.net] 
Sent: Tuesday, January 27, 2015 9:26 PM
To: Tom Gundersen
Cc: Rauta, Alin; Kinsella, Ray; systemd Mailing List
Subject: Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) 
support to networkd

On Tue, 27.01.15 19:54, Tom Gundersen (t...@jklm.no) wrote:

 Hi Alin,
 
 Thanks for working on this.
 
 I think the main concepts here make sense, but I have some comments on 
 the implementation.
 
 So the main ideas are:
 
 1) a notion of groups of links
 2) a notion of up- and downlinks
 3) configuring downlinks if and only if at least one uplink in the 
 group has a carrier
 
 Comments:
 
 Maybe we should not restrict the naming to UFD, as the grouping may 
 be useful for other things in the future (would be great if you could 
 comment on Holger's email for instance). In fact Lennart suggested we 
 introduce the concept of 'tags' instead of groups, and these will be 
 similar to tags in udev rules.

Taking this one step further we could even simplify further: maybe the entire 
concept of tags our groups is unnecessary. Instead, let's just introduce a 
single new setting:

BindCarrier=

Which takes a list of interface names, and supports globbing. Now, with this 
functionality in place, and a good naming regime we could implement such 
uplink/download behaviour too, right? I mean, let's say you name all your 
uplink interfaces uplink0, uplink1, uplink2, and your downlink interfaces 
downlink0, downlink1, and so on. Now, in the .network file for the downlink, 
we'd simply say BindCarrier=uplink*, which would then mean that the port is 
only configured if at least one interface matching that name, with a carrier is 
found.

Alin, wouldn't this be sufficient for you? I kinda prefer this solution due to 
its simplicity, and as it does not introduce any new concepts, and only a 
single new setting...

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] full reset of reset network state with networkd

2015-01-28 Thread poma

On 28.01.2015 10:23, Igor Bukanov wrote:
 If during the boot the network is configured with DHCP but later is
 configured with a static address with a new .network file, then
 systemctl restart networkd still keeps the old address obtained with
 DHCP.  This is expected according to documentation. Is there a way to
 force with networkd to fully reset the network configuration so it
 matches the one defined by unit files  and avoid manual removal of the
 older IP without doing the reboot?

http://linux-ip.net/html/tools-ip-address.html#tools-ip-address-flush


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

Re: [systemd-devel] [PATCH] sysv-generator: Handle .sh suffixes when translating Provides:

Hey Lennart,

Lennart Poettering [2015-01-27 23:09 +0100]:
 Hmm, we already had code that checks this in place, didn#t we?

We only previously had this .sh stripping in sysv_translate_name(),
but that translates and init script name like foo.sh to
foo.service. But that's not what we need in
sysv_translate_facility() to filter out the Provides: item which
refers to itself.

 I mean sysv_translate_facility() already filters out the case where
 the service name is identical to the provided name. Hence, why do you
 need a second check for this?

It's not really a new check, we just fixed the existing one:

-} else if (filename  streq(name, filename))
+} else if (filename  streq(name, filename_no_sh))

I. e. if filename ends with .sh, the streq wouldn't previously match
as Provides: names don't have the .sh suffixes. I. e. this is the
case where you encounter the item in Provides: which refers to its own
name, not to other scripts. We should not create an alias symlink for
that, as it would refer to itself.

 I wonder if the simple fix could just be to change this:
 
 } else if (filename  streq(name, filename))
 
 to this
 
 } else if (filename  streq(n, filename))
 
 Or so, in that function?

That particularly wouldn't help, as both n and name are foo here
in that context. I. e. n and name are both the value of the currently
processed Provides: list item (just that n strips off $, but that's
irrelevant here). But filename has the .sh suffix while Provides:
names never have .sh suffixes, so that comparison fails and without
the patch it would go on and create a foo.service - foo.service
alias symlink.

This case has been mitigated in two other places, so you need to
revert both 77354c7e and the extra sanity check in add_alias() of
commit 29e0e6d to see it again. So you could say that we don't need
the filename_no_sh comparison in sysv_translate_facility() as the new
check in add_alias() as well as 29e0e6d will save us too, but this
would still feel unclean to me.

Thanks,

Martin

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

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

2015-01-28 Thread Andrei Borzenkov

On Wed, Jan 28, 2015 at 6:04 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Wed, Jan 28, 2015 at 03:50:42AM +0100, Lennart Poettering wrote:
 On Wed, 28.01.15 03:47, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) 
 wrote:

  On Wed, Jan 28, 2015 at 01:53:17AM +0100, Lennart Poettering wrote:
   On Mon, 19.01.15 10:43, Zbigniew Jędrzejewski-Szmek 
   (zbys...@kemper.freedesktop.org) wrote:
  
 src/journal/journalctl.c |   28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)
   
New commits:
commit 40f0b71b063da6a36b8d7ec75ef20103abd18243
Author: Zbigniew J??drzejewski-Szmek zbys...@in.waw.pl
Date:   Mon Jan 19 13:42:34 2015 -0500
   
journalctl: trim --help to fit in 80 columns
   
Terminals tend to be 80 columns wide by default, and the help
text is only supposed to be a terse reminder anyway.
   
  
   Hmm, maybe we should add a test target to the makefile that runs all
   our tools with --help and checks that the output it generates is
   identical to the output pssed through fold -w 79 or so?
  
   (I added this to the TODO list for now)
 
  Done.

 Hmm, your commit checks for 80 chars, right? Shouldn't we rather check
 for 79? Many terminals that are 80 chars wide will leave one line free
 if you output 80 consecutive chars plus one newline...
 Are you sure? I though this was fixed already.
 A quick test with the linux console, urxvt, konsole, systemd-subterm,
 and xterm all DTRT.

I definitely see it every now and then although I cannot right now
tell exactly under which conditions. This could also depend on
terminfo entry on particular system.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Unwants

On 27 January 2015 at 21:35, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Tue, Jan 27, 2015 at 10:30:48PM +0100, Lennart Poettering wrote:
 On Tue, 27.01.15 15:45, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) 
 wrote:

  Yes, I think attempting any kind of dependency removal *from loaded
  units* would be very complicated, and would require major surgery to
  current unit engine. And things would become conceptually more complicated,
  which we certainly don't need.
 
  But masking of .wants/ links is something different I think. It is a
  *localized* modification to a single configuration file. We currently
  allow overridding of almost all configuration (units files, files in
  .d directories, recently even generators), but .wants and .requires
  are an exception. I think we should allow this. Apart from current
  use case, it would things more consistent for the user.

 Hmm, I am open to allowing to override the symlinks with symlinks, if
 you follow what I mean. But i'd be careful with allowing to override
 stuff listed in Wants= in a unit file in /usr, with a symlink in a
 .wants/ dir in /etc, if you follow what I mean.
 Yes, exactly.

 But yeah, allowing symlinks to override symlinks makes sense, a patch
 for that would be good.

 Lennart

 Zbyszek


ack.


-- 
Regards,

Dimitri.

Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

On Wed, 28.01.15 04:04, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

 On Wed, Jan 28, 2015 at 03:50:42AM +0100, Lennart Poettering wrote:
  On Wed, 28.01.15 03:47, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) 
  wrote:
  
   On Wed, Jan 28, 2015 at 01:53:17AM +0100, Lennart Poettering wrote:
On Mon, 19.01.15 10:43, Zbigniew Jędrzejewski-Szmek 
(zbys...@kemper.freedesktop.org) wrote:

  src/journal/journalctl.c |   28 ++--
  1 file changed, 14 insertions(+), 14 deletions(-)
 
 New commits:
 commit 40f0b71b063da6a36b8d7ec75ef20103abd18243
 Author: Zbigniew J??drzejewski-Szmek zbys...@in.waw.pl
 Date:   Mon Jan 19 13:42:34 2015 -0500
 
 journalctl: trim --help to fit in 80 columns
 
 Terminals tend to be 80 columns wide by default, and the help
 text is only supposed to be a terse reminder anyway.
 

Hmm, maybe we should add a test target to the makefile that runs all
our tools with --help and checks that the output it generates is
identical to the output pssed through fold -w 79 or so?

(I added this to the TODO list for now)
   
   Done.
  
  Hmm, your commit checks for 80 chars, right? Shouldn't we rather check
  for 79? Many terminals that are 80 chars wide will leave one line free
  if you output 80 consecutive chars plus one newline...
 Are you sure? I though this was fixed already.
 A quick test with the linux console, urxvt, konsole, systemd-subterm,
 and xterm all DTRT.

I know for sure that the old MS-DOS 5.0 console certainly wasn't happy
with 80ch lines... Because I remember this issue from when I started
programming back on those machines...

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] Added UFD (Uplink failure detection) support to networkd

On Wed, 28.01.15 10:13, Rauta, Alin (alin.ra...@intel.com) wrote:

 Lennart, on a switch I should be able to configure more than one UFD
 group. 

What precisely does this mean? WOuld those groups be orthogonal?

I really would like to avoid introdcuing the tags concept for
now. Would a solution where you give the uplinks appropriate names
(like uplink0, uplinkXYZ, uplink_waldo and so on) suffice, when
you can then refer to them in a .network file you apply to the
downlinks as BindCarrier=uplink*?

BindCarrier= would take a list of interface names, possibly with
globs. If you want to up and down a link foo if at least one of the
links bar, quux, piep, miau1, miau2 are up, you could write
this as BindCarrier=bar quux piep miau*.

What would introducing the tag concept give you beyond this very
simple schreme described above?

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] Swap gets activated twice (through fstab and gpt generators)

Lennart Poettering [2015-01-28 13:15 +0100]:
  I built a package with this for Debian and Ubuntu. The Debian reporter
  in https://bugs.debian.org/772182 confirmed that this is working, I
  think/hope the Ubuntu reporter in
  https://bugs.launchpad.net/bugs/1399595 is also usually very
  responsive, I think he'll report back soon too. So it fixes that
  problem, thanks!
 
 Is the swap device mounted afterwards?

Yes, and we also confirmed that it's from the fstab generator, not the
gpt one.

  However, in my VM with no GPT, but a simple fstab entry for the swap
  booting now hangs forever, swap.target doesn't become active any more.
  I don't have time right now to investigate this further, but I suppose
  this should be fairly easy to reproduce.
 
 Hmm. Any chance you can boot this in debug mode and get me the last
 100 log lines or so when this hangs? Also, could you enable the debug
 shell and get me the output of systemctl list-jobs?

Both at http://people.canonical.com/~pitti/tmp/systemd-debug/

Thanks,

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

Re: [systemd-devel] [PATCH] systemd-udevd.service: restore mount propagation

Lennart Poettering [2015-01-28 13:33 +0100]:
 Hmm, yeah, we apparently only add that for file systems listed in
 /etc/fstab...
 
 If you change the get_mount_parameters_fragment() invocation at the
 beginning of mount_add_device_links() in src/core/mount.c to
 get_mount_parameters(), does this make things work for you?
 
 This change might have more effects than just making this work, but I
 think it's the right thing to do. Could you test please?

BAZINGA! Thanks for this, now it works perfectly! Now the mount unit
looks like this:

| Where=/media/martin/Ubuntu 15.04 amd64
| What=/dev/sr0
| [...]
| Id=media-martin-Ubuntu\x5cx2015.04\x5cx20amd64.mount
| Names=media-martin-Ubuntu\x5cx2015.04\x5cx20amd64.mount
| Requires=-.mount
| Wants=system.slice
| BindsTo=dev-sr0.device
| WantedBy=dev-sr0.device
| Conflicts=umount.target
| Before=local-fs.target umount.target
| After=system.slice -.mount local-fs-pre.target systemd-journald.socket 
dev-sr0.device
| [...]

and requesting the CD eject causes cdrom_id --eject, which triggers
the new DISK_MEDIA_CHANGE rule, which stops the .device unit, which in
turn stops the .mount unit.

Patches attached for both parts of the issue. The first one is really
your patch, so please do commit yourself if you prefer (feel free to
steal any or all of my patch description, of course).

I'll also adjust the fd.o bug report accordingly.

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
From 0e7493429c017d8a74a299a3e60278c4f68af430 Mon Sep 17 00:00:00 2001
From: Martin Pitt martin.p...@ubuntu.com
Date: Wed, 28 Jan 2015 13:53:25 +0100
Subject: [PATCH 1/2] core/mount: add dependencies to dynamically mounted
 mounts too

Add unit dependencies for dynamic (i. e. not from fstab) mounts. With that,
mount units properly bind to their underlying device, and thus get
automatically stopped/unmounted when the underlying device goes away.

This cleans up stale mounts from unplugged devices.

Thanks to Lennart Poettering for pointing out the fix!
---
 src/core/mount.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/core/mount.c b/src/core/mount.c
index f944c02..b13712f 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -300,7 +300,7 @@ static int mount_add_device_links(Mount *m) {
 
 assert(m);
 
-p = get_mount_parameters_fragment(m);
+p = get_mount_parameters(m);
 if (!p)
 return 0;
 
-- 
2.1.4

From 0cc891bcd8d3fa9967dd733292caf86a43dd3503 Mon Sep 17 00:00:00 2001
From: Martin Pitt martin.p...@ubuntu.com
Date: Wed, 28 Jan 2015 13:57:47 +0100
Subject: [PATCH 2/2] rules: clean up stale CD drive mounts after ejection

Ejecting a CD with the hardware drive button only causes a change uevent, but
the device node stays around (just without a medium). Pick up these uevents and
mark the device as SYSTEMD_READY=0 on ejection, so that systemd stops the
device unit and consequently all mount units on it.

On media insertion, mark the device as SYSTEMD_READY=1 again.

https://bugs.freedesktop.org/show_bug.cgi?id=72206
https://bugzilla.opensuse.org/show_bug.cgi?id=909418
https://bugs.archlinux.org/task/42071
https://bugs.launchpad.net/bugs/1168742
---
 rules/60-cdrom_id.rules | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/rules/60-cdrom_id.rules b/rules/60-cdrom_id.rules
index 6eaf76a..7bfb12e 100644
--- a/rules/60-cdrom_id.rules
+++ b/rules/60-cdrom_id.rules
@@ -15,6 +15,12 @@ ENV{DISK_EJECT_REQUEST}==?*, RUN+=cdrom_id --eject-media $devnode, GOTO=cdr
 # enable the receiving of media eject button events
 IMPORT{program}=cdrom_id --lock-media $devnode
 
+# ejecting a CD does not remove the device node, so mark the systemd device
+# unit as inactive while there is no medium; this automatically cleans up of
+# stale mounts after ejecting
+ENV{DISK_MEDIA_CHANGE}==?*, ENV{ID_CDROM_MEDIA}!=?*, ENV{SYSTEMD_READY}=0
+ENV{DISK_MEDIA_CHANGE}==?*, ENV{ID_CDROM_MEDIA}==?*, ENV{SYSTEMD_READY}=1
+
 KERNEL==sr0, SYMLINK+=cdrom, OPTIONS+=link_priority=-100
 
 LABEL=cdrom_end
-- 
2.1.4



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

Re: [systemd-devel] [PATCH] systemd-udevd.service: restore mount propagation

Lennart Poettering [2015-01-27 23:33 +0100]:
  That sounds good indeed! I can sit down at qemu tomorrow and simulate
  some CD insertions/removals, and come up with an udev rule for this.
 
 That would be great. It would really just be a matter of setting
 SYSTEMD_READY=0 for block devices where media sense suggests that no
 media is in the drive. Probably a one line fix...

Turns out that there's no proper way to simulate that under QEMU --
that has no eject button, and the eject monitor command blocks
as long as the OS is still accessing it (i. e. it's mounted).

I borrowed the laptop from a friend which has a CD drive (I can do
this until Saturday while I'm in Belgium, FTR), and confirm the stale
mounts. I tried adding these rules to 60-cdrom_id.rules after the
IMPORT line:

  # remove a medium/eject CD: disable corresponding .mount units
  ENV{DISK_MEDIA_CHANGE}==?*, ENV{ID_CDROM_MEDIA}!=?*, 
ENV{SYSTEMD_READY}=0
  # insert a medium; undo the previous rule
  ENV{DISK_MEDIA_CHANGE}==?*, ENV{ID_CDROM_MEDIA}==?*, 
ENV{SYSTEMD_READY}=1

These essentially make SYSTEMD_READY the negation of ID_CDROM_MEDIA,
but as the latter isn't actually 0 but disappears, and we can't
negate in udev without resorting to (much slower) shell hacks, we
need two rules.

In udevadm I see that this has the intended effect -- as soon as I
eject the CD, /dev/sr0 gets ENV{SYSTEMD_READY}=0. But there's still
something missing, as merely adding this property doesn't yet tell
systemd to stop the unit -- media-ubuntu-5ML.mount is still active
after that. systemd.device(5) also only documents the other transition
from 0 to 1, but not from 1 to 0. So do we need to teach systemd to listen
to 1 → 0 transitions too for stopping?

Martin

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

Re: [systemd-devel] [PATCH] systemd-udevd.service: restore mount propagation

Martin Pitt [2015-01-28 10:35 +0100]:
 Turns out that there's no proper way to simulate that under QEMU --
 that has no eject button, and the eject monitor command blocks
 as long as the OS is still accessing it (i. e. it's mounted).

Lies! In fact eject ide1-cd0 works rather well, it causes the
DISK_EJECT_REQUEST=1 uevent, and then the cdrom_id --eject magic takes
place.

So in case anyone wonders how to reproduce this:

$ qemu-system-x86_64 -enable-kvm -m 2048 -snapshot -drive 
file=my_os.img,if=virtio -drive if=ide,index=1,media=cdrom -monitor stdio
QEMU 2.1.2 monitor - type 'help' for more information
# take any ISO you like
(qemu) change ide1-cd0 /home/martin/Downloads/ubuntu/vivid-desktop-amd64.iso
(qemu) eject ide1-cd0
Device 'ide1-cd0' is locked

Martin

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

Re: [systemd-devel] root= ignored (was: failing boot start jobs delay reboot)

On Wed, 28.01.15 00:58, Felix Miata (mrma...@earthlink.net) wrote:

 Lennart Poettering composed on 2015-01-28 02:03 (UTC+0100):
 
  Felix Miata wrote:
 
  Both. When they occur during init they repeat during shutdown. Even when I
  let init complete and succeed to fix the typo or oversight, the init 
  failure
  gets remembered and repeated at shutdown. Often the start job is on account
  of a volume label that has been replaced, usually along with a UUID, 
  because
  the clone is a partition on the same HD. Fedora is particularly frustrating
  by embedding dependent root volume label and not obeying root= on cmdline
  (openSUSE obeys root=). Those typos usually have to be fixed by chroot to 
  run
  dracut.
 
  Hmm, Fedora doesn't obey root=? That sounds like a bug. 
 
 I think it's only a problem due to Fedora's configuration of its Dracut
 hostonly option used by default. AFAICR, its rescue initrds have always
 worked. I can't remember now, but it may possibly be Mageia with hostonly
 enabled disobeys root= too, locking onto root's UUID when the initrd was
 built. It's never been a problem I've observed in openSUSE, which let dracut
 evolve a lot longer before switching to it from mkinitrd.

Hmm, but even in hostonly mode I'd assume that kernel cmdline settings
override the included settings... Still sounds like a bug...

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] systemd-udevd.service: restore mount propagation

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

 I. e. the .mount does not seem to be bound on the .device, and isn't
 taken down automatically (stopping the mount manually works fine). In
 show I don't see a BindsTo, and the Requires also doesn't mention
 the /dev/sr1 device:

Hmm, yeah, we apparently only add that for file systems listed in
/etc/fstab...

If you change the get_mount_parameters_fragment() invocation at the
beginning of mount_add_device_links() in src/core/mount.c to
get_mount_parameters(), does this make things work for you?

This change might have more effects than just making this work, but I
think it's the right thing to do. Could you test please?

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] Swap gets activated twice (through fstab and gpt generators)

On Wed, 28.01.15 12:37, Martin Pitt (martin.p...@ubuntu.com) wrote:

Lennart Poettering [2015-01-28 1:03 +0100]:
I implemented a different logic now:

http://cgit.freedesktop.org/systemd/systemd/commit/?id=37cf8fee46025d704660a9fc1d1349fe7d0b139d

With this change we'll now dispatch only one mkswap per device node,
regardless which symlinked alias is used to refer to it. I have only
given this very light testing, and I am not sure this solves the
original problem you reported, hence I'd be thankful if you could
check if this makes the problem go away.

I built a package with this for Debian and Ubuntu. The Debian reporter
in https://bugs.debian.org/772182 confirmed that this is working, I
think/hope the Ubuntu reporter in
https://bugs.launchpad.net/bugs/1399595 is also usually very
responsive, I think he'll report back soon too. So it fixes that
problem, thanks!

Is the swap device mounted afterwards?

However, in my VM with no GPT, but a simple fstab entry for the swap
booting now hangs forever, swap.target doesn't become active any more.
I don't have time right now to investigate this further, but I suppose
this should be fairly easy to reproduce.

Hmm. Any chance you can boot this in debug mode and get me the last
100 log lines or so when this hangs? Also, could you enable the debug
shell and get me the output of systemctl list-jobs?

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] Swap gets activated twice (through fstab and gpt generators)

On Wed, 28.01.15 13:41, Martin Pitt (martin.p...@ubuntu.com) wrote:

Lennart Poettering [2015-01-28 13:15 +0100]:
I built a package with this for Debian and Ubuntu. The Debian reporter
in https://bugs.debian.org/772182 confirmed that this is working, I
think/hope the Ubuntu reporter in
https://bugs.launchpad.net/bugs/1399595 is also usually very
responsive, I think he'll report back soon too. So it fixes that
problem, thanks!

Is the swap device mounted afterwards?

Yes, and we also confirmed that it's from the fstab generator, not the
gpt one.

Hmm. Any chance you can boot this in debug mode and get me the last
100 log lines or so when this hangs? Also, could you enable the debug
shell and get me the output of systemctl list-jobs?

Both at http://people.canonical.com/~pitti/tmp/systemd-debug/

Ah, thanks! That was helpful.

I apparently fucked up the new linked list iteration macro I added for
this. I think this should make it work:

http://cgit.freedesktop.org/systemd/systemd/commit/?id=cdda4aa8d20c2679cc937d40e793abe7806f17cb

Can you check?

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 10/12] Add fsckd service and socket, retarget systemd-fsck

On Wed, Jan 28, 2015 at 02:24:32PM +0100, Didier Roche wrote:
 

 From 000f1b6ff4f5f80a2a13309590d255de6d6526ec Mon Sep 17 00:00:00 2001
 From: Didier Roche didro...@ubuntu.com
 Date: Mon, 26 Jan 2015 17:30:00 +0100
 Subject: [PATCH 10/12] Add fsckd service and socket, retarget systemd-fsck
 
 systemd-fsckd can be socket-activated by systemd-fsck process. Reflect that
 in the different unit files.
 ---
  Makefile.am|  3 +++
  units/.gitignore   |  1 +
  units/systemd-fsck-root.service.in |  4 +++-
  units/systemd-f...@.service.in |  5 +++--
  units/systemd-fsckd.service.in | 16 
  units/systemd-fsckd.socket | 15 +++
  6 files changed, 41 insertions(+), 3 deletions(-)
  create mode 100644 units/systemd-fsckd.service.in
  create mode 100644 units/systemd-fsckd.socket
 
 diff --git a/Makefile.am b/Makefile.am
 index a9d61f1..1eeba4f 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -492,6 +492,7 @@ dist_systemunit_DATA = \
   units/slices.target \
   units/system.slice \
   units/x-.slice \
 + units/systemd-fsckd.socket \
   units/systemd-initctl.socket \
   units/systemd-shutdownd.socket \
   units/syslog.socket \
 @@ -543,6 +544,7 @@ nodist_systemunit_DATA = \
   units/systemd-kexec.service \
   units/systemd-fsck@.service \
   units/systemd-fsck-root.service \
 + units/systemd-fsckd.service \
   units/systemd-machine-id-commit.service \
   units/systemd-udevd.service \
   units/systemd-udev-trigger.service \
 @@ -596,6 +598,7 @@ EXTRA_DIST += \
   units/user/systemd-exit.service.in \
   units/systemd-f...@.service.in \
   units/systemd-fsck-root.service.in \
 + units/systemd-fsckd.service.in \
   units/systemd-machine-id-commit.service.in \
   units/u...@.service.m4.in \
   units/debug-shell.service.in \
 diff --git a/units/.gitignore b/units/.gitignore
 index 6fdb629..26ae965 100644
 --- a/units/.gitignore
 +++ b/units/.gitignore
 @@ -28,6 +28,7 @@
  /systemd-firstboot.service
  /systemd-fsck-root.service
  /systemd-fsck@.service
 +/systemd-fsckd.service
  /systemd-machine-id-commit.service
  /systemd-halt.service
  /systemd-hibernate.service
 diff --git a/units/systemd-fsck-root.service.in 
 b/units/systemd-fsck-root.service.in
 index 6d76578..bd3bdbc 100644
 --- a/units/systemd-fsck-root.service.in
 +++ b/units/systemd-fsck-root.service.in
 @@ -9,12 +9,14 @@
  Description=File System Check on Root Device
  Documentation=man:systemd-fsck-root.service(8)
  DefaultDependencies=no
 +Wants=systemd-fsckd.socket
  Before=local-fs.target shutdown.target
 +After=systemd-fsckd.socket
  ConditionPathIsReadWrite=!/
  
  [Service]
  Type=oneshot
  RemainAfterExit=yes
  ExecStart=@rootlibexecdir@/systemd-fsck
 -StandardOutput=journal+console
 +StandardOutput=journal
Just remove the line completely to use the admin default (here and in
other cases...).

  TimeoutSec=0
 diff --git a/units/systemd-f...@.service.in b/units/systemd-f...@.service.in
 index 857e625..3ceb5f2 100644
 --- a/units/systemd-f...@.service.in
 +++ b/units/systemd-f...@.service.in
 @@ -10,12 +10,13 @@ Description=File System Check on %f
  Documentation=man:systemd-fsck@.service(8)
  DefaultDependencies=no
  BindsTo=%i.device
 -After=%i.device systemd-fsck-root.service local-fs-pre.target
 +Wants=systemd-fsckd.socket
 +After=%i.device systemd-fsck-root.service local-fs-pre.target 
 systemd-fsckd.socket
  Before=shutdown.target
  
  [Service]
  Type=oneshot
  RemainAfterExit=yes
  ExecStart=@rootlibexecdir@/systemd-fsck %f
 -StandardOutput=journal+console
 +StandardOutput=journal
  TimeoutSec=0
 diff --git a/units/systemd-fsckd.service.in b/units/systemd-fsckd.service.in
 new file mode 100644
 index 000..27c325f
 --- /dev/null
 +++ b/units/systemd-fsckd.service.in
 @@ -0,0 +1,16 @@
 +#  This file is part of systemd.
 +#
 +#  systemd is free software; you can redistribute it and/or modify it
 +#  under the terms of the GNU Lesser General Public License as published by
 +#  the Free Software Foundation; either version 2.1 of the License, or
 +#  (at your option) any later version.
 +
 +[Unit]
 +Description=File System Check Daemon to report status
 +DefaultDependencies=no
 +Requires=systemd-fsckd.socket
 +Before=shutdown.target
 +
 +[Service]
 +ExecStart=@rootlibexecdir@/systemd-fsckd
 +StandardOutput=journal+console
 diff --git a/units/systemd-fsckd.socket b/units/systemd-fsckd.socket
 new file mode 100644
 index 000..96a034a
 --- /dev/null
 +++ b/units/systemd-fsckd.socket
 @@ -0,0 +1,15 @@
 +#  This file is part of systemd.
 +#
 +#  systemd is free software; you can redistribute it and/or modify it
 +#  under the terms of the GNU Lesser General Public License as published by
 +#  the Free Software Foundation; either version 2.1 of the License, or
 +#  (at your option) any later version.
 +
 +[Unit]
 +Description=fsck to fsckd communication Socket

Re: [systemd-devel] [PATCH] systemd-udevd.service: restore mount propagation

Zbigniew Jędrzejewski-Szmek [2015-01-28 16:29 +0100]:
  | Where=/media/martin/Ubuntu 15.04 amd64
  | What=/dev/sr0
  | [...]
  | Id=media-martin-Ubuntu\x5cx2015.04\x5cx20amd64.mount
  | Names=media-martin-Ubuntu\x5cx2015.04\x5cx20amd64.mount
  | Requires=-.mount
  | Wants=system.slice
  | BindsTo=dev-sr0.device
  | WantedBy=dev-sr0.device
  | Conflicts=umount.target
  | Before=local-fs.target umount.target
 This looks wrong. It should have no relation to local-fs.target, which
 is only for things from /etc/fstab (and manually created .mount units).

Ah, indeed it is. Just note that this isn't due to this patch, but
already the status in current master. The only difference with this
patch is the addition of BindsTo/Wants=dev-sr0.device.

Thanks for pointing this out!

Martin

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

[systemd-devel] [PATCH] logind: handle closing sessions over daemon restarts

Hello,

We restart logind in our systemd package on package upgrades, as that
should generally be safe and our policy is to do that whenever
possible to avoid reboots and apply security and other fixes
immediately.

We got several reports (https://launchpad.net/bugs/1415104) about
users losing their device ACLs and polkit privileges when they install
package updates involving systemd. I found out that this happens if
you have older sessions around in state closing, i. e. there's still
some leftover process in them [1]. After restarting logind, that old
closing session suddenly becomes Active=yes, and the real active
session becomes Active=no.

Patch attached, I tested it fairly thoroughly.

Thanks for considering!

Martin

[1] In many cases that's of course a bug in its own right. E. g.
pulseaudio ought to die with the session instead of keeping it open,
but there's also legitimate use cases like screen.
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
From 6706e1bfc69eb2cc5e3886839e71ab9d35d57627 Mon Sep 17 00:00:00 2001
From: Martin Pitt martin.p...@ubuntu.com
Date: Wed, 28 Jan 2015 18:14:01 +0100
Subject: [PATCH] logind: handle closing sessions over daemon restarts

It may happen that you have several sessions with the same VT:

 - Open a session c1 which leaves some processes around, and log out. The
   session will stay in State=closing and become Active=no.
 - Log back in on the same VT, get a new session c2 which is State=active and
   Active=yes.

When restarting logind after that, the first session that matches the current
VT becomes Active=yes, which will be c1; c2 thus is Active=no and does not get
the usual polkit/device ACL privileges.

Restore the closing state in session_load(), to avoid treating all restored
sessions as State=active. In seat_active_vt_changed(), prefer active sessions
over closing ones if more than one session matches the current VT.

Finally, fix the confusing comment in session_load() and explain it a bit
better.

https://launchpad.net/bugs/1415104
---
 src/login/logind-seat.c| 14 +-
 src/login/logind-session.c | 11 +--
 2 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/src/login/logind-seat.c b/src/login/logind-seat.c
index 197138c..126c5b8 100644
--- a/src/login/logind-seat.c
+++ b/src/login/logind-seat.c
@@ -340,12 +340,24 @@ int seat_active_vt_changed(Seat *s, unsigned int vtnr) {
 
 log_debug(VT changed to %u, vtnr);
 
+/* we might have earlier closing sessions on the same VT, so try to
+ * find a running one first */
 LIST_FOREACH(sessions_by_seat, i, s-sessions)
-if (i-vtnr == vtnr) {
+if (i-vtnr == vtnr  !i-stopping) {
 new_active = i;
 break;
 }
 
+if (!new_active) {
+/* no running one? then we can't decide which one is the
+ * active one, let the first one win */
+LIST_FOREACH(sessions_by_seat, i, s-sessions)
+if (i-vtnr == vtnr) {
+new_active = i;
+break;
+}
+}
+
 r = seat_set_active(s, new_active);
 manager_spawn_autovt(s-manager, vtnr);
 
diff --git a/src/login/logind-session.c b/src/login/logind-session.c
index a51f9f3..a02a537 100644
--- a/src/login/logind-session.c
+++ b/src/login/logind-session.c
@@ -301,6 +301,7 @@ int session_load(Session *s) {
 _cleanup_free_ char *remote = NULL,
 *seat = NULL,
 *vtnr = NULL,
+*state = NULL,
 *pos = NULL,
 *leader = NULL,
 *type = NULL,
@@ -327,6 +328,7 @@ int session_load(Session *s) {
SERVICE,s-service,
DESKTOP,s-desktop,
VTNR,   vtnr,
+   STATE,  state,
POS,pos,
LEADER, leader,
TYPE,   type,
@@ -415,13 +417,18 @@ int session_load(Session *s) {
 s-class = c;
 }
 
+if (state  streq(state, closing))
+s-stopping = true;
+
 if (s-fifo_path) {
 int fd;
 
 /* If we open an unopened pipe for reading we will not
get an EOF. to trigger an EOF we hence open it for
-   reading, but close it right-away which then will
-   trigger the EOF. */
+   writing, but close it right away which then will
+   trigger the EOF. This will happen immediately if no
+   other process has the FIFO open for writing, i. e.
+   when the session died before

Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd

2015-01-28 Thread Rauta, Alin

Hi Lennart, Tom,

We should also be able to add virtual devices to UFD groups, like Andrei 
mentioned in his email.
In this case, do you think BindCarrier= and Tag= in .network files would 
still work ?

If we think about LAG (link aggregation) and if I am right, it's mapped to the 
kernel as a virtual device and contains multiple links. This way, it makes 
sense to have groups of links as netdevs. The only difference in case of UFD is 
that is not mapped to the kernel, but it's mapped inside networkd.

Another thing is that maybe later on we want to provide some properties for an 
UFD group, maybe to change to way we consider an uplink as failing. This would 
be easy if we have a netdev for the UFD group. Also, defining a netdev, we 
don't lose the identity of the feature nor we mask it.

The patch I've sent introduces NETDEV_CREATE_GROUP as a new netdev 
create_type that can be used for other groups also, not just UFDs.
The UFD group creation is done by calling netdev-create which is an  
abstraction  for an inside netdev_create_ufd_group, so it's generic.
If, for example, I want to add a new kind of groups, not UFD, I have to define 
a new netdev kind (kind=new_group_kind) and to provide the corresponding create 
function in the netdev abstraction table.

I don't know in which other way to configure the UFDs and handle all use cases 
(for both virtual  physical devices).

Please let me know what you think.

Best Regards,
Alin

-Original Message-
From: Lennart Poettering [mailto:lenn...@poettering.net] 
Sent: Wednesday, January 28, 2015 1:53 PM
To: Andrei Borzenkov
Cc: Rauta, Alin; Kinsella, Ray; systemd Mailing List
Subject: Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) 
support to networkd

On Wed, 28.01.15 16:48, Andrei Borzenkov (arvidj...@gmail.com) wrote:

 On Wed, Jan 28, 2015 at 3:40 PM, Lennart Poettering 
 lenn...@poettering.net wrote:
  On Wed, 28.01.15 10:13, Rauta, Alin (alin.ra...@intel.com) wrote:
 
  Lennart, on a switch I should be able to configure more than one 
  UFD group.
 
  What precisely does this mean? WOuld those groups be orthogonal?
 
 
 No. You have two different VLANs; uplink group 1 connects to to VLAN1, 
 uplink group 2 connects to VLAN2. They are not orthogonal in any way 
 and exist at the same time. If group 1 goes down, it does not affect 
 group 2 in any way.

Hmm, if they don't affect each other, then they *are* orthogonal.

Now I am really confused...

 
  I really would like to avoid introdcuing the tags concept for now. 
  Would a solution where you give the uplinks appropriate names (like 
  uplink0, uplinkXYZ, uplink_waldo and so on) suffice, when you 
  can then refer to them in a .network file you apply to the downlinks 
  as BindCarrier=uplink*?
 
  BindCarrier= would take a list of interface names, possibly with 
  globs. If you want to up and down a link foo if at least one of 
  the links bar, quux, piep, miau1, miau2 are up, you could 
  write this as BindCarrier=bar quux piep miau*.
 
  What would introducing the tag concept give you beyond this very 
  simple schreme described above?
 
  Lennart
 
  --
  Lennart Poettering, Red Hat
  ___
  systemd-devel mailing list
  systemd-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Lennart

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

Re: [systemd-devel] initializing _cleanup_* variables [was: [PATCH 01/12] fsckd daemon for inter-fsckd communication]

On Wed, 28.01.15 16:47, Martin Pitt (martin.p...@ubuntu.com) wrote:

 Hey Zbyszek,
 
 Zbigniew Jędrzejewski-Szmek [2015-01-28 15:37 +0100]:
   +static int handle_requests(int socket_fd) {
   +Clients *first = NULL;
   +usec_t last_activity = 0;
   +int numdevices = 0, clear = 0;
   +double percent = 100;
   +_cleanup_fclose_ FILE *console = NULL;
  NULL not necessary (and you don't have it in similar circumstances above ;))
 
 How is that not necessary? Just because the very next line initializes
 it, and there is no exit path before? Because in the general case it
 certainly is necessary, otherwise the _cleanup_ handler will try to
 free/close/clean up a random pointer value and crash.
 
 So IMHO it's a good defensive habit to always init _cleanup_* vars
 with NULL. In the future someone might put some code with return
 before the fopen() below, and then get a crash.

Yeah, nowadays I tend to always initialize _cleanup_ vars at the time
i declare them. It's better to be safe than sorry...

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 04/12] Add some plymouth functionality to connect and send, messages

On Wed, 28.01.15 14:22, Didier Roche (didro...@ubuntu.com) wrote:

  # 
 --
 +have_plymouth=no
 +AC_ARG_ENABLE(plymouth, AS_HELP_STRING([--disable-plymouth], [disable 
 plymouth integration]))
 +if test x$enable_plymouth != xno; then
 +PKG_CHECK_MODULES([PLYMOUTH], [ply-boot-client = 0.8.0],
 +[AC_DEFINE(HAVE_PLYMOUTH, 1, [Define if plymouth is 
 available]) have_plymouth=yes], have_plymouth=no)
 +if test x$have_plymouth = xno -a x$enable_plymouth = xyes; then
 +AC_MSG_ERROR([*** plymouth integration requested but 
 libraries not found])
 +fi
 +fi
 +AM_CONDITIONAL(HAVE_PLYMOUTH, [test $have_plymouth = yes])

Hmm, I am bit concerned about adding this dependency. So far we
managed to talk to plymouth without using its library, and I am really
not sure we should start doing so now. So far the messages to send
were so simply that it really wasn't worth the effort to use the full
library. 

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 06/12] Support cancellation of fsck in progress

On Wed, 28.01.15 14:22, Didier Roche (didro...@ubuntu.com) wrote:

  src/fsck/fsck.c   | 29 +
  src/fsckd/fsckd.c | 43 +++
  src/fsckd/fsckd.h |  5 +
  3 files changed, 69 insertions(+), 8 deletions(-)
 
 diff --git a/src/fsck/fsck.c b/src/fsck/fsck.c
 index f5dd546..0b42e3b 100644
 --- a/src/fsck/fsck.c
 +++ b/src/fsck/fsck.c
 @@ -47,6 +47,8 @@
  static bool arg_skip = false;
  static bool arg_force = false;
  static const char *arg_repair = -a;
 +static pid_t fsck_pid;
 +static bool cancel_requested = false;

Please do not introduce new global variables unnecessarily. We try to
keep variables locally, and keep the global state at a minimum. An
exception is mostly the command line args, which by their nature are
global anyway...

Lennart

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

Re: [systemd-devel] [PATCH 01/12] fsckd daemon for inter-fsckd communication

On Wed, 28.01.15 14:20, Didier Roche (didier.ro...@canonical.com) wrote:

  static int process_progress(int fd) {
 -_cleanup_fclose_ FILE *console = NULL, *f = NULL;
 +_cleanup_fclose_ FILE *f = NULL;
  usec_t last = 0;
 -bool locked = false;
 -int clear = 0;
 +_cleanup_close_ int fsckd_fd;
 +static const union sockaddr_union sa = {
 +.un.sun_family = AF_UNIX,
 +.un.sun_path = FSCKD_SOCKET_PATH,
 +};
 +
 +fsckd_fd = socket(AF_UNIX, SOCK_STREAM | SOCK_NONBLOCK, 0);

Please always specifiy SOCK_CLOEXEC. In fact, *all* our fs should be
opened in CLOEXEC mode these days, except for the very few case where
that's explicitly not desired.

 -for (j = 0; j  (unsigned) clear; j++)
 -fputc(' ', console);
 -fputc('\r', console);
 -fflush(console);
 +n = send(fsckd_fd, progress, sizeof(FsckProgress), 0);
 +if (n  0 || (size_t) n  sizeof(FsckProgress))
 +log_warning_errno(n, Cannot communicate
 -fsck progress to fsckd: %m);

Hmm, this error check is incorrect. The first argument of
log_warning_errno() should carry an errno integer of some kind, but
the raw glibc send() does not return that, it returns a size...

 +
 +#define IDLE_TIME_MINUTES 1
 +
 +typedef struct Clients {
 +int fd;
 +char device[PATH_MAX];

Hmm, no, please don't. Please never use fixed size arrays for these
things unless the string is really fixed size. Please use char* here,
and allocate the data. 

 +last_activity = now(CLOCK_MONOTONIC);
 +
 +for (;;) {
 +int new_client_fd = 0;
 +Clients *current;
 +_cleanup_free_ char *console_message = NULL;
 +double current_percent = 100;
 +int current_numdevices = 0, m = 0;
 +usec_t t;
 +
 +/* Initialize and list new clients */
 +new_client_fd = accept4(socket_fd, NULL, NULL, 
 SOCK_NONBLOCK);
 +if (new_client_fd  0) {
 +log_debug(new fsck client connected to fd: %d, 
 new_client_fd);
 +current = alloca0(sizeof(Clients));

It's not OK to invoke alloca() in loops. This cannot work. Please use
normal heap memoy for this.

 +current-fd = new_client_fd;
 +if (!first)
 +LIST_INIT(clients, current);
 +else
 +LIST_PREPEND(clients, first, current);
 +first = current;


LIST_PREPEND(clients, first, current) already does all of the five
lines above.

 +current = NULL;
 +}
 +
 +LIST_FOREACH(clients, current, first) {
 +   FsckProgress fsck_data;
 +   int rc = 0;
 +
 +if (current-fd  0)
 +rc = recv(current-fd, fsck_data, 
 sizeof(FsckProgress), 0);
 +
 +if ((current-fd != 0)  (rc == 0)) {
 +log_debug(fsck client connected to
 fd %d disconnected, current-fd);

Please print propery exit codes.

 +current-fd = 0;
 +current-percent = 100;
 +} else if ((rc  0)  (errno !=
 EWOULDBLOCK)) {

EWOULDBLOCK is a windows name. Please use EAGAIN.

 +if ((fabs(current_percent - percent)  0.01) || 
 (current_numdevices != numdevices)) {
 +numdevices = current_numdevices;
 +percent = current_percent;
 +
 +asprintf(console_message, Checking in
 progress on %d disks (%3.1f%% complete),
 + numdevices, percent);

Missing oom check.

 +
 +/* write to console */
 +fprintf(console, \r%s\r%n, console_message, m);
 +fflush(console);

Hmm, what's the reason for first writing this to an alocated buffer,
and then to the console? You can write this directly to the console, no?


 +static int create_socket(void) {
 +/* Create the socket manually for testing */
 +union {
 +struct sockaddr sa;
 +struct sockaddr_un un;
 +} sa;

Please use sockaddr_union for this.

 +int fd;
 +
 +fd = socket(AF_UNIX, SOCK_STREAM | SOCK_NONBLOCK, 0);
 +if (fd  0)
 +return log_error_errno(errno, socket() failed:
 %m);

SOCK_CLOEXEC, please.

 +
 +memset(sa, 0, sizeof(sa));
 +sa.un.sun_family = AF_UNIX;

Please initialize fields with constant values when you declare the
variable already.

 +strncpy(sa.un.sun_path, FSCKD_SOCKET_PATH,

Re: [systemd-devel] Fwd: journald doesn't forward messages to syslog w/o CAP_SYS_ADMIN (LXC)

On Tue, 13.01.15 12:05, Martin Pitt (mp...@debian.org) wrote:

 Hello all,
 
 I'm forwarding a bug report about journal forwarding in containers
 without CAP_SYS_ADMIN. I adjusted Christian's patch for current git
 master and to be in git am format.

For completeness' sake: this apparently got applied now by yourself.

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 05/12] Connect and send to plymouth progress report

On Wed, 28.01.15 14:22, Didier Roche (didro...@ubuntu.com) wrote:

 
 +#ifdef HAVE_PLYMOUTH
 +asprintf(fsck_message, fsckd:%d:%3.1f:%s, 
 numdevices, percent, console_message);
 +#endif

OOM check.

The communcaition here with plymouth still looks simple enough to just
do that directly in our code, the way we did it so far...

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] backlight: let udev properties override clamping

2015-01-28 Thread Topi Miettinen

On my computer, the minimum brightness enforced by clamping in
backlight is too bright.

Let udev property ID_BACKLIGHT_CLAMP control whether the brightness
is clamped or not.
---
 man/systemd-backli...@.service.xml | 11 ++-
 src/backlight/backlight.c  |  5 -
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/man/systemd-backli...@.service.xml 
b/man/systemd-backli...@.service.xml
index 453afbf..4105685 100644
--- a/man/systemd-backli...@.service.xml
+++ b/man/systemd-backli...@.service.xml
@@ -58,7 +58,16 @@
 is a service that restores the display backlight
 brightness at early boot and saves it at shutdown. On
 disk, the backlight brightness is stored in
-filename/var/lib/systemd/backlight//filename./para
+filename/var/lib/systemd/backlight//filename. During
+loading, if udev property ID_BACKLIGHT_CLAMP is not
+present or is set to literal1/literal, the
+brightness is clamped to at least value
+literal1/literal or 5% of maximum brightness. This
+is to avoid an unpowered display due to poor API
+design in kernel (unfixed as of 2015-01-28) that does
+not allow user space to know the difference between
+lowest brightness and powering off the
+backlight./para
 /refsect1
 
 refsect1
diff --git a/src/backlight/backlight.c b/src/backlight/backlight.c
index 1271a66..df53b75 100644
--- a/src/backlight/backlight.c
+++ b/src/backlight/backlight.c
@@ -373,6 +373,7 @@ int main(int argc, char *argv[]) {
 
 if (streq(argv[1], load)) {
 _cleanup_free_ char *value = NULL;
+const char *clamp;
 
 if (!shall_restore_state())
 return EXIT_SUCCESS;
@@ -390,7 +391,9 @@ int main(int argc, char *argv[]) {
 return EXIT_FAILURE;
 }
 
-clamp_brightness(device, value, max_brightness);
+clamp = udev_device_get_property_value(device, 
ID_BACKLIGHT_CLAMP);
+if (clamp == NULL || streq(clamp, 1))
+clamp_brightness(device, value, max_brightness);
 
 r = udev_device_set_sysattr_value(device, brightness, value);
 if (r  0) {
-- 
2.1.4

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

Re: [systemd-devel] Running system services required for certain filesystems

On Mon, 12.01.15 10:37, Colin Guthrie (gm...@colin.guthr.ie) wrote:

 Hi,
 
 On a related note to my previous message (subject systemctl status not
 showing still running processes in inactive .mount unit cgroups (NFS
 specifically)), when mount.nfs runs to mount NFS filesystems, it shells
 out to /usr/sbin/start-statd which in turn calls sytemctl to start
 rpc.statd service. This feels ugly.

I think the right answer for all this complexity is to add proper
socket activation to the various daemons NFS needs. Then the ordering
problems go away, and the services are automatically started when they
are needed, but not before. 

inetd back in the day had socket activation for RPC services, maybe we
should reintroduce that concept back to systemd?

(I didn't follow the details of this thread, my NFS-fu is a bit too
limited. If there's anything unresolved I am supposed to say something
about, please let me know.)

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] systemctl status not showing still running processes in inactive .mount unit cgroups (NFS specifically)

On Thu, 15.01.15 09:39, Colin Guthrie (gm...@colin.guthr.ie) wrote:

Ross Lagerwall wrote on 14/01/15 22:41:
On Mon, Jan 12, 2015 at 09:04:35PM +0300, Andrei Borzenkov wrote:
В Mon, 12 Jan 2015 10:34:07 +
Colin Guthrie co...@mageia.org пишет:

Anyway, assuming the process is in the .mount unit cgroup, should
systemd detect the umount and kill the processes accordingly, and if

It does not do it currently. It only starts killing if (u)mount times
out. Otherwise if umount is successful it goes to stopped state
immediately. Although it probably should, even for the sake of user
space helpers.

not, should calling systemctl status on .mount units show processes
even if it's in an inactive state?

I believe something very similar (not only for mount units) was
reported recently, but I do not have reference handy. I mean, processes
belonging to stopped unit (e.g. with KillMode=none) are not displayed.

This commit is probably needed:

http://cgit.freedesktop.org/systemd/systemd/commit/?id=dab5bf859900c0abdbf78c584e4aed42a19768cd

That indeed looks like a likely candidate. I'll try breaking things
again and checking status output with this patch applied.

Did this fix things for you? Are all processes invoked by the mount
unit terminated cleanly now on umount?

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] initializing _cleanup_* variables [was: [PATCH 01/12] fsckd daemon for inter-fsckd communication]

On Wed, 28.01.15 16:06, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote:

 On 28 January 2015 at 15:47, Martin Pitt martin.p...@ubuntu.com wrote:
  Hey Zbyszek,
 
  Zbigniew Jędrzejewski-Szmek [2015-01-28 15:37 +0100]:
   +static int handle_requests(int socket_fd) {
   +Clients *first = NULL;
   +usec_t last_activity = 0;
   +int numdevices = 0, clear = 0;
   +double percent = 100;
   +_cleanup_fclose_ FILE *console = NULL;
  NULL not necessary (and you don't have it in similar circumstances above 
  ;))
 
  How is that not necessary? Just because the very next line initializes
  it, and there is no exit path before? Because in the general case it
  certainly is necessary, otherwise the _cleanup_ handler will try to
  free/close/clean up a random pointer value and crash.
 
  So IMHO it's a good defensive habit to always init _cleanup_* vars
  with NULL. In the future someone might put some code with return
  before the fopen() below, and then get a crash.
 
  Or is there some gcc magic that I missed? (I thought only global
  variables were guaranteed to be NULL, not stack vars).
 
 
 Well, during systemd build there are some -Wmaybe-uninitialized
 warnings in most cases it is code similar to the above case or
 like checking r || check uninitialised variable. Shall we fix all of
 them? In most cases it would be of limited gain, but at least it will
 be clear to see when -Wmaybe-uninitalized warnings catches a real
 thing.
 
 (or is my compiler old and has false positives?)

This is probably caused by LTO. The gcc warnings when using LTO are
not useful. While hacking it's a really good idea to disable LTO, the
warnings get more useful. It also saves you a lot of time to do so,
since LTO is awfully slow. 

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] backlight: let udev properties override clamping

On Wed, 28.01.15 23:51, Topi Miettinen (toiwo...@gmail.com) wrote:

 diff --git a/src/backlight/backlight.c b/src/backlight/backlight.c
 index 1271a66..df53b75 100644
 --- a/src/backlight/backlight.c
 +++ b/src/backlight/backlight.c
 @@ -373,6 +373,7 @@ int main(int argc, char *argv[]) {
  
  if (streq(argv[1], load)) {
  _cleanup_free_ char *value = NULL;
 +const char *clamp;
  
  if (!shall_restore_state())
  return EXIT_SUCCESS;
 @@ -390,7 +391,9 @@ int main(int argc, char *argv[]) {
  return EXIT_FAILURE;
  }
  
 -clamp_brightness(device, value, max_brightness);
 +clamp = udev_device_get_property_value(device, 
 ID_BACKLIGHT_CLAMP);
 +if (clamp == NULL || streq(clamp, 1))

Please use parse_boolean() for this.

I think it would be better to name this ID_BACKLIGHT_CLAMP_MIN or so.

Otherwise looks fine to me.

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] Break JobNew signal dbus signature by adding JobType.

On Sun, 11.01.15 18:08, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote:

 At the moment JobNew and JobRemoved signals are not useful for
 tracking streams of events. JobType is missing from both of them, and
 thus one can only track that something is happening and to which
 units (And whether something is about to happen, finished, failed,
 got aborted etc.). To get the JobType, one needs to query property
 from the job, however this works only for slow jobs, typically the
 job is gone on the systemd side already and thus subscriber has no
 chance in quering the job type.
 
 It looks like previously JobNew signal api was changed in 2012. Today
 however there are slightly more clients of JobNew/JobRemoved
 signals. Performing the codesearch.debian.net queries, JobRemoved has
 a few users (e.g. go-systemd - docker.io), but JobNew only has
 systemd-ui as it's consumer. I am proposing to break JobNew signature,
 patch systemd-ui to handle both cases. And then users of JobRemoved
 signal would be able to get job_type, by subscribing to JobNew signal
 and caching/storing the job_type.

This stuff is actually covered by the stability guarantee. Hence I am
very conservative about changing this.

I'd be very careful with adding more and more bits to the existing
signals. I mean, I am sure for lots of cases people would want even
more bits sent along, but where would we say no then?

Sending out JobNew with basic information, and then expecting clients
to query the newly appeared job's properties to get more is an OK
strategy I think. It *is* racy, since by the time the client would
query the properties the job might already be gone again, but at least
this window is smaller than for JobRemoved: if you'd want to learn
more about a job that just finishd, you'd have to query a job object
that well, just disappeared to just have disappeared...

I general, if we really do want to do something about this entire
problem set, then we should go all the way and start adopting David
Zeuthen's ObjectManager stuff, that is even described in the dbus
spec, and for which we have nice support for sd-bus. It's a bit
chatty, but it is race-free and solves this problem comprehensively.

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 11/12] Add man page and references to it.

On Wed, Jan 28, 2015 at 02:24:55PM +0100, Didier Roche wrote:
 

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

Re: [systemd-devel] [PATCH] systemd-udevd.service: restore mount propagation

On Wed, Jan 28, 2015 at 02:09:37PM +0100, Martin Pitt wrote:
 Lennart Poettering [2015-01-28 13:33 +0100]:
  Hmm, yeah, we apparently only add that for file systems listed in
  /etc/fstab...
  
  If you change the get_mount_parameters_fragment() invocation at the
  beginning of mount_add_device_links() in src/core/mount.c to
  get_mount_parameters(), does this make things work for you?
  
  This change might have more effects than just making this work, but I
  think it's the right thing to do. Could you test please?
 
 BAZINGA! Thanks for this, now it works perfectly! Now the mount unit
 looks like this:
 
 | Where=/media/martin/Ubuntu 15.04 amd64
 | What=/dev/sr0
 | [...]
 | Id=media-martin-Ubuntu\x5cx2015.04\x5cx20amd64.mount
 | Names=media-martin-Ubuntu\x5cx2015.04\x5cx20amd64.mount
 | Requires=-.mount
 | Wants=system.slice
 | BindsTo=dev-sr0.device
 | WantedBy=dev-sr0.device
 | Conflicts=umount.target
 | Before=local-fs.target umount.target
This looks wrong. It should have no relation to local-fs.target, which
is only for things from /etc/fstab (and manually created .mount units).

Zbyszek

 | After=system.slice -.mount local-fs-pre.target systemd-journald.socket 
 dev-sr0.device
 | [...]
 
 and requesting the CD eject causes cdrom_id --eject, which triggers
 the new DISK_MEDIA_CHANGE rule, which stops the .device unit, which in
 turn stops the .mount unit.
 
 Patches attached for both parts of the issue. The first one is really
 your patch, so please do commit yourself if you prefer (feel free to
 steal any or all of my patch description, of course).
 
 I'll also adjust the fd.o bug report accordingly.
 
 Thanks,
 
 Martin
 -- 
 Martin Pitt| http://www.piware.de
 Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

 From 0e7493429c017d8a74a299a3e60278c4f68af430 Mon Sep 17 00:00:00 2001
 From: Martin Pitt martin.p...@ubuntu.com
 Date: Wed, 28 Jan 2015 13:53:25 +0100
 Subject: [PATCH 1/2] core/mount: add dependencies to dynamically mounted
  mounts too
 
 Add unit dependencies for dynamic (i. e. not from fstab) mounts. With that,
 mount units properly bind to their underlying device, and thus get
 automatically stopped/unmounted when the underlying device goes away.
 
 This cleans up stale mounts from unplugged devices.
 
 Thanks to Lennart Poettering for pointing out the fix!
 ---
  src/core/mount.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/src/core/mount.c b/src/core/mount.c
 index f944c02..b13712f 100644
 --- a/src/core/mount.c
 +++ b/src/core/mount.c
 @@ -300,7 +300,7 @@ static int mount_add_device_links(Mount *m) {
  
  assert(m);
  
 -p = get_mount_parameters_fragment(m);
 +p = get_mount_parameters(m);
  if (!p)
  return 0;
  
 -- 
 2.1.4
 

 From 0cc891bcd8d3fa9967dd733292caf86a43dd3503 Mon Sep 17 00:00:00 2001
 From: Martin Pitt martin.p...@ubuntu.com
 Date: Wed, 28 Jan 2015 13:57:47 +0100
 Subject: [PATCH 2/2] rules: clean up stale CD drive mounts after ejection
 
 Ejecting a CD with the hardware drive button only causes a change uevent, but
 the device node stays around (just without a medium). Pick up these uevents 
 and
 mark the device as SYSTEMD_READY=0 on ejection, so that systemd stops the
 device unit and consequently all mount units on it.
 
 On media insertion, mark the device as SYSTEMD_READY=1 again.
 
 https://bugs.freedesktop.org/show_bug.cgi?id=72206
 https://bugzilla.opensuse.org/show_bug.cgi?id=909418
 https://bugs.archlinux.org/task/42071
 https://bugs.launchpad.net/bugs/1168742
 ---
  rules/60-cdrom_id.rules | 6 ++
  1 file changed, 6 insertions(+)
 
 diff --git a/rules/60-cdrom_id.rules b/rules/60-cdrom_id.rules
 index 6eaf76a..7bfb12e 100644
 --- a/rules/60-cdrom_id.rules
 +++ b/rules/60-cdrom_id.rules
 @@ -15,6 +15,12 @@ ENV{DISK_EJECT_REQUEST}==?*, RUN+=cdrom_id 
 --eject-media $devnode, GOTO=cdr
  # enable the receiving of media eject button events
  IMPORT{program}=cdrom_id --lock-media $devnode
  
 +# ejecting a CD does not remove the device node, so mark the systemd device
 +# unit as inactive while there is no medium; this automatically cleans up of
 +# stale mounts after ejecting
 +ENV{DISK_MEDIA_CHANGE}==?*, ENV{ID_CDROM_MEDIA}!=?*, 
 ENV{SYSTEMD_READY}=0
 +ENV{DISK_MEDIA_CHANGE}==?*, ENV{ID_CDROM_MEDIA}==?*, 
 ENV{SYSTEMD_READY}=1
 +
  KERNEL==sr0, SYMLINK+=cdrom, OPTIONS+=link_priority=-100
  
  LABEL=cdrom_end
 -- 
 2.1.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] [PATCH 06/12] Support cancellation of fsck in progress

Dimitri John Ledkov [2015-01-28 15:21 +]:
 Hm? an interactive message with key-binding is usually shown and then
 plymouth reacts to such a key prompt.
 This is how it has always worked on plymouth prompts since forever...
 thus this would not be a surprise to most plymouth users (~ 5+ years
 by now?!)
 Doing it otherwise, will, on the contrary, impede user experience.

I don't see anything wrong with always making Control-C work for the
Unix wizards, and then the more human friendly annouced key bindings
which can be translated, and thus also work on keyboards where you
don't have a c in the first place.

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

Re: [systemd-devel] [PATCH 06/12] Support cancellation of fsck in progress

On 28 January 2015 at 15:31, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Wed, Jan 28, 2015 at 03:21:27PM +, Dimitri John Ledkov wrote:
 On 28 January 2015 at 14:53, Zbigniew Jędrzejewski-Szmek
 zbys...@in.waw.pl wrote:
 
  On Wed, Jan 28, 2015 at 02:22:54PM +0100, Didier Roche wrote:
  
 
   From 104cf82ba28941e907f277a713f834ceb3d909f0 Mon Sep 17 00:00:00 2001
   From: Didier Roche didro...@ubuntu.com
   Date: Mon, 26 Jan 2015 16:40:52 +0100
   Subject: [PATCH 06/12] Support cancellation of fsck in progress
  
   Grab in fsckd plymouth watch key for C or c, and propagate this cancel 
   request
   to systemd-fsck which will terminate fsck.
  Could we bind to ^c or if this is not possible, three c's in three
  seconds instead? I'm worried that before you could press anything to 
  little
  effect in plymouth, and now a single key will have significant 
  consequences.
 


 Hm? an interactive message with key-binding is usually shown and then
 plymouth reacts to such a key prompt.
 This is how it has always worked on plymouth prompts since forever...
 thus this would not be a surprise to most plymouth users (~ 5+ years
 by now?!)
 Doing it otherwise, will, on the contrary, impede user experience.
 If you say so. I have never interacted with plymouth except to press ESC.
 I'll have to give this a try.

Actually it's not ESC button, but rather any escape sequence will drop
into messages mode. That is shift, ctrl, alt, Fn, all of them.
Thus I don't think ^c binding is actually available to plymouth clients.
But my plymouth knowledge is rusty.

-- 
Regards,

Dimitri.

Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 06/12] Support cancellation of fsck in progress

On 28 January 2015 at 14:53, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:

 On Wed, Jan 28, 2015 at 02:22:54PM +0100, Didier Roche wrote:
 

  From 104cf82ba28941e907f277a713f834ceb3d909f0 Mon Sep 17 00:00:00 2001
  From: Didier Roche didro...@ubuntu.com
  Date: Mon, 26 Jan 2015 16:40:52 +0100
  Subject: [PATCH 06/12] Support cancellation of fsck in progress
 
  Grab in fsckd plymouth watch key for C or c, and propagate this cancel 
  request
  to systemd-fsck which will terminate fsck.
 Could we bind to ^c or if this is not possible, three c's in three
 seconds instead? I'm worried that before you could press anything to little
 effect in plymouth, and now a single key will have significant consequences.



Hm? an interactive message with key-binding is usually shown and then
plymouth reacts to such a key prompt.
This is how it has always worked on plymouth prompts since forever...
thus this would not be a surprise to most plymouth users (~ 5+ years
by now?!)
Doing it otherwise, will, on the contrary, impede user experience.


  Send a message to signal to user what key we are grabbing for fsck cancel.
 
  Message is: fsckd-cancel-msg:string
  Where string is a translated string ready to be displayed by the plymouth 
  theme
  indicating that c or C can be used to cancel current checks. It can be
  overriden (matching only fsckd-cancel-msg prefix) for themes supporting 
  i18n.
  ---
   src/fsck/fsck.c   | 29 +
   src/fsckd/fsckd.c | 43 +++
   src/fsckd/fsckd.h |  5 +
   3 files changed, 69 insertions(+), 8 deletions(-)
 
  diff --git a/src/fsck/fsck.c b/src/fsck/fsck.c
  index f5dd546..0b42e3b 100644
  --- a/src/fsck/fsck.c
  +++ b/src/fsck/fsck.c
  @@ -47,6 +47,8 @@
   static bool arg_skip = false;
   static bool arg_force = false;
   static const char *arg_repair = -a;
  +static pid_t fsck_pid;
  +static bool cancel_requested = false;
 
   static void start_target(const char *target) {
   _cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
  @@ -165,6 +167,7 @@ static int process_progress(int fd) {
   ssize_t n;
   usec_t t;
   FsckProgress progress;
  +FsckdMessage fsckd_message;
 
   if (fscanf(f, %i %lu %lu %ms, pass, cur, max, 
  device) != 4)
   break;
  @@ -185,6 +188,16 @@ static int process_progress(int fd) {
   n = send(fsckd_fd, progress, sizeof(FsckProgress), 0);
   if (n  0 || (size_t) n  sizeof(FsckProgress))
   log_warning_errno(n, Cannot communicate fsck 
  progress to fsckd: %m);
  +
  +/* get fsckd requests */
  +n = recv(fsckd_fd, fsckd_message, sizeof(FsckdMessage), 
  0);
  +if (n  0) {
  +if (fsckd_message.cancel) {
  +log_warning(Request to cancel fsck from 
  fsckd);
  +cancel_requested = true;
  +kill(fsck_pid, SIGTERM);
  +}
  +}
   }
 
   return 0;
  @@ -193,7 +206,6 @@ static int process_progress(int fd) {
   int main(int argc, char *argv[]) {
   const char *cmdline[9];
   int i = 0, r = EXIT_FAILURE, q;
  -pid_t pid;
   siginfo_t status;
   _cleanup_udev_unref_ struct udev *udev = NULL;
   _cleanup_udev_device_unref_ struct udev_device *udev_device = NULL;
  @@ -321,11 +333,11 @@ int main(int argc, char *argv[]) {
   cmdline[i++] = device;
   cmdline[i++] = NULL;
 
  -pid = fork();
  -if (pid  0) {
  +fsck_pid = fork();
  +if (fsck_pid  0) {
   log_error_errno(errno, fork(): %m);
   goto finish;
  -} else if (pid == 0) {
  +} else if (fsck_pid == 0) {
   /* Child */
   if (progress_pipe[0] = 0)
   safe_close(progress_pipe[0]);
  @@ -340,7 +352,7 @@ int main(int argc, char *argv[]) {
   progress_pipe[0] = -1;
   }
 
  -q = wait_for_terminate(pid, status);
  +q = wait_for_terminate(fsck_pid, status);
   if (q  0) {
   log_error_errno(q, waitid(): %m);
   goto finish;
  @@ -348,11 +360,11 @@ int main(int argc, char *argv[]) {
 
   if (status.si_code != CLD_EXITED || (status.si_status  ~1)) {
 
  -if (status.si_code == CLD_KILLED || status.si_code == 
  CLD_DUMPED)
  +if ((!cancel_requested  status.si_code == CLD_KILLED) || 
  status.si_code == CLD_DUMPED)
   log_error(fsck terminated by signal %s., 
  signal_to_string(status.si_status));
   else if (status.si_code == CLD_EXITED)
   log_error(fsck failed with error code %i.,

Re: [systemd-devel] [PATCH 04/12] Add some plymouth functionality to connect and send, messages

On Wed, Jan 28, 2015 at 02:22:04PM +0100, Didier Roche wrote:
 

 From 7afe9270e3210668053089caaff8a1dd790a48f5 Mon Sep 17 00:00:00 2001
 From: Didier Roche didro...@ubuntu.com
 Date: Mon, 26 Jan 2015 17:07:32 +0100
 Subject: [PATCH 04/12] Add some plymouth functionality to connect and send
  messages
 
 Connect to plymouth (if running).
 Automatic reconnect if plymouth was disconnected (or respawned)
 when trying to send a subsequent message.
 ---
  Makefile.am   |  2 ++
  configure.ac  | 12 
  src/shared/plymouth.c | 83 
 +++
  src/shared/plymouth.h |  8 +
  4 files changed, 105 insertions(+)
 
 diff --git a/Makefile.am b/Makefile.am
 index 18be607..a9d61f1 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -929,10 +929,12 @@ libsystemd_shared_la_CFLAGS = \
   $(AM_CFLAGS) \
   $(CAP_CFLAGS) \
   $(SECCOMP_CFLAGS) \
 + $(PLYMOUTH_CFLAGS) \
   -pthread
  
  libsystemd_shared_la_LIBADD = \
   $(CAP_LIBS) \
 + $(PLYMOUTH_LIBS) \
   -lm
  
  # 
 --
 diff --git a/configure.ac b/configure.ac
 index 12e4ab2..62f1eef 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -857,6 +857,18 @@ fi
  AM_CONDITIONAL(HAVE_MICROHTTPD, [test $have_microhttpd = yes])
  
  # 
 --
 +have_plymouth=no
 +AC_ARG_ENABLE(plymouth, AS_HELP_STRING([--disable-plymouth], [disable 
 plymouth integration]))
 +if test x$enable_plymouth != xno; then
 +PKG_CHECK_MODULES([PLYMOUTH], [ply-boot-client = 0.8.0],
 +[AC_DEFINE(HAVE_PLYMOUTH, 1, [Define if plymouth is 
 available]) have_plymouth=yes], have_plymouth=no)
 +if test x$have_plymouth = xno -a x$enable_plymouth = xyes; then
 +AC_MSG_ERROR([*** plymouth integration requested but 
 libraries not found])
 +fi
 +fi
 +AM_CONDITIONAL(HAVE_PLYMOUTH, [test $have_plymouth = yes])
 +
 +# 
 --
  have_gnutls=no
  AC_ARG_ENABLE(gnutls, AS_HELP_STRING([--disable-gnutls], [disable gnutls 
 support]))
  if test x$enable_gnutls != xno; then
 diff --git a/src/shared/plymouth.c b/src/shared/plymouth.c
 index c4865dd..f7155c4 100644
 --- a/src/shared/plymouth.c
 +++ b/src/shared/plymouth.c
 @@ -19,13 +19,96 @@
along with systemd; If not, see http://www.gnu.org/licenses/.
  ***/
  
 +#ifdef HAVE_PLYMOUTH
 +#include ply-boot-client.h
 +#endif
 +
  #include stdbool.h
  #include stdio.h
  #include stdlib.h
  #include unistd.h
  
 +#include log.h
  #include plymouth.h
  
 +#ifdef HAVE_PLYMOUTH
 +void plymouth_disconnected (void *user_data, ply_boot_client_t *client);
 +void plymouth_update_failed(void *user_data, ply_boot_client_t *client);
 +
 +static ply_boot_client_t *plymouth_client = NULL;
 +static ply_event_loop_t *plymouth_event_loop = NULL;
 +#endif
 +
  bool plymouth_running(void) {
  return access(/run/plymouth/pid, F_OK) = 0;
  }
 +
 +#ifdef HAVE_PLYMOUTH
 +bool plymouth_connect(void) {
Is there a particular reason why this cannot return a normal int code?

 +
 +/* Keep existing connection */
 +if (plymouth_client)
 +return true;
 +
 +/* Create the event loop */
 +if (!plymouth_event_loop)
Please make this {

 +plymouth_event_loop = ply_event_loop_new();
 +
 +if (!plymouth_event_loop) {
 +log_error(Couldn't create event loop for plymouth);
 +return false;
 +}

} a subclause of the if. It looks weird otherwise.

 +
 +plymouth_client = ply_boot_client_new();
 +
 +if (!ply_boot_client_connect(plymouth_client, plymouth_disconnected, 
 NULL)) {
 +log_error(Couldn't connect to plymouth);
 +ply_boot_client_free(plymouth_client);
 +plymouth_client = NULL;
 +plymouth_event_loop = NULL;
 +return false;
 +}
 +
 +/* attach event loop after being connected to plymouth or the 
 disconnect handler won't be registered
 +   and flush all events that may exists from an older connection if 
 we are reconnected */
 +ply_boot_client_attach_to_event_loop(plymouth_client, 
 plymouth_event_loop);
 +ply_boot_client_flush(plymouth_client);
 +
 +return true;
 +}
 +
 +void plymouth_disconnect(void) {
 +if (!plymouth_client)
 + return;
 +ply_boot_client_disconnect(plymouth_client);
 +ply_boot_client_flush(plymouth_client);
 +}
 +
 +void plymouth_update(const char *message) {
 +if (!plymouth_running() || !plymouth_connect())
 +return;
 +
 +ply_boot_client_update_daemon(plymouth_client, message, NULL, NULL, 
 NULL);
 +ply_boot_client_flush(plymouth_client);
 +}
 +
 +void plymouth_delete_message(void) {
 +

Re: [systemd-devel] [PATCH 05/12] Connect and send to plymouth progress report

On Wed, Jan 28, 2015 at 02:22:30PM +0100, Didier Roche wrote:
 

 From c60d4f41e279dd5ed7134d97d95549aac1f38e69 Mon Sep 17 00:00:00 2001
 From: Didier Roche didro...@ubuntu.com
 Date: Mon, 26 Jan 2015 16:29:30 +0100
 Subject: [PATCH 05/12] Connect and send to plymouth progress report
 
 Try to connect and send to plymouth (if running) some check report progress,
 using libplymouth.
 
 Update message is the following:
 fsckd:num_devices:progress:string
 
 * num_devices corresponds to the current number of devices being checked (int)
 * progress corresponds to the current minimum percentage of all devices being
   checking (float, from 0 to 100)
checked

 * string is a translated message ready to be displayed by the plymouth theme
   displaying the information above. It can be overriden by plymouth themes
   supporting i18n.
 ---
  src/fsckd/fsckd.c | 23 ++-
  src/shared/plymouth.c | 15 +++
  src/shared/plymouth.h |  2 ++
  3 files changed, 39 insertions(+), 1 deletion(-)
 
 diff --git a/src/fsckd/fsckd.c b/src/fsckd/fsckd.c
 index e27cd6d..b516193 100644
 --- a/src/fsckd/fsckd.c
 +++ b/src/fsckd/fsckd.c
 @@ -39,6 +39,9 @@
  #include log.h
  #include list.h
  #include macro.h
 +#ifdef HAVE_PLYMOUTH
 +#include plymouth.h
 +#endif
  #include sd-daemon.h
  #include time-util.h
  #include util.h
 @@ -95,6 +98,9 @@ static int handle_requests(int socket_fd) {
  int new_client_fd = 0;
  Clients *current;
  _cleanup_free_ char *console_message = NULL;
 +#ifdef HAVE_PLYMOUTH
 +_cleanup_free_ char *fsck_message = NULL;
 +#endif
  double current_percent = 100;
  int current_numdevices = 0, m = 0;
  usec_t t;
 @@ -155,6 +161,9 @@ static int handle_requests(int socket_fd) {
  
  asprintf(console_message, Checking in progress on 
 %d disks (%3.1f%% complete),
   numdevices, percent);
 +#ifdef HAVE_PLYMOUTH
 +asprintf(fsck_message, fsckd:%d:%3.1f:%s, 
 numdevices, percent, console_message);
 +#endif
oom check.

  
  /* write to console */
  if (show_progress) {
 @@ -162,6 +171,11 @@ static int handle_requests(int socket_fd) {
  fflush(console);
  }
  
 +#ifdef HAVE_PLYMOUTH
 +/* send to plymouth */
 +plymouth_update(fsck_message);
 +#endif
 +
  if (m  clear)
  clear = m;
  }
 @@ -187,6 +201,9 @@ static int handle_requests(int socket_fd) {
  fputc('\r', console);
  fflush(console);
  }
 +#ifdef HAVE_PLYMOUTH
 +plymouth_disconnect();
 +#endif
  
  return 0;
  }
 @@ -218,7 +235,11 @@ static int create_socket(void) {
  
  static void help(void) {
  printf(%s [OPTIONS...]\n\n
 -   Capture fsck progress and forward one stream to plymouth\n\n
 +#ifdef HAVE_PLYMOUTH
 +   Capture fsck progress, log to console and forward one stream 
 to plymouth\n\n
 +#else
 +   Capture fsck progress and log to console\n\n
 +#endif
   -h --help Show this help\n
  --version  Show package version\n,
 program_invocation_short_name);
 diff --git a/src/shared/plymouth.c b/src/shared/plymouth.c
 index f7155c4..b43d355 100644
 --- a/src/shared/plymouth.c
 +++ b/src/shared/plymouth.c
 @@ -92,6 +92,21 @@ void plymouth_update(const char *message) {
  ply_boot_client_flush(plymouth_client);
  }
  
 +static void plymouth_key_pressed(void *callback, const char *pressed_key, 
 ply_boot_client_t *client) {
 +((keypress_callback)callback)();
 +}
 +
 +bool plymouth_watch_key(const char *keys, const char *message, 
 keypress_callback callback) {
 +if (!plymouth_running() || !plymouth_connect())
 +return false;
 +
 +ply_boot_client_tell_daemon_to_display_message (plymouth_client, 
 message, NULL,
 +
 plymouth_update_failed, NULL);
 +ply_boot_client_ask_daemon_to_watch_for_keystroke (plymouth_client, 
 keys, plymouth_key_pressed,
 +   NULL, callback);
 +return true;
 +}
 +
  void plymouth_delete_message(void) {
  if (!plymouth_running() || !plymouth_client)
  return;
 diff --git a/src/shared/plymouth.h b/src/shared/plymouth.h
 index 15cecb7..f5ea00c 100644
 --- a/src/shared/plymouth.h
 +++ b/src/shared/plymouth.h
 @@ -30,5 +30,7 @@ bool plymouth_connect(void);
  void plymouth_disconnect(void);
  void plymouth_update(const char *message);
  
 +typedef void (*keypress_callback)(void);
  void plymouth_delete_message(void);
 +bool plymouth_watch_key(const char

Re: [systemd-devel] [PATCH 06/12] Support cancellation of fsck in progress

On Wed, Jan 28, 2015 at 03:21:27PM +, Dimitri John Ledkov wrote:
 On 28 January 2015 at 14:53, Zbigniew Jędrzejewski-Szmek
 zbys...@in.waw.pl wrote:

  On Wed, Jan 28, 2015 at 02:22:54PM +0100, Didier Roche wrote:

   From 104cf82ba28941e907f277a713f834ceb3d909f0 Mon Sep 17 00:00:00 2001
   From: Didier Roche didro...@ubuntu.com
   Date: Mon, 26 Jan 2015 16:40:52 +0100
   Subject: [PATCH 06/12] Support cancellation of fsck in progress

   Grab in fsckd plymouth watch key for C or c, and propagate this cancel 
   request
   to systemd-fsck which will terminate fsck.
  Could we bind to ^c or if this is not possible, three c's in three
  seconds instead? I'm worried that before you could press anything to little
  effect in plymouth, and now a single key will have significant consequences.

 Hm? an interactive message with key-binding is usually shown and then
 plymouth reacts to such a key prompt.
 This is how it has always worked on plymouth prompts since forever...
 thus this would not be a surprise to most plymouth users (~ 5+ years
 by now?!)
 Doing it otherwise, will, on the contrary, impede user experience.
If you say so. I have never interacted with plymouth except to press ESC.
I'll have to give this a try.

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

Re: [systemd-devel] initializing _cleanup_* variables [was: [PATCH 01/12] fsckd daemon for inter-fsckd communication]

Hey Zbyszek,

Zbigniew Jędrzejewski-Szmek [2015-01-28 15:37 +0100]:
  +static int handle_requests(int socket_fd) {
  +Clients *first = NULL;
  +usec_t last_activity = 0;
  +int numdevices = 0, clear = 0;
  +double percent = 100;
  +_cleanup_fclose_ FILE *console = NULL;
 NULL not necessary (and you don't have it in similar circumstances above ;))

How is that not necessary? Just because the very next line initializes
it, and there is no exit path before? Because in the general case it
certainly is necessary, otherwise the _cleanup_ handler will try to
free/close/clean up a random pointer value and crash.

So IMHO it's a good defensive habit to always init _cleanup_* vars
with NULL. In the future someone might put some code with return
before the fopen() below, and then get a crash.

Or is there some gcc magic that I missed? (I thought only global
variables were guaranteed to be NULL, not stack vars).

 
  +
  +console = fopen(/dev/console, we);

Thanks for clarifying,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


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

[systemd-devel] Odp: Re: BUG: several bugs in core/main.c (v218)

2015-01-28 Thread Tomasz Pawlak

On Mon, 26.01.15 00:33, Tomasz Pawlak (tomazzi at wp.pl) wrote:

First of all, Iv'e disabled automatic replies from systemd-devel, because my 
e-mail account gets flooded with hundreds of e-mails. The side effect was, that 
I haven't been informed about this reply.

 You are right, but it's not as simple as it may look at first sight:
 
 1. If we allow the process to continue without sig handlers
 installed, then results can be just catastrophic: kernel panic with
 all the services launched - broken transanctions, half-written
 records/files, etc - total mess, corrupted or lost data etc.  So,
 since successfull installation of the sig handlers is one of the
 most critical parts of initialisation, it is actualy safer to just
 quit. This is just a critical fault (and is currently completely
 ignored).

Hmm? no. if PID 1 dies then either the kernel halts PID 1 or we do.


Well, apparently the above is not so clear as I would like it to be, so here's 
an explanation:
What You'are sayng is a systemd' point of view: no clients crashed, so 
everything is fine.
But it's not. If the init sytem fails, then also f.e. non-activated serivices 
can cause failures in client applications, but what's worse: You can't predict 
how it fails. If it'll crash the kernel, or just some part of it ( like a 
device driver ) then the results are at best unpredictable.

Therefore I say: if something such important as sigaction fails, then it should 
be treated as a sign that there's something really wrong with the system, and 
there's no point to continue, maybe excluding a try to make a log entry. 
-

 2. Another thing is, that those signals are not equivalently
 important, f.e. SIGABRT can be throwed by thousants lines of code in
 this project (by abort()), so it is much more likely that assertion
 checking will prevent segfaults, throwing SIGABRT instead. This
 means that SIGABRT is actually far more probable than SIGSEGV.  This
 in turn leads to simple solution: the process should unconditionally
 exit if hander for SIGABRT have failed to install, but with other
 sig handlers failed, we may take a risk and continue.  In any case,
 such situation should be logged as soon as possible.  Ignoring this
 is just asking for catastrophe.

The only thing you can do to recover from SIGABRT or SIGSEGV,
reexec()ing yourself from the sig handler. That' something the kernel
doesn't allow for PID 1 however...

It's illusionary to believe that you could just do some magic, and
return from SIGSEGV and continue running your program. You
cannot. SIGSEGV is more often than not an indication for a memory
corruption, and if that happens, there's no way to bring back the
memory to a state where things are good again, because memory doesn't
tell you if its in a good or bad state.

---
Yes and no.
What You say is an old school point of view.
The key problem with critical signals in classic approach is that the program 
doesn't have any valuable informations about the context in which the signal 
was triggered. (essentially because siginfo is not provideing any valuable 
informations, from the runtime point of view)
There are generally 3 kinds of segfaults: read operation, write operation and a 
failed access to protected memory (whether it is protected by MMU or by other 
means does not matter here.)

Only the segfaults caused by write ops are hard (but not impossible) to recover 
from, because such ops can damage heap data, especially the heap 
chunk/fragmentaion data, what will cause errors during further dynamic heap 
allocations.

However, when the program knows the context of the signal, then it is rather 
simple to fix this at runtime, but it needs several additional conditions to be 
fulfilled:
The program must not fail in main thread (what is only a matter of careful 
design), and all the functionality of the prog must be splitted into threads 
running with custom stacks. Then, it is possible to restart any part of the 
prog, using the fact that TLS variables are mapped to physically different 
memory areas.

Of course, this is just a quick reply, and it would need far more detailed 
explanations, but I simply have no time for this.

However, this (among some other things) is why I think that systemd's 
exceptions handling leaves much to desire - the policy is to just quit on any 
error.
---

 3. SIGFPE: how often the code uses FPU? - I mean, that handler for
 this sig can be dynamically installed/unistalled when needed,
 probably only on a thread level, not for the whole process. This
 will allow to completely safely report failed sigaction by assertion
 checking.

SIGFPE is also triggered by integer divisions by zero (yeah, the name
is misleading). 

Catching SIGFPE, SIGSEGV, SIGABRT and so on are for software problems
that we don't exptect. If we expected them then we could certainly
handle them in a nicer way than getting a signal thrown...

---
Of course You are right. As an excuse, I can say that I'm working not only with 
Linux

[systemd-devel] BUG: several bugs in core/main.c (v218)

2015-01-28 Thread Tomasz Pawlak

On Sun, 25.01.15 03:37, Tomasz Pawlak (tomazzi at wp.pl) wrote:

---
Unfortunatelly, due to my mistake this thread was splitted,
The other part is here:
http://lists.freedesktop.org/archives/systemd-devel/2015-January/027648.html

---

 core/main.c:1519
   /* Make sure we leave a core dump without panicing the
* kernel. */
   if (getpid() == 1) {
   install_crash_handler();
 
   r = mount_cgroup_controllers(arg_join_controllers);
   if (r  0)
   goto finish;
   }
 
 core/main.c:226
 static void install_crash_handler(void) {
   struct sigaction sa = {
   .sa_handler = crash,
   .sa_flags = SA_NODEFER,
   };
 
   sigaction_many(sa, SIGNALS_CRASH_HANDLER, -1);
 }
 
 /shared/util.c:2207
 int sigaction_many(const struct sigaction *sa, ...) {
   va_list ap;
   int r = 0, sig;
 
   va_start(ap, sa);
   while ((sig = va_arg(ap, int))  0)
   if (sigaction(sig, sa, NULL)  0)
   r = -errno;
   va_end(ap);
 
   return r;
 }
 
 shared/def.h:40
 #define SIGNALS_CRASH_HANDLER SIGSEGV,SIGILL,SIGFPE,SIGBUS,SIGQUIT,SIGABRT
 
 
 BUGS:
 1. Ignoring return value from sigaction_many(): all sig handlers can
 silently fail to install, thus leaving the whole process unprotected

Well, if the kernel, policy, valgrind, some arch or whatever else
disallows us to install a crash handler for one of the signals, than
we won't have one on it, but I don't think that's a problem. We do the
best we can regarding setting up crash handling and if we can't we
just proceed. I mean, if your system crashes then you are fucked
anyway - the crash handler is something to makes it slighlty less
annyoing, but essentially you are still fucked, there's no way around
it.

Hence, I think ignoring the result of sigaction_many() is really the
best thing we can do: we make the best of the situation, for a
peripheral feature.

---
I've replied in the 2nd part of this td - btw, can someone merge those parts?
---

 2. SIGSEGV should be catched by a handler running on a separate
 stack (SA_ONSTACK) - otherwise it can cause segfault itself, when
 the first SIGSEGV which triggered the handler is caused by stack
 overflow.

I'd take a patch for this, but in general: the crash handler is
nothing that is supposed to recover your system. All it does its close
all fds, fork, and coredump in the child while freezing in the
parent. That makes sure that all communication with PID 1 is severed
(so that clients talking to it don't hang), we get a clean coredump,
but the kernel doesn't oops immediately. That's really all there is to
it.

So far we never ran into stack overflow issues, hence nobody was ever
tempted to cover that case too, and set up a separate stack. In
particular since doing this without testing it is pointless...

---
Actually, when the program is a critical part of the system, than ALL sig 
handlers should use separate stack (what in fact makes the life easier) - 
that's because it's completely unpredictable, whether there's enough stack 
space to execute the handler - i.e. each sig handler can cause segfault when 
it's executed at the bottom of the stack (where top/bootom is only a matter of 
naming convention)
---

 3. SA_NODEFER makes no sense, since the handler is expected to catch
 only first critical signal. With SA_NODEFER nesting of signals is
 possible, what can cause unpredictable results, including uncatched
 stack overflow caused by the handler itself.

We set SA_NODEFER so that the signal handler can raise the signal
again in the child process so that we get clean coredump for the logs.

Anyway, given that this all is not obvious to see from the sources I
have now added a couple of comments there.

---
The only effect of SA_NODEFER is that sig mask is not automatically set for a 
signal which triggered the handler.
This means nesting of signals, as the handler can be interrupted and another 
instance is started for a new signal context.  (and sig handlers are not 
signal-safe with SA_NODEFER, what means that they have to be fully re-entrant)
This also means, that there's completely no warranty that the handler won't be 
interrupted with external signal - mess.
---

Lennart


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

[systemd-devel] [PATCH] hwdb: add a touchpad hwdb

2015-01-28 Thread Peter Hutterer

Currently used to tag devices in the new Lenovo *50 series and the X1 Carbon
3rd. These laptops re-introduced the physical trackpoint buttons that were
missing from the *40 series but those buttons are now wired up to the
touchpad.

The touchpad now sends BTN_0, BTN_1 and BTN_2 for the trackpoint. The same
button codes were used in older touchpads that had dedicated scroll up/down
buttons. Input drivers need to work around this and thus know what they're
dealing with.

For the previous gen we introduced INPUT_PROP_TOPBUTTONPAD in the kernel, but
the resulting mess showed that these per-device quirks should really live in
userspace.

The list currently includes the X1 Carbon 3rd PNPID, others will be added as
get to know which PNPID they have.
---
 Makefile.am |  4 +++-
 hwdb/70-touchpad.hwdb   | 39 +++
 rules/70-touchpad.rules | 12 
 3 files changed, 54 insertions(+), 1 deletion(-)
 create mode 100644 hwdb/70-touchpad.hwdb
 create mode 100644 rules/70-touchpad.rules

diff --git a/Makefile.am b/Makefile.am
index 80c4161..e3ba11c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3560,6 +3560,7 @@ dist_udevrules_DATA += \
rules/60-persistent-storage.rules \
rules/64-btrfs.rules \
rules/70-mouse.rules \
+   rules/70-touchpad.rules \
rules/75-net-description.rules \
rules/75-tty-description.rules \
rules/78-sound-card.rules \
@@ -3751,7 +3752,8 @@ dist_udevhwdb_DATA = \
hwdb/20-OUI.hwdb \
hwdb/20-net-ifname.hwdb \
hwdb/60-keyboard.hwdb \
-   hwdb/70-mouse.hwdb
+   hwdb/70-mouse.hwdb \
+   hwdb/70-touchpad.hwdb
 
 EXTRA_DIST += \
units/systemd-hwdb-update.service.in
diff --git a/hwdb/70-touchpad.hwdb b/hwdb/70-touchpad.hwdb
new file mode 100644
index 000..bbf44db
--- /dev/null
+++ b/hwdb/70-touchpad.hwdb
@@ -0,0 +1,39 @@
+# This file is part of systemd.
+#
+# The lookup keys are composed in:
+#   70-touchpad.rules
+#
+# Note: The format of the touchpad: prefix match key is a
+# contract between the rules file and the hardware data, it might
+# change in later revisions to support more or better matches, it
+# is not necessarily expected to be a stable ABI.
+#
+# Match string format:
+# touchpad:pnpid:pnpid:
+#
+# To add local entries, create a new file
+#   /etc/udev/hwdb.d/71-touchpad-local.hwdb
+# and add your rules there. To load the new rules execute (as root):
+#   udevadm hwdb --update
+#   udevadm trigger /dev/input/eventXX
+# where /dev/input/eventXX is the touchpad in question. If in
+# doubt, simply use /dev/input/event* to reload all input rules.
+#
+# If your changes are generally applicable, open a bug report on
+#   http://bugs.freedesktop.org/enter_bug.cgi?product=systemd
+# and include your new rules, a description of the device, and the
+# output of
+#   udevadm info /dev/input/eventXX
+# (or /dev/input/event*).
+#
+# Allowed properties are:
+#TOUCHPAD_HAS_TRACKPOINT_BUTTONS=1
+#
+# If the TOUCHPAD_HAS_TRACKPOINT_BUTTONS property is set, this
+# device has the trackpoint buttons wired up to the touchpad as
+# BTN_0, BTN_1 and BTN_2. This affects the Lenovo X1 Carbon 3rd
+# and the *50 series (T450, T550, etc.)
+
+# Lenovo X1 Carbon 3rd
+touchpad:pnpid:*LEN0048*:
+ TOUCHPAD_HAS_TRACKPOINT_BUTTONS=1
diff --git a/rules/70-touchpad.rules b/rules/70-touchpad.rules
new file mode 100644
index 000..88e6fd2
--- /dev/null
+++ b/rules/70-touchpad.rules
@@ -0,0 +1,12 @@
+# do not edit this file, it will be overwritten on update
+
+ACTION==remove, GOTO=touchpad_end
+KERNEL!=event*, GOTO=touchpad_end
+ENV{ID_INPUT_TOUCHPAD}==, GOTO=touchpad_end
+
+# touchpad:pnpid:pnpid:*
+KERNELS==serio1, \
+IMPORT{builtin}=hwdb 'touchpad:pnpid:$attr{firmware_id}:', \
+GOTO=touchpad_end
+
+LABEL=touchpad_end
-- 
2.1.0

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

Re: [systemd-devel] systemd networking : problems with bridges

2015-01-28 Thread Charles Devereaux

Will do!

On Wed, Jan 28, 2015 at 9:41 PM, Lennart Poettering lenn...@poettering.net
wrote:

 On Sun, 11.01.15 18:18, Charles Devereaux (syst...@guylhem.net) wrote:

  What about another option in networkd-wait-online-link.c to pass an
  ignore parameter, along with a list of interfaces names, so that
  link_relevant does: something like:
 
  if (l-flags  IFF_LOOPBACK)
  return false;
 
  if (STR_IN_SET(l-ifname, arg_ignore)) {
  return false;
 
  At the moment, my dirty workaround is to have br0 hardcoded  in
  manager_all_configured from src/network/networkd-wait-online-manager.c:
 
  if (!link_relevant(l) || STR_IN_SET(l-ifname, br0)) {

 I think such a patch that introduces --ignore-interface= or so would
 make sense. If you prep a good patch we can merge this.

 I'd probably even go one step further with this, and make this a glob,
 so that once can easily ignore whole sets of interfaces...

 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] BUG: several bugs in core/main.c (v218)

On Tue, Jan 27, 2015 at 01:57:58AM +0100, Lennart Poettering wrote:
 On Mon, 26.01.15 23:45, Tomasz Pawlak (toma...@wp.pl) wrote:
 
   Actually it *is* protected, see kill(2). Signals are ignored for PID 1
   unless it installed handlers for them. Nevertheless, we probably want to
   abort on SIGSEGV and similar and not continue, so we shouldn't ever run
   without the handlers installed.
  
  Actually this is not what kill(2) says: it says that indeed, the
  signals are not delivered to PID1 to prevent accidential
  termination. This however *does not* mean that You are allowed to
  ignore the signals, because by doing so You can run the process into
  undefined state.
 
 We are not ignoring them, we just let the kernel deal with them for
 us, instead of doing so on our own. The kernel will OOPS the kernel
 when init does abnormally.
Ah, OK. So the kernel simply kills PID1 on a fatal signal. I thought
that it would let the process continue, which sounds bizarre, now that
I think about it.

 And that's actually pretty OK behaviour in
 that case. Of course, it would be slightly better if not the whole
 system would crash, but only PID 1 like we can do it with the crash
 handler, but either way you have to reboot anyway to get back to a
 working system.
Agreed. Nothing to fix here.

Zbyszek

   We shouldn't really ever fail to install the handlers, so this is a
   rather academic exercise. I guess we can add an assert_se() around
   it.
 
  This very bad and dangerus assumption, as the sigaction may fail due
  to various reasons, like wrong/malformed args, internal kernel
  problems or just random memory faults (which are very unlikely in
  ECC RAM, but not so unlikely on customer grade hardware or on
  embedded systems).  No ofense, but the discussion is indeed becoming
  academic when You are trying to prove that it's not necessary to
  check return value from a call to external function which has
  defined error codes.
  
  Systemd is is not just another user space application - it is going
  to be one of the most important parts of the system - so please -
  such excuses should not even appear in this mailing list.
 
 Well, we are pretty careful usually when it comes to checking return
 values. But this case is simply one of those cases where you can only
 choose between:
 
 a) if you cannot install the crash handler, continue and the let the
kernel do its normal crash handling.
 
 b) if you cannot install the crash handler, abort immediately.
 
 I fail to see how b) would be that much better than a) here. It just
 replaces one way to die with another way to die. Sure, our crash
 handling way to die is nicer than the kernel's own, but allowing the
 system to boot up in the first place, is certainly even nicer!
 
 Lennart
 
 -- 
 Lennart Poettering, Red Hat
 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [systemd-commits] 2 commits - src/journal src/shared

On Wed, Jan 28, 2015 at 05:48:01PM -0800, Lennart Poettering wrote:
 Revert journal: do not check for number of files
 
 This reverts commit b914ea8d379b446c4c9fac4ba181771676ef38cd.
 
 We really need to put a limit on all our resources, everywhere, and in
 particular if we operate on external data.
 
 Hence, let's reintroduce the limit, but bump it substantially, so that
 it is guaranteed to be higher than any realistic RLIMIT_NOFILE setting.
Hm, each journal file requires a descriptor. How could we open more
than RLIMIT_NOFILE files?

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

Re: [systemd-devel] [PATCH] hwdb: add a touchpad hwdb

2015-01-28 Thread Peter Hutterer

On Thu, Jan 29, 2015 at 03:04:29AM +0100, Lennart Poettering wrote:
 On Thu, 29.01.15 11:58, Peter Hutterer (peter.hutte...@who-t.net) wrote:
 
  Currently used to tag devices in the new Lenovo *50 series and the X1 Carbon
  3rd. These laptops re-introduced the physical trackpoint buttons that were
  missing from the *40 series but those buttons are now wired up to the
  touchpad.
  
  The touchpad now sends BTN_0, BTN_1 and BTN_2 for the trackpoint. The same
  button codes were used in older touchpads that had dedicated scroll up/down
  buttons. Input drivers need to work around this and thus know what they're
  dealing with.
  
  For the previous gen we introduced INPUT_PROP_TOPBUTTONPAD in the kernel, 
  but
  the resulting mess showed that these per-device quirks should really live in
  userspace.
  
  The list currently includes the X1 Carbon 3rd PNPID, others will be added as
  get to know which PNPID they have.
 
 Looks fine to me. Go ahead, commit!
 
well, that was fast. Thanks. Pushed 
  3e495a6..001a247  master - master

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

Re: [systemd-devel] systemd networking : problems with bridges

On Sun, 11.01.15 18:18, Charles Devereaux (syst...@guylhem.net) wrote:

 What about another option in networkd-wait-online-link.c to pass an
 ignore parameter, along with a list of interfaces names, so that
 link_relevant does: something like:
 
 if (l-flags  IFF_LOOPBACK)
 return false;
 
 if (STR_IN_SET(l-ifname, arg_ignore)) {
 return false;
 
 At the moment, my dirty workaround is to have br0 hardcoded  in
 manager_all_configured from src/network/networkd-wait-online-manager.c:
 
 if (!link_relevant(l) || STR_IN_SET(l-ifname, br0)) {

I think such a patch that introduces --ignore-interface= or so would
make sense. If you prep a good patch we can merge this.

I'd probably even go one step further with this, and make this a glob,
so that once can easily ignore whole sets of interfaces...

Lennart

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

Re: [systemd-devel] [systemd-commits] 2 commits - src/journal src/shared

On Thu, 29.01.15 03:22, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

 On Wed, Jan 28, 2015 at 05:48:01PM -0800, Lennart Poettering wrote:
  Revert journal: do not check for number of files
  
  This reverts commit b914ea8d379b446c4c9fac4ba181771676ef38cd.
  
  We really need to put a limit on all our resources, everywhere, and in
  particular if we operate on external data.
  
  Hence, let's reintroduce the limit, but bump it substantially, so that
  it is guaranteed to be higher than any realistic RLIMIT_NOFILE setting.
 Hm, each journal file requires a descriptor. How could we open more
 than RLIMIT_NOFILE files?

Hmm, I see what you mean. You are right, the fact that fds are
limited, means JournalFile objects in an sd_journal are implicitly
limited too.

I think we should still leave this in though, in case people set
RLIMIT_NOFILE to 65K. We should be careful to grow the number of
journal files to read without bounds since most operations scale with
O(n) then...

Also, one thing I still want to do is that we track more journal files
than we have open, and encode enough information in the journal file
name so that we can skip over them without having to open them for
many operations. For example: if we look at the most recent log
entries, and we find journal files whose name already indicates that
they only contain really old data it's not worth opening them at all,
and we don't have to pay the price of O(n). In this case we'd have
more JournalFile objects than actual open fds. In that case we however
should still put a limit on the JournalFile objects we allocate. 

Anyway, that code doesn't exist yet of course, so it's mostly a
made-up reason...

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] Cannot use systemctl after heavy swapping

On Wed, 07.01.15 07:59, Alan Fisher (a...@unixcube.org) wrote:

 Hello!
 
 I seem to have reproduced this issue. After a lot of swapping, systemd
 appeared to have become stuck. Trying to restart services with systemctl
 blocked indefinitely. Strangely, this seemed to be the case even after a
 reboot.
 
 Here is a part of the strace -p 1
 
 recvmsg(16, 0x7fff52622560, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) =
 -1EAGAIN(Resourcetemporarily unavailable) epoll_wait(4, {{EPOLLOUT,
 {u32=3793072544, u64=140341849469344}}}, 29, 0) =
 1clock_gettime(CLOCK_BOOTTIME, {863156, 624419539}) = 0recvmsg(16,
 0x7fff52622560, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) =
 -1EAGAIN(Resourcetemporarily unavailable) epoll_wait(4, {{EPOLLOUT,
 {u32=3793072544, u64=140341849469344}}}, 29, 0) =
 1clock_gettime(CLOCK_BOOTTIME, {863156, 624668458}) = 0recvmsg(16,
 0x7fff52622560, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) =
 -1EAGAIN(Resourcetemporarily unavailable) epoll_wait(4, {{EPOLLOUT,
 {u32=3793072544, u64=140341849469344}}}, 29, 0) =
 1clock_gettime(CLOCK_BOOTTIME, {863156, 624919333}) = 0recvmsg(16,
 0x7fff52622560, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) =
 -1EAGAIN(Resourcetemporarily unavailable) epoll_wait(4, {{EPOLLOUT,
 {u32=3793072544, u64=140341849469344}}}, 29, 0) =
 1clock_gettime(CLOCK_BOOTTIME, {863156, 625167344}) = 0recvmsg(16,
 0x7fff52622560, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) =
 -1EAGAIN(Resourcetemporarily unavailable) epoll_wait(4, {{EPOLLOUT,
 {u32=3793072544, u64=140341849469344}}}, 29, 0) =
 1clock_gettime(CLOCK_BOOTTIME, {863156, 625417381}) = 0recvmsg(16,
 0x7fff52622560, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) =
 -1EAGAIN(Resourcetemporarily unavailable) epoll_wait(4, {{EPOLLOUT,
 {u32=3793072544, u64=140341849469344}}}, 29, 0) =
 1clock_gettime(CLOCK_BOOTTIME, {863156, 625665881}) = 0
 
 systemd --version prints
 
 systemd 215
 +PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP
 -APPARMOR
 
 After a second reboot, the problem seems to have disappeared.

Sorry for the late reply!

Hmm, this looks like an EAGAIN busy loop in PID 1, three questions:

a) That fd 16, do you have any idea what this is? What does
   /proc/1/fd/ say about it? If this is a socket, can you check with
   lsof with which peer it is talking?

b) any chance you can run pstack 1 when this happens to get a stack
   trace out of PID 1?

c) any chance you can reproduce the issue with a more current systemd version?

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] logind: support of shared devices

On Wed, 07.01.15 22:45, Oleg Samarin (osamari...@gmail.com) wrote:

   After adding the simple udev rule:
  
   --
   KERNEL==seq, SUBSYSTEM==sound, TAG+=shared
   --
  
   /dev/snd/seq becomes accessible from all seats.
  
   Could you resolve this patch upstream or propose another way of granting
   access to /dev/snd/seq on activating sessions?
  
  Why not remove the uaccess TAG from the device and set your own
  permissions? Like:
  
  TAG-=uaccess, MODE=whatever, GROUP=something
  
  This way, logind will never touch the device and your statically set
  access-rules will be applied. If you now set the group to your
  user-group, only your user will have access to the device, regardless
  of the seat it's on.
 
 1. uaccess tag is added by another udev rule, and I do not know, what
 will happen if there are two rules in contradiction
 2. By default /dev/seq/snd belongs to the audio group. Changing it may
 be unsafe fore some applcations.
 3. Static access rules do not regard on whether the session is active or
 not. I want that the access would be granted only to users that have
 active sessions.

Hmm, I am not sure if we should support shared device access for
things like the sequencer. I mean, is thta device even capable of
being shared, and wouldn't two users which have access at the same
time step on each other's toes all the time, and could get access to
stuff they shouldn't be getting?

uaccess is really about trying to make access to harware (slightly,
but well) more secure than with static groups. However, I am not sure
that parallel access to the same device by two users would really be
more secure?

And if this isn't any more secure anyway, maybe it would be OK to just
add your user to the audio group and get unrestricted access to the
device? The group exists precisely for cases like this: as a way how
the admin can grant certain users access to a device without that
being bound to any session magic...

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] hwdb: add a touchpad hwdb

On Thu, 29.01.15 11:58, Peter Hutterer (peter.hutte...@who-t.net) wrote:

 Currently used to tag devices in the new Lenovo *50 series and the X1 Carbon
 3rd. These laptops re-introduced the physical trackpoint buttons that were
 missing from the *40 series but those buttons are now wired up to the
 touchpad.
 
 The touchpad now sends BTN_0, BTN_1 and BTN_2 for the trackpoint. The same
 button codes were used in older touchpads that had dedicated scroll up/down
 buttons. Input drivers need to work around this and thus know what they're
 dealing with.
 
 For the previous gen we introduced INPUT_PROP_TOPBUTTONPAD in the kernel, but
 the resulting mess showed that these per-device quirks should really live in
 userspace.
 
 The list currently includes the X1 Carbon 3rd PNPID, others will be added as
 get to know which PNPID they have.

Looks fine to me. Go ahead, commit!

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] journal verify problem

On Thu, 08.01.15 14:18, Michał Zegan (webczat_...@poczta.onet.pl) wrote:

 Hello, I am running archlinux with systemd 218.
 My journal is sealed.
 But, when I try to verify it giving a verification key, then when user
 journals are verified, I always get the error bad message.
 This happens only for user journals, system journal verifies correctly.
 To clarify, I currently have more than one user and all journals fail
 verification except the system one. I am not sure what will happen if
 the system one rotates.

What's the precise message you get?

Note that the final parts of live journal files can usually not be verified
via the sealing logic, since there's not seal behind them yet. Each
seal can only be used to validate the bits before it, and hence, while
new entries are appended, these entries cannot be validated until the
next seal is written.

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] Relative links in tmpfiles.d/etc.conf

On Sat, 03.01.15 12:07, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

 Hi,
 
 Our /etc is a sym link and due to that all the links created by
 tmpfiles.d/etc.conf are wrong. Is there a reason why the links are
 relative?
 
 I would like to send a patch to either:
 a) Convert the relative links to absolute ones.
 b) Follow the sym link before creating the relative one.

I think it is quite beneficial of symlinks stay relative on disk, so
that when we look at a container image in subdirectory the symlinks
point to the correct files.

Maybe /etc can be made a bind mount in your setup?

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] BUG: several bugs in core/main.c (v218)

On Thu, Jan 29, 2015 at 12:17:08AM +0100, Tomasz Pawlak wrote:
 On Sun, 25.01.15 03:37, Tomasz Pawlak (tomazzi at wp.pl) wrote:
 ---
 I've replied in the 2nd part of this td - btw, can someone merge those parts?

That ship has already sailed. Your client did not set In-reply-to.

BTW., could you use standard quoting, the thing with arrows is very
unreadable.

 ---
 
  2. SIGSEGV should be catched by a handler running on a separate
  stack (SA_ONSTACK) - otherwise it can cause segfault itself, when
  the first SIGSEGV which triggered the handler is caused by stack
  overflow.
 
 I'd take a patch for this, but in general: the crash handler is
 nothing that is supposed to recover your system. All it does its close
 all fds, fork, and coredump in the child while freezing in the
 parent. That makes sure that all communication with PID 1 is severed
 (so that clients talking to it don't hang), we get a clean coredump,
 but the kernel doesn't oops immediately. That's really all there is to
 it.
 
 So far we never ran into stack overflow issues, hence nobody was ever
 tempted to cover that case too, and set up a separate stack. In
 particular since doing this without testing it is pointless...
 
 ---
 Actually, when the program is a critical part of the system, than ALL sig 
 handlers should use separate stack (what in fact makes the life easier) - 
 that's because it's completely unpredictable, whether there's enough stack 
 space to execute the handler - i.e. each sig handler can cause segfault when 
 it's executed at the bottom of the stack (where top/bootom is only a matter 
 of naming convention)

IIUC, you are saying that we could trigger for example a FPE, and
then exhaust all the memory in the signal handler. Nah, we can ignore
this possibility.

 The only effect of SA_NODEFER is that sig mask is not automatically set for a 
 signal which triggered the handler.
 This means nesting of signals, as the handler can be interrupted and another 
 instance is started for a new signal context.  (and sig handlers are not 
 signal-safe with SA_NODEFER, what means that they have to be fully re-entrant)
 This also means, that there's completely no warranty that the handler won't 
 be interrupted with external signal - mess.

Not really. systemd is single-threaded, so a signal could come only from two 
places:
the signal handler could cause a fault, or it could be delivered from another 
program.
The first is unlikely, stack handlers do a tiny amount of work, and the second 
is OK,
because killing PID 1 is only allowed for privileged processes, and if someone 
can
send arbitrary signals to PID 1, they can cause a failure in other ways.

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

Re: [systemd-devel] [TOOL] Check-undocumented arguments and bash autocompletions

On Sun, Jan 11, 2015 at 09:46:47PM +0100, Carlos Morata Castillo wrote:
 Hi,
 
 I've updated the tool today to work with verbs and some cache issues.
Sorry for the delayed reply. This seems useful, to catch regressions,
and to see how much stuff is still undocumented.

 ./check-undocumented.sh -p hostnamectl
 Not standar hostnamectl.Update please.
 Updates needed in ../shell-completion/bash/hostnamectl
 ...Option not found: --machine
 ...Verb not found: set-location
It would be nice to turn this into a makefile target, like other tools...

 --
 #!/bin/bash 
 #  This file is part of systemd.
 #
 #  Copyright 2015 Carlos Morata Castillo cmc...@inlumine.ual.es
 #
 #  systemd is free software; you can redistribute it and/or modify it
 #  under the terms of the GNU Lesser General Public License as published by
 #  the Free Software Foundation; either version 2.1 of the License, or
 #  (at your option) any later version.
 #
 #  systemd is distributed in the hope that it will be useful, but
 #  WITHOUT ANY WARRANTY; without even the implied warranty of
 #  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
 #  Lesser General Public License for more details.
 #
 #  You should have received a copy of the GNU Lesser General Public License
 #  along with systemd; If not, see http://www.gnu.org/licenses/.
 
 #
 # Parse command line commands options and search for undocumented
 # options/commands in his manpage and bash autocompletion
 
 #Version 0.1 Parse manpages and bash autocompletion options
 #Version 0.2 Parse manpages and bash autocompletion verbs/commands
 
 __version=0.2
 MANPAGES=../man
 BASH_AUTO=../shell-completion/bash
 
 function get_systemd_commands(){
 local regex
 regex='(root)?bin_PROGRAMS[[:space:]]?(\+?)=(.*)'
This should be supplied by make as commandline args, see dist-check-help
in Makefile.am.

 
 grep -E $regex ../Makefile.am -A 20 | while read a; do 
 [[ $a =~ $regex ]]  echo ${BASH_REMATCH[3]}
 done
 }
 
 function get_options(){
 local com args arg value
 com=$1
 [[ ! $com ]]  return
 hash $com 2/dev/null || return 0
 
 args=($($com -h))
 for arg in $(seq 0 $((${#args[@]}-1))); 
 do
 value=${args[arg]}
 if [[ $value == -* ]]; then
 echo $value
 fi
 done
 }

Hm, maybe simply use sed -n '//p' (or whatever the syntax is to
just print the matching pattern. We use sed during build, and it would
be more readable than the bash stuff.

 
 function get_verbs(){
 local com regex_commands regex_verbs line arr found
 com=$1 -h
 regex_commands='^(.*)Commands:$'
 regex_verbs='^([[:space:]]){1,2}([-[:alnum:]])(.*)'; 
 
 while IFS= read -r line
 do
 [[ $line =~ $regex_commands ]]  found=1  continue
 if [[ $found ]]; 
 then
 if [[ $line =~ $regex_verbs ]]; 
 then
 arr=(${line//[[:space:]]/ })
 echo ${arr[0]}
 fi
 fi
 done  ($com)
 }
 
 function filter(){
 local value ret
 value=$1
 ret=true
 
 #Shall it leave out -M and -H or not?
 [[ $value = -h || $value = --help 
 || $value = -M || $value = -H 
 || $value = --version ]] 
 ret=false
 echo $ret
 }
That's a good question. It would be nice to process xml files after
processing xincludes, similarly to the python filters we have. So
this leads me to ask, whether it wouldn't be better to write this
as a python program... Might be way shorter in effect.

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

[systemd-devel] [PATCH] fs: switch to d_splice_alias()

2015-01-28 Thread Bryan Hundven

During the 3.19 merge window, two commits in Linus's tree:
b5ae6b15bd73e35b129408755a0804287a87e041
=
merge d_materialise_unique() into d_splice_alias()
=
and
41d28bca2da4bd75a8915c1ccf2cacf7f4a2e531
=
switch d_materialise_unique() users to d_splice_alias()
=

...requires us to switch to d_splice_alias().

Signed-off-by: Bryan Hundven bryanhund...@gmail.com
---
 fs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs.c b/fs.c
index 7fc5ede..33aff4b 100644
--- a/fs.c
+++ b/fs.c
@@ -175,7 +175,7 @@ static struct dentry *fs_dir_iop_lookup(struct inode *dir,
if (IS_ERR(inode))
dnew = ERR_CAST(inode);
else
-   dnew = d_materialise_unique(dentry, inode);
+   dnew = d_splice_alias(inode, dentry);
 
kdbus_node_release(node);
}
-- 
2.2.2

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

Re: [systemd-devel] Autocompletion by default in containers and typo on systemctl.in

On Sat, Jan 10, 2015 at 01:29:11AM +0100, Carlos Morata Castillo wrote:
 Hi,
 
 1- It'll be nice if when you nspawn a container it'll have
 autocompletion enabled by default.
 
 Just need to execute this line:
 . /usr/share/bash-completion/bash_completion
 
 
 (This file is /usr/share/bash-completion/bash_completion/systemctl by
 default in bash-completion)

There's no guarantee that the container has the same (or even similar)
shell, systemd version, etc. Why do you think completions shouldn't
happen through the normal process where stuff is installed into the
container if it so be used there?

 2- Rename shell-completion/bash/systemctl.in to systemctl in repo and
 update Makefile.am properly.
systemctl.in is converted to systemctl by substituting directory names
in it. Just renaming it is not enough.

Zbyszek

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

Re: [systemd-devel] [PATCH 1/2] systemd-helpers

On Sat, Jan 10, 2015 at 01:33:05PM +0100, Carlos Morata Castillo wrote:
 Hi,
 
 As stated here, we should use a library for bash autocompletions (maybe even 
 with include guards).
 http://cgit.freedesktop.org/systemd/systemd/commit/shell-completion/bash/localectl?id=a72d698d0d9ff9c158155b44cdc77376df31a317
 
 Explanation:
 
 Using autotools make the autocompletions to 
 /usr/share/bash-completions/completions (as the exit from pkg-config 
 --variable=completionsdir
 bash-completion).
 We ended up having multiple function definitions and even messing around with 
 the global bash function namespace, as the functions are called
 __get_something being possible to redefine other binary bash function. 
 
 With this patch:
 1- All the files in bash completions, except busctl and systemctl.in, use 
 this common library.
 2- They are prefixed with the namespace __systemdh.

The diffstat looks nice. But the inclusion of the library file needs
to be fixed. Two possibilites:

1. m4 macros at compile time
2. include the library file using the full absolute path (specified as 
@VARIABLE@),
   and also substitute this at compile time. I think this might be a nicer 
option,
   since m4 messes with the syntax too much.

   See how systemctl.in defines the path to /usr/lib/systmed/systemd.

Zbyszek

 ---
  shell-completion/bash/bootctl | 12 ++---
  shell-completion/bash/coredumpctl | 21 
  shell-completion/bash/hostnamectl | 14 ++
  shell-completion/bash/journalctl  | 10 ++--
  shell-completion/bash/localectl   | 18 +++
  shell-completion/bash/loginctl| 36 ++
  shell-completion/bash/machinectl  | 26 --
  shell-completion/bash/systemd-analyze | 31 
  shell-completion/bash/systemd-cat | 10 ++--
  shell-completion/bash/systemd-cgls| 17 ++-
  shell-completion/bash/systemd-cgtop   |  8 +--
  shell-completion/bash/systemd-delta   | 10 ++--
  shell-completion/bash/systemd-detect-virt |  8 +--
  shell-completion/bash/systemd-helpers | 83 
 +++
  shell-completion/bash/systemd-nspawn  | 43 +++-
  shell-completion/bash/systemd-run | 60 ++
  shell-completion/bash/timedatectl | 18 +++
  shell-completion/bash/udevadm | 20 +++-
  Makefile.am   | 1 +
  19 files changed, 206 insertions(+), 240 deletions(-)
  create mode 100644 shell-completion/bash/systemd-helpers
 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] root= ignored

2015-01-28 Thread Chris Murphy

On Wed, Jan 28, 2015 at 1:19 AM, Felix Miata mrma...@earthlink.net wrote:
 Chris Murphy composed on 2015-01-27 23:29 (UTC-0700):

 Felix Miata wrote:

 Lennart Poettering composed on 2015-01-28 02:03 (UTC+0100):

 Hmm, Fedora doesn't obey root=? That sounds like a bug.

 I'm not sure what it means, Fedora doesn't obey root=. Since a long
 time it uses root=UUID= and this has worked for me.

 All current distros whose bootloaders I've used include a root= in each of
 their bootloader stanzas. AFAIK, root=UUID= is used in Fedora's Grub2
 stanzas.

That's true unless LVM is being used, which happens to be the default,
in which case it's root=VG/LV.

 When Fedora is the source and clone, attempting boot of clone using default
 initrd produces an emergency shell, unlike openSUSE.

I'm unable to reproduce this problem on a BIOS system. Old volume is
Btrfs, new volumes is Btrfs (new volume UUID), and I just copy the
files from old to new (I actually used btrfs send receive). I of
course had to install a new bootloader with grub2-install, and create
a new grub.cfg with grub2-mkconfig in order for the correct new volume
root=UUID= to be set. And I also had to edit the fstab on the new
volume so that the right UUIDs are called for there too. The resulting
system boots fine.

However, on UEFI that's not the case, I get dropped to a dracut shell:

[  188.409072] f21s2.localdomain dracut-initqueue[263]: Warning:
/dev/disk/by-uuid/083A-7E6C does not exist

That UUID is for the old FAT32 EFI System Partition. Somehow dracut is
baking in the EFI System partition UUID into the initramfs, instead of
honoring the correct one that I put into fstab. As a result boot fails
and will always fail until I rebuild the initramfs. So I'd definitely
consider that a bug.

https://bugzilla.redhat.com/show_bug.cgi?id=1187007


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

Re: [systemd-devel] [PATCH] Updates in bash autocompletions

On Sat, Jan 10, 2015 at 02:08:21AM +0100, Carlos Morata Castillo wrote:
 Hi,
 
 I did ./check-undocumented.sh -b (my script just submitted) and checked
 the results.
 
 
 Cheers.

 
 ---
  shell-completion/bash/coredumpctl |  2 +-
  shell-completion/bash/hostnamectl |  2 +-
  shell-completion/bash/journalctl  | 11 ++-
  shell-completion/bash/localectl   |  2 +-
  shell-completion/bash/loginctl|  7 ---
  shell-completion/bash/systemd-analyze |  2 +-
  shell-completion/bash/systemd-cgtop   |  3 ++-
  shell-completion/bash/timedatectl |  2 +-
  8 files changed, 17 insertions(+), 14 deletions(-)
 
 diff --git a/shell-completion/bash/coredumpctl 
 b/shell-completion/bash/coredumpctl
 index e23152d..6091677 100644
 --- a/shell-completion/bash/coredumpctl
 +++ b/shell-completion/bash/coredumpctl
 @@ -37,7 +37,7 @@ __journal_fields=(MESSAGE{,_ID} PRIORITY 
 CODE_{FILE,LINE,FUNC}
  _coredumpctl() {
  local i verb comps
  local cur=${COMP_WORDS[COMP_CWORD]} prev=${COMP_WORDS[COMP_CWORD-1]}
 -local OPTS='-h --help --version --no-pager --no-legend -o --output 
 -F --field'
 +local OPTS='-h --help --version --no-pager --no-legend -o --output 
 -F --field -1'
  
  local -A VERBS=(
  [LIST]='list'
 diff --git a/shell-completion/bash/hostnamectl 
 b/shell-completion/bash/hostnamectl
 index 7a0850d..9ad52e0 100644
 --- a/shell-completion/bash/hostnamectl
 +++ b/shell-completion/bash/hostnamectl
 @@ -28,7 +28,7 @@ _hostnamectl() {
  local i verb comps
  local cur=${COMP_WORDS[COMP_CWORD]} prev=${COMP_WORDS[COMP_CWORD-1]}
  local OPTS='-h --help --version --transient --static --pretty
 ---no-ask-password -H --host'
 +--no-ask-password -H --host --machine'
Hm, this needs more work, since --machine should complete to an arg.

  
  if [[ $cur = -* ]]; then
  COMPREPLY=( $(compgen -W '${OPTS[*]}' -- $cur) )
 diff --git a/shell-completion/bash/journalctl 
 b/shell-completion/bash/journalctl
 index 14dcd22..57b4591 100644
 --- a/shell-completion/bash/journalctl
 +++ b/shell-completion/bash/journalctl
 @@ -44,14 +44,15 @@ _journalctl() {
--disk-usage -f --follow --header
-h --help -l --local --new-id128 -m --merge 
 --no-pager
--no-tail -q --quiet --setup-keys --this-boot 
 --verify
 -  --version --list-catalog --update-catalog 
 --list-boots'
 +  --version --list-catalog --update-catalog 
 --list-boots --show-cursor
 +  --dmesg -k --pager-end -e -r --reverse --utc 
 -x --catalog --no-full --force --dump-catalog --flush'
 [ARG]='-b --boot --this-boot -D --directory --file -F 
 --field
 -  -o --output -u --unit --user-unit -p 
 --priority'
 -[ARGUNKNOWN]='-c --cursor --interval -n --lines --since 
 --until
 -  --verify-key'
 +  -o --output -u --unit --user-unit -p 
 --priority --machine 
 +-c --cursor --interval -n --lines --since --until 
 --after-cursor 
 +--verify-key --identifier --root'
The split between ARG and ARGUNKNOWN was there for a reason. For the
latter we cannot provide completions. This is a kind of internal
documentation, please do not remove this.

Also, you patch adds whitespace at the end of lines here.
If you run ./autogen.sh, it'll install a git hook which will tell you about
such issues.

I applied the patch with some small tweaks.

  )
  
 -if __contains_word $prev ${OPTS[ARG]} ${OPTS[ARGUNKNOWN]}; then
 +if __contains_word $prev ${OPTS[ARG]}; then
  case $prev in
  --boot|--this-boot|-b)
  comps=$(journalctl -F '_BOOT_ID' 2/dev/null)
 diff --git a/shell-completion/bash/localectl b/shell-completion/bash/localectl
 index c9e22af..e0c06a7 100644
 --- a/shell-completion/bash/localectl
 +++ b/shell-completion/bash/localectl
 @@ -34,7 +34,7 @@ _localectl() {
  local i verb comps locale_vals
  local cur=${COMP_WORDS[COMP_CWORD]} prev=${COMP_WORDS[COMP_CWORD-1]}
  local OPTS='-h --help --version --no-convert --no-pager 
 --no-ask-password
 --H --host'
 +-H --host --machine'
Again, --machine needs arg completiion.

  
  if __contains_word $prev $OPTS; then
  case $prev in
 diff --git a/shell-completion/bash/loginctl b/shell-completion/bash/loginctl
 index e7adb93..ea277c6 100644
 --- a/shell-completion/bash/loginctl
 +++ b/shell-completion/bash/loginctl
 @@ -33,9 +33,10 @@ _loginctl () {
  local i verb comps
  
  local -A OPTS=(
 -   [STANDALONE]='--all -a --help -h --no-pager --privileged -P

Re: [systemd-devel] [PATCH] systemd-udevd.service: restore mount propagation

On Wed, 28.01.15 16:29, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

 On Wed, Jan 28, 2015 at 02:09:37PM +0100, Martin Pitt wrote:
  Lennart Poettering [2015-01-28 13:33 +0100]:
   Hmm, yeah, we apparently only add that for file systems listed in
   /etc/fstab...
   
   If you change the get_mount_parameters_fragment() invocation at the
   beginning of mount_add_device_links() in src/core/mount.c to
   get_mount_parameters(), does this make things work for you?
   
   This change might have more effects than just making this work, but I
   think it's the right thing to do. Could you test please?
  
  BAZINGA! Thanks for this, now it works perfectly! Now the mount unit
  looks like this:
  
  | Where=/media/martin/Ubuntu 15.04 amd64
  | What=/dev/sr0
  | [...]
  | Id=media-martin-Ubuntu\x5cx2015.04\x5cx20amd64.mount
  | Names=media-martin-Ubuntu\x5cx2015.04\x5cx20amd64.mount
  | Requires=-.mount
  | Wants=system.slice
  | BindsTo=dev-sr0.device
  | WantedBy=dev-sr0.device
  | Conflicts=umount.target
  | Before=local-fs.target umount.target
 This looks wrong. It should have no relation to local-fs.target, which
 is only for things from /etc/fstab (and manually created .mount units).

I think ordering before local-fs.target is the right thing in this
case. Wants= or Reuqires= would be inappropriate, but After= is OK and
needed AFAICS. It is useful during shutdown, so that the mount units
stay around until all services with After=local-fs.target are
shut down, and not any earlier than 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] Jenkins Failing and Not Updating Github Mirror

2015-01-28 Thread Chris Atkinson

On Wed, 28 Jan 2015 03:42:33 +0100
Lennart Poettering lenn...@poettering.net wrote:

 On Sun, 18.01.15 01:58, Simon Peeters (peeters.si...@gmail.com) wrote:
 
  2015-01-18 1:28 GMT+01:00 Chris Atkinson c...@pipeline.com:
   It looks like Jenkins has been failing to build for the last
   three days and hasn't updated the Github mirror for a similar
   period (since commit 435fc3176520a58f1c20ccb983c9fb40b30a1471).
  
   https://github.com/systemd/systemd
   http://systemd.getpantheon.com:8080/jenkins/
  
   Regards,
  impl.cc(344)] Failed to connect to MCS endpoint with error -106
[16682:16709:0128/072106:ERROR:connection_factory_impl.cc(344)] Failed
to connect to MCS endpoint with error -105
[16682:16682:0128/072753:ERROR:navigation_entry_screenshot_manager.cc(152)]
Invalid entry with unique id: 788
[WARNING:flash/platform/pepper/pep_module.cpp(63)] SANDBOXED
[16682:16682:0128/072935:ERROR:navigation_entry_screenshot_manager.cc(152)]
Invalid entry with unique id: 793 [3,614770944:12:47:07.051220] Native
Client modul
  so a quick analysis:
  
  The build initially broke on
  30535c16924a3da7b47ea87190d929d617d95c5a (nspawn: add file system
  locks for controlling access to container images), due to missing
  kernel #defines probably triggered by an older kernel on the
  jenkins machine. This was fixed in
  f4a53250acb3aea2eb5ebed059887b9417afbd9e (missing: add macros for
  OFD locks), but unfortunately a missing zlib dependency introduced
  by edce2aed3aa93b84f7b4c70412bdb665da2977b0 (import: support
  importing qcow2 images) had already broken the build again.
  
  So the solution would be to make zlib available on the jenkins
  machine (David?), or make zlib an optional dep (Lennart?).
 
 I now made it build-time optional, as it always was supposed to
 be. Let's see if this fixes Jenkins again.
 
 Lennart
 

Github is updated through 3b48ce4ec4639437ca3db344962ed37b0c83ea9a and
Jenkins last successfully built at Jan 28, 2015 4:06:36 PM, so it
appears all is well.

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

Re: [systemd-devel] initializing _cleanup_* variables [was: [PATCH 01/12] fsckd daemon for inter-fsckd communication]

On 28 January 2015 at 15:47, Martin Pitt martin.p...@ubuntu.com wrote:
 Hey Zbyszek,

 Zbigniew Jędrzejewski-Szmek [2015-01-28 15:37 +0100]:
  +static int handle_requests(int socket_fd) {
  +Clients *first = NULL;
  +usec_t last_activity = 0;
  +int numdevices = 0, clear = 0;
  +double percent = 100;
  +_cleanup_fclose_ FILE *console = NULL;
 NULL not necessary (and you don't have it in similar circumstances above ;))

 How is that not necessary? Just because the very next line initializes
 it, and there is no exit path before? Because in the general case it
 certainly is necessary, otherwise the _cleanup_ handler will try to
 free/close/clean up a random pointer value and crash.

 So IMHO it's a good defensive habit to always init _cleanup_* vars
 with NULL. In the future someone might put some code with return
 before the fopen() below, and then get a crash.

 Or is there some gcc magic that I missed? (I thought only global
 variables were guaranteed to be NULL, not stack vars).


Well, during systemd build there are some -Wmaybe-uninitialized
warnings in most cases it is code similar to the above case or
like checking r || check uninitialised variable. Shall we fix all of
them? In most cases it would be of limited gain, but at least it will
be clear to see when -Wmaybe-uninitalized warnings catches a real
thing.

(or is my compiler old and has false positives?)


  +
  +console = fopen(/dev/console, we);

 Thanks for clarifying,

 Martin
 --
 Martin Pitt| http://www.piware.de
 Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

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




-- 
Regards,

Dimitri.

Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] initializing _cleanup_* variables [was: [PATCH 01/12] fsckd daemon for inter-fsckd communication]

On Wed, Jan 28, 2015 at 04:06:30PM +, Dimitri John Ledkov wrote:
 On 28 January 2015 at 15:47, Martin Pitt martin.p...@ubuntu.com wrote:
  Hey Zbyszek,
 
  Zbigniew Jędrzejewski-Szmek [2015-01-28 15:37 +0100]:
   +static int handle_requests(int socket_fd) {
   +Clients *first = NULL;
   +usec_t last_activity = 0;
   +int numdevices = 0, clear = 0;
   +double percent = 100;
   +_cleanup_fclose_ FILE *console = NULL;
  NULL not necessary (and you don't have it in similar circumstances above 
  ;))
 
  How is that not necessary? Just because the very next line initializes
  it, and there is no exit path before?
Yes.

  Because in the general case it
  certainly is necessary, otherwise the _cleanup_ handler will try to
  free/close/clean up a random pointer value and crash.
Of course, but I think that in this case it is pretty obvious when
that the next line overwrites the NULL.

  So IMHO it's a good defensive habit to always init _cleanup_* vars
  with NULL. In the future someone might put some code with return
  before the fopen() below, and then get a crash.
They can screw up in this and a thousand other ways. If there's a bunch
of other code in between, I agree that adding a defensive initialization
is good. In a simple case like this, I'm fine with skipping it.

Please note though, that my initial complaint was that there's an
inconsistency in the patch: one place had it, one didn't.

  Or is there some gcc magic that I missed? (I thought only global
  variables were guaranteed to be NULL, not stack vars).
No.
 
 Well, during systemd build there are some -Wmaybe-uninitialized
 warnings in most cases it is code similar to the above case or
 like checking r || check uninitialised variable. Shall we fix all of
 them? In most cases it would be of limited gain, but at least it will
 be clear to see when -Wmaybe-uninitalized warnings catches a real
 thing.
gcc issues false positive warnings in two cases:
1. when the same conditional is used twice, and cannot change:

  bool cond = ...;
  int var;
  if (cond)
 var = ...;
  ...
  if (cond)
 use(var);

2. when there's a loop which must be executed at least one:
   int var;
   while(true) {
  var = ...;
  break;
   }
   use(var);

Adding workarounds is frowned upon, unless they are very simple.  We
try not to have warnings in the -O0 compilation mode. There's just too
many false warnings at higher optimization levels to fix all.

 (or is my compiler old and has false positives?)
Hard to say, not knowing the version :)
gcc5 issues approx. 10 new warnings.

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

Re: [systemd-devel] [PATCH] systemd-udevd.service: restore mount propagation

On Wed, 28.01.15 14:09, Martin Pitt (martin.p...@ubuntu.com) wrote:

 Lennart Poettering [2015-01-28 13:33 +0100]:
  Hmm, yeah, we apparently only add that for file systems listed in
  /etc/fstab...
  
  If you change the get_mount_parameters_fragment() invocation at the
  beginning of mount_add_device_links() in src/core/mount.c to
  get_mount_parameters(), does this make things work for you?
  
  This change might have more effects than just making this work, but I
  think it's the right thing to do. Could you test please?
 
 BAZINGA! Thanks for this, now it works perfectly! Now the mount unit
 looks like this:

Applied both patches, but dropped this line:

 +ENV{DISK_MEDIA_CHANGE}==?*, ENV{ID_CDROM_MEDIA}==?*, 
 ENV{SYSTEMD_READY}=1

SYSTEMD_READY=1 is the implied default, hence there's no reason to set
it.

Note that this patch only covers CD driver media sensing. We really
should hanlde SD/CF card readers the same way. Unfortunately however
there's currently no nice property available that we could check for
media with. This would have have to be added to the blkid builtin or
so.

I have now added this to the TODO list. Would be happy to merge a
clean patch!

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 12/12] Add mock fsck process

Zbigniew Jędrzejewski-Szmek [2015-01-28 16:08 +0100]:
  +#!/bin/bash
 I think you can change this to /bin/sh, I don't see any bashisms.
 
  +declare -a maxpass=(30 5 2 30 60)

I do :-) POSIX shell doesn't have arrays AFAIK, and declare -a
definitively doesn't work in e. g. dash.

  +for pass in {1..5}; do
  +maxprogress=${maxpass[$((pass-1))]}

That said, if using POSIX shell is a concern (probably not for this
little test dummy), this could certainly be rewritten to something
like

  pass=0
  for maxprogress in 30 5 2 30 60; do
  pass=$((pass+1))

which isn't really more complicated and avoids arrays.

Martin

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

Re: [systemd-devel] [PATCH 1/2] networkd: accept a trailing '.' on the end of domains

On Thu, 15.01.15 13:24, Michael Marineau (michael.marin...@coreos.com) wrote:

 While not common outside of BIND configs the implied top level '.' in
 domains is commonly accepted and crops up in random places. Starting
 with commit 784d9b9c networkd began validating domains as hostnames
 which rejects trailing dots, breaking short name resolution in some
 environments such as Google Compute Engine. This change splits the
 validation code into two functions to be more tolerant for domains.

Did I get this right? the Google Compute Engine returns a domain name
with trailing dot in the DHCP domain option? 

Our DHCP client should certainly accept that, if that's what people
send, but I am not sure we should be equally liberal for locally
configured bits...

I now made this change: 

http://cgit.freedesktop.org/systemd/systemd/commit/?id=f50f01f4b738f2f00b30d0e02e8cf54ab99a9f27

Does that make things work on the google thing?

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-networkd quietly ignores DHCPv6 leases