Re: [systemd-devel] [PATCH] Generate a fake systemd-fsck-root.service in the initramfs

2015-05-10 Thread Andrei Borzenkov
В Sun, 10 May 2015 19:47:58 +
Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет:

 On Sun, May 10, 2015 at 09:59:18PM +0300, Andrei Borzenkov wrote:
  В Sun, 10 May 2015 17:23:12 +
  Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет:
  
   On Wed, May 06, 2015 at 07:12:07PM +0200, Lennart Poettering wrote:
On Wed, 06.05.15 15:50, Harald Hoyer (harald.ho...@gmail.com) wrote:

 Works for me... booted with ro on the kernel cmdline:
 
 $ systemctl status systemd-fsck-root.service
 ● systemd-fsck-root.service - File System Check on Root Device
Loaded: loaded (/usr/lib/systemd/system/systemd-fsck-root.service; 
 static;
 vendor preset: disabled)
Active: inactive (dead) since Mi 2015-05-06 15:37:58 CEST; 1min 
 44s ago
  Docs: man:systemd-fsck-root.service(8)
  Main PID: 144 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/systemd-fsck-root.service

I think tis is really confusing for the admin. he now thinks that this
is actually the exit status of the root fsck, but it's atcually just
/bin/true.
   I pushed now a version which generates a real systemd-fsck-root.service
   in the initramfs.
   
   It *does* introduce the extra synchronization dep. If it turns out to be
   a problem, it should be easy enough to fix,
  
  If it easy to fix, why not do it upfront?
 I see two ways to implement that:
 
 - add a target (e.g. systemd-fsck-root.target), and order 
 systemd-fsck-root.service
   before it, systemd-fsck-root@.service after it, but don't install this 
 target
   into the initramfs. This way, we'll have a dependency only in the real fs.
 - make the After=systemd-fsck-root.service dependency only in the real fs.
   For example, this could be done by moving it to a snippet
   /usr/lib/systemd/system/systemd-fsck@.service.d/root-dependency.conf,
   and not installing this snippet in the initramfs.
 
 Either way is easy, but annoyingly visible. If you have a non-theoretical
 use case where this matters, or a simpler / less visible way to do it,
 then indeed I'd do it right now.
 

I see. No, I do not have practical example before me. The only case
I'm aware of when this would matter is root on loop, but I have never
seen such system myself (and distribution I use currently does not
offer this in installer, as far as I know).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] nspawn: check the pid in SIGCHLD handler before terminating the container

2015-05-10 Thread systemd github import bot
Patchset imported to github.
Pull request:
https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1431278952-28662-1-git-send-email-alban%40endocode.com

--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [RESEND][PATCH] man: IPMasquerade only implies IPForward=ipv4

2015-05-10 Thread Benedikt Morbach
at least that's what the code does.
---

I didn't get any feedback last time[1], maybe this fell through the cracks?

[1] http://lists.freedesktop.org/archives/systemd-devel/2015-April/031353.html

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

diff --git a/man/systemd.network.xml b/man/systemd.network.xml
index 31484d8..5504b46 100644
--- a/man/systemd.network.xml
+++ b/man/systemd.network.xml
@@ -382,7 +382,7 @@
   interface. If enabled packets forwarded from the network
   interface will be appear as coming from the local host.
   Takes a boolean argument. Implies
-  varnameIPForward=yes/varname. Defaults to
+  varnameIPForward=ipv4/varname. Defaults to
   literalno/literal./para/listitem
 /varlistentry
 varlistentry
-- 
2.3.3

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


Re: [systemd-devel] [PATCH 2/3] Allow $SYSTEMD_PRETEND_INITRD to override initramfs detection

2015-05-10 Thread Zbigniew Jędrzejewski-Szmek
On Mon, May 04, 2015 at 12:51:27PM +, Zbigniew Jędrzejewski-Szmek wrote:
 On Mon, May 04, 2015 at 02:55:39AM +0200, Lennart Poettering wrote:
  On Sat, 02.05.15 13:16, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) 
  wrote:
  
   When testing generators and other utilities, it is extremely useful
   to be able to trigger initramfs behaviour.
  
  Hmm, what about the following solution: instead of checking with
  access() for /etc/initrd-release and then also checking with statfs()
  on / whether the root disk is writable, maybe we should just
  immediately invoke statfs() on /etc/initrd-release and check the
  results. If the call returns ENOENT we know that the file doesn't
  exist, and if it returns useful data we can verify if it's tmpfs. 
  
  Now, with that in place to test initrd code something like this
  suffices:
  
  touch /etc/initrd-release /run/initrd-release
  mount --bind /run/initrd-release /etc/initrd-release
  
  As that would result in a file in /etc/initrd-release that is backed
  by tmpfs
  
  In general I'd be very conservative when adding new APIs (which is
  basically what $SYSTEMD_PRETEND_INITRD would become), especially if we
  only need them for debugging, they are are quiet dangerous and when we
  have other options too...
 Hm, this would require root privileges, and is a global setting. I'd like to
 by able to do something like this:
 
  mkdir /tmp/x  SYSTEMD_PRETEND_INITRD=0 ./systemd-fstab-generator 
 /tmp/{x,x,x}
  mkdir /tmp/y  SYSTEMD_PRETEND_INITRD=1 ./systemd-fstab-generator 
 /tmp/{y,y,y}
  diff -r /tmp/{x,y}
 
 If I have to issue some sudo stuff in between than it's probably not
 worth it.
 
 What about having a compilation time switch (like -DVALGRIND that we
 already have), which would be used to conditionalize support for
 SYSTEMD_PRETEND_INITRD, and potentially similar things later on? This
 would make it fairly easy to build or even install systemd with
 support for this, without creating a public API.
Any thoughts on this?

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


Re: [systemd-devel] [PATCH] Generate a fake systemd-fsck-root.service in the initramfs

2015-05-10 Thread Zbigniew Jędrzejewski-Szmek
On Wed, May 06, 2015 at 07:12:07PM +0200, Lennart Poettering wrote:
 On Wed, 06.05.15 15:50, Harald Hoyer (harald.ho...@gmail.com) wrote:
 
  Works for me... booted with ro on the kernel cmdline:
  
  $ systemctl status systemd-fsck-root.service
  ● systemd-fsck-root.service - File System Check on Root Device
 Loaded: loaded (/usr/lib/systemd/system/systemd-fsck-root.service; 
  static;
  vendor preset: disabled)
 Active: inactive (dead) since Mi 2015-05-06 15:37:58 CEST; 1min 44s ago
   Docs: man:systemd-fsck-root.service(8)
   Main PID: 144 (code=exited, status=0/SUCCESS)
 CGroup: /system.slice/systemd-fsck-root.service
 
 I think tis is really confusing for the admin. he now thinks that this
 is actually the exit status of the root fsck, but it's atcually just
 /bin/true.
I pushed now a version which generates a real systemd-fsck-root.service
in the initramfs.

It *does* introduce the extra synchronization dep. If it turns out to be
a problem, it should be easy enough to fix, iff anyone actually encounters
that in practice.

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


[systemd-devel] Systemd 215 cannot start journald 219 inside systemd-nspawn

2015-05-10 Thread Felipe Sateler
Hi,

I'm having a problem with a systemd-nspawn'ed container. The guest
journal will not start and thus I have no logs.

The host is a 215 Debian Jessie system. The guest is a 219 Debian Sid system.

The nspawn unit is at http://paste.debian.net/173849/
The host journal log for the systemd process is at
http://paste.debian.net/173848/

Trying to run systemd-journald manually yields the following error:

Failed to join audit multicast group: Operation not permitted

Downgrading the guest systemd to 215 enables journald to start normally.

Is this expected? Or more importantly, can this problem be worked
around without upgrading the host or downgrading the guest?

-- 

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


[systemd-devel] [PATCH] nspawn: check the pid in SIGCHLD handler before terminating the container

2015-05-10 Thread Alban Crequy
From: Alban Crequy al...@endocode.com

When a process starts systemd-nspawn with exec*() without fork(),
systemd-nspawn can be the parent process of children processes unknown
to systemd-nspawn. It can then receive the signal SIGCHLD for both the
container leader process and the previously started processes. So it
should distinguish them.
---
 src/nspawn/nspawn.c | 51 +--
 1 file changed, 45 insertions(+), 6 deletions(-)

diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index 05d2c71..49f6650 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -23,6 +23,7 @@
 #include sched.h
 #include unistd.h
 #include sys/types.h
+#include sys/wait.h
 #include sys/mount.h
 #include stdlib.h
 #include string.h
@@ -3511,6 +3512,12 @@ static int change_uid_gid(char **_home) {
 return 0;
 }
 
+typedef struct SigChildData {
+pid_t leader_pid;
+siginfo_t leader_status;
+bool terminated;
+} SigChildData;
+
 /*
  * Return values:
  *  0 : wait_for_terminate() failed to get the state of the
@@ -3528,13 +3535,17 @@ static int change_uid_gid(char **_home) {
  * That is, success is indicated by a return value of zero, and an
  * error is indicated by a non-zero value.
  */
-static int wait_for_container(pid_t pid, ContainerStatus *container) {
+static int wait_for_container(SigChildData *sigchld_ctx, pid_t pid, 
ContainerStatus *container) {
 siginfo_t status;
 int r;
 
-r = wait_for_terminate(pid, status);
-if (r  0)
-return log_warning_errno(r, Failed to wait for container: 
%m);
+if (sigchld_ctx-terminated) {
+status = sigchld_ctx-leader_status;
+} else {
+r = wait_for_terminate(pid, status);
+if (r  0)
+return log_warning_errno(r, Failed to wait for 
container: %m);
+}
 
 switch (status.si_code) {
 
@@ -3594,6 +3605,31 @@ static int on_orderly_shutdown(sd_event_source *s, const 
struct signalfd_siginfo
 return 0;
 }
 
+static int on_sigchld(sd_event_source *s, const struct signalfd_siginfo *si, 
void *userdata) {
+SigChildData *ctx = userdata;
+pid_t leader_pid = ctx-leader_pid;
+
+/* several terminated children could be merged in a single SIGCHLD, so
+ * don't rely on si-ssi_pid. */
+
+while (1) {
+int r;
+siginfo_t status;
+
+zero(status);
+r = waitid(P_ALL, -1, status, WEXITED | WNOHANG);
+if (r  0)
+break;
+if (status.si_pid == leader_pid) {
+ctx-leader_status = status;
+ctx-terminated = true;
+return sd_event_exit(sd_event_source_get_event(s), 0);
+}
+}
+
+return 0;
+}
+
 static int determine_names(void) {
 int r;
 
@@ -3917,6 +3953,7 @@ int main(int argc, char *argv[]) {
 .sa_handler = nop_handler,
 .sa_flags = SA_NOCLDSTOP,
 };
+SigChildData sigchld_ctx = {0,};
 
 r = barrier_create(barrier);
 if (r  0) {
@@ -4386,7 +4423,9 @@ int main(int argc, char *argv[]) {
 }
 
 /* simply exit on sigchld */
-sd_event_add_signal(event, NULL, SIGCHLD, 
NULL, NULL);
+sigchld_ctx.leader_pid = pid;
+sigchld_ctx.terminated = false;
+sd_event_add_signal(event, NULL, SIGCHLD,  
on_sigchld , sigchld_ctx);
 
 if (arg_expose_ports) {
 r = watch_rtnl(event, 
rtnl_socket_pair[0], exposed, rtnl);
@@ -4425,7 +4464,7 @@ int main(int argc, char *argv[]) {
 /* Normally redundant, but better safe than sorry */
 kill(pid, SIGKILL);
 
-r = wait_for_container(pid, container_status);
+r = wait_for_container(sigchld_ctx, pid, container_status);
 pid = 0;
 
 if (r  0)
-- 
2.1.4

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


[systemd-devel] [PATCH] networkd: don't touch global forwarding setting

2015-05-10 Thread Benedikt Morbach
This reverts commit 43c6d5abacaebf813845934ec8d5e5ee3c431854
(and a small part of 4046d8361c55c80ab8577aea52523b9e6eab0d0c)

It turns out we don't actually need to set the global ip_forward setting.
The only relevant setting is the one on each interface.

What the global toggle actually does is switch forwarding on/off for all
currently present interfaces and change the default for new ones.

That means that by setting the global ip_forward we

  - Introduce a race condition, because if the interface with IPForward=yes
is brought up after one with IPForward=no, both will have forwarding
enabled, because the global switch turns it on for all interfaces.
If the other interface comes up first networkd correctly sets forward=0
and it doesn't get overridden.

  - Change the forwarding setting for interfaces that networkd is not
configured to touch, even if the user disabled forwarding via sysctl,
either globally or per-interface

As forwarding works fine without this, as long as all relevant interfacest
individually set IPForward=yes:  just drop it

This means that non-networkd interfaces use the global default while
networkd interfaces default to off if IPForward isn't given.
---

There were no comments last time[1], maybe it fell through the cracks?

For reference, I have IPForward=yes on br0.network and enp0s25.network.
My /proc/sys/net/ipv4 looks like this and forwarding works fine:

/proc/sys/net/ipv4/ip_forward   0
/proc/sys/net/ipv4/conf/all/forwarding  0
/proc/sys/net/ipv4/conf/br0/forwarding  1
/proc/sys/net/ipv4/conf/default/forwarding  0
/proc/sys/net/ipv4/conf/enp0s25/forwarding  1
...
/proc/sys/net/ipv4/conf/wlp3s0/forwarding   0

before this patch it was:

/proc/sys/net/ipv4/ip_forward   1
/proc/sys/net/ipv4/conf/all/forwarding  1
/proc/sys/net/ipv4/conf/br0/forwarding  1
/proc/sys/net/ipv4/conf/default/forwarding  1
/proc/sys/net/ipv4/conf/enp0s25/forwarding  1
...
/proc/sys/net/ipv4/conf/wlp3s0/forwarding   [0 or 1 randomly depending on 
if it was faster than br0 and enp0s25 or not]

Even though forwarding is disabled globally via sysctl and wlp3s0 has no 
IPForward.

[1] http://lists.freedesktop.org/archives/systemd-devel/2015-April/031352.html

 man/systemd.network.xml |  4 +---
 src/network/networkd-link.c | 28 +---
 2 files changed, 2 insertions(+), 30 deletions(-)

diff --git a/man/systemd.network.xml b/man/systemd.network.xml
index e4d1820..5504b46 100644
--- a/man/systemd.network.xml
+++ b/man/systemd.network.xml
@@ -373,9 +373,7 @@
   globally turned on in the kernel, with the
   filenamenet.ipv4.ip_forward/filename and
   filenamenet.ipv4.ip_forward/filename sysctl
-  options. Also, if this option is enabled for at least one
-  interface, the global options in the kernel are also enabled
-  as necessary, to ensure IP forwarding can take place./para
+  options./para
   /listitem
 /varlistentry
 varlistentry
diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
index 0c6bb65..5d0f199 100644
--- a/src/network/networkd-link.c
+++ b/src/network/networkd-link.c
@@ -1486,39 +1486,13 @@ static int link_enter_join_netdev(Link *link) {
 
 static int link_set_ipv4_forward(Link *link) {
 const char *p = NULL;
-bool b;
 int r;
 
-b = link_ipv4_forward_enabled(link);
-
 p = strjoina(/proc/sys/net/ipv4/conf/, link-ifname, /forwarding);
-r = write_string_file_no_create(p, one_zero(b));
+r = write_string_file_no_create(p, 
one_zero(link_ipv4_forward_enabled(link)));
 if (r  0)
 log_link_warning_errno(link, r, Cannot configure IPv4 
forwarding for interface %s: %m, link-ifname);
 
-if (b) {
-_cleanup_free_ char *buf = NULL;
-
-/* If IP forwarding is turned on for this interface,
- * then propagate this to the global setting. Given
- * that turning this on has side-effects on other
- * fields, we'll try to avoid doing this unless
- * necessary, hence check the previous value
- * first. Note that we never turn this option off
- * again, since all interfaces we manage do not do
- * forwarding anyway by default, and ownership rules
- * of this control are so unclear. */
-
-r = read_one_line_file(/proc/sys/net/ipv4/ip_forward, buf);
-if (r  0)
-log_link_warning_errno(link, r, Cannot read 
/proc/sys/net/ipv4/ip_forward: %m);
-else if (!streq(buf, 1)) {
-r = 
write_string_file_no_create(/proc/sys/net/ipv4/ip_forward, 1);
-if (r  0)
-log_link_warning_errno(link, r, Cannot write 

Re: [systemd-devel] [PATCH] Generate a fake systemd-fsck-root.service in the initramfs

2015-05-10 Thread Andrei Borzenkov
В Sun, 10 May 2015 17:23:12 +
Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет:

 On Wed, May 06, 2015 at 07:12:07PM +0200, Lennart Poettering wrote:
  On Wed, 06.05.15 15:50, Harald Hoyer (harald.ho...@gmail.com) wrote:
  
   Works for me... booted with ro on the kernel cmdline:
   
   $ systemctl status systemd-fsck-root.service
   ● systemd-fsck-root.service - File System Check on Root Device
  Loaded: loaded (/usr/lib/systemd/system/systemd-fsck-root.service; 
   static;
   vendor preset: disabled)
  Active: inactive (dead) since Mi 2015-05-06 15:37:58 CEST; 1min 44s ago
Docs: man:systemd-fsck-root.service(8)
Main PID: 144 (code=exited, status=0/SUCCESS)
  CGroup: /system.slice/systemd-fsck-root.service
  
  I think tis is really confusing for the admin. he now thinks that this
  is actually the exit status of the root fsck, but it's atcually just
  /bin/true.
 I pushed now a version which generates a real systemd-fsck-root.service
 in the initramfs.
 
 It *does* introduce the extra synchronization dep. If it turns out to be
 a problem, it should be easy enough to fix,

If it easy to fix, why not do it upfront?

iff anyone actually encounters
 that in practice.
 
 Zbyszek
 ___
 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] networkd: don't touch global forwarding setting

2015-05-10 Thread systemd github import bot
Patchset imported to github.
Pull request:
https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1431283960-2691-1-git-send-email-benedikt.morbach%40googlemail.com

--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [RESEND][PATCH] man: IPMasquerade only implies IPForward=ipv4

2015-05-10 Thread systemd github import bot
Patchset imported to github.
Pull request:
https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1431282734-1026-1-git-send-email-benedikt.morbach%40googlemail.com

--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] Generate a fake systemd-fsck-root.service in the initramfs

2015-05-10 Thread Zbigniew Jędrzejewski-Szmek
On Sun, May 10, 2015 at 09:59:18PM +0300, Andrei Borzenkov wrote:
 В Sun, 10 May 2015 17:23:12 +
 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет:
 
  On Wed, May 06, 2015 at 07:12:07PM +0200, Lennart Poettering wrote:
   On Wed, 06.05.15 15:50, Harald Hoyer (harald.ho...@gmail.com) wrote:
   
Works for me... booted with ro on the kernel cmdline:

$ systemctl status systemd-fsck-root.service
● systemd-fsck-root.service - File System Check on Root Device
   Loaded: loaded (/usr/lib/systemd/system/systemd-fsck-root.service; 
static;
vendor preset: disabled)
   Active: inactive (dead) since Mi 2015-05-06 15:37:58 CEST; 1min 44s 
ago
 Docs: man:systemd-fsck-root.service(8)
 Main PID: 144 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/systemd-fsck-root.service
   
   I think tis is really confusing for the admin. he now thinks that this
   is actually the exit status of the root fsck, but it's atcually just
   /bin/true.
  I pushed now a version which generates a real systemd-fsck-root.service
  in the initramfs.
  
  It *does* introduce the extra synchronization dep. If it turns out to be
  a problem, it should be easy enough to fix,
 
 If it easy to fix, why not do it upfront?
I see two ways to implement that:

- add a target (e.g. systemd-fsck-root.target), and order 
systemd-fsck-root.service
  before it, systemd-fsck-root@.service after it, but don't install this target
  into the initramfs. This way, we'll have a dependency only in the real fs.
- make the After=systemd-fsck-root.service dependency only in the real fs.
  For example, this could be done by moving it to a snippet
  /usr/lib/systemd/system/systemd-fsck@.service.d/root-dependency.conf,
  and not installing this snippet in the initramfs.

Either way is easy, but annoyingly visible. If you have a non-theoretical
use case where this matters, or a simpler / less visible way to do it,
then indeed I'd do it right now.

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