Re: [systemd-devel] [PATCHv6 0/3] hibernate-resume: implement support for resuming from hibernation

[Jan Janssen]

Ivan Shapovalov intelfx100 at gmail.com writes:

 
 On Wednesday 27 August 2014 at 03:16:10, Zbigniew Jędrzejewski-Szmek wrote:   
  On Tue, Aug 26, 2014 at 10:21:59PM +0200, Lennart Poettering wrote:
   On Wed, 27.08.14 00:17, Ivan Shapovalov (intelfx100 at gmail.com) wrote:
This patchset allows systemd to parse resume= kernel command line
parameter
and initiate resume from the specified device.
  What about swap files with the resume_offset= parameter? Are they still
  being used?
 
 I don't know if somebody uses that, but for now it's missing functionality.
 
 After a cursory search, I could not find a mechanism to initiate a resume with
 offset from userspace. In Arch, it was never implemented even if possible.
 

I'm a heavy user of this myself. It's especially useful because you can just
have a single luks encrypted ext4 without a lvm in between for a swap
partition or (even more yuck) using a separate (encrypted) swap partition.

Arch does support this, mostly because as far as I know, the resume_offset=
is consumed by the kernel, while resume= has to refer to the (unencrypted)
filesystem (/dev/mapper/root in my case). So, as long as this solution waits
for the device to show up in /dev/ (and especially /dev/mapper/ for my
case), this should work out.

Here's information to set this up. Imho more people should be aware this is
possible:
https://wiki.archlinux.org/index.php/Suspend#Hibernation_into_swap_file

Jan

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

Re: [systemd-devel] [PATCHv6 0/3] hibernate-resume: implement support for resuming from hibernation

[Ivan Shapovalov]

On Thursday 28 August 2014 at 06:25:51, Jan Janssen wrote:  
 Ivan Shapovalov intelfx100 at gmail.com writes:
 
  
  On Wednesday 27 August 2014 at 03:16:10, Zbigniew Jędrzejewski-Szmek wrote: 
   On Tue, Aug 26, 2014 at 10:21:59PM +0200, Lennart Poettering wrote:
On Wed, 27.08.14 00:17, Ivan Shapovalov (intelfx100 at gmail.com) 
wrote:
 This patchset allows systemd to parse resume= kernel command line
 parameter
 and initiate resume from the specified device.
   What about swap files with the resume_offset= parameter? Are they still
   being used?
  
  I don't know if somebody uses that, but for now it's missing functionality.
  
  After a cursory search, I could not find a mechanism to initiate a resume 
  with
  offset from userspace. In Arch, it was never implemented even if possible.
  
 
 I'm a heavy user of this myself. It's especially useful because you can just
 have a single luks encrypted ext4 without a lvm in between for a swap
 partition or (even more yuck) using a separate (encrypted) swap partition.
 
 Arch does support this, mostly because as far as I know, the resume_offset=
 is consumed by the kernel, while resume= has to refer to the (unencrypted)
 filesystem (/dev/mapper/root in my case). So, as long as this solution waits
 for the device to show up in /dev/ (and especially /dev/mapper/ for my
 case), this should work out.
 
 Here's information to set this up. Imho more people should be aware this is
 possible:
 https://wiki.archlinux.org/index.php/Suspend#Hibernation_into_swap_file
 
 Jan

Hmm, so is resume_offset= parsed independently of resume=? If that's the
case, and resume_offset= can be parsed by kernel while resume= is parsed
by userspace, then yes, I was wrong and this should work.

Actually, it should work _just like before_, sans tuxonice support.

-- 
Ivan Shapovalov / intelfx /

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

Re: [systemd-devel] Build errors with lto and compat-libs

[Michael Olbrich]

On Tue, Aug 26, 2014 at 09:42:38PM +0200, Lennart Poettering wrote:
 On Tue, 26.08.14 15:15, Michael Olbrich (m.olbr...@pengutronix.de) wrote:
  On Mon, Aug 18, 2014 at 03:48:09PM +0200, Lennart Poettering wrote:
   On Sun, 17.08.14 09:54, Michael Olbrich (m.olbr...@pengutronix.de) wrote:
With --enable-compat-libs building fails like this:

  CCLD libsystemd-journal.la
[...]
/tmp/ccISOiYU.ltrans1.ltrans.o: In function `sd_journal_process':
ccISOiYU.ltrans1.o:(.text+0x0): multiple definition of 
`sd_journal_process'
libsystemd_journal_internal_la-sd-journal.o (symbol from 
plugin):(.text+0x0): first defined here
[...]
for all symbols listed in src/compat-libs/libsystemd-journal.sym

I have no idea what happens here, but making 'obsolete_lib()' a noop or
removing lto from configure.ac 'fixes' the problem.

This is with gcc-4.8.2 and binutils-2.24 building for ARM.

Any ideas what happens here?
   
   No really. But I figure LTO is not very reliable on ARM and stuff. It's
   probably best to turn it off there.
  
  Well it looks like it fails on x86 as well here, with the same compiler
  version. I can run configure with cc_cv_CFLAGS__flto=no here. I'm not sure,
  how an upstream fix should look like.
 
 Hmm, I am not experiencing this here, not sure how I can help you...

That's ok. I've disabled it for now. I'll see if I can find what triggers
the problem here.

Michael

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Having systemd shutdown when pressing the power button

[Koen Kooi]

Hi,

I am working on a system (http://www.acmesystems.it/arietta) where I hooked up 
the button as a power key:


https://github.com/koenkooi/linux/commit/c823e0b046efcfff61e21fa4c89d5d68090ef6de

Evtest shows it doing the right thing (issuing KEY_POWER) when being pressed, 
but systemd seems to totally ignore it. I've seen this behaviour in the past 
and noticed the DE (GNOME2, old but it works) would pick it up and present the 
dialog. Since this is a headless system I want systemd to handle it instead of 
the DE (which isn't installed).
Every doc or blog post I read says that systemd should already be handling it, 
but it isn't in my case. I suspect that systemd only handles ACPI powerkey 
events, but I haven't actually looked at the code.

Are more people experiencing this and does someone have a workaround or fix?

thanks,

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

Re: [systemd-devel] Having systemd shutdown when pressing the power button

[Mantas Mikulėnas]

On Thu, Aug 28, 2014 at 11:50 AM, Koen Kooi k...@dominion.thruhere.net wrote:

 Hi,

 I am working on a system (http://www.acmesystems.it/arietta) where I hooked 
 up the button as a power key:

 
 https://github.com/koenkooi/linux/commit/c823e0b046efcfff61e21fa4c89d5d68090ef6de

 Evtest shows it doing the right thing (issuing KEY_POWER) when being pressed, 
 but systemd seems to totally ignore it. I've seen this behaviour in the past 
 and noticed the DE (GNOME2, old but it works) would pick it up and present 
 the dialog. Since this is a headless system I want systemd to handle it 
 instead of the DE (which isn't installed).

Yes, systemd-logind handles the key events, unless something inhibits
this. For example, GNOME 3 does:

$ systemd-inhibit --list
 Who: grawity (UID 1000/grawity, PID 945/gnome-settings-)
What: handle-power-key:handle-suspend-key:handle-hibernate-key
 Why: GNOME handling keypresses
Mode: block

 Every doc or blog post I read says that systemd should already be handling 
 it, but it isn't in my case. I suspect that systemd only handles ACPI 
 powerkey events, but I haven't actually looked at the code.

It receives the events via /dev/input, whether ACPI or not. Reading
src/login/logind-button.c:155, it checks for either KEY_POWER or
KEY_POWER2.

Make sure it correctly detects your input device. You should be seeing
something like this in the logs:

logind[388]: New seat seat0.
logind[388]: Watching system buttons on /dev/input/event3 (Power Button)
logind[388]: Watching system buttons on /dev/input/event4 (Video Bus)
logind[388]: Watching system buttons on /dev/input/event1 (Lid Switch)
logind[388]: Watching system buttons on /dev/input/event2 (Sleep Button)
logind[388]: New session c1 of user gdm.
logind[388]: Lid closed.

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

Re: [systemd-devel] [PATCH] tty-ask-password-agent: reset a signal handler for SIGTERM to the default

[HATAYAMA, Daisuke]

(2014/08/28 4:46), Lennart Poettering wrote:

On Wed, 27.08.14 09:47, HATAYAMA, Daisuke (d.hatay...@jp.fujitsu.com) wrote:


Sounds like the right option here... I have now added a slightly
different patch (1dedb74a2e1d840b531b76b01a76979f3b57456b) that does
this.



Thanks! But this could still hang in very rare case becuase the reset is
done in a child process after fork(). Please consider the case where the
child process continue sleeping after fork() before resetting signal
handlers until it receives SIGTERM. For such reason, my patch resets
SIGTERM signal handler in the parent systemctl side.


Hmm, there's indeed a race here. I add a commit now that will block all
signals before forking, and unblocks them afterwards. The new process
will hence be created with all signals blocked, and we will hence not
lose them until we after we reset the signal handlers...

Hope this makes sense?

(Blocking the signals temporarily, instead of resetting the signal
handlers has the benefit, that we signal masks are per-thread, and not
per-process, like signal handlers are. The code hence stays generic
enough to not break should the call ever get invoked from a threaded
process...)



Thanks! It's smarter than my patch.

Also, I verified your fix by artifically creating the problematic
case by making prctl() sleep 5 seconds using kprobes, and I think this
now works well.

For example, systemctl with the first patch applied only hangs like this

]# strace -ff -F -e 
trace=clone,execve,rt_sigprocmask,signalfd4,poll,kill,waitid systemctl stop 
kdump
execve(/usr/bin/systemctl, [systemctl, stop, kdump], [/* 29 vars */]) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
poll([{fd=4, events=POLLOUT}], 1, 9) = 1 ([{fd=4, revents=POLLOUT}])
poll([{fd=4, events=POLLIN}], 1, 9) = 1 ([{fd=4, revents=POLLIN}])
poll([{fd=4, events=POLLOUT}], 1, 9) = 1 ([{fd=4, revents=POLLOUT}])
poll([{fd=4, events=POLLIN}], 1, 9) = 1 ([{fd=4, revents=POLLIN}])
poll([{fd=4, events=POLLOUT}], 1, 9) = 1 ([{fd=4, revents=POLLOUT}])
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7f41511c7b50) = 9723
poll([{fd=4, events=POLLIN}], 1, 25000) = 1 ([{fd=4, revents=POLLIN}])
poll([{fd=4, events=POLLIN}], 1, 25000) = 1 ([{fd=4, revents=POLLIN}])
poll([{fd=4, events=POLLIN}], 1, 25000) = 1 ([{fd=4, revents=POLLIN}])
poll([{fd=4, events=POLLIN}], 1, 25000) = 1 ([{fd=4, revents=POLLIN}])
poll([{fd=4, events=POLLIN}], 1, 25000) = 1 ([{fd=4, revents=POLLIN}])
kill(9723, SIGTERM) = 0
kill(9723, SIGCONT) = 0
waitid(P_PID, 9723, Process 9723 attached
 unfinished ...
[pid  9723] --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=9722, 
si_uid=0} ---
[pid  9723] --- SIGCONT {si_signo=SIGCONT, si_code=SI_USER, si_pid=9722, 
si_uid=0} ---
[pid  9723] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid  9723] execve(/usr/bin/systemd-tty-ask-password-agent, 
[/usr/bin/systemd-tty-ask-passwor..., --watch], [/* 29 vars */]) = 0
[pid  9723] rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
[pid  9723] rt_sigprocmask(SIG_SETMASK, [INT TERM], NULL, 8) = 0
[pid  9723] signalfd4(-1, [INT TERM], 8, O_NONBLOCK|O_CLOEXEC) = 5
[pid  9723] poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}], 2, 4294967295

while systemctl with the second patch doesn't hang like this

]# strace -ff -F -e 
trace=clone,execve,rt_sigprocmask,signalfd4,poll,kill,waitid systemctl stop 
kdump
execve(/usr/bin/systemctl, [systemctl, stop, kdump], [/* 29 vars */]) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
poll([{fd=4, events=POLLOUT}], 1, 9) = 1 ([{fd=4, revents=POLLOUT}])
poll([{fd=4, events=POLLIN}], 1, 9) = 1 ([{fd=4, revents=POLLIN}])
poll([{fd=4, events=POLLOUT}], 1, 9) = 1 ([{fd=4, revents=POLLOUT}])
poll([{fd=4, events=POLLIN}], 1, 9) = 1 ([{fd=4, revents=POLLIN}])
poll([{fd=4, events=POLLOUT}], 1, 9) = 1 ([{fd=4, revents=POLLOUT}])
rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7fc2780dcb50) = 9794
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
poll([{fd=4, events=POLLIN}], 1, 25000) = 1 ([{fd=4, revents=POLLIN}])
poll([{fd=4, events=POLLIN}], 1, 25000) = 1 ([{fd=4, revents=POLLIN}])
poll([{fd=4, events=POLLIN}], 1, 25000) = 1 ([{fd=4, revents=POLLIN}])
poll([{fd=4, events=POLLIN}], 1, 25000) = 1 ([{fd=4, revents=POLLIN}])
poll([{fd=4, events=POLLIN}], 1, 25000) = 1 ([{fd=4, revents=POLLIN}])
kill(9794, SIGTERM) = 0
kill(9794, SIGCONT) = 0
waitid(P_PID, 9794, Process 9794 attached
 unfinished ...
[pid  9794] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid  9794] --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=9793, 
si_uid=0} ---
[pid  9794] +++ killed by SIGTERM +++
... waitid resumed {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=9794, 
si_status=SIGTERM, si_utime=0, si_stime=0}, WEXITED, NULL) = 0

[systemd-devel] [PATCH V5] use the switch_root function in shutdown

[harald]

From: Harald Hoyer har...@redhat.com

removes code duplication

also move switch-root to shared
---

V2:
- Removed all references to /mnt in switch_root() and the bogus comment.
V3:
- moved switch-root.[ch] to shared
- added switch to mount MS_MOVE or MS_BIND the old dirs
V4:
- mkdir_p_label() in switch_root()
V5:
- fixed coding style
- mountflags now argument of switch_root()
- add comment for mountflags used


 Makefile.am|  4 +-
 src/core/main.c|  4 +-
 src/core/shutdown.c| 88 --
 src/{core = shared}/switch-root.c | 35 ---
 src/{core = shared}/switch-root.h |  2 +-
 5 files changed, 41 insertions(+), 92 deletions(-)
 rename src/{core = shared}/switch-root.c (81%)
 rename src/{core = shared}/switch-root.h (88%)

diff --git a/Makefile.am b/Makefile.am
index 4028112..14ba8f8 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -864,6 +864,8 @@ libsystemd_shared_la_SOURCES = \
src/shared/memfd.h \
src/shared/uid-range.c \
src/shared/uid-range.h \
+   src/shared/switch-root.h \
+   src/shared/switch-root.c \
src/shared/nss-util.h
 
 nodist_libsystemd_shared_la_SOURCES = \
@@ -1105,8 +1107,6 @@ libsystemd_core_la_SOURCES = \
src/core/namespace.h \
src/core/build.h \
src/core/sysfs-show.h \
-   src/core/switch-root.h \
-   src/core/switch-root.c \
src/core/killall.h \
src/core/killall.c \
src/core/audit-fd.c \
diff --git a/src/core/main.c b/src/core/main.c
index 792b316..3807e73 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -1841,8 +1841,8 @@ finish:
  * deserializing. */
 broadcast_signal(SIGTERM, false, true);
 
-/* And switch root */
-r = switch_root(switch_root_dir);
+/* And switch root with MS_MOVE, because we remove the 
old directory afterwards and detach it. */
+r = switch_root(switch_root_dir, /mnt, true, 
MS_MOVE);
 if (r  0)
 log_error(Failed to switch root, ignoring: 
%s, strerror(-r));
 }
diff --git a/src/core/shutdown.c b/src/core/shutdown.c
index 1abc140..8026f59 100644
--- a/src/core/shutdown.c
+++ b/src/core/shutdown.c
@@ -48,6 +48,7 @@
 #include killall.h
 #include cgroup-util.h
 #include def.h
+#include switch-root.h
 
 #define FINALIZE_ATTEMPTS 50
 
@@ -131,15 +132,8 @@ static int parse_argv(int argc, char *argv[]) {
 return 0;
 }
 
-static int prepare_new_root(void) {
-static const char dirs[] =
-/run/initramfs/oldroot\0
-/run/initramfs/proc\0
-/run/initramfs/sys\0
-/run/initramfs/dev\0
-/run/initramfs/run\0;
-
-const char *dir;
+static int switch_root_initramfs(void) {
+int r;
 
 if (mount(/run/initramfs, /run/initramfs, NULL, MS_BIND, NULL)  
0) {
 log_error(Failed to mount bind /run/initramfs on 
/run/initramfs: %m);
@@ -151,66 +145,19 @@ static int prepare_new_root(void) {
 return -errno;
 }
 
-NULSTR_FOREACH(dir, dirs)
-if (mkdir_p_label(dir, 0755)  0  errno != EEXIST) {
-log_error(Failed to mkdir %s: %m, dir);
-return -errno;
-}
-
-if (mount(/sys, /run/initramfs/sys, NULL, MS_BIND, NULL)  0) {
-log_error(Failed to mount bind /sys on /run/initramfs/sys: 
%m);
-return -errno;
-}
-
-if (mount(/proc, /run/initramfs/proc, NULL, MS_BIND, NULL)  0) {
-log_error(Failed to mount bind /proc on /run/initramfs/proc: 
%m);
-return -errno;
-}
-
-if (mount(/dev, /run/initramfs/dev, NULL, MS_BIND, NULL)  0) {
-log_error(Failed to mount bind /dev on /run/initramfs/dev: 
%m);
-return -errno;
-}
-
-if (mount(/run, /run/initramfs/run, NULL, MS_BIND, NULL)  0) {
-log_error(Failed to mount bind /run on /run/initramfs/run: 
%m);
-return -errno;
+/* switch_root with MS_BIND, because there might still be processes 
lurking around, which have open file desriptors.
+ * /run/initramfs/shutdown will take care of these.
+ * Also do not detach the old root, because /run/initramfs/shutdown 
needs to access it.
+ */
+r = switch_root(/run/initramfs, /oldroot, false, MS_BIND);
+if (r  0) {
+log_error(Failed to switch root to \/run/initramfs\: %m);
+return r;
 }
 
 return 0;
 }
 
-static int pivot_to_new_root(void) {
-
-if (chdir(/run/initramfs)  0) {
-log_error(Failed to change directory to /run/initramfs: %m);
-return -errno;
-}
-
-   

[systemd-devel] [PATCH] use the switch_root function in shutdown

[harald]

From: Harald Hoyer har...@redhat.com

removes code duplication

also move switch-root to shared
---


V2:
- Removed all references to /mnt in switch_root() and the bogus comment.
V3:
- moved switch-root.[ch] to shared
- added switch to mount MS_MOVE or MS_BIND the old dirs
V4:
- mkdir_p_label() in switch_root()
V5:
- fixed coding style
- mountflags now argument of switch_root()
- add comment for mountflags used
V6:
- removed double error message, if switch_root_initramfs() failed


 Makefile.am|  4 +-
 src/core/main.c|  4 +-
 src/core/shutdown.c| 88 +++---
 src/{core = shared}/switch-root.c | 35 ---
 src/{core = shared}/switch-root.h |  2 +-
 5 files changed, 37 insertions(+), 96 deletions(-)
 rename src/{core = shared}/switch-root.c (81%)
 rename src/{core = shared}/switch-root.h (88%)

diff --git a/Makefile.am b/Makefile.am
index 4028112..14ba8f8 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -864,6 +864,8 @@ libsystemd_shared_la_SOURCES = \
src/shared/memfd.h \
src/shared/uid-range.c \
src/shared/uid-range.h \
+   src/shared/switch-root.h \
+   src/shared/switch-root.c \
src/shared/nss-util.h
 
 nodist_libsystemd_shared_la_SOURCES = \
@@ -1105,8 +1107,6 @@ libsystemd_core_la_SOURCES = \
src/core/namespace.h \
src/core/build.h \
src/core/sysfs-show.h \
-   src/core/switch-root.h \
-   src/core/switch-root.c \
src/core/killall.h \
src/core/killall.c \
src/core/audit-fd.c \
diff --git a/src/core/main.c b/src/core/main.c
index 792b316..3807e73 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -1841,8 +1841,8 @@ finish:
  * deserializing. */
 broadcast_signal(SIGTERM, false, true);
 
-/* And switch root */
-r = switch_root(switch_root_dir);
+/* And switch root with MS_MOVE, because we remove the 
old directory afterwards and detach it. */
+r = switch_root(switch_root_dir, /mnt, true, 
MS_MOVE);
 if (r  0)
 log_error(Failed to switch root, ignoring: 
%s, strerror(-r));
 }
diff --git a/src/core/shutdown.c b/src/core/shutdown.c
index 1abc140..db6407f 100644
--- a/src/core/shutdown.c
+++ b/src/core/shutdown.c
@@ -48,6 +48,7 @@
 #include killall.h
 #include cgroup-util.h
 #include def.h
+#include switch-root.h
 
 #define FINALIZE_ATTEMPTS 50
 
@@ -131,16 +132,7 @@ static int parse_argv(int argc, char *argv[]) {
 return 0;
 }
 
-static int prepare_new_root(void) {
-static const char dirs[] =
-/run/initramfs/oldroot\0
-/run/initramfs/proc\0
-/run/initramfs/sys\0
-/run/initramfs/dev\0
-/run/initramfs/run\0;
-
-const char *dir;
-
+static int switch_root_initramfs(void) {
 if (mount(/run/initramfs, /run/initramfs, NULL, MS_BIND, NULL)  
0) {
 log_error(Failed to mount bind /run/initramfs on 
/run/initramfs: %m);
 return -errno;
@@ -151,66 +143,13 @@ static int prepare_new_root(void) {
 return -errno;
 }
 
-NULSTR_FOREACH(dir, dirs)
-if (mkdir_p_label(dir, 0755)  0  errno != EEXIST) {
-log_error(Failed to mkdir %s: %m, dir);
-return -errno;
-}
-
-if (mount(/sys, /run/initramfs/sys, NULL, MS_BIND, NULL)  0) {
-log_error(Failed to mount bind /sys on /run/initramfs/sys: 
%m);
-return -errno;
-}
-
-if (mount(/proc, /run/initramfs/proc, NULL, MS_BIND, NULL)  0) {
-log_error(Failed to mount bind /proc on /run/initramfs/proc: 
%m);
-return -errno;
-}
-
-if (mount(/dev, /run/initramfs/dev, NULL, MS_BIND, NULL)  0) {
-log_error(Failed to mount bind /dev on /run/initramfs/dev: 
%m);
-return -errno;
-}
-
-if (mount(/run, /run/initramfs/run, NULL, MS_BIND, NULL)  0) {
-log_error(Failed to mount bind /run on /run/initramfs/run: 
%m);
-return -errno;
-}
-
-return 0;
+/* switch_root with MS_BIND, because there might still be processes 
lurking around, which have open file desriptors.
+ * /run/initramfs/shutdown will take care of these.
+ * Also do not detach the old root, because /run/initramfs/shutdown 
needs to access it.
+ */
+return switch_root(/run/initramfs, /oldroot, false, MS_BIND);
 }
 
-static int pivot_to_new_root(void) {
-
-if (chdir(/run/initramfs)  0) {
-log_error(Failed to change directory to /run/initramfs: %m);
-return -errno;
-}
-
-/* Work-around for a kernel 

[systemd-devel] [PATCH] journal: do server_vacuum for sigusr1

[WaLyong Cho]

runtime journal is migrated to system journal when only
/run/systemd/journal/flushed exist. It's ok but according to this
the system journal directory size(max use) can be over the config. If
journal is not rotated during some time the journal directory can be
remained as over the config(or default) size. To avoid, do
server_vacuum just after the system journal migration from runtime.
---
 src/journal/journald-server.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
index 01da38b..7e85892 100644
--- a/src/journal/journald-server.c
+++ b/src/journal/journald-server.c
@@ -1224,6 +1224,7 @@ static int dispatch_sigusr1(sd_event_source *es, const 
struct signalfd_siginfo *
 touch(/run/systemd/journal/flushed);
 server_flush_to_var(s);
 server_sync(s);
+server_vacuum(s);
 
 return 0;
 }
-- 
1.9.3

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

Re: [systemd-devel] [PATCH] journal: do server_vacuum for sigusr1

[WaLyong Cho]

On 08/28/2014 09:33 PM, WaLyong Cho wrote:
 runtime journal is migrated to system journal when only
 /run/systemd/journal/flushed exist. It's ok but according to this
 the system journal directory size(max use) can be over the config. If
 journal is not rotated during some time the journal directory can be
 remained as over the config(or default) size. To avoid, do
 server_vacuum just after the system journal migration from runtime.

If I add some of detail, you maybe think why this case could be happen.
Actually, it did. Assume every poweroff was not proceeded cleanly.
(Yeah, it is included in our terrible test case.) Then, journal backup
file(*.journal~) will be made on every startup time. These files will be
migrated to /var/log/journal by systemd-journal-flush.service unit.
(But not vacuumed.) That only be vacuumed when rotate is needed. But we
almost didn't have the chance because the system.journal is newly
created by backup. So if the journal file size is big then the vacuum
will be never happened. Finally, the /var/log/journal directory was
increased continuously.

Whatever the cause, I think server_vacuum should be done after the
journal file migration to make sure the size is NOT over-ed.

 ---
  src/journal/journald-server.c | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
 index 01da38b..7e85892 100644
 --- a/src/journal/journald-server.c
 +++ b/src/journal/journald-server.c
 @@ -1224,6 +1224,7 @@ static int dispatch_sigusr1(sd_event_source *es, const 
 struct signalfd_siginfo *
  touch(/run/systemd/journal/flushed);
  server_flush_to_var(s);
  server_sync(s);
 +server_vacuum(s);
  
  return 0;
  }
 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] use the switch_root function in shutdown

[Lennart Poettering]

On Thu, 28.08.14 14:01, har...@redhat.com (har...@redhat.com) wrote:

  
  if (!in_container  !in_initrd() 
  access(/run/initramfs/shutdown, X_OK) == 0) {
 -
 -if (prepare_new_root() = 0 
 -pivot_to_new_root() = 0) {
 +if (switch_root_initramfs() = 0) {
  arguments[0] = (char*) /shutdown;
  
 -log_info(Returning to initrd...);
 +setsid();
 +make_console_stdio();
 +
 +log_info(Successfully changed into root pivot.\n
 + Returning to initrd...);
  
  execv(/shutdown, arguments);
  log_error(Failed to execute shutdown binary: %m);
 -}
 +} else
 +log_error(Failed to switch root to 
 \/run/initramfs\: %m);
  }

The error of switch_root_initramfs() is returned in the return value,
not in errno. Hence you need to store the result in some variable r
first, and then print the error with %s and strerror(-r) instead of %m...


Lennart

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

[systemd-devel] [PATCH V7] use the switch_root function in shutdown

[harald]

From: Harald Hoyer har...@redhat.com

removes code duplication

also move switch-root to shared
---


V2:
- Removed all references to /mnt in switch_root() and the bogus comment.
V3:
- moved switch-root.[ch] to shared
- added switch to mount MS_MOVE or MS_BIND the old dirs
V4:
- mkdir_p_label() in switch_root()
V5:
- fixed coding style
- mountflags now argument of switch_root()
- add comment for mountflags used
V6:
- removed double error message, if switch_root_initramfs() failed
V7:
- use return value of switch_root_initramfs() with strerror()

 Makefile.am|  4 +-
 src/core/main.c|  4 +-
 src/core/shutdown.c| 90 +++---
 src/{core = shared}/switch-root.c | 35 +++
 src/{core = shared}/switch-root.h |  2 +-
 5 files changed, 39 insertions(+), 96 deletions(-)
 rename src/{core = shared}/switch-root.c (81%)
 rename src/{core = shared}/switch-root.h (88%)

diff --git a/Makefile.am b/Makefile.am
index 4028112..14ba8f8 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -864,6 +864,8 @@ libsystemd_shared_la_SOURCES = \
src/shared/memfd.h \
src/shared/uid-range.c \
src/shared/uid-range.h \
+   src/shared/switch-root.h \
+   src/shared/switch-root.c \
src/shared/nss-util.h
 
 nodist_libsystemd_shared_la_SOURCES = \
@@ -1105,8 +1107,6 @@ libsystemd_core_la_SOURCES = \
src/core/namespace.h \
src/core/build.h \
src/core/sysfs-show.h \
-   src/core/switch-root.h \
-   src/core/switch-root.c \
src/core/killall.h \
src/core/killall.c \
src/core/audit-fd.c \
diff --git a/src/core/main.c b/src/core/main.c
index 792b316..3807e73 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -1841,8 +1841,8 @@ finish:
  * deserializing. */
 broadcast_signal(SIGTERM, false, true);
 
-/* And switch root */
-r = switch_root(switch_root_dir);
+/* And switch root with MS_MOVE, because we remove the 
old directory afterwards and detach it. */
+r = switch_root(switch_root_dir, /mnt, true, 
MS_MOVE);
 if (r  0)
 log_error(Failed to switch root, ignoring: 
%s, strerror(-r));
 }
diff --git a/src/core/shutdown.c b/src/core/shutdown.c
index 1abc140..e23f3c6 100644
--- a/src/core/shutdown.c
+++ b/src/core/shutdown.c
@@ -48,6 +48,7 @@
 #include killall.h
 #include cgroup-util.h
 #include def.h
+#include switch-root.h
 
 #define FINALIZE_ATTEMPTS 50
 
@@ -131,16 +132,7 @@ static int parse_argv(int argc, char *argv[]) {
 return 0;
 }
 
-static int prepare_new_root(void) {
-static const char dirs[] =
-/run/initramfs/oldroot\0
-/run/initramfs/proc\0
-/run/initramfs/sys\0
-/run/initramfs/dev\0
-/run/initramfs/run\0;
-
-const char *dir;
-
+static int switch_root_initramfs(void) {
 if (mount(/run/initramfs, /run/initramfs, NULL, MS_BIND, NULL)  
0) {
 log_error(Failed to mount bind /run/initramfs on 
/run/initramfs: %m);
 return -errno;
@@ -151,66 +143,13 @@ static int prepare_new_root(void) {
 return -errno;
 }
 
-NULSTR_FOREACH(dir, dirs)
-if (mkdir_p_label(dir, 0755)  0  errno != EEXIST) {
-log_error(Failed to mkdir %s: %m, dir);
-return -errno;
-}
-
-if (mount(/sys, /run/initramfs/sys, NULL, MS_BIND, NULL)  0) {
-log_error(Failed to mount bind /sys on /run/initramfs/sys: 
%m);
-return -errno;
-}
-
-if (mount(/proc, /run/initramfs/proc, NULL, MS_BIND, NULL)  0) {
-log_error(Failed to mount bind /proc on /run/initramfs/proc: 
%m);
-return -errno;
-}
-
-if (mount(/dev, /run/initramfs/dev, NULL, MS_BIND, NULL)  0) {
-log_error(Failed to mount bind /dev on /run/initramfs/dev: 
%m);
-return -errno;
-}
-
-if (mount(/run, /run/initramfs/run, NULL, MS_BIND, NULL)  0) {
-log_error(Failed to mount bind /run on /run/initramfs/run: 
%m);
-return -errno;
-}
-
-return 0;
+/* switch_root with MS_BIND, because there might still be processes 
lurking around, which have open file desriptors.
+ * /run/initramfs/shutdown will take care of these.
+ * Also do not detach the old root, because /run/initramfs/shutdown 
needs to access it.
+ */
+return switch_root(/run/initramfs, /oldroot, false, MS_BIND);
 }
 
-static int pivot_to_new_root(void) {
-
-if (chdir(/run/initramfs)  0) {
-log_error(Failed to change directory to /run/initramfs: %m);
-

Re: [systemd-devel] [PATCH V7] use the switch_root function in shutdown

[Lennart Poettering]

On Thu, 28.08.14 15:23, har...@redhat.com (har...@redhat.com) wrote:

 From: Harald Hoyer har...@redhat.com
 
 removes code duplication
 
 also move switch-root to shared


Looks good! Please push! Thanks!

Lennart

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

Re: [systemd-devel] Having systemd shutdown when pressing the power button

[Mantas Mikulėnas]

On Thu, Aug 28, 2014 at 4:35 PM, Koen Kooi k...@dominion.thruhere.net wrote:


 Op 28 aug. 2014, om 11:06 heeft Mantas Mikulėnas graw...@gmail.com het 
 volgende geschreven:

  On Thu, Aug 28, 2014 at 11:50 AM, Koen Kooi k...@dominion.thruhere.net 
  wrote:
 
  Hi,
 
  I am working on a system (http://www.acmesystems.it/arietta) where I 
  hooked up the button as a power key:
 
 
  https://github.com/koenkooi/linux/commit/c823e0b046efcfff61e21fa4c89d5d68090ef6de
 
  Evtest shows it doing the right thing (issuing KEY_POWER) when being 
  pressed, but systemd seems to totally ignore it. I've seen this behaviour 
  in the past and noticed the DE (GNOME2, old but it works) would pick it up 
  and present the dialog. Since this is a headless system I want systemd to 
  handle it instead of the DE (which isn't installed).
 
  Yes, systemd-logind handles the key events, unless something inhibits
  this. For example, GNOME 3 does:
 
  $ systemd-inhibit --list
  Who: grawity (UID 1000/grawity, PID 945/gnome-settings-)
 What: handle-power-key:handle-suspend-key:handle-hibernate-key
  Why: GNOME handling keypresses
 Mode: block
 
  Every doc or blog post I read says that systemd should already be handling 
  it, but it isn't in my case. I suspect that systemd only handles ACPI 
  powerkey events, but I haven't actually looked at the code.
 
  It receives the events via /dev/input, whether ACPI or not. Reading
  src/login/logind-button.c:155, it checks for either KEY_POWER or
  KEY_POWER2.
 
  Make sure it correctly detects your input device. You should be seeing
  something like this in the logs:
 
  logind[388]: New seat seat0.
  logind[388]: Watching system buttons on /dev/input/event3 (Power Button)
  logind[388]: Watching system buttons on /dev/input/event4 (Video Bus)
  logind[388]: Watching system buttons on /dev/input/event1 (Lid Switch)
  logind[388]: Watching system buttons on /dev/input/event2 (Sleep Button)
  logind[388]: New session c1 of user gdm.
  logind[388]: Lid closed.

 So what happens when no one is logged in?

Nothing special; systemd-logind runs regardless of whether any user
sessions are active, and it continues handling the lid/button events
according to configuration.

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

Re: [systemd-devel] Having systemd shutdown when pressing the power button

[David Herrmann]

Hi

On Thu, Aug 28, 2014 at 10:50 AM, Koen Kooi k...@dominion.thruhere.net wrote:
 Hi,

 I am working on a system (http://www.acmesystems.it/arietta) where I hooked 
 up the button as a power key:

 
 https://github.com/koenkooi/linux/commit/c823e0b046efcfff61e21fa4c89d5d68090ef6de

 Evtest shows it doing the right thing (issuing KEY_POWER) when being pressed, 
 but systemd seems to totally ignore it. I've seen this behaviour in the past 
 and noticed the DE (GNOME2, old but it works) would pick it up and present 
 the dialog. Since this is a headless system I want systemd to handle it 
 instead of the DE (which isn't installed).
 Every doc or blog post I read says that systemd should already be handling 
 it, but it isn't in my case. I suspect that systemd only handles ACPI 
 powerkey events, but I haven't actually looked at the code.

 Are more people experiencing this and does someone have a workaround or fix?

We only open a restricted set of input devices. We don't want logind
to wake up for key-events it's really not interested in (like normal
keyboard events). However, in case KEY_POWER is reported via the same
evdev interface than basic keyboard events, we should really avoid
opening it.

I posted a kernel patch to allow masking input events in April. I have
since resent it 5 times without getting any response... Last revision
is available here:
  https://www.mail-archive.com/linux-input@vger.kernel.org/msg11660.html
First revision from April is here:
  http://www.spinics.net/lists/linux-input/msg30924.html

With that in place, we can open any input device and just mask all
events but KEY_POWER.

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

[systemd-devel] bad memory access in test-dhcp6-client

[Zbigniew Jędrzejewski-Szmek]

Hi,
when systemd is compiled with --enable-address-sanitizer, $subject happens:

$ build/test-dhcp6-client 
Assertion 'interface_index = -1' failed at 
../src/libsystemd-network/sd-dhcp6-client.c:129, function 
sd_dhcp6_client_set_index(). Ignoring.
=
==29135==ERROR: AddressSanitizer: global-buffer-overflow on address 
0x7fe204aa9148 at pc 0x7fe204a5958f bp 0x7fff3e47d470 sp 0x7fff3e47d460
READ of size 1 at 0x7fe204aa9148 thread T0
#0 0x7fe204a5958e in option_parse_hdr 
../src/libsystemd-network/dhcp6-option.c:145
#1 0x7fe204a59884 in dhcp6_option_parse 
../src/libsystemd-network/dhcp6-option.c:165
#2 0x7fe204a4eb9c in test_advertise_option 
../src/libsystemd-network/test-dhcp6-client.c:227
#3 0x7fe204a51c58 in main ../src/libsystemd-network/test-dhcp6-client.c:584
#4 0x7fe2031590df in __libc_start_main (/lib64/libc.so.6+0x200df)
#5 0x7fe204a4cc5b (/home/test/systemd/build/test-dhcp6-client+0x25c5b)

0x7fe204aa9148 is located 2 bytes to the right of global variable 
'msg_advertise' from '../src/libsystemd-network/test-dhcp6-client.c' 
(0x7fe204aa9080) of size 198
0x7fe204aa9148 is located 56 bytes to the left of global variable 'msg_reply' 
from '../src/libsystemd-network/test-dhcp6-client.c' (0x7fe204aa9180) of size 
173
SUMMARY: AddressSanitizer: global-buffer-overflow 
../src/libsystemd-network/dhcp6-option.c:145 option_parse_hdr
Shadow bytes around the buggy address:
  0x0ffcc094d1d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ffcc094d1e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ffcc094d1f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ffcc094d200: 06 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
  0x0ffcc094d210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=0x0ffcc094d220: 00 00 00 00 00 00 00 00 06[f9]f9 f9 f9 f9 f9 f9
  0x0ffcc094d230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ffcc094d240: 00 00 00 00 00 05 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x0ffcc094d250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ffcc094d260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ffcc094d270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Heap right redzone:  fb
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack partial redzone:   f4
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Contiguous container OOB:fc
  ASan internal:   fe
==29135==ABORTING

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

[systemd-devel] Systemd-networkd doesn't add static routes anymore

[Moviuro]

Hi all,

I'm using systemd 216 on Archlinux (uptodate).
Everything worked fine at last boot (systemd 215, kernel 3.14.1)

Here is my tap0.network: 
[Match]
Name=tap0

[Network]
DHCP=yes

[Route]
Gateway=10.3.16.1
Destination=10.3.14.0/24

[Route]
Gateway=10.3.16.1
Destination=10.3.15.0/24

And the routes: 
% ip route show
default via 192.168.1.1 dev wlan0  proto dhcp  metric 1024 
10.3.16.0/24 dev tap0  proto kernel  scope link  src 10.3.16.201 
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.128 
192.168.1.1 dev wlan0  proto dhcp  scope link  metric 1024

And relevant journal snippet:
Aug 28 15:37:01 systemd-networkd[371]: tap0 : gained carrier
Aug 28 15:37:01 systemd-networkd[371]: tap0 : could not set route: Network is 
unreachable
Aug 28 15:37:01 systemd-networkd[371]: tap0 : could not set route: Network is 
unreachable
Aug 28 15:37:01 systemd-networkd[371]: tap0 : link configured
Aug 28 15:37:01 systemd-networkd[371]: tap0 : DHCPv4 address 10.3.16.201/24 
Aug 28 15:37:01 systemd-networkd[371]: tap0 : link configured
**At this point I do have all my routes**
**Shutdown begins**
Aug 28 16:58:54 systemd-networkd[371]: wlan0 : lost carrier
Aug 28 16:58:54 systemd-networkd[371]: wlan0 : DHCP lease lost
Aug 28 16:58:54 systemd-networkd[371]: tap0 : lost carrier
Aug 28 16:58:54 systemd-networkd[371]: tap0 : DHCP lease lost
-- Reboot --
Aug 28 16:59:20 systemd-networkd[364]: rtnl: received address for a 
nonexistent link, ignoring
Aug 28 16:59:20 systemd-networkd[364]: rtnl: received address for a 
nonexistent link, ignoring
Aug 28 16:59:23 systemd-networkd[364]: wlan0 : gained carrier
Aug 28 16:59:24 systemd-networkd[364]: wlan0 : DHCPv4 address 192.168.1.128/24 
via 192.168.1.1
Aug 28 16:59:24 systemd-networkd[364]: wlan0 : link configured
Aug 28 16:59:37 systemd-networkd[364]: rtnl: received address for a 
nonexistent link, ignoring
Aug 28 16:59:37 systemd-networkd[364]: rtnl: received address for a 
nonexistent link, ignoring
Aug 28 16:59:37 systemd-networkd[364]: tap0 : gained carrier
Aug 28 16:59:37 systemd-networkd[364]: tap0 : could not set route: Network is 
unreachable
Aug 28 16:59:37 systemd-networkd[364]: tap0 : could not set route: Network is 
unreachable
Aug 28 16:59:37 systemd-networkd[364]: tap0 : DHCPv4 address 10.3.16.201/24

Note that tap0 never becomes 'configured'.
The man does not tell any changes in networkd configuration and my setup is  
2 months old.

Regards,
--
Moviuro @ PsychoticDelirium Our life is the immortals' death.

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

[systemd-devel] [PATCH] firstboot: remove extra paranoia in --root checking

[Dave Reisner]

Some package managers will chroot before running post-install and
post-upgrade scripts. Doing this prevents systemd-firstboot from being
used piecemeal at installation or upgrade time, as the --root=/ will be
cleverly ignored.

There's already enough sanity checks in this tool that we don't also
need add intelligence on top of the --root parameter. If a sys-admin
wants to run this tool with --root=/, I see no reason why we should
actively stop them.
---
Hi.

It's currently far more difficult than it needs to be to perform the seemingly
simple task of creating a *unique* machine ID for new installations. The
systemd-machine-id-setup tool almost accomplishes this, but fails to create
something unique when generating IDs for nspawn containers in VMs[1]. A recent
change[2] tried to address this, but it's still negated by the fact that most
package managers will chroot before running install scriptlets.

systemd-firstboot is too smart for its own good. The tool has a --root
parameter, but this is made useless by the fact that it silently ignores any
root value which is equivalent to /. And, without a --root specified, the
--setup-machine-id feature of firstboot will be a no-op. This makes
systemd-firstboot unsuitable for usage in a post-install script, again, because
of the chroot.

systemd is the only software on most machines which will read and use the
machine ID. It therefore makes sense that systemd is responsible for creating
this. The installation bootstrap scripts shouldn't have to rely on systemd
being installed in the host environment in order to generate this data. This
really is a dead simple task that's entirely feasible to do as part of the
package's post-installation work. But yet... it currently isn't.

philosoraptor
Why does a tool called firstboot have a feature which refuses to run on first
boot?
/philosoraptor

[1] https://bugs.archlinux.org/task/40131
[2] http://cgit.freedesktop.org/systemd/systemd/commit/?id=5dd6d0f8ff1

 src/firstboot/firstboot.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/src/firstboot/firstboot.c b/src/firstboot/firstboot.c
index fd73adb..a17c18a 100644
--- a/src/firstboot/firstboot.c
+++ b/src/firstboot/firstboot.c
@@ -747,11 +747,6 @@ static int parse_argv(int argc, char *argv[]) {
 
 path_kill_slashes(arg_root);
 
-if (path_equal(arg_root, /)) {
-free(arg_root);
-arg_root = NULL;
-}
-
 break;
 
 case ARG_LOCALE:
-- 
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCHv6 0/3] hibernate-resume: implement support for resuming from hibernation

[Jan Janssen]

On Thursday 28 August 2014 11:33:44 Ivan Shapovalov wrote:
 On Thursday 28 August 2014 at 06:25:51, Jan Janssen wrote:
  Ivan Shapovalov intelfx100 at gmail.com writes:
   On Wednesday 27 August 2014 at 03:16:10, Zbigniew Jędrzejewski-Szmek 
   wrote:
On Tue, Aug 26, 2014 at 10:21:59PM +0200, Lennart Poettering wrote:
 On Wed, 27.08.14 00:17, Ivan Shapovalov (intelfx100 at gmail.com) 
 wrote:
  This patchset allows systemd to parse resume= kernel command line
  
  parameter
  
  and initiate resume from the specified device.

What about swap files with the resume_offset= parameter? Are they
still
being used?
   
   I don't know if somebody uses that, but for now it's missing
   functionality.
   
   After a cursory search, I could not find a mechanism to initiate a
   resume with offset from userspace. In Arch, it was never implemented
   even if possible. 
  I'm a heavy user of this myself. It's especially useful because you can
  just have a single luks encrypted ext4 without a lvm in between for a
  swap partition or (even more yuck) using a separate (encrypted) swap
  partition.
  
  Arch does support this, mostly because as far as I know, the
  resume_offset=
  is consumed by the kernel, while resume= has to refer to the (unencrypted)
  filesystem (/dev/mapper/root in my case). So, as long as this solution
  waits for the device to show up in /dev/ (and especially /dev/mapper/ for
  my case), this should work out.
  
  Here's information to set this up. Imho more people should be aware this
  is
  possible:
  https://wiki.archlinux.org/index.php/Suspend#Hibernation_into_swap_file
  
  Jan
 
 Hmm, so is resume_offset= parsed independently of resume=? If that's the
 case, and resume_offset= can be parsed by kernel while resume= is parsed
 by userspace, then yes, I was wrong and this should work.
 
 Actually, it should work _just like before_, sans tuxonice support.

I gave it a try and resume works for me with that sd-resume hook in arch. But 
I'm not too sure whether fsck is delayed properly:

systemd[1]: Started Cryptography Setup for 
luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78.
systemd[1]: Found device /dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78.
systemd[1]: Starting File System Check on 
/dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78...
systemd[1]: Starting Resume from hibernation using device 
/dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78...
systemd-fsck[135]: fsck.ext4 doesn't exist, not checking file system on 
/dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78
systemd[1]: Starting Encrypted Volumes.
systemd[1]: Reached target Encrypted Volumes.
systemd[1]: Starting System Initialization.
systemd[1]: Reached target System Initialization.
systemd[1]: Starting Basic System.
systemd[1]: Reached target Basic System.
systemd[1]: Started File System Check on 
/dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78.
kernel: PM: Starting manual resume from disk
kernel: PM: Hibernation image partition 254:0 present
kernel: PM: Looking for hibernation image.
systemd-hibernate-resume[137]: Could not resume from 
'/dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78' (254:0).
systemd[1]: Started Resume from hibernation using device 
/dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78.

If I read this correctly, the moment the plaintext device appears, the resume 
and fsck are racing each other. And in this case,
fsck won (good thing my fsck binaries are not in the systemd initrd for now).

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

Re: [systemd-devel] [PATCH 0/2] units: add and use ConditionInitrd= instead of checking for /etc/initrd-release.

[Thomas Bächler]

Am 27.08.2014 um 22:48 schrieb Thomas Bächler:
 Am 27.08.2014 um 20:25 schrieb Ivan Shapovalov:
 On Wednesday 27 August 2014 at 20:19:45, Lennart Poettering wrote:   
 On Wed, 27.08.14 20:26, Ivan Shapovalov (intelfx...@gmail.com) wrote:

 This is as proposed by Thomas in review of my hibernate-resume patchset.

 The objective benefit of this change is that in_initrd() function is used
 for checking, which not only checks for /etc/initrd-release, but also 
 verifies
 that the rootfs is on a virtual device.

 If we add a new condition then I want to hear a strong case for it.

On that note, where's the strong case for 'ConditionFirstBoot='? It's
equivalent to ConditionPathExists=/run/systemd/first-boot. And it's
needed in a single service. What makes this different from ConditionInitrd=?



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

Re: [systemd-devel] [PATCH 0/2] units: add and use ConditionInitrd= instead of checking for /etc/initrd-release.

[Lennart Poettering]

On Thu, 28.08.14 19:44, Thomas Bächler (tho...@archlinux.org) wrote:

 Am 27.08.2014 um 22:48 schrieb Thomas Bächler:
  Am 27.08.2014 um 20:25 schrieb Ivan Shapovalov:
  On Wednesday 27 August 2014 at 20:19:45, Lennart Poettering wrote: 
  On Wed, 27.08.14 20:26, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
  This is as proposed by Thomas in review of my hibernate-resume patchset.
 
  The objective benefit of this change is that in_initrd() function is used
  for checking, which not only checks for /etc/initrd-release, but also 
  verifies
  that the rootfs is on a virtual device.
 
  If we add a new condition then I want to hear a strong case for it.
 
 On that note, where's the strong case for 'ConditionFirstBoot='? It's
 equivalent to ConditionPathExists=/run/systemd/first-boot. And it's
 needed in a single service. What makes this different from ConditionInitrd=?

Well, the difference is that checking for /etc/initrd-release (which we
should actually move to /usr/lib/initrd-release similar to
/usr/lib/os-release...) is kinda official API, but
/run/systemd/first-boot is internal stuff...

People are supposed to parse the initrd-release file, but not our
internal ones...

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 0/2] units: add and use ConditionInitrd= instead of checking for /etc/initrd-release.

[Lennart Poettering]

On Wed, 27.08.14 22:48, Thomas Bächler (tho...@archlinux.org) wrote:

 Am 27.08.2014 um 20:25 schrieb Ivan Shapovalov:
  On Wednesday 27 August 2014 at 20:19:45, Lennart Poettering wrote:  
  On Wed, 27.08.14 20:26, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
  This is as proposed by Thomas in review of my hibernate-resume patchset.
 
  The objective benefit of this change is that in_initrd() function is used
  for checking, which not only checks for /etc/initrd-release, but also 
  verifies
  that the rootfs is on a virtual device.
 
  If we add a new condition then I want to hear a strong case for it. I
  mean, what's wrong with checking for initrd-release? Why would that not
  suffice?
 
 Whether or not we are in initrd is what we want to check. The existence
 of /etc/initrd-release is an implementation detail. Having the same file
 check as a condition in units duplicates the code that has been
 implemented in the in_initrd() function.

Well, in_initrd() previously did only the exacty same check, as the
condition... We added the tmpfs/ramfs check only as extra safety net,
because dracut once upon a time ended up copying the initrd-release file
into the host os and disaster ensued...

Note that the ConditionXYZ stuff in most cases is just supposed to be
optimization stuff, which allows us to skip execution of things if
there's no point to bother...

I think you do have a point though, and it would be good to use the full
in_initrd() check here, but maybe the lesson to take here is to simply
do that inside of the resume tool, rather than add a new condition for
it... That way, the condition is just an optimization, but the safety
net is inside the tool itself...

I have now commited a patch that adds this. (the generator actually
already had it...)

 In addition, someone who writes unit files should not be forced to know
 these implementation details, but should have the proper condition
 documented for the purpose.

No, /etc/initrd-release is really supposed to be API (we probably should
put together a man page for it, to make that clear). It's something an
initrd implementor has to write, and then systemd can make use of it,
but where systemd might just be one consumer of...

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 3/3] systemd-journal-upload: fix invalid After=

[Marius Tessmann]

After= belongs into [Unit], not [Install]. Found with systemd-analyze
verify.
---
 units/systemd-journal-upload.service.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/units/systemd-journal-upload.service.in 
b/units/systemd-journal-upload.service.in
index e79f962..359ff10 100644
--- a/units/systemd-journal-upload.service.in
+++ b/units/systemd-journal-upload.service.in
@@ -7,6 +7,7 @@
 
 [Unit]
 Description=Journal Remote Upload Service
+After=network.target
 
 [Service]
 ExecStart=@rootlibexecdir@/systemd-journal-upload \
@@ -18,4 +19,3 @@ WatchdogSec=20min
 
 [Install]
 WantedBy=multi-user.target
-After=network.target
-- 
2.1.0

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

[systemd-devel] [PATCH 2/3] systemd-firstboot: fix typo in man page

[Marius Tessmann]

---
 man/systemd-firstboot.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man/systemd-firstboot.xml b/man/systemd-firstboot.xml
index 5da0a75..8d97302 100644
--- a/man/systemd-firstboot.xml
+++ b/man/systemd-firstboot.xml
@@ -101,7 +101,7 @@
 allows commandsystemd-firstboot/command to operate
 on mounted but not booted disk images and in early
 boot. It is not recommended to use
-commandsystemd-firsboot/command on the running
+commandsystemd-firstboot/command on the running
 system while it is up./para
 /refsect1
 
-- 
2.1.0

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

[systemd-devel] [PATCH 1/3] systemd-firstboot.service: fix man page section

[Marius Tessmann]

Found with systemd-analyze verify.
---
 units/systemd-firstboot.service.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/units/systemd-firstboot.service.in 
b/units/systemd-firstboot.service.in
index a8719a8..6cdde5b 100644
--- a/units/systemd-firstboot.service.in
+++ b/units/systemd-firstboot.service.in
@@ -7,7 +7,7 @@
 
 [Unit]
 Description=First Boot Wizard
-Documentation=man:systemd-firstboot(8)
+Documentation=man:systemd-firstboot(1)
 DefaultDependencies=no
 Conflicts=shutdown.target
 After=systemd-readahead-collect.service systemd-readahead-replay.service 
systemd-remount-fs.service systemd-sysusers.service
-- 
2.1.0

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

[systemd-devel] systemd-resolved, multi-home DNS resolution, VPNs, and privacy

[Josh Triplett]

The documentation for systemd-resolved says it sends DNS queries on all
interfaces.  That seems like a bug for privacy and security reasons: I
don't necessarily want a query for foo.internalhost.com going anywhere
other than my VPN for internalhost.com, and if I run a VPN for privacy
purposes then I don't want *anything* other than the VPN itself to send
traffic over a non-VPN interface.  Any way we could fix that while
retaining the works out of the box behavior?

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

Re: [systemd-devel] systemd-resolved, multi-home DNS resolution, VPNs, and privacy

[Tom Gundersen]

On Thu, Aug 28, 2014 at 10:08 PM, Josh Triplett j...@joshtriplett.org wrote:
 The documentation for systemd-resolved says it sends DNS queries on all
 interfaces.  That seems like a bug for privacy and security reasons: I
 don't necessarily want a query for foo.internalhost.com going anywhere
 other than my VPN for internalhost.com, and if I run a VPN for privacy
 purposes then I don't want *anything* other than the VPN itself to send
 traffic over a non-VPN interface.  Any way we could fix that while
 retaining the works out of the box behavior?


Hi Josh,

The idea is to make it possible to lock this down further. I believe
we still lack a few bits before we have everything, but the general
idea is outlined here:
http://lists.freedesktop.org/archives/systemd-devel/2014-August/021960.html,
which I think fits with what you are after.

Cheers,

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

Re: [systemd-devel] Systemd-networkd doesn't add static routes anymore

[Moviuro]

After git bisect-ing (following dreisner's instructions on #systemd), I get 
the following info:

38de08a does not add static routes
ccf1c02 systemd-networkd is broken (does not run) (crash)
54cba0b systemd-networkd is broken (does not run) (crash)
3c9b886 systemd-networkd is broken (does not run) (crash)
68ba387 systemd-networkd works as expected

I can't help review the code as I know no C, but I hope that helps

Cheers,

On Thursday 28 August 2014 18:57:15 you wrote:
 So I downgraded to systemd 215-4 with the same kernel (3.16.1) and now I get
 my routes on tap0 as well as the 'tap0: link configured' message.
 
 Cheers,
 
 On Thursday 28 August 2014 17:27:12 you wrote:
  Hi all,
  
  I'm using systemd 216 on Archlinux (uptodate).
  Everything worked fine at last boot (systemd 215, kernel 3.14.1)
  
  Here is my tap0.network:
  [Match]
  Name=tap0
  
  [Network]
  DHCP=yes
  
  [Route]
  Gateway=10.3.16.1
  Destination=10.3.14.0/24
  
  [Route]
  Gateway=10.3.16.1
  Destination=10.3.15.0/24
  
  And the routes:
  % ip route show
  default via 192.168.1.1 dev wlan0  proto dhcp  metric 1024
  10.3.16.0/24 dev tap0  proto kernel  scope link  src 10.3.16.201
  192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.128
  192.168.1.1 dev wlan0  proto dhcp  scope link  metric 1024
  
  And relevant journal snippet:
  Aug 28 15:37:01 systemd-networkd[371]: tap0 : gained carrier
  Aug 28 15:37:01 systemd-networkd[371]: tap0 : could not set route: Network
  is unreachable
  Aug 28 15:37:01 systemd-networkd[371]: tap0 : could not set route: Network
  is unreachable
  Aug 28 15:37:01 systemd-networkd[371]: tap0 : link configured
  Aug 28 15:37:01 systemd-networkd[371]: tap0 : DHCPv4 address
  10.3.16.201/24
  Aug 28 15:37:01 systemd-networkd[371]: tap0 : link configured
  **At this point I do have all my routes**
  **Shutdown begins**
  Aug 28 16:58:54 systemd-networkd[371]: wlan0 : lost carrier
  Aug 28 16:58:54 systemd-networkd[371]: wlan0 : DHCP lease lost
  Aug 28 16:58:54 systemd-networkd[371]: tap0 : lost carrier
  Aug 28 16:58:54 systemd-networkd[371]: tap0 : DHCP lease lost
  -- Reboot --
  Aug 28 16:59:20 systemd-networkd[364]: rtnl: received address for a
  nonexistent link, ignoring
  Aug 28 16:59:20 systemd-networkd[364]: rtnl: received address for a
  nonexistent link, ignoring
  Aug 28 16:59:23 systemd-networkd[364]: wlan0 : gained carrier
  Aug 28 16:59:24 systemd-networkd[364]: wlan0 : DHCPv4 address
  192.168.1.128/24 via 192.168.1.1
  Aug 28 16:59:24 systemd-networkd[364]: wlan0 : link configured
  Aug 28 16:59:37 systemd-networkd[364]: rtnl: received address for a
  nonexistent link, ignoring
  Aug 28 16:59:37 systemd-networkd[364]: rtnl: received address for a
  nonexistent link, ignoring
  Aug 28 16:59:37 systemd-networkd[364]: tap0 : gained carrier
  Aug 28 16:59:37 systemd-networkd[364]: tap0 : could not set route: Network
  is unreachable
  Aug 28 16:59:37 systemd-networkd[364]: tap0 : could not set route: Network
  is unreachable
  Aug 28 16:59:37 systemd-networkd[364]: tap0 : DHCPv4 address
  10.3.16.201/24
  
  Note that tap0 never becomes 'configured'.
  The man does not tell any changes in networkd configuration and my setup
  is
  
   2 months old.
  
  Regards,
  --
  Moviuro @ PsychoticDelirium Our life is the immortals' death.
-- 
Moviuro @ Schizophrenia
Our life is the immortals' death

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

Re: [systemd-devel] [PATCH 1/3] systemd-firstboot.service: fix man page section

[Zbigniew Jędrzejewski-Szmek]

On Thu, Aug 28, 2014 at 10:01:44PM +0200, Marius Tessmann wrote:
 Found with systemd-analyze verify.
Heh.

Applied all three.

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

Re: [systemd-devel] [PATCHv6 0/3] hibernate-resume: implement support for resuming from hibernation

[Andrei Borzenkov]

В Thu, 28 Aug 2014 19:36:53 +0200
Jan Janssen medhe...@web.de пишет:

 On Thursday 28 August 2014 11:33:44 Ivan Shapovalov wrote:
  On Thursday 28 August 2014 at 06:25:51, Jan Janssen wrote:
   Ivan Shapovalov intelfx100 at gmail.com writes:
On Wednesday 27 August 2014 at 03:16:10, Zbigniew Jędrzejewski-Szmek 
wrote:
 On Tue, Aug 26, 2014 at 10:21:59PM +0200, Lennart Poettering wrote:
  On Wed, 27.08.14 00:17, Ivan Shapovalov (intelfx100 at gmail.com) 
  wrote:
   This patchset allows systemd to parse resume= kernel command line
   
   parameter
   
   and initiate resume from the specified device.
 
 What about swap files with the resume_offset= parameter? Are they
 still
 being used?

I don't know if somebody uses that, but for now it's missing
functionality.

After a cursory search, I could not find a mechanism to initiate a
resume with offset from userspace. In Arch, it was never implemented
even if possible. 
   I'm a heavy user of this myself. It's especially useful because you can
   just have a single luks encrypted ext4 without a lvm in between for a
   swap partition or (even more yuck) using a separate (encrypted) swap
   partition.
   
   Arch does support this, mostly because as far as I know, the
   resume_offset=
   is consumed by the kernel, while resume= has to refer to the (unencrypted)
   filesystem (/dev/mapper/root in my case). So, as long as this solution
   waits for the device to show up in /dev/ (and especially /dev/mapper/ for
   my case), this should work out.
   
   Here's information to set this up. Imho more people should be aware this
   is
   possible:
   https://wiki.archlinux.org/index.php/Suspend#Hibernation_into_swap_file
   
   Jan
  
  Hmm, so is resume_offset= parsed independently of resume=? If that's the
  case, and resume_offset= can be parsed by kernel while resume= is parsed
  by userspace, then yes, I was wrong and this should work.
  
  Actually, it should work _just like before_, sans tuxonice support.
 
 I gave it a try and resume works for me with that sd-resume hook in arch. But 
 I'm not too sure whether fsck is delayed properly:
 
 systemd[1]: Started Cryptography Setup for 
 luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78.
 systemd[1]: Found device 
 /dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78.
 systemd[1]: Starting File System Check on 
 /dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78...

Hmm ... it is not systemd-fsck-root.service. Do you have
local-fs-pre.target installed in initrd? What units are there at all?

 systemd[1]: Starting Resume from hibernation using device 
 /dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78...
 systemd-fsck[135]: fsck.ext4 doesn't exist, not checking file system on 
 /dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78
 systemd[1]: Starting Encrypted Volumes.
 systemd[1]: Reached target Encrypted Volumes.
 systemd[1]: Starting System Initialization.
 systemd[1]: Reached target System Initialization.
 systemd[1]: Starting Basic System.
 systemd[1]: Reached target Basic System.
 systemd[1]: Started File System Check on 
 /dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78.
 kernel: PM: Starting manual resume from disk
 kernel: PM: Hibernation image partition 254:0 present
 kernel: PM: Looking for hibernation image.
 systemd-hibernate-resume[137]: Could not resume from 
 '/dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78' (254:0).
 systemd[1]: Started Resume from hibernation using device 
 /dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78.
 
 If I read this correctly, the moment the plaintext device appears, the resume 
 and fsck are racing each other. And in this case,
 fsck won (good thing my fsck binaries are not in the systemd initrd for now).
 
 Jan
 ___
 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