Re: [systemd-devel] host0 virtual link suddenly default down in systemd-nspawn container

[Ansgar Burchardt]

Johannes Ernst writes:
> I've been running the same systemd-nspawn container for some time, always 
> with the same options:
>
>   systemd-nspawn -b -n -D dir -M name --bind /home -x
>
> It would always bring up the virtual ethernet link immediately during
> boot of the container. But since a recent Arch (host) upgrade (I
> think), the virtual ethernet link host0 now stays "down" during boot
> of the container:

Do you use systemd-networkd?  I noticed that systemd-networks no longer
starts in nspawn containers (the condition for CAP_NET_ADMIN failed), so
nothing configured the network interface after upgrading to systemd 243
in Debian experimental.

I haven't had time to investigate the problem further.

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

Re: [systemd-devel] about administator Authentication agents

[Ansgar Burchardt]

On Mon, 2015-11-23 at 15:09 +0100, Michael Biebl wrote:
> 2015-11-23 13:32 GMT+01:00 Mantas Mikulėnas :
> > I remember Debian had an oddly restrictive policy for systemd bus
> > access
> > (though it seems to be fixed now?).
> 
> The Debian systemd package never diverged from the upstream D-Bus
> policy afair.
> 
> *But* in the past, the systemd-shim package shipped it's own set of
> D-Bus policies which broke systemd [1]. This has been fixed for a
> very
> long time though.
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765101

Even though it has been fixed for a long time, I think users can still
be affected by this: if systemd-shim was removed (but not purged)
before the bug was fixed, the wrong DBus policy would still stay around
as it was included as a conffile...

So if the initial poster uses Debian or a Debian-derived distribution,
it might be worth making sure that systemd-shim was purged, for example
by running "apt-get purge systemd-shim".

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

Re: [systemd-devel] How does systemd discover template instances?

[Ansgar Burchardt]

Michael Chapman  writes:
> On Thu, 15 Oct 2015, Stuart Longland wrote:
>> Assuming I have a few files distributed in the base package:
>>  /lib/systemd/system/comms-drivers.service
>>  /lib/systemd/system/comms-drivers@.service
>>
>> Ordinarily, one would tell systemd about template instances by creating
>> symbolic links.
>>
>> Suppose however I wanted to not do this, but instead, provide some
>> automatic discovery mechanism for systemd, so it could run a script that
>> would tell it what instances exist.
>>
>> Is there a mechanism for doing this in systemd?
>
> One approach you might want to consider is using a systemd generator
> [1] to create the instance symlinks automatically at boot, e.g.:

This was done for OpenVPN in Debian. As Stuart said he based his
sysvinit script on Debian's openvpn script, the systemd integration
might also help him.

The generator can be found at [2], the .service files at [3] and [4].

Ansgar

  [2] 

  [3] 

  [4] 

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

Re: [systemd-devel] [HEADSUP] systemd-222 around the corner

[Ansgar Burchardt]

Hi,

Colin Guthrie gm...@colin.guthr.ie writes:
 Bit late now, but does anyone else have the issue that calling
 systemctl reload will kill off any machines registered in machined.

 To me the problem commit is 9b420b3cfb8b93daf50e4cdbc92b05f2209ef893.

 machined: make sure to track machine unit states properly

 Can someone confirm this? (mentioned it in the getent hosts machine
 thread but no one confirmed - or denied - the problem there).

I can confirm that systemctl daemon-reload will make machined lose
track of containers (though the container itself keeps running) and
already opened an issue[1].

I haven't tried if reverting the commit you mentioned fixes it, but I
think the real issue might be systemd emitting UnitRemoved signals on
reload... It seems semantically incorrect to do so.

Ansgar

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

[systemd-devel] systemd-networkd: option for IPv6 privacy extension?

[Ansgar Burchardt]

Hi,

I'm wondering if systemd-networkd could provide an option to control the
IPv6 privacy extension? It is controlled via a sysctl setting:

  net.ipv6.conf.${interface}.use_tempaddr

with three values:

  = 0 : disable Privacy Extensions
  == 1 : enable Privacy Extensions, but prefer public
 addresses over temporary addresses.
1 : enable Privacy Extensions and prefer temporary
 addresses over public addresses.

-- Documentation/networking/ip-sysctl.txt

It would be nice if systemd-networkd would allow to control these
options, for example by a IP6Privacy setting in the Address section of
.network units (NetworkManager already uses ip6-privacy).

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

Re: [systemd-devel] [PATCH] parse_boolean: require exact matches

[Ansgar Burchardt]

Lennart Poettering lenn...@poettering.net writes:
 On Sun, 27.07.14 15:19, Ansgar Burchardt (ans...@debian.org) wrote:
 Require exact matches in all cases instead of treating strings
 starting with 't' ('f') as true (false).
 
 This is required for config_parse_protect_system to parse ProtectSystem=full
 correctly: it uses parse_boolean and only tries a more specific parsing
 function if that did not return a valid result. Thus full was treated as
 false before.

 Hmm, that sounds as if we also should change the order in which we parse
 the string, no? I mean, first try to parse it as native enum, and only
 if that doesn't work parse it as boolean?

The order should not matter as long as the allowed values for
ProtectSystem and similar options stays a superset of those for
booleans.

Changing just the order instead of requiring exact matches in
parse_boolean would not be so nice: a mistyped 'fill' instead of 'full'
would silently be parsed as 'false' instead of giving an error.

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

[systemd-devel] Support for pre-restart check

[Ansgar Burchardt]

Hi,

while looking at how to convert sysvinit scripts to service files in
Debian, I noticed that some scripts do an additional sanity check during
the restart action. That is, they run an extra command to validate the
configuration and only restart the service on success.

Systemd doesn't seem to provide such an option so far. Would you think
this is something one would like to see? If yes, what about the
following idea:

Add an ExecRestartPre option in the [Service] section. These commands
are executed when a restart is requested, before the service is stopped.
If they fail, the restart is aborted with an error.

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

Re: [systemd-devel] Support for pre-restart check

[Ansgar Burchardt]

Hi,

On 07/30/2014 13:26, Jóhann B. Guðmundsson wrote:
 On 07/30/2014 10:22 AM, Ansgar Burchardt wrote:
 while looking at how to convert sysvinit scripts to service files in
 Debian, I noticed that some scripts do an additional sanity check during
 the restart action. That is, they run an extra command to validate the
 configuration and only restart the service on success.

 Systemd doesn't seem to provide such an option so far. Would you think
 this is something one would like to see? If yes, what about the
 following idea:

 Add an ExecRestartPre option in the [Service] section. These commands
 are executed when a restart is requested, before the service is stopped.
 If they fail, the restart is aborted with an error.

 This has been discussed before and check the archive for that discussion
 but the bottom line is that this is not needed we already have
 ExecStartPre=, ExecStartPost=, ExecStop=, ExecStopPost=, or ExecReload=
 which cover those usecases

I searched for such discussion, but did not find anything relevant. Do
you have a link?

And how would you use the existing Exec* options to cover this usecase?
ExecStart* certainly doesn't help, ExecReload only works for reload and
not for restart.  ExecStop is to actually stop the service (and should
not fail due to invalid configuration); ExecStopPost is too late.

Ansgar

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

[systemd-devel] [PATCH] Correct references to ProtectSystem and ProtectHome in documentation

[Ansgar Burchardt]

---
 NEWS | 2 +-
 man/systemd.exec.xml | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/NEWS b/NEWS
index 71017fa..d6cbc5a 100644
--- a/NEWS
+++ b/NEWS
@@ -299,7 +299,7 @@ CHANGES WITH 214:
   moved to /run/systemd/resolve/. If you have a symlink from
   /etc/resolv.conf, it might be necessary to correct it.
 
-* Two new service settings, ProtectedHome= and ProtectedSystem=,
+* Two new service settings, ProtectHome= and ProtectSystem=,
   have been added. When enabled, they will make the user data
   (such as /home) inaccessible or read-only and the system
   (such as /usr) read-only, for specific services. This allows
diff --git a/man/systemd.exec.xml b/man/systemd.exec.xml
index 2f75915..a1eb112 100644
--- a/man/systemd.exec.xml
+++ b/man/systemd.exec.xml
@@ -1027,8 +1027,8 @@
 namespace related options
 (varnamePrivateTmp=/varname,
 varnamePrivateDevices=/varname,
-varnameReadOnlySystem=/varname,
-varnameProtectedHome=/varname,
+varnameProtectSystem=/varname,
+varnameProtectHome=/varname,
 varnameReadOnlyDirectories=/varname,
 varnameInaccessibleDirectories=/varname
 and
-- 
2.0.1

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

[systemd-devel] [PATCH] parse_boolean: require exact matches

[Ansgar Burchardt]

Require exact matches in all cases instead of treating strings
starting with 't' ('f') as true (false).

This is required for config_parse_protect_system to parse ProtectSystem=full
correctly: it uses parse_boolean and only tries a more specific parsing
function if that did not return a valid result. Thus full was treated as
false before.
---
 src/shared/util.c| 4 ++--
 src/test/test-util.c | 1 +
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/shared/util.c b/src/shared/util.c
index 4fda31c..49c17ef 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -231,9 +231,9 @@ int unlink_noerrno(const char *path) {
 int parse_boolean(const char *v) {
 assert(v);
 
-if (streq(v, 1) || v[0] == 'y' || v[0] == 'Y' || v[0] == 't' || v[0] 
== 'T' || strcaseeq(v, on))
+if (streq(v, 1) || strcaseeq(v, yes) || strcaseeq(v, y) || 
strcaseeq(v, true) || strcaseeq(v, t) || strcaseeq(v, on))
 return 1;
-else if (streq(v, 0) || v[0] == 'n' || v[0] == 'N' || v[0] == 'f' || 
v[0] == 'F' || strcaseeq(v, off))
+else if (streq(v, 0) || strcaseeq(v, no) || strcaseeq(v, n) || 
strcaseeq(v, false) || strcaseeq(v, f) || strcaseeq(v, off))
 return 0;
 
 return -EINVAL;
diff --git a/src/test/test-util.c b/src/test/test-util.c
index ed91a67..9a28ef9 100644
--- a/src/test/test-util.c
+++ b/src/test/test-util.c
@@ -129,6 +129,7 @@ static void test_parse_boolean(void) {
 
 assert_se(parse_boolean(garbage)  0);
 assert_se(parse_boolean()  0);
+assert_se(parse_boolean(full)  0);
 }
 
 static void test_parse_pid(void) {
-- 
2.0.1

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

[systemd-devel] [PATCH] drop_duplicates: copy full BindMount struct

[Ansgar Burchardt]

At least

  t-ignore = f-ignore;

is missing here. Just copy the full struct to be sure.
---
 src/core/namespace.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/core/namespace.c b/src/core/namespace.c
index 5466b7b..fe95377 100644
--- a/src/core/namespace.c
+++ b/src/core/namespace.c
@@ -124,8 +124,7 @@ static void drop_duplicates(BindMount *m, unsigned *n) {
 if (previous  path_equal(f-path, previous-path))
 continue;
 
-t-path = f-path;
-t-mode = f-mode;
+*t = *f;
 
 previous = t;
 
-- 
2.0.1

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

[systemd-devel] Reason for IgnoreSIGPIPE=true by default

[Ansgar Burchardt]

Hi,

I'm wondering what the reason for IgnoreSIGPIPE to default to true is.
The documentation just states that

Defaults to true because SIGPIPE generally is useful only in shell
pipelines.

But I don't think that this alone is a good reason to change the default.

It can confuse programs which use pipes and do not expect their signal
handlers to be messed with, see [1] for the same issue in Python. As
another example, tar xf *.tar.gz will fail on some archives if SIGPIPE
is ignored[2].

Another problem is that this not only affects the program started by
systemd itself, but leaks into all child processes as well. See [3] for
a bug report against cron due to this (yes, can be worked around by
setting IgnoreSIGPIPE=false for cron.service, but I believe systemd is
wrong here).

Ansgar

  [1] http://bugs.python.org/issue1652
  [2] I think the .gz needs trailing zeros in either the compressed or
  uncompressed data stream. I could look at the file it failed
  with...
  [3] https://bugs.debian.org/756047
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] NEWS: fix typo

[Ansgar Burchardt]

---
 NEWS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/NEWS b/NEWS
index 73a1dc2..41ed127 100644
--- a/NEWS
+++ b/NEWS
@@ -30,7 +30,7 @@ CHANGES WITH 210:
 * logind will now watch SW_DOCK switches and inhibit reaction
   to the lid switch if it is pressed. This means that logind
   will not suspend the machine anymore if the lid is closed
-  and the systemd is docked, if the laptop supports SW_DOCK
+  and the system is docked, if the laptop supports SW_DOCK
   notifications via the input layer. Note that ACPI docking
   stations do not generate this currently. Also note that this
   logic is usually not fully sufficient and Desktop
-- 
1.8.5.3

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

[systemd-devel] [PATCH] man: fix a typo

[Ansgar Burchardt]

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

diff --git a/man/journald.conf.xml b/man/journald.conf.xml
index 03bcd0c..9516432 100644
--- a/man/journald.conf.xml
+++ b/man/journald.conf.xml
@@ -400,7 +400,7 @@
 and
 
literalsystemd.journald.forward_to_console=/literal.
 When forwarding to the console, the
-TTY to log to log to can be changed
+TTY to log to can be changed
 with varnameTTYPath=/varname,
 described below./para/listitem
 /varlistentry
-- 
1.8.5.3

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