Re: [systemd-devel] [RFC 25/25] add -z muldefs to linker flags

[Michael Biebl]

2014-09-19 0:34 GMT+02:00 David Herrmann dh.herrm...@gmail.com:
  -Wl,-fuse-ld=gold])

The reason to use gold  was that the compat libraries require the
ifunc functionality.

This is no longer the case, so I'd suggest to not override the default
linker and simply use the system default one.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] socket-proxyd: Unchecked return value from library

[Susant Sahani]

CID 1237543 (#1 of 1): Unchecked return value from library
(CHECKED_RETURN)
---
 src/socket-proxy/socket-proxyd.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/socket-proxy/socket-proxyd.c b/src/socket-proxy/socket-proxyd.c
index ff2b24f..7b0714d 100644
--- a/src/socket-proxy/socket-proxyd.c
+++ b/src/socket-proxy/socket-proxyd.c
@@ -125,7 +125,11 @@ static int connection_create_pipes(Connection *c, int 
buffer[2], size_t *sz) {
 return -errno;
 }
 
-fcntl(buffer[0], F_SETPIPE_SZ, BUFFER_SIZE);
+r = fcntl(buffer[0], F_SETPIPE_SZ, BUFFER_SIZE);
+if (r  0) {
+log_error(Failed to set pipe buffer size: %m);
+return -errno;
+}
 
 r = fcntl(buffer[0], F_GETPIPE_SZ);
 if (r  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] socket-proxyd: Unchecked return value from library

[David Herrmann]

Hi

On Fri, Sep 19, 2014 at 9:57 AM, Susant Sahani sus...@redhat.com wrote:
 CID 1237543 (#1 of 1): Unchecked return value from library
 (CHECKED_RETURN)
 ---
  src/socket-proxy/socket-proxyd.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

 diff --git a/src/socket-proxy/socket-proxyd.c 
 b/src/socket-proxy/socket-proxyd.c
 index ff2b24f..7b0714d 100644
 --- a/src/socket-proxy/socket-proxyd.c
 +++ b/src/socket-proxy/socket-proxyd.c
 @@ -125,7 +125,11 @@ static int connection_create_pipes(Connection *c, int 
 buffer[2], size_t *sz) {
  return -errno;
  }

 -fcntl(buffer[0], F_SETPIPE_SZ, BUFFER_SIZE);
 +r = fcntl(buffer[0], F_SETPIPE_SZ, BUFFER_SIZE);
 +if (r  0) {
 +log_error(Failed to set pipe buffer size: %m);
 +return -errno;
 +}

I don't think that's right. Ignoring the return value of that fcntl is
just fine. We read the buffer-size afterwards, so if it failed, we
still continue properly. See fcntl(2) for a bunch of errors that might
happen and really shouldn't be fatal nor cause log-messages (like
EBUSY if we try to _reduce_ the buffer size).

Thanks
David


  r = fcntl(buffer[0], F_GETPIPE_SZ);
  if (r  0) {
 --
 1.9.3

 ___
 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] socket-proxyd: Unchecked return value from library

[Susant Sahani]

On 09/19/2014 01:35 PM, David Herrmann wrote:

Hi


Hi,


On Fri, Sep 19, 2014 at 9:57 AM, Susant Sahani sus...@redhat.com wrote:

CID 1237543 (#1 of 1): Unchecked return value from library
(CHECKED_RETURN)
---
  src/socket-proxy/socket-proxyd.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/socket-proxy/socket-proxyd.c b/src/socket-proxy/socket-proxyd.c
index ff2b24f..7b0714d 100644
--- a/src/socket-proxy/socket-proxyd.c
+++ b/src/socket-proxy/socket-proxyd.c
@@ -125,7 +125,11 @@ static int connection_create_pipes(Connection *c, int 
buffer[2], size_t *sz) {
  return -errno;
  }

-fcntl(buffer[0], F_SETPIPE_SZ, BUFFER_SIZE);
+r = fcntl(buffer[0], F_SETPIPE_SZ, BUFFER_SIZE);
+if (r  0) {
+log_error(Failed to set pipe buffer size: %m);
+return -errno;
+}


I don't think that's right. Ignoring the return value of that fcntl is
just fine. We read the buffer-size afterwards, so if it failed, we
still continue properly. See fcntl(2) for a bunch of errors that might


Well I think set and get are two operations. for example let's say set 
failed but get success.
setting BUFFER_SIZE failed and in this case buf size is remained as 
default pipe size.



happen and really shouldn't be fatal nor cause log-messages (like
EBUSY if we try to _reduce_ the buffer size).

Thanks
David


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

Re: [systemd-devel] [PATCH] socket-proxyd: Unchecked return value from library

[David Herrmann]

Hi

On Fri, Sep 19, 2014 at 10:28 AM, Susant Sahani sus...@redhat.com wrote:
 On 09/19/2014 01:35 PM, David Herrmann wrote:
 I don't think that's right. Ignoring the return value of that fcntl is
 just fine. We read the buffer-size afterwards, so if it failed, we
 still continue properly. See fcntl(2) for a bunch of errors that might


 Well I think set and get are two operations. for example let's say set
 failed but get success.
 setting BUFFER_SIZE failed and in this case buf size is remained as default
 pipe size.

..exactly! And the default buffer size is just fine. We'd prefer if we
could set it to BUFFER_SIZE, but if we're not allowed to do that, we
still continue running with the already set buffer size.

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

Re: [systemd-devel] [PATCH] ask-password: Add --do-echo to enable echoing the user input

[David Sommerseth]

On 18/09/14 18:02, Colin Guthrie wrote:
 I'd rather the ability to make a single request and have the agent ask
 for all credentials and reply once rather than looping over both
 separately however.

+1 ... But I'll have to say that this will require a bit of re-designing
old cold paths in OpenVPN.  But it is doable.  Anyhow, AFAIK (and nobody
have told me otherwise in this ML), such an approach does not exist.
I've heard vague rumours about a new implementation using dbus, but not
seen any clear evidence of that yet.

Right now (which is the situation I try to solve), it is the issue of
avoiding masking username which is my primary goal, as it seems
ask-password is the only way to get user input via systemd.  When an
agreed approach can be reached, I can adopt OpenVPN and submit the
needed patches to that community.

When systemd have landed on a better approach, I'll be happy to include
patches in OpenVPN to go in that direction.


All this said, I'll post another updated to this patch soonish.  When
going through the tty-ask-password-agent, the masking still happens.
I'm digging into that now.


--
kind regards,

David Sommerseth

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

Re: [systemd-devel] [PATCH] socket-proxyd: Unchecked return value from library

[Susant Sahani]

On 09/19/2014 02:00 PM, David Herrmann wrote:

Hi

On Fri, Sep 19, 2014 at 10:28 AM, Susant Sahani sus...@redhat.com wrote:

On 09/19/2014 01:35 PM, David Herrmann wrote:

I don't think that's right. Ignoring the return value of that fcntl is
just fine. We read the buffer-size afterwards, so if it failed, we
still continue properly. See fcntl(2) for a bunch of errors that might



Well I think set and get are two operations. for example let's say set
failed but get success.
setting BUFFER_SIZE failed and in this case buf size is remained as default
pipe size.


..exactly! And the default buffer size is just fine. We'd prefer if we
could set it to BUFFER_SIZE, but if we're not allowed to do that, we
still continue running with the already set buffer size.


yes but how about giving a log for coverity and we ignore the error ?



Thanks
David



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

Re: [systemd-devel] [PATCH] socket-proxyd: Unchecked return value from library

[Alexander E. Patrakov]

19.09.2014 14:35, Susant Sahani wrote:

On 09/19/2014 02:00 PM, David Herrmann wrote:

Hi

On Fri, Sep 19, 2014 at 10:28 AM, Susant Sahani sus...@redhat.com
wrote:

On 09/19/2014 01:35 PM, David Herrmann wrote:

I don't think that's right. Ignoring the return value of that fcntl is
just fine. We read the buffer-size afterwards, so if it failed, we
still continue properly. See fcntl(2) for a bunch of errors that might



Well I think set and get are two operations. for example let's say set
failed but get success.
setting BUFFER_SIZE failed and in this case buf size is remained as
default
pipe size.


..exactly! And the default buffer size is just fine. We'd prefer if we
could set it to BUFFER_SIZE, but if we're not allowed to do that, we
still continue running with the already set buffer size.


yes but how about giving a log for coverity and we ignore the error ?


How would an admin react to that log message? I'm fine with it being at 
the debug priority, but I am not the person who makes decisions here.


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

Re: [systemd-devel] [PATCH] socket-proxyd: Unchecked return value from library

[David Herrmann]

Hi

On Fri, Sep 19, 2014 at 10:39 AM, Alexander E. Patrakov
patra...@gmail.com wrote:
 19.09.2014 14:35, Susant Sahani wrote:

 On 09/19/2014 02:00 PM, David Herrmann wrote:

 Hi

 On Fri, Sep 19, 2014 at 10:28 AM, Susant Sahani sus...@redhat.com
 wrote:

 On 09/19/2014 01:35 PM, David Herrmann wrote:

 I don't think that's right. Ignoring the return value of that fcntl is
 just fine. We read the buffer-size afterwards, so if it failed, we
 still continue properly. See fcntl(2) for a bunch of errors that might



 Well I think set and get are two operations. for example let's say set
 failed but get success.
 setting BUFFER_SIZE failed and in this case buf size is remained as
 default
 pipe size.


 ..exactly! And the default buffer size is just fine. We'd prefer if we
 could set it to BUFFER_SIZE, but if we're not allowed to do that, we
 still continue running with the already set buffer size.


 yes but how about giving a log for coverity and we ignore the error ?


 How would an admin react to that log message? I'm fine with it being at the
 debug priority, but I am not the person who makes decisions here.

Exactly! There is little point in generating those messages.

Lets fix tools, not work around their bugs. Coverity should understand
that ignoring ioctl() return codes is sometimes exactly what we want.
So I'd prefer if we mark it as false positive.

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

Re: [systemd-devel] [PATCH] socket-proxyd: Unchecked return value from library

[Susant Sahani]

On 09/19/2014 02:11 PM, David Herrmann wrote:

Hi

On Fri, Sep 19, 2014 at 10:39 AM, Alexander E. Patrakov
patra...@gmail.com wrote:

19.09.2014 14:35, Susant Sahani wrote:


On 09/19/2014 02:00 PM, David Herrmann wrote:


Hi

On Fri, Sep 19, 2014 at 10:28 AM, Susant Sahani sus...@redhat.com
wrote:


On 09/19/2014 01:35 PM, David Herrmann wrote:


I don't think that's right. Ignoring the return value of that fcntl is
just fine. We read the buffer-size afterwards, so if it failed, we
still continue properly. See fcntl(2) for a bunch of errors that might




Well I think set and get are two operations. for example let's say set
failed but get success.
setting BUFFER_SIZE failed and in this case buf size is remained as
default
pipe size.



..exactly! And the default buffer size is just fine. We'd prefer if we
could set it to BUFFER_SIZE, but if we're not allowed to do that, we
still continue running with the already set buffer size.



yes but how about giving a log for coverity and we ignore the error ?



How would an admin react to that log message? I'm fine with it being at the
debug priority, but I am not the person who makes decisions here.


Exactly! There is little point in generating those messages.

Lets fix tools, not work around their bugs. Coverity should understand
that ignoring ioctl() return codes is sometimes exactly what we want.
So I'd prefer if we mark it as false positive.


Well In this exact scenario this makes sense .

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

Re: [systemd-devel] [RFC 25/25] add -z muldefs to linker flags

[Emil Renner Berthing]

On 19 September 2014 08:42, Michael Biebl mbi...@gmail.com wrote:
 2014-09-19 0:34 GMT+02:00 David Herrmann dh.herrm...@gmail.com:
  -Wl,-fuse-ld=gold])

 The reason to use gold  was that the compat libraries require the
 ifunc functionality.

 This is no longer the case, so I'd suggest to not override the default
 linker and simply use the system default one.

Hi, thanks for looking at this.

This is the error I get when compiling the latest systemd from git,
but with that line from configure.ac removed, so it doesn't use gold
to link:

http://sprunge.us/LWiH

I didn't look into why those functions are defined multiple times yet,
but I thought I'd post this early.

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

Re: [systemd-devel] [RFC 25/25] add -z muldefs to linker flags

[Dan Horák]

On Fri, 19 Sep 2014 11:24:14 +0200
Emil Renner Berthing syst...@esmil.dk wrote:

 On 19 September 2014 08:42, Michael Biebl mbi...@gmail.com wrote:
  2014-09-19 0:34 GMT+02:00 David Herrmann dh.herrm...@gmail.com:
   -Wl,-fuse-ld=gold])
 
  The reason to use gold  was that the compat libraries require the
  ifunc functionality.
 
  This is no longer the case, so I'd suggest to not override the
  default linker and simply use the system default one.
 
 Hi, thanks for looking at this.
 
 This is the error I get when compiling the latest systemd from git,
 but with that line from configure.ac removed, so it doesn't use gold
 to link:
 
 http://sprunge.us/LWiH
 
 I didn't look into why those functions are defined multiple times yet,
 but I thought I'd post this early.

there was a bug in binutils causing linking problems with systemd for
LTO + ifunc when using ld.bfd instead of gold, see
http://pkgs.fedoraproject.org/cgit/binutils.git/commit/?id=d7c31854e82903e663df160ad4c26c938eca4b59


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

[systemd-devel] percentage values in journald.conf

[Christian Hesse]

Hello everybody,

I am just trying to give journald some useful configuration on my system with
a dedicated log partition. The man page speaks about default values in
percent, so I tried:

SystemMaxUse=75%
SystemKeepFree=25%

However this is ignored. Are values in percent supposed to work?

Either we should make this work (I would prefer) or mention in man page more
clearly that values are expected in absolut values, not percentage.
-- 
main(a){char*c=/*Schoene Gruesse */B?IJj;MEH
CX:;,b;for(a/*Chris   get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/*   gcc -o sig sig.c  ./sig*/b/42*2-3)*42);}


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

[systemd-devel] journal repair

[Jóhann B. Guðmundsson]

Is the plan to introduce an repair switch or is the plan to inform the 
users how they should proceed if that is not the case since users are 
getting confused when they encounter journal errors like these


Data object missing from hash at entry...
Data object references invalid entry at...
Invalid tail monotonic timestamp...
Invalid object contents at...
File corruption detected at...
etc.

And are wasting their time on the internet searching for means to fix 
those errors.


I think we need to somehow provide the end user with the next step once 
a corruption of anykind has been detected in the relevant journal file 
even if it's just.


FAIL: corruption detected, your logs are fucked delete the file.

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

Re: [systemd-devel] [PATCH v5] socket: introduce SELinuxContextFromNet option

[Tom Gundersen]

On Mon, Sep 8, 2014 at 3:42 PM, Michal Sekletar msekl...@redhat.com wrote:
 This makes possible to spawn service instances triggered by socket with
 MLS/MCS SELinux labels which are created based on information provided by
 connected peer.

 Implementation of label_get_child_mls_label derived from xinetd.

 Reviewed-by: Paul Moore pmo...@redhat.com
 ---

 Changes in v5:
 * removed unneeded #include of libselinux headers from socket.c
 * fixed white-space issue in service_set_socket_fd

As all the comments from v4 has been fixed, please go ahead and commit this.

Cheers,

Tom

  man/systemd.socket.xml|  26 
  src/core/execute.c|  29 +++--
  src/core/execute.h|   1 +
  src/core/load-fragment-gperf.gperf.m4 |   3 +
  src/core/service.c|  10 +--
  src/core/service.h|   3 +-
  src/core/socket.c |  16 +++--
  src/core/socket.h |   2 +
  src/shared/label.c| 113 
 ++
  src/shared/label.h|   2 +
  10 files changed, 190 insertions(+), 15 deletions(-)

 diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml
 index 7a63348..dad0267 100644
 --- a/man/systemd.socket.xml
 +++ b/man/systemd.socket.xml
 @@ -676,6 +676,32 @@
  /varlistentry

  varlistentry
 +  
 termvarnameSELinuxContextFromNet=/varname/term
 + listitemparaTakes a boolean
 + argument. When true systemd will attempt
 + to figure out the SELinux label used
 + for the instantiated service from the
 + information handed by the peer over the
 + network. Note that only the security
 + level is used from the information
 + provided by the peer. Other parts of
 + the resulting SELinux context originate
 + from either the target binary that is
 + effectively triggered by socket unit
 + are taken from the value of the
 + varnameSELinuxContext=/varname
 + option.This configuration option only
 + affects sockets with
 + varnameAccept=/varname mode set to
 + literaltrue/literal. Also note that
 + this option is useful only when
 + MLS/MCS SELinux policy is
 + deployed. Defaults to
 + literalfalse/literal.
 + /para/listitem
 +/varlistentry
 +
 +varlistentry
  termvarnamePipeSize=/varname/term
  listitemparaTakes a size in
  bytes. Controls the pipe buffer size
 diff --git a/src/core/execute.c b/src/core/execute.c
 index 0a59147..37b9ed4 100644
 --- a/src/core/execute.c
 +++ b/src/core/execute.c
 @@ -83,6 +83,7 @@
  #include af-list.h
  #include mkdir.h
  #include apparmor-util.h
 +#include label.h

  #ifdef HAVE_SECCOMP
  #include seccomp-util.h
 @@ -1646,11 +1647,29 @@ static int exec_child(ExecCommand *command,
  #endif

  #ifdef HAVE_SELINUX
 -if (context-selinux_context  use_selinux()) {
 -err = setexeccon(context-selinux_context);
 -if (err  0  !context-selinux_context_ignore) {
 -*error = EXIT_SELINUX_CONTEXT;
 -return err;
 +if (use_selinux()) {
 +if (context-selinux_context) {
 +err = setexeccon(context-selinux_context);
 +if (err  0  
 !context-selinux_context_ignore) {
 +*error = EXIT_SELINUX_CONTEXT;
 +return err;
 +}
 +}
 +
 +if (params-selinux_context_net  socket_fd = 0) {
 +_cleanup_free_ char *label = NULL;
 +
 +err = label_get_child_mls_label(socket_fd, 
 command-path, label);
 +if (err  0) {
 +*error = EXIT_SELINUX_CONTEXT;
 +return err;
 +}
 +
 +err = setexeccon(label);
 +  

[systemd-devel] [PATCH] tty-ask-password-agent: Allow user input to be echoed

[David Sommerseth]

This is a continuation of the patch ask-password: Add --do-echo to enable
echoing the user input.

This allows user input going via the ask-password-agent to be echoed
as well, if the --do-echo argument is provided to systemd-ask-password.

Again it was preferred to add a new function, ask_password_agent_echo(),
over modifying the ask_password_agent() API to make the use case clearer
and keep backwards compatibility with applications depending on
ask_password_agent().

Signed-off-by: David Sommerseth dav...@redhat.com
---
 src/ask-password/ask-password.c |  5 -
 src/shared/ask-password-api.c   | 16 +++-
 src/shared/ask-password-api.h   |  2 ++
 src/tty-ask-password-agent/tty-ask-password-agent.c |  6 --
 4 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/src/ask-password/ask-password.c b/src/ask-password/ask-password.c
index c77cc66..c6744b9 100644
--- a/src/ask-password/ask-password.c
+++ b/src/ask-password/ask-password.c
@@ -179,7 +179,10 @@ int main(int argc, char *argv[]) {
 } else {
 char **l;
 
-if ((r = ask_password_agent(arg_message, arg_icon, arg_id, 
timeout, arg_accept_cached, l)) = 0) {
+r = arg_do_echo ? ask_password_agent_echo(arg_message, 
arg_icon, arg_id, timeout, arg_accept_cached, l)
+: ask_password_agent(arg_message, arg_icon, arg_id, 
timeout, arg_accept_cached, l);
+
+if (r = 0) {
 char **p;
 
 STRV_FOREACH(p, l) {
diff --git a/src/shared/ask-password-api.c b/src/shared/ask-password-api.c
index 283bfc2..39c122e 100644
--- a/src/shared/ask-password-api.c
+++ b/src/shared/ask-password-api.c
@@ -311,12 +311,13 @@ fail:
 return r;
 }
 
-int ask_password_agent(
+static int __ask_password_agent(
 const char *message,
 const char *icon,
 const char *id,
 usec_t until,
 bool accept_cached,
+bool do_echo,
 char ***_passphrases) {
 
 enum {
@@ -378,10 +379,12 @@ int ask_password_agent(
 PID=PID_FMT\n
 Socket=%s\n
 AcceptCached=%i\n
+DoEcho=%i\n
 NotAfter=USEC_FMT\n,
 getpid(),
 socket_name,
 accept_cached ? 1 : 0,
+do_echo ? 1 : 0,
 until);
 
 if (message)
@@ -557,6 +560,17 @@ finish:
 return r;
 }
 
+int ask_password_agent(const char *message, const char *icon, const char *id,
+   usec_t until, bool accept_cached, char ***_passphrases) 
{
+return __ask_password_agent(message, icon, id, until, accept_cached, 
false, _passphrases);
+}
+
+int ask_password_agent_echo(const char *message, const char *icon, const char 
*id,
+usec_t until, bool accept_cached, char 
***_passphrases) {
+return __ask_password_agent(message, icon, id, until, accept_cached, 
true, _passphrases);
+}
+
+
 int ask_password_auto(const char *message, const char *icon, const char *id,
   usec_t until, bool accept_cached, char ***_passphrases) {
 assert(message);
diff --git a/src/shared/ask-password-api.h b/src/shared/ask-password-api.h
index c3dde63..d467398 100644
--- a/src/shared/ask-password-api.h
+++ b/src/shared/ask-password-api.h
@@ -28,6 +28,8 @@ int ask_password_tty_echo(const char *message, usec_t until, 
const char *flag_fi
 
 int ask_password_agent(const char *message, const char *icon, const char *id,
usec_t until, bool accept_cached, char ***_passphrases);
+int ask_password_agent_echo(const char *message, const char *icon, const char 
*id,
+usec_t until, bool accept_cached, char 
***_passphrases);
 
 int ask_password_auto(const char *message, const char *icon, const char *id,
   usec_t until, bool accept_cached, char ***_passphrases);
diff --git a/src/tty-ask-password-agent/tty-ask-password-agent.c 
b/src/tty-ask-password-agent/tty-ask-password-agent.c
index 8a02fb0..90bbd1e 100644
--- a/src/tty-ask-password-agent/tty-ask-password-agent.c
+++ b/src/tty-ask-password-agent/tty-ask-password-agent.c
@@ -214,7 +214,7 @@ static int parse_password(const char *filename, char 
**wall) {
 _cleanup_free_ char *socket_name = NULL, *message = NULL, *packet = 
NULL;
 uint64_t not_after = 0;
 unsigned pid = 0;
-bool accept_cached = false;
+bool accept_cached = false, do_echo = false;
 
 const ConfigTableItem items[] = {
 { Ask, Socket,   config_parse_string,   0, 
socket_name   },
@@ -222,6 +222,7 @@ static int parse_password(const char *filename, char 
**wall) {
 { Ask, Message,  config_parse_string,   0, message
   },
 { Ask, 

Re: [systemd-devel] [RFC 00/25] Compile against the musl libc

[Tom Gundersen]

On Thu, Sep 18, 2014 at 9:21 PM, Emil Renner Berthing syst...@esmil.dk wrote:
 On 18 September 2014 18:29, Tom Gundersen t...@jklm.no wrote:
 In general, I don't think we should add patches for the sole purpose
 of non-glibc compatibility. You would in most cases be much better
 served by adding the missing functionality to your libc, rather than
 to each of the project requiring the functionality.

 Thank you for looking through these. The problem is that musl is aiming
 at making a lean and efficient posix libc, not a glibc clone. So stuff
 like parse_printf_format and canonicalize_file_name is not a fix, but
 unnecessary bloat. So it seems I'm stuck between a rock and a hard place.
 I guess I had hoped the resistance in this camp would be more against
 doing the work rather than actually be able to work with a posix libc and not
 only glibc.

We are not against being more POSIX compliant per se, but
reimplementing functionality in systemd that arguably should be done
in libc does not make much sense to me. If parse_printf_format (for
instance) is too bloated for yor libc, then surely putting it in
systemd gives the same amount of bloat overall (actually, it would be
worse as it would probably get statically linked into most of the
systemd-* binaries, whereas if you keep it in your libc it would only
be around once, and if you have more than just systemd around that
requires the functions to be reimplemented it gets worse still). Using
a minimal libc may make sense with projects that explicitly only use
minimal functionality (without reimplementing things), but avoiding
useful features is not a game systemd wants to be in, so I don't think
that applies here.

I understand not wanting to include unused functionality in libc if
you are trying to save space, but by not including stuff that is
actually used on your system I don't see how you gain anything.

I would rather try to compile glibc and systemd with unused
functionality disabled, or perhaps add the missing functionality to
your libc and make it optional for systems that don't require it.

 That said, we are of course happy to take patches that are the right
 thing to do regardless of which libc is being used, so I merged some
 of the patches you posted.

 Cool. I can resend updates of the ones you commented on.

 Btw, have you considered simply putting glibc on your router in the
 first place? If you can fit systemd, you can probably fit glibc too...

 Well, last time I tried this linux, musl, systemd, busybox, base, I had a
 Lua webserver running from linux + squashfs taking around 3MB out
 the 8MB available on the gadget. Maybe systemd has grown since then,
 I didn't get this far this time around.

 Also I think I might have made a mistake in mentioning OpenWRT. My
 point was more that I'd like systemd to run on hardware with the same
 kind of specs as OpenWRT is designed for, not necessarely replacing
 OpenWRT everywhere. I was thinking of gadgets like the VoCore [1],
 Arduino's Yun [2], Intel's Galileo boards[3] and Edison SOC [4] to name
 a few.

Would be cool if you get this working. Good luck!

Cheers,

Tom

 [1] 
 https://www.indiegogo.com/projects/vocore-a-coin-sized-linux-computer-with-wifi
 [2] http://arduino.cc/en/Main/ArduinoBoardYun
 [3] 
 http://www.intel.com/content/www/us/en/do-it-yourself/galileo-maker-quark-board.html
 [4] http://www.youtube.com/watch?v=GY8kaaFzbTE
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC 25/25] add -z muldefs to linker flags

[Michael Biebl]

2014-09-19 11:31 GMT+02:00 Dan Horák d...@danny.cz:
 On Fri, 19 Sep 2014 11:24:14 +0200
 Emil Renner Berthing syst...@esmil.dk wrote:

 On 19 September 2014 08:42, Michael Biebl mbi...@gmail.com wrote:
  2014-09-19 0:34 GMT+02:00 David Herrmann dh.herrm...@gmail.com:
   -Wl,-fuse-ld=gold])
 
  The reason to use gold  was that the compat libraries require the
  ifunc functionality.
 
  This is no longer the case, so I'd suggest to not override the
  default linker and simply use the system default one.

 Hi, thanks for looking at this.

 This is the error I get when compiling the latest systemd from git,
 but with that line from configure.ac removed, so it doesn't use gold
 to link:

 http://sprunge.us/LWiH

 I didn't look into why those functions are defined multiple times yet,
 but I thought I'd post this early.

 there was a bug in binutils causing linking problems with systemd for
 LTO + ifunc when using ld.bfd instead of gold, see
 http://pkgs.fedoraproject.org/cgit/binutils.git/commit/?id=d7c31854e82903e663df160ad4c26c938eca4b59

Right, but we no longer usce ifunc, so we no longer need to override
the default linker.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v5] socket: introduce SELinuxContextFromNet option

[Michal Sekletar]

On Fri, Sep 19, 2014 at 12:13:18PM +0200, Tom Gundersen wrote:
 On Mon, Sep 8, 2014 at 3:42 PM, Michal Sekletar msekl...@redhat.com wrote:
  This makes possible to spawn service instances triggered by socket with
  MLS/MCS SELinux labels which are created based on information provided by
  connected peer.
 
  Implementation of label_get_child_mls_label derived from xinetd.
 
  Reviewed-by: Paul Moore pmo...@redhat.com
  ---
 
  Changes in v5:
  * removed unneeded #include of libselinux headers from socket.c
  * fixed white-space issue in service_set_socket_fd
 
 As all the comments from v4 has been fixed, please go ahead and commit this.

Rebased and pushed.

Regards,

Michal

 
 Cheers,
 
 Tom
 
   man/systemd.socket.xml|  26 
   src/core/execute.c|  29 +++--
   src/core/execute.h|   1 +
   src/core/load-fragment-gperf.gperf.m4 |   3 +
   src/core/service.c|  10 +--
   src/core/service.h|   3 +-
   src/core/socket.c |  16 +++--
   src/core/socket.h |   2 +
   src/shared/label.c| 113 
  ++
   src/shared/label.h|   2 +
   10 files changed, 190 insertions(+), 15 deletions(-)
 
  diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml
  index 7a63348..dad0267 100644
  --- a/man/systemd.socket.xml
  +++ b/man/systemd.socket.xml
  @@ -676,6 +676,32 @@
   /varlistentry
 
   varlistentry
  +  
  termvarnameSELinuxContextFromNet=/varname/term
  + listitemparaTakes a boolean
  + argument. When true systemd will attempt
  + to figure out the SELinux label used
  + for the instantiated service from the
  + information handed by the peer over the
  + network. Note that only the security
  + level is used from the information
  + provided by the peer. Other parts of
  + the resulting SELinux context originate
  + from either the target binary that is
  + effectively triggered by socket unit
  + are taken from the value of the
  + varnameSELinuxContext=/varname
  + option.This configuration option only
  + affects sockets with
  + varnameAccept=/varname mode set to
  + literaltrue/literal. Also note that
  + this option is useful only when
  + MLS/MCS SELinux policy is
  + deployed. Defaults to
  + literalfalse/literal.
  + /para/listitem
  +/varlistentry
  +
  +varlistentry
   termvarnamePipeSize=/varname/term
   listitemparaTakes a size in
   bytes. Controls the pipe buffer size
  diff --git a/src/core/execute.c b/src/core/execute.c
  index 0a59147..37b9ed4 100644
  --- a/src/core/execute.c
  +++ b/src/core/execute.c
  @@ -83,6 +83,7 @@
   #include af-list.h
   #include mkdir.h
   #include apparmor-util.h
  +#include label.h
 
   #ifdef HAVE_SECCOMP
   #include seccomp-util.h
  @@ -1646,11 +1647,29 @@ static int exec_child(ExecCommand *command,
   #endif
 
   #ifdef HAVE_SELINUX
  -if (context-selinux_context  use_selinux()) {
  -err = setexeccon(context-selinux_context);
  -if (err  0  !context-selinux_context_ignore) {
  -*error = EXIT_SELINUX_CONTEXT;
  -return err;
  +if (use_selinux()) {
  +if (context-selinux_context) {
  +err = setexeccon(context-selinux_context);
  +if (err  0  
  !context-selinux_context_ignore) {
  +*error = EXIT_SELINUX_CONTEXT;
  +return err;
  +}
  +}
  +
  +if (params-selinux_context_net  socket_fd = 0) 
  {
  +_cleanup_free_ char *label = NULL;
  +
  +err = label_get_child_mls_label(socket_fd, 
  command-path, label);
  +if (err  0) {
  +

Re: [systemd-devel] [RFC 00/25] Compile against the musl libc

[Umut Tezduyar Lindskog]

Axis Communications is running fairly compact version of systemd with some 
properties disabled with --disable--xyz. Files are a bit over 10 mb on MIPS ISA 
(stripped of binaries and conf files). 

Top 10 large files are (in kb)

276 ./Root/usr/lib/systemd/systemd-udevd
280 ./Root/usr/bin/udevadm
288 ./Root/usr/bin/busctl
296 ./Root/usr/lib/systemd/systemd-hostnamed
300 ./Root/usr/lib/systemd/systemd-timedated
304 ./Root/usr/lib/systemd/systemd-bus-proxyd
368 ./Root/usr/bin/systemd-nspawn
548 ./Root/usr/bin/systemctl
1152 ./Root/usr/bin/systemd-analyze
1220 ./Root/usr/lib/systemd/systemd

Umut

[1] Maybe it is time (again) to visit making /shared code part of libsystemd or 
libsystemd-internal. Has anyone made any calculation regarding the cost of 
using static library. If not, maybe I can take a stab.
[2] I am quite surprised systemd-analyze is so big.


On 18 Sep 2014, at 05:19 pm, Jóhann B. Guðmundsson johan...@gmail.com wrote:

 
 On 09/18/2014 02:20 PM, Philippe De Swert wrote:
 Hi,
 
 On 18/09/14 17:13, Emil Renner Berthing wrote:
 On 18 September 2014 16:10, Jóhann B. Guðmundsson johan...@gmail.com 
 wrote:
 On 09/18/2014 01:24 PM, Emil Renner Berthing wrote:
 The real reason is of course that I'd like to see systemd running
 on my router and other small devices that usually run some OpenWRT
 derivative.
 The openwrt community is still going forward with their (re)-invention of
 init system called procd since they were incapable of using systemd built
 with --disable-alots right?
 
 Or are you talking about you dont want to use OpenWRT but your own or
 something else and thus the request?
 Yes, indeed. Also I am hoping that having this option means other small
 devices will run systemd in the future.
 I think you are missing the point of musl So you have so little
 space you need a smaller libc but then you want to use a binary of ~1MB
 + tools to replace an init of a few Kb?
 
 Moreover systemd needs a lot more kernel options, so making smaller
 kernels gets hard. Not to mention for example cgroups etc is often very
 unstable in the earlier kernels that have the support for those devices.
 IOW more kernel crashes due to systemd requiring cgroups.
 
 The reason why OpenWrt would do their own init, is to keep it small.
 Often those routers etc have only a few Mb of flash. Even with
 compression just having a 2Mb just for the init system is a bit much.
 
 It would be interesting to get some how low can you go numbers from 
 the embedded crowd regarding systemd and or systemd + udev-hwdb.
 
 I would think 16MiB target should be fairly easy to achieved but 
 anything less than that might be well work...
 
 JBG
 ___
 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] [RFC 18/25] sd-ipv4all: fall back to random if no random_r

[Umut Tezduyar Lindskog]

As Tom stated this is changing the behaviour. Maybe not when you only
have 1 interface but if we are talking about multiple interfaces, then
they will share common entropy.

Umut

On Thu, Sep 18, 2014 at 5:43 PM, Tom Gundersen t...@jklm.no wrote:
 No, this actually breaks the behaviour, so we absolutely cannot do
 this. Again, I suggest adding the missing features to your libc.

 Cheers,

 Tom

 On Thu, Sep 18, 2014 at 3:24 PM, Emil Renner Berthing syst...@esmil.dk 
 wrote:
 ---
  configure.ac   |  1 +
  src/libsystemd-network/sd-ipv4ll.c | 25 +
  2 files changed, 22 insertions(+), 4 deletions(-)

 diff --git a/configure.ac b/configure.ac
 index 397521e..9cd4c05 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -301,6 +301,7 @@ RT_LIBS=$LIBS
  AC_SUBST(RT_LIBS)
  LIBS=$save_LIBS

 +AC_CHECK_FUNCS([random_r])
  AC_CHECK_FUNCS([fanotify_init fanotify_mark])
  AC_CHECK_FUNCS([__secure_getenv secure_getenv])
  AC_CHECK_DECLS([gettid, pivot_root, canonicalize_file_name, strndupa, 
 name_to_handle_at, setns, LO_FLAGS_PARTSCAN],
 diff --git a/src/libsystemd-network/sd-ipv4ll.c 
 b/src/libsystemd-network/sd-ipv4ll.c
 index 8b24331..5712350 100644
 --- a/src/libsystemd-network/sd-ipv4ll.c
 +++ b/src/libsystemd-network/sd-ipv4ll.c
 @@ -81,8 +81,10 @@ struct sd_ipv4ll {
  usec_t defend_window;
  int next_wakeup_valid;
  be32_t address;
 +#ifdef HAVE_RANDOM_R
  struct random_data *random_data;
  char *random_data_state;
 +#endif
  /* External */
  be32_t claimed_address;
  struct ether_addr mac_addr;
 @@ -141,18 +143,24 @@ static sd_ipv4ll *ipv4ll_stop(sd_ipv4ll *ll, int 
 event) {

  static int ipv4ll_pick_address(sd_ipv4ll *ll, be32_t *address) {
  be32_t addr;
 -int r;
 -int32_t random;

  assert(ll);
  assert(address);
 +#ifdef HAVE_RANDOM_R
  assert(ll-random_data);
 +#endif

  do {
 -r = random_r(ll-random_data, random);
 +#ifdef HAVE_RANDOM_R
 +int32_t value;
 +int r = random_r(ll-random_data, value);
 +
  if (r  0)
  return r;
 -addr = htonl((random  0x) | IPV4LL_NETWORK);
 +#else
 +long int value = random();
 +#endif
 +addr = htonl((value  0x) | IPV4LL_NETWORK);
  } while (addr == ll-address ||
  (ntohl(addr)  IPV4LL_NETMASK) != IPV4LL_NETWORK ||
  (ntohl(addr)  0xFF00) == 0x ||
 @@ -481,6 +489,7 @@ int sd_ipv4ll_set_address_seed (sd_ipv4ll *ll, uint8_t 
 seed[8]) {

  entropy = *seed;

 +#ifdef HAVE_RANDOM_R
  free(ll-random_data);
  free(ll-random_data_state);

 @@ -503,6 +512,10 @@ error:
  ll-random_data = NULL;
  ll-random_data_state = NULL;
  }
 +#else
 +srandom(entropy);
 +r = 0;
 +#endif
  return r;
  }

 @@ -535,6 +548,7 @@ int sd_ipv4ll_start (sd_ipv4ll *ll) {
  ll-defend_window = 0;
  ll-claimed_address = 0;

 +#ifdef HAVE_RANDOM_R
  if (!ll-random_data) {
  uint8_t seed[8];

 @@ -546,6 +560,7 @@ int sd_ipv4ll_start (sd_ipv4ll *ll) {
  if (r  0)
  goto out;
  }
 +#endif

  if (ll-address == 0) {
  r = ipv4ll_pick_address(ll, ll-address);
 @@ -614,8 +629,10 @@ sd_ipv4ll *sd_ipv4ll_unref(sd_ipv4ll *ll) {

  sd_ipv4ll_detach_event(ll);

 +#ifdef HAVE_RANDOM_R
  free(ll-random_data);
  free(ll-random_data_state);
 +#endif
  free(ll);

  return NULL;
 --
 2.1.0

 ___
 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] socket-proxyd: Unchecked return value from library

[Simon McVittie]

On 19/09/14 09:05, David Herrmann wrote:
 -fcntl(buffer[0], F_SETPIPE_SZ, BUFFER_SIZE);
 +r = fcntl(buffer[0], F_SETPIPE_SZ, BUFFER_SIZE);
 +if (r  0) {
 +log_error(Failed to set pipe buffer size: %m);
 +return -errno;
 +}
 
 I don't think that's right. Ignoring the return value of that fcntl is
 just fine.

An idiom I've found to be useful in cases like this is something like

r = whatever();
if (r  0) {
/* ignore failure because [short justification here] */
}

which avoids compiler warnings for functions marked with
__attribute__(warn_unused_result) (and hopefully also this Coverity
warning), while making the intention clear.

S

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

Re: [systemd-devel] journal repair

[Zbigniew Jędrzejewski-Szmek]

On Fri, Sep 19, 2014 at 10:00:02AM +, Jóhann B. Guðmundsson wrote:
 Is the plan to introduce an repair switch or is the plan to inform
 the users how they should proceed if that is not the case since
 users are getting confused when they encounter journal errors like
 these
 
 Data object missing from hash at entry...
 Data object references invalid entry at...
 Invalid tail monotonic timestamp...
 Invalid object contents at...
 File corruption detected at...
 etc.
 
 And are wasting their time on the internet searching for means to
 fix those errors.
 
 I think we need to somehow provide the end user with the next step
 once a corruption of anykind has been detected in the relevant
 journal file even if it's just.
It is now possible to fix files by rewriting them:

  journalctl --file /var/log/xxx.journal | systemd-journal-remote --file 
/tmp/xxx.journal -
  mv /tmp/xxx.journal /var/log/xxx.journal

We could easily provide the functionality to do this automatically,
but I don't know how useful this would be.

 FAIL: corruption detected, your logs are fucked delete the file.
The error is usually at the end, so deleting all entries just because
one is bad does not seem reasonable.

Zbyszek

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

Re: [systemd-devel] journal repair

[Jóhann B. Guðmundsson]

On 09/19/2014 02:10 PM, Zbigniew Jędrzejewski-Szmek wrote:

   journalctl --file /var/log/xxx.journal | systemd-journal-remote --file 
/tmp/xxx.journal -
   mv /tmp/xxx.journal /var/log/xxx.journal

We could easily provide the functionality to do this automatically,
but I don't know how useful this would be.


Granting them the ability to fix this via switch --repair or offer to 
fix it when encountered which they confirm with yes or no or simply do 
it automatically will be very useful for those users that are 
encountering these errors.


It kinda goes hand in hand if you provide the ability to verify you also 
provide the ability to fix it in the process.


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

[systemd-devel] [PATCH] systemctl: add add-wants and add-requires verbs

[Lukas Nykryn]

---
 TODO   |  1 -
 man/systemctl.xml  | 27 ++
 src/core/dbus-manager.c| 85 +
 src/core/org.freedesktop.systemd1.conf |  8 +++
 src/shared/install.c   | 87 +++---
 src/shared/install.h   |  8 +++
 src/systemctl/systemctl.c  | 99 +-
 7 files changed, 295 insertions(+), 20 deletions(-)

diff --git a/TODO b/TODO
index 9ac6fac..923cbb8 100644
--- a/TODO
+++ b/TODO
@@ -450,7 +450,6 @@ Features:
   - systemctl mask should find all names by which a unit is accessible
 (i.e. by scanning for symlinks to it) and link them all to /dev/null
   - systemctl list-unit-files should list generated files (and probably with a 
new state generated for them, or so)
-  - systemctl: maybe add systemctl add-wants or so...
 
 * timer units:
   - timer units should get the ability to trigger when:
diff --git a/man/systemctl.xml b/man/systemctl.xml
index b28a3b7..73dfa87 100644
--- a/man/systemctl.xml
+++ b/man/systemctl.xml
@@ -1098,6 +1098,33 @@ kobject-uevent 1 systemd-udevd-kernel.socket 
systemd-udevd.service
 /varlistentry
 
 varlistentry
+  termcommandadd-wants|add-requires 
replaceableTARGET/replaceable
+  replaceableNAME/replaceable.../command
+  /term
+
+  listitem
+paraEnables one or more units similarly to 
commandenable/command,
+but instead of looking to literal[Install]/literal section of
+the unit file, adds literalWants/literal
+resp. literalRequires/literal dependency to the specified
+replaceableTARGET/replaceable.
+/para
+
+paraThis command will print the actions executed. This
+output may be suppressed by passing option--quiet/option.
+/para
+
+paraDepending on whether option--system/option,
+option--user/option, option--runtime/option,
+or option--global/option is specified, this enables the unit
+for the system, for the calling user only, for only this boot of
+the system, or for all future logins of all users, or only this
+boot.  Note that in the last case, no systemd daemon
+configuration is reloaded./para
+  /listitem
+/varlistentry
+
+varlistentry
   termcommandlink 
replaceableFILENAME/replaceable.../command/term
 
   listitem
diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
index 533ce43..9335e94 100644
--- a/src/core/dbus-manager.c
+++ b/src/core/dbus-manager.c
@@ -1562,9 +1562,6 @@ static int method_enable_unit_files_generic(
 sd_bus_error *error) {
 
 _cleanup_strv_free_ char **l = NULL;
-#ifdef HAVE_SELINUX
-char **i;
-#endif
 UnitFileChange *changes = NULL;
 unsigned n_changes = 0;
 UnitFileScope scope;
@@ -1589,14 +1586,17 @@ static int method_enable_unit_files_generic(
 return r;
 
 #ifdef HAVE_SELINUX
-STRV_FOREACH(i, l) {
-Unit *u;
-
-u = manager_get_unit(m, *i);
-if (u) {
-r = selinux_unit_access_check(u, message, verb, error);
-if (r  0)
-return r;
+{
+char **i;
+STRV_FOREACH(i, l) {
+Unit *u;
+
+u = manager_get_unit(m, *i);
+if (u) {
+r = selinux_unit_access_check(u, message, 
verb, error);
+if (r  0)
+return r;
+}
 }
 }
 #endif
@@ -1828,6 +1828,67 @@ static int method_preset_all_unit_files(sd_bus *bus, 
sd_bus_message *message, vo
 return reply_unit_file_changes_and_free(m, bus, message, -1, changes, 
n_changes);
 }
 
+static int method_add_install_dependency_unit_files(sd_bus *bus, 
sd_bus_message *message, void *userdata, UnitFileInstallDependency dep, 
sd_bus_error *error) {
+_cleanup_strv_free_ char **l = NULL;
+Manager *m = userdata;
+UnitFileChange *changes = NULL;
+unsigned n_changes = 0;
+UnitFileScope scope;
+int runtime, force, r;
+char *target;
+
+assert(bus);
+assert(message);
+assert(m);
+
+r = bus_verify_manage_unit_files_async(m, message, error);
+if (r  0)
+return r;
+if (r == 0)
+return 1; /* No authorization for now, but the async polkit 
stuff will call us again when it has it */
+
+r = sd_bus_message_read_strv(message, l);
+if (r  0)
+return r;
+
+r = sd_bus_message_read(message, sbb, target, runtime, force);
+if (r  0)
+  

Re: [systemd-devel] [PATCH 1/3] journal: Do not count on the compiler initializing found_last to false

[Dale R. Worley]

 From: Philippe De Swert philippedesw...@gmail.com
 
 There is a very unlikely case where this can happen since gcc usually
 does the sane thing. But let's make sure found_last is initialized anyway.

You'd better -- the C standard does *not* require the compiler to
intialize local (auto) variables.

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

[systemd-devel] [RFC] [PATCH] cgroup: don't trim cgroup trees created by someone else

[Michal Sekletar]

In cases when there is a cgroup tree in a controller hierarchy which was
not created by us, but it looks like it was (i.e. cgroup path is the
same as the one in systemd's named hierarchy) we shouldn't delete it.
---

Reproducer:
1) start qemu-kvm VM via virsh/virt-manager
2) ls /sys/fs/cgroup/memory /* see machine.slice cgroup */
3) verify that scope unit for VM has MemoryAccounting=no
4) systemctl daemon-reload
5) systemctl restart some_service
6) ls /sys/fs/cgroup/memory /* see machine.slice cgroup gone */

To be honest I have no idea if the approach taken here is correct, however
it fixes the bug at least on my machine.


 src/core/cgroup.c| 2 +-
 src/shared/cgroup-util.c | 2 --
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/core/cgroup.c b/src/core/cgroup.c
index 6c6e4f5..8ede79a 100644
--- a/src/core/cgroup.c
+++ b/src/core/cgroup.c
@@ -780,7 +780,7 @@ void unit_destroy_cgroup(Unit *u) {
 if (!u-cgroup_path)
 return;
 
-r = cg_trim_everywhere(u-manager-cgroup_supported, u-cgroup_path, 
!unit_has_name(u, SPECIAL_ROOT_SLICE));
+r = cg_trim_everywhere(u-cgroup_realized_mask, u-cgroup_path, 
!unit_has_name(u, SPECIAL_ROOT_SLICE));
 if (r  0)
 log_debug(Failed to destroy cgroup %s: %s, u-cgroup_path, 
strerror(-r));
 
diff --git a/src/shared/cgroup-util.c b/src/shared/cgroup-util.c
index da8e885..a19b5b4 100644
--- a/src/shared/cgroup-util.c
+++ b/src/shared/cgroup-util.c
@@ -1615,8 +1615,6 @@ int cg_create_everywhere(CGroupControllerMask supported, 
CGroupControllerMask ma
 NULSTR_FOREACH(n, mask_names) {
 if (mask  bit)
 cg_create(n, path);
-else if (supported  bit)
-cg_trim(n, path, true);
 
 bit = 1;
 }
-- 
2.0.1

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

[systemd-devel] Systemd-nspawn -- Unable to initialize virtual ethernet connection

[James Lott]

Hello!

I am trying to setup and play around with some of the private networking 
features of systemd, and one of the big thinks I'm trying to get working is 
the virtual ethernet links. For some reason though, I am unable to start a 
containder using a virtual ethernet link. My attempt is included below.

---
[root@utility01 ~]# systemd-nspawn --network-veth -bD /home/proxy.ddwrt01
Spawning container proxy.ddwrt01 on /home/proxy.ddwrt01.
Press ^] three times within 1s to kill container.
Failed to add netlink interface name: Invalid argument
---

Dropping the --network-veth option:

---
[root@utility01 ~]# systemd-nspawn -bD /home/proxy.ddwrt01  

  
Spawning container proxy.ddwrt01 on /home/proxy.ddwrt01.
Press ^] three times within 1s to kill container.
systemd 216 running in system mode. (+PAM -AUDIT -SELINUX -IMA -APPARMOR 
+SMACK -SYSVINIT +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID 
-ELFUTILS +KMOD -IDN )
Detected virtualization 'systemd-nspawn'.
Detected architecture 'arm'.

Welcome to Arch Linux ARM!
---

Some additional environment information:

[root@utility01 ~]# uname -a
Linux utility01 3.12.26-2-ARCH #1 PREEMPT Sun Aug 31 22:36:40 MDT 2014 armv6l 
GNU/Linux
[root@utility01 ~]# pacman -Q systemd
systemd 216-3

I'm happy to run any additional tests or provide any additional information 
needed to help try to reproduce. Thanks in advance for any help!

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

[systemd-devel] systemd-networkd -- Unable to create VLAN device

[James Lott]

Hello again!

I've been eager to play with networking features, in case you couldn't tell ;) 
This patricular issue seems separate from my first one though, so I thought it 
would be best to discuss separately.

I am trying to use systemd-networkd to essentially replace vconfig. I am using 
eth0 as a trunked link and am trying to setup a pair of VLAN devices to 
receive the taged frames. It seems that the VLAN netdevs are silently failing 
to be created.

Sep 19 09:47:34 utility01 systemd[1]: Starting Network Service...
Sep 19 09:47:34 utility01 systemd-networkd[776]: 
[/etc/systemd/network/vlan1.network:6] VLAN could not be found, ignoring 
assignment: 1
Sep 19 09:47:34 utility01 systemd-networkd[776]: 
[/etc/systemd/network/vlan0.network:6] VLAN could not be found, ignoring 
assignment: 0
Sep 19 09:47:34 utility01 systemd-networkd[776]: 
[/etc/systemd/network/eth0.network:6] VLAN could not be found, ignoring 
assignment: 1
Sep 19 09:47:34 utility01 systemd-networkd[776]: 
[/etc/systemd/network/eth0.network:7] VLAN could not be found, ignoring 
assignment: 0
Sep 19 09:47:34 utility01 systemd-networkd[776]: eth0.0  : gained 
carrier
Sep 19 09:47:34 utility01 systemd-networkd[776]: eth0: gained 
carrier
Sep 19 09:47:34 utility01 systemd-networkd[776]: lo  : gained 
carrier
Sep 19 09:47:34 utility01 systemd[1]: Started Network Service.

Although I strongly believe this to be an error I am making somewhere, I have 
read and re-read all of the systemd-networkd man pages, and cannot for the 
life of me figure out where I went wrong. Any help is much appreciated! 
Additional environment information is included below.

[root@utility01 network]# uname -a
Linux utility01 3.12.26-2-ARCH #1 PREEMPT Sun Aug 31 22:36:40 MDT 2014 armv6l 
GNU/Linux
[root@utility01 network]# pacman -Q systemd
systemd 216-3
[root@utility01 network]# lsmod | grep 8021q
8021q  20658  0 
garp6303  1 8021q
mrp 8249  1 8021q

[root@utility01 network]# pwd
/etc/systemd/network
[root@utility01 network]# for f in *; do echo; echo -- $f; echo; cat 
$f; done

-- eth0.network

[Match]
Name=eth0

[Network]
DHCP=v4
VLAN=1
VLAN=0

-- vlan0.netdev

[NetDev]
Name=vlan0
Kind=vlan

[VLAN]
Id=0

-- vlan0.network

[Match]
Name=vlan0

[Network]
DHCP=v4
VLAN=0

-- vlan1.netdev

[NetDev]
Name=vlan1
Kind=vlan

[VLAN]
Id=1

-- vlan1.network

[Match]
Name=vlan1

[Network]
DHCP=v4
VLAN=1
[root@utility01 network]# ip link
1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ifb0: BROADCAST,NOARP mtu 1500 qdisc noop state DOWN mode DEFAULT group 
default qlen 32
link/ether 3e:ff:bc:28:42:cb brd ff:ff:ff:ff:ff:ff
3: ifb1: BROADCAST,NOARP mtu 1500 qdisc noop state DOWN mode DEFAULT group 
default qlen 32
link/ether 3a:65:88:fc:ab:27 brd ff:ff:ff:ff:ff:ff
4: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP 
mode DEFAULT group default qlen 1000
link/ether b8:27:eb:9d:3a:06 brd ff:ff:ff:ff:ff:ff
5: wlan0: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
link/ether 64:66:b3:20:04:f5 brd ff:ff:ff:ff:ff:ff
6: eth0.0@eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state 
UP mode DEFAULT group default 
link/ether b8:27:eb:9d:3a:06 brd ff:ff:ff:ff:ff:ff

NOTE: The existing eth0.0 was created using vconfig, which I created simply to 
get this machine back on the network while I troubleshooted my issue.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] shared/util.h: portable sizeof(long) == sizeof(int) test

[Emil Renner Berthing]

Don't rely on __WORDSIZE, but just standard LONG_MAX
and INT_MAX from limits.h.
---
 src/shared/util.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/shared/util.h b/src/shared/util.h
index 08d556f..00068c6 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -205,7 +205,7 @@ int safe_atod(const char *s, double *ret_d);
 
 int safe_atou8(const char *s, uint8_t *ret);
 
-#if __WORDSIZE == 32
+#if LONG_MAX == INT_MAX
 static inline int safe_atolu(const char *s, unsigned long *ret_u) {
 assert_cc(sizeof(unsigned long) == sizeof(unsigned));
 return safe_atou(s, (unsigned*) ret_u);
-- 
2.1.0

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

Re: [systemd-devel] [PATCH] shared/util.h: portable sizeof(long) == sizeof(int) test

[David Herrmann]

Hi

On Fri, Sep 19, 2014 at 8:26 PM, Emil Renner Berthing syst...@esmil.dk wrote:
 Don't rely on __WORDSIZE, but just standard LONG_MAX
 and INT_MAX from limits.h.

Why? The commit message lacks any explanation of that change.

Thanks
David

 ---
  src/shared/util.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/src/shared/util.h b/src/shared/util.h
 index 08d556f..00068c6 100644
 --- a/src/shared/util.h
 +++ b/src/shared/util.h
 @@ -205,7 +205,7 @@ int safe_atod(const char *s, double *ret_d);

  int safe_atou8(const char *s, uint8_t *ret);

 -#if __WORDSIZE == 32
 +#if LONG_MAX == INT_MAX
  static inline int safe_atolu(const char *s, unsigned long *ret_u) {
  assert_cc(sizeof(unsigned long) == sizeof(unsigned));
  return safe_atou(s, (unsigned*) ret_u);
 --
 2.1.0

 ___
 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] systemd-networkd -- Unable to create VLAN device

[Tom Gundersen]

On Fri, Sep 19, 2014 at 6:59 PM, James Lott ja...@lottspot.com wrote:
 Hello again!

 I've been eager to play with networking features, in case you couldn't tell ;)
 This patricular issue seems separate from my first one though, so I thought it
 would be best to discuss separately.

 I am trying to use systemd-networkd to essentially replace vconfig. I am using
 eth0 as a trunked link and am trying to setup a pair of VLAN devices to
 receive the taged frames. It seems that the VLAN netdevs are silently failing
 to be created.

 Sep 19 09:47:34 utility01 systemd[1]: Starting Network Service...
 Sep 19 09:47:34 utility01 systemd-networkd[776]:
 [/etc/systemd/network/vlan1.network:6] VLAN could not be found, ignoring
 assignment: 1
 Sep 19 09:47:34 utility01 systemd-networkd[776]:
 [/etc/systemd/network/vlan0.network:6] VLAN could not be found, ignoring
 assignment: 0
 Sep 19 09:47:34 utility01 systemd-networkd[776]:
 [/etc/systemd/network/eth0.network:6] VLAN could not be found, ignoring
 assignment: 1
 Sep 19 09:47:34 utility01 systemd-networkd[776]:
 [/etc/systemd/network/eth0.network:7] VLAN could not be found, ignoring
 assignment: 0
 Sep 19 09:47:34 utility01 systemd-networkd[776]: eth0.0  : gained
 carrier
 Sep 19 09:47:34 utility01 systemd-networkd[776]: eth0: gained
 carrier
 Sep 19 09:47:34 utility01 systemd-networkd[776]: lo  : gained
 carrier
 Sep 19 09:47:34 utility01 systemd[1]: Started Network Service.

 Although I strongly believe this to be an error I am making somewhere, I have
 read and re-read all of the systemd-networkd man pages, and cannot for the
 life of me figure out where I went wrong. Any help is much appreciated!
 Additional environment information is included below.

 [root@utility01 network]# uname -a
 Linux utility01 3.12.26-2-ARCH #1 PREEMPT Sun Aug 31 22:36:40 MDT 2014 armv6l
 GNU/Linux
 [root@utility01 network]# pacman -Q systemd
 systemd 216-3
 [root@utility01 network]# lsmod | grep 8021q
 8021q  20658  0
 garp6303  1 8021q
 mrp 8249  1 8021q

 [root@utility01 network]# pwd
 /etc/systemd/network
 [root@utility01 network]# for f in *; do echo; echo -- $f; echo; cat
 $f; done

 -- eth0.network

 [Match]
 Name=eth0

 [Network]
 DHCP=v4
 VLAN=1
 VLAN=0

This needs to be the names of your vlan interfaces, not their vlanid. I.e.,

VLAN=vlan0
VLAN=vlan1

 -- vlan0.netdev

 [NetDev]
 Name=vlan0
 Kind=vlan

 [VLAN]
 Id=0

 -- vlan0.network

 [Match]
 Name=vlan0

 [Network]
 DHCP=v4
 VLAN=0

 -- vlan1.netdev

 [NetDev]
 Name=vlan1
 Kind=vlan

 [VLAN]
 Id=1

 -- vlan1.network

 [Match]
 Name=vlan1

 [Network]
 DHCP=v4
 VLAN=1
 [root@utility01 network]# ip link
 1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN mode
 DEFAULT group default
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 2: ifb0: BROADCAST,NOARP mtu 1500 qdisc noop state DOWN mode DEFAULT group
 default qlen 32
 link/ether 3e:ff:bc:28:42:cb brd ff:ff:ff:ff:ff:ff
 3: ifb1: BROADCAST,NOARP mtu 1500 qdisc noop state DOWN mode DEFAULT group
 default qlen 32
 link/ether 3a:65:88:fc:ab:27 brd ff:ff:ff:ff:ff:ff
 4: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP
 mode DEFAULT group default qlen 1000
 link/ether b8:27:eb:9d:3a:06 brd ff:ff:ff:ff:ff:ff
 5: wlan0: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN mode DEFAULT
 group default qlen 1000
 link/ether 64:66:b3:20:04:f5 brd ff:ff:ff:ff:ff:ff
 6: eth0.0@eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state
 UP mode DEFAULT group default
 link/ether b8:27:eb:9d:3a:06 brd ff:ff:ff:ff:ff:ff

 NOTE: The existing eth0.0 was created using vconfig, which I created simply to
 get this machine back on the network while I troubleshooted my issue.
 ___
 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] shared/util.h: portable sizeof(long) == sizeof(int) test

[Emil Renner Berthing]

On 19 September 2014 22:19, David Herrmann dh.herrm...@gmail.com wrote:
 On Fri, Sep 19, 2014 at 8:26 PM, Emil Renner Berthing syst...@esmil.dk 
 wrote:
 Don't rely on __WORDSIZE, but just standard LONG_MAX
 and INT_MAX from limits.h.

 Why? The commit message lacks any explanation of that change.

Ah, sorry. This is a better version of the [RFC 5/25] patch I sent earlier.
The point is that __WORDSIZE is not portable, but both
LONG_MAX and INT_MAX are mandated in limits.h.

I can resend with this explanation in the commit message if you want.

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

Re: [systemd-devel] systemd-networkd -- Unable to create VLAN device

[James Lott]

Holy smokes, that did it! Many thanks for taking time out of your day to help 
me find my silly mistake :)

On Friday 19 September 2014 22:51:41 Tom Gundersen wrote:
 On Fri, Sep 19, 2014 at 6:59 PM, James Lott ja...@lottspot.com wrote:
  Hello again!
  
  I've been eager to play with networking features, in case you couldn't
  tell ;) This patricular issue seems separate from my first one though, so
  I thought it would be best to discuss separately.
  
  I am trying to use systemd-networkd to essentially replace vconfig. I am
  using eth0 as a trunked link and am trying to setup a pair of VLAN
  devices to receive the taged frames. It seems that the VLAN netdevs are
  silently failing to be created.
  
  Sep 19 09:47:34 utility01 systemd[1]: Starting Network Service...
  Sep 19 09:47:34 utility01 systemd-networkd[776]:
  [/etc/systemd/network/vlan1.network:6] VLAN could not be found, ignoring
  assignment: 1
  Sep 19 09:47:34 utility01 systemd-networkd[776]:
  [/etc/systemd/network/vlan0.network:6] VLAN could not be found, ignoring
  assignment: 0
  Sep 19 09:47:34 utility01 systemd-networkd[776]:
  [/etc/systemd/network/eth0.network:6] VLAN could not be found, ignoring
  assignment: 1
  Sep 19 09:47:34 utility01 systemd-networkd[776]:
  [/etc/systemd/network/eth0.network:7] VLAN could not be found, ignoring
  assignment: 0
  Sep 19 09:47:34 utility01 systemd-networkd[776]: eth0.0  : gained
  carrier
  Sep 19 09:47:34 utility01 systemd-networkd[776]: eth0: gained
  carrier
  Sep 19 09:47:34 utility01 systemd-networkd[776]: lo  : gained
  carrier
  Sep 19 09:47:34 utility01 systemd[1]: Started Network Service.
  
  Although I strongly believe this to be an error I am making somewhere, I
  have read and re-read all of the systemd-networkd man pages, and cannot
  for the life of me figure out where I went wrong. Any help is much
  appreciated! Additional environment information is included below.
  
  [root@utility01 network]# uname -a
  Linux utility01 3.12.26-2-ARCH #1 PREEMPT Sun Aug 31 22:36:40 MDT 2014
  armv6l GNU/Linux
  [root@utility01 network]# pacman -Q systemd
  systemd 216-3
  [root@utility01 network]# lsmod | grep 8021q
  8021q  20658  0
  garp6303  1 8021q
  mrp 8249  1 8021q
  
  [root@utility01 network]# pwd
  /etc/systemd/network
  [root@utility01 network]# for f in *; do echo; echo -- $f; echo;
  cat $f; done
  
  -- eth0.network
  
  [Match]
  Name=eth0
  
  [Network]
  DHCP=v4
  VLAN=1
  VLAN=0
 
 This needs to be the names of your vlan interfaces, not their vlanid. I.e.,
 
 VLAN=vlan0
 VLAN=vlan1
 
  -- vlan0.netdev
  
  [NetDev]
  Name=vlan0
  Kind=vlan
  
  [VLAN]
  Id=0
  
  -- vlan0.network
  
  [Match]
  Name=vlan0
  
  [Network]
  DHCP=v4
  VLAN=0
  
  -- vlan1.netdev
  
  [NetDev]
  Name=vlan1
  Kind=vlan
  
  [VLAN]
  Id=1
  
  -- vlan1.network
  
  [Match]
  Name=vlan1
  
  [Network]
  DHCP=v4
  VLAN=1
  [root@utility01 network]# ip link
  1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN mode
  DEFAULT group default
  
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  
  2: ifb0: BROADCAST,NOARP mtu 1500 qdisc noop state DOWN mode DEFAULT
  group default qlen 32
  
  link/ether 3e:ff:bc:28:42:cb brd ff:ff:ff:ff:ff:ff
  
  3: ifb1: BROADCAST,NOARP mtu 1500 qdisc noop state DOWN mode DEFAULT
  group default qlen 32
  
  link/ether 3a:65:88:fc:ab:27 brd ff:ff:ff:ff:ff:ff
  
  4: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state
  UP mode DEFAULT group default qlen 1000
  
  link/ether b8:27:eb:9d:3a:06 brd ff:ff:ff:ff:ff:ff
  
  5: wlan0: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN mode
  DEFAULT
  group default qlen 1000
  
  link/ether 64:66:b3:20:04:f5 brd ff:ff:ff:ff:ff:ff
  
  6: eth0.0@eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue
  state UP mode DEFAULT group default
  
  link/ether b8:27:eb:9d:3a:06 brd ff:ff:ff:ff:ff:ff
  
  NOTE: The existing eth0.0 was created using vconfig, which I created
  simply to get this machine back on the network while I troubleshooted my
  issue. ___
  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] Systemd-nspawn -- Unable to initialize virtual ethernet connection

[Tom Gundersen]

On Fri, Sep 19, 2014 at 6:37 PM, James Lott ja...@lottspot.com wrote:
 I am trying to setup and play around with some of the private networking
 features of systemd, and one of the big thinks I'm trying to get working is
 the virtual ethernet links. For some reason though, I am unable to start a
 containder using a virtual ethernet link. My attempt is included below.

This is a bug. Thanks for the report!

I now pushed a fix:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=c00524c9cc7fb498c7244350e25823b8352f078c.

The problem was that we were not correctly truncating the machine name
(by default taken from the folder name) when using it to create a veth
link. Until the fix lands in your distro, you can simply rename your
container instance to a shorter name using the --machine switch to
systemd-nspawn.

Cheers,

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

Re: [systemd-devel] Systemd-nspawn -- Unable to initialize virtual ethernet connection

[James Lott]

Thanks so much for debugging that!

Your recommended work around, of course, works perfectly for me until the 
release hits the Arch repos (although my gentoo machines will happily and 
impatiently pull in the git snapshot  ).

Do you know what the version number for the next systemd release will be? I 
want to make sure I keep my eyes peeled for it!

On Friday 19 September 2014 23:04:40 Tom Gundersen wrote:
 On Fri, Sep 19, 2014 at 6:37 PM, James Lott ja...@lottspot.com wrote:
  I am trying to setup and play around with some of the private networking
  features of systemd, and one of the big thinks I'm trying to get working
  is
  the virtual ethernet links. For some reason though, I am unable to start a
  containder using a virtual ethernet link. My attempt is included below.
 
 This is a bug. Thanks for the report!
 
 I now pushed a fix:
 http://cgit.freedesktop.org/systemd/systemd/commit/?id=c00524c9cc7fb498c724
 4350e25823b8352f078c.
 
 The problem was that we were not correctly truncating the machine name
 (by default taken from the folder name) when using it to create a veth
 link. Until the fix lands in your distro, you can simply rename your
 container instance to a shorter name using the --machine switch to
 systemd-nspawn.
 
 Cheers,
 
 Tom

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

Re: [systemd-devel] Systemd-nspawn -- Unable to initialize virtual ethernet connection

[Tom Gundersen]

On Fri, Sep 19, 2014 at 11:24 PM, James Lott ja...@lottspot.com wrote:
 Do you know what the version number for the next systemd release will be? I
 want to make sure I keep my eyes peeled for it!

We are currently at 216, so the next one will be 217 (I guess in a
month or so from now).

Cheers,

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