Re: [systemd-devel] [PATCH v2 5/5] mount: auto-detect iSCSI and FCoE as requiring network

[Karel Zak]

On Wed, Dec 10, 2014 at 01:53:09AM +0100, Lennart Poettering wrote:
 On Tue, 09.12.14 12:30, Karel Zak (k...@redhat.com) wrote:
 
  On Mon, Dec 08, 2014 at 08:10:08PM +0100, Lennart Poettering wrote:
   Any idea when you intend to realease this new API in a release or even
   in a stable one?
  
   I'd like to have v2.26-rc1 this month.
  
 
 Hmm, OK, then I'll release 218 with the current direct inotify

or you can release it without this feature :-) 

It's all about mount -o _netdev executed from command line and it's 
unsupported by systemd for years -- I think we can wait one release.

Karel

-- 
 Karel Zak  k...@redhat.com
 http://karelzak.blogspot.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] virt: fix container detection when we're not PID 1

[Jan Synacek]

systemd-detect-virt would print none when using nspawn to run a shell
inside a container and then running systemd-detect-virt in it, because
the shell would be PID 1, not the actuall systemd-detect-virt process.
---
 src/shared/virt.c | 19 ++-
 1 file changed, 6 insertions(+), 13 deletions(-)

diff --git a/src/shared/virt.c b/src/shared/virt.c
index f9c4e67..298e005 100644
--- a/src/shared/virt.c
+++ b/src/shared/virt.c
@@ -275,18 +275,10 @@ int detect_container(const char **id) {
 goto finish;
 }
 
-if (getpid() == 1) {
-/* If we are PID 1 we can just check our own
- * environment variable */
-
-e = getenv(container);
-if (isempty(e)) {
-r = 0;
-goto finish;
-}
-} else {
-
-/* Otherwise, PID 1 dropped this information into a
+/* Check our own environment variable */
+e = getenv(container);
+if (isempty(e)) {
+/* PID 1 dropped this information into a
  * file in /run. This is better than accessing
  * /proc/1/environ, since we don't need CAP_SYS_PTRACE
  * for that. */
@@ -300,7 +292,8 @@ int detect_container(const char **id) {
 return r;
 
 e = m;
-}
+} else
+r = 0;
 
 /* We only recognize a selected few here, since we want to
  * enforce a redacted namespace */
-- 
1.9.3

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

Re: [systemd-devel] [PATCH] test: fix some tests when running inside a container

[Jan Synacek]

Jan Synacek jsyna...@redhat.com writes:
 ---
  src/test/test-execute.c | 2 +-
  src/test/test-util.c| 3 ---
  test/udev-test.pl   | 8 
  3 files changed, 9 insertions(+), 4 deletions(-)

 diff --git a/src/test/test-util.c b/src/test/test-util.c
 index 20e711d..c055955 100644
 --- a/src/test/test-util.c
 +++ b/src/test/test-util.c
 @@ -495,7 +495,6 @@ static void test_get_process_comm(void) {
  pid_t e;
  uid_t u;
  gid_t g;
 -dev_t h;
  int r;
  pid_t me;
  
 @@ -544,8 +543,6 @@ static void test_get_process_comm(void) {
  assert_se(r = 0 || r == -EACCES);
  log_info(self strlen(environ): '%zd', strlen(env));
  
 -assert_se(get_ctty_devnr(1, h) == -ENOENT);
 -
  getenv_for_pid(1, PATH, i);
  log_info(pid1 $PATH: '%s', strna(i));

This part is wrong, sorry about that, I'll send a new patch.

-- 
Jan Synacek
Software Engineer, Red Hat


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

Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'

[Francis Moreau]

Hello,

On 12/10/2014 07:23 AM, Ivan Shapovalov wrote:
 On Tuesday 09 December 2014 at 17:25:48, Francis Moreau wrote:
 Hello Lennart,

 Thanks for answering !

 On 12/09/2014 02:10 PM, Lennart Poettering wrote:
 On Tue, 09.12.14 11:19, Francis Moreau (francis.m...@gmail.com) wrote:

 Hello,

 I've a very weird behaviour with systemd 217:

 # systemctl show -p Wants multi-user.target | grep network.service
 # systemctl show -p Wants runlevel3.target | grep network.service
 Wants= ... network.service ...
 # systemctl show -p Wants multi-user.target | grep network.service
 Wants=... network.service ...

 So basically the network.service is not part of the multi-user target
 dependencies. But if I'm showing the state of the runlevel3 target, the
 network service magically becomes a dep of multi-user.target.

 The network.service is an sysv service which is started by rc[345].d and
 has in its LSB:

 Provide: $network

 Could anybody clarify what I'm facing ?

 systemd lazy loads services from the file system as they are
 referenced. This includes symlinked aliases, which are only loaded when
 a unit is referenced by that specific name.


 Sorry but I don't really understand.

 Do you mean that the network.service wasn't loaded although the
 runlevel3.target, which is an alias for multi-user target (default
 target) wants it ?

 I would be glad if you could enlight me because I'm confused.
 
 Apparently, network.service gets pulled in only via runlevel3.target, i. e.
 there is a symlink of kind
 
 /{etc,usr/lib,run}/systemd/system/runlevel3.target.wants/network.service - 
 network.service
 
 That is, the Wants= dependency is generated for runlevel3.target only, not for
 multi-user.target.
 
 And, because systemd loads units lazily, systemd does not know about 
 runlevel3.target
 (and its dependencies) before anything forces systemd to load that unit.
 
 After you issue `systemctl show runlevel3.target`, systemd loads that unit,
 loads its dependencies and merges them to multi-user.target (because 
 runlevel3.target
 is an alias for multi-user.target).

That helps, thanks !

However that seems a bit weird to have a target with 'hidden'
dependencies that can appears magically when poking another one, at
least from my point of (user) view.

Was the lazy load mechanism integrated recently ? I'm asking because
systemd 208 doesn't show the same behaviour.

What's the recommanded way to make sure that the Wants= dependencies
generated for runlevel3 target get pplied as soon as possible to its
alias target 'multi-user' ?

Thanks for your help.

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

[systemd-devel] [PATCH v2] test: fix some tests when running inside a container

[Jan Synacek]

---
v2:
* don't remove the assert, run in if not in a container

 src/test/test-execute.c | 2 +-
 src/test/test-util.c| 4 +++-
 test/udev-test.pl   | 8 
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/src/test/test-execute.c b/src/test/test-execute.c
index 85deb27..60466f0 100644
--- a/src/test/test-execute.c
+++ b/src/test/test-execute.c
@@ -164,7 +164,7 @@ int main(int argc, char *argv[]) {
 r = manager_new(SYSTEMD_USER, true, m);
 if (IN_SET(r, -EPERM, -EACCES, -EADDRINUSE, -EHOSTDOWN, -ENOENT)) {
 printf(Skipping test: manager_new: %s, strerror(-r));
-return -EXIT_TEST_SKIP;
+return EXIT_TEST_SKIP;
 }
 assert_se(r = 0);
 assert_se(manager_startup(m, NULL, NULL) = 0);
diff --git a/src/test/test-util.c b/src/test/test-util.c
index 20e711d..fe54586 100644
--- a/src/test/test-util.c
+++ b/src/test/test-util.c
@@ -35,6 +35,7 @@
 #include def.h
 #include fileio.h
 #include conf-parser.h
+#include virt.h
 
 static void test_streq_ptr(void) {
 assert_se(streq_ptr(NULL, NULL));
@@ -544,7 +545,8 @@ static void test_get_process_comm(void) {
 assert_se(r = 0 || r == -EACCES);
 log_info(self strlen(environ): '%zd', strlen(env));
 
-assert_se(get_ctty_devnr(1, h) == -ENOENT);
+if (!detect_container(NULL))
+assert_se(get_ctty_devnr(1, h) == -ENOENT);
 
 getenv_for_pid(1, PATH, i);
 log_info(pid1 $PATH: '%s', strna(i));
diff --git a/test/udev-test.pl b/test/udev-test.pl
index 14f11df..3e05b61 100755
--- a/test/udev-test.pl
+++ b/test/udev-test.pl
@@ -27,6 +27,7 @@ my $udev_dev= test/dev;
 my $udev_run= test/run;
 my $udev_rules_dir  = $udev_run/udev/rules.d;
 my $udev_rules  = $udev_rules_dir/udev-test.rules;
+my $EXIT_TEST_SKIP  = 77;
 
 my @tests = (
 {
@@ -1485,6 +1486,13 @@ if (!($==0)) {
 exit;
 }
 
+# skip the test when running in a container
+system(systemd-detect-virt, -c, -q);
+if ($?  8 == 0) {
+print Running in a container, skipping the test.\n;
+exit($EXIT_TEST_SKIP);
+}
+
 udev_setup();
 
 my $test_num = 1;
-- 
1.9.3

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

[systemd-devel] [PATCH] test: fix some tests when running inside a container

[Jan Synacek]

---
 src/test/test-execute.c | 2 +-
 src/test/test-util.c| 3 ---
 test/udev-test.pl   | 8 
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/src/test/test-execute.c b/src/test/test-execute.c
index 85deb27..60466f0 100644
--- a/src/test/test-execute.c
+++ b/src/test/test-execute.c
@@ -164,7 +164,7 @@ int main(int argc, char *argv[]) {
 r = manager_new(SYSTEMD_USER, true, m);
 if (IN_SET(r, -EPERM, -EACCES, -EADDRINUSE, -EHOSTDOWN, -ENOENT)) {
 printf(Skipping test: manager_new: %s, strerror(-r));
-return -EXIT_TEST_SKIP;
+return EXIT_TEST_SKIP;
 }
 assert_se(r = 0);
 assert_se(manager_startup(m, NULL, NULL) = 0);
diff --git a/src/test/test-util.c b/src/test/test-util.c
index 20e711d..c055955 100644
--- a/src/test/test-util.c
+++ b/src/test/test-util.c
@@ -495,7 +495,6 @@ static void test_get_process_comm(void) {
 pid_t e;
 uid_t u;
 gid_t g;
-dev_t h;
 int r;
 pid_t me;
 
@@ -544,8 +543,6 @@ static void test_get_process_comm(void) {
 assert_se(r = 0 || r == -EACCES);
 log_info(self strlen(environ): '%zd', strlen(env));
 
-assert_se(get_ctty_devnr(1, h) == -ENOENT);
-
 getenv_for_pid(1, PATH, i);
 log_info(pid1 $PATH: '%s', strna(i));
 }
diff --git a/test/udev-test.pl b/test/udev-test.pl
index 14f11df..3e05b61 100755
--- a/test/udev-test.pl
+++ b/test/udev-test.pl
@@ -27,6 +27,7 @@ my $udev_dev= test/dev;
 my $udev_run= test/run;
 my $udev_rules_dir  = $udev_run/udev/rules.d;
 my $udev_rules  = $udev_rules_dir/udev-test.rules;
+my $EXIT_TEST_SKIP  = 77;
 
 my @tests = (
 {
@@ -1485,6 +1486,13 @@ if (!($==0)) {
 exit;
 }
 
+# skip the test when running in a container
+system(systemd-detect-virt, -c, -q);
+if ($?  8 == 0) {
+print Running in a container, skipping the test.\n;
+exit($EXIT_TEST_SKIP);
+}
+
 udev_setup();
 
 my $test_num = 1;
-- 
1.9.3

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

[systemd-devel] when is a service ready to be used after startup?

[Olaf Hering]

I wonder how systemd handles the startup time of a daemon once it did
the execve (or whatever systemd does internally). Every daemon needs
some time until it can service requests. 

In the following example a socket is provided, a daemon handles the
socket and another tool will use the socket. How can I make sure tool B
will always find an operational socket handled by A? There is the
obvious startup time required within A until it can service requests.

What happens if B runs and tries to acces /path while A is still
starting up?

Olaf

A.socket:
[Unit]
DescriptionA socket
[Socket]
ListenStream=/path
SocketMode=0600
Service=A.service
[Install]
WantedBy=sockets.target


A.service:
[Unit]
Description=A service
Requires=A.socke
[Service]
Type=notify
ExecStart=/bin/A
[Install]
WantedBy=multi-user.target


B.service:
[Unit]
Description=B, a tool talking to A
Requires=A.service
[Service]
Type=oneshot
ExecStart=/bin/B
[Install]
WantedBy=multi-user.target
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v7] run: introduce timer support option

[Lennart Poettering]

On Wed, 10.12.14 16:01, WaLyong Cho (walyong@samsung.com) wrote:

 On 12/10/2014 02:25 AM, Lennart Poettering wrote:
  On Tue, 09.12.14 16:07, WaLyong Cho (walyong@samsung.com) wrote:
  
  Support timer options --on-active=, --on-boot=, --on-startup=,
  --on-unit-active=, --on-unit-inactive=, --on-calendar=. Each options
  corresponding with OnActiveSec=, OnBootSec=, OnStartupSec=,
  OnUnitActiveSec=, OnUnitInactiveSec=, OnCalendar= of timer
  respectively. And OnCalendar= and WakeSystem= supported by
  --timer-property= option like --property= of systemd-run.
  
  Looks good! Applied!
  
  Thanks!
 
 Do you have plan to crontab-generator?

No. At least on Fedora we only have a limited number of system cron
jobs, and I'd rather see those converted natively, rather than
maintaining a compatibility generator for a longer time

Lennart

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

Re: [systemd-devel] serialization bug, swap bug, etc.

[Lennart Poettering]

On Wed, 10.12.14 09:10, Mantas Mikulėnas (graw...@gmail.com) wrote:

 On Thu, Nov 20, 2014 at 9:13 AM, Mantas Mikulėnas graw...@gmail.com wrote:
 
  ~ I'm also getting this on every reload:
 
  systemd[1]: [/usr/lib/systemd/system/systemd-journald.service:24] Failed
  to parse capability in bounding set, ignoring: CAP_AUDIT_READ
 
  I suppose I can ignore the message. I see that cap_audit_read was added to
  kernel 3.16, but unfortunately it doesn't exist in the current libcap
  release (libcap 2.24).
 
 
 Seems like this no longer shows up on my machine, since Arch seems to be
 building libcap against linux-api-headers now (instead of its internal
 copy, I guess).

I also added some code to systemd yesterday that uses its own cap
list, which is more up-to-date. In fact, I think we should drop the
libcap dependency altogether and just do the two syscalls it offers to
us natively in systemd code. Neither is libcap a particularly nice
library, nor is the stuff it does particularly complex, hence we can
as well wrap the two calls we need in our code.

Lennart

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

Re: [systemd-devel] [PATCH] virt: fix container detection when we're not PID 1

[Lennart Poettering]

On Wed, 10.12.14 09:21, Jan Synacek (jsyna...@redhat.com) wrote:

 systemd-detect-virt would print none when using nspawn to run a shell
 inside a container and then running systemd-detect-virt in it, because
 the shell would be PID 1, not the actuall systemd-detect-virt
 process.

So, previously the code read the env var directly from
/proc/1/environ, but that file is only readable with privs, hence I
added code to PID 1 to write the value of that env var to
/run/systemd/container which is readable without privs. Now, if you
run a shell as PID 1 that will obviously not happen and the detection
won't work after all. 

Simply relying that $container is inherited from PID 1 down is
something I'd really like to avoid, though.

I have now made a change to the code that falls back to
getenv_for_pid() if /rub/systemd/container does not exist. THis will
only be ffective with perms however. The new code hence still isn't
perfect: if you boot up with only a shell as PID 1 and drop privileges
the code will still not be able to detect the container manager. Not
sure what other option we have, though.

 ---
  src/shared/virt.c | 19 ++-
  1 file changed, 6 insertions(+), 13 deletions(-)
 
 diff --git a/src/shared/virt.c b/src/shared/virt.c
 index f9c4e67..298e005 100644
 --- a/src/shared/virt.c
 +++ b/src/shared/virt.c
 @@ -275,18 +275,10 @@ int detect_container(const char **id) {
  goto finish;
  }
  
 -if (getpid() == 1) {
 -/* If we are PID 1 we can just check our own
 - * environment variable */
 -
 -e = getenv(container);
 -if (isempty(e)) {
 -r = 0;
 -goto finish;
 -}
 -} else {
 -
 -/* Otherwise, PID 1 dropped this information into a
 +/* Check our own environment variable */
 +e = getenv(container);
 +if (isempty(e)) {
 +/* PID 1 dropped this information into a
   * file in /run. This is better than accessing
   * /proc/1/environ, since we don't need CAP_SYS_PTRACE
   * for that. */
 @@ -300,7 +292,8 @@ int detect_container(const char **id) {
  return r;
  
  e = m;
 -}
 +} else
 +r = 0;
  
  /* We only recognize a selected few here, since we want to
   * enforce a redacted namespace */
 -- 
 1.9.3
 
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Lennart

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

Re: [systemd-devel] when is a service ready to be used after startup?

[Mantas Mikulėnas]

On Wed, Dec 10, 2014 at 11:32 AM, Olaf Hering o...@aepfle.de wrote:


 I wonder how systemd handles the startup time of a daemon once it did
 the execve (or whatever systemd does internally). Every daemon needs
 some time until it can service requests.


It depends.

* With regular services, systemd expects the daemon itself to announce that
it's ready. You use Type=forking, Type=notify, Type=dbus to choose
which event systemd will wait for.

* With socket-activated services, this doesn't matter at all, since the
requests won't fail, just get queued by the kernel.


 In the following example a socket is provided, a daemon handles the
 socket and another tool will use the socket. How can I make sure tool B
 will always find an operational socket handled by A? There is the
 obvious startup time required within A until it can service requests.


Keep in mind that socket is operational and daemon is ready to service
requests are two separate events. With regular services, the difference is
hard to notice. But in this example, you are using socket activation, and
making these events separate is the whole point of socket activation!

What happens if B runs and tries to acces /path while A is still
 starting up?


1) systemd will ensure that the socket is operational long before it starts
any services;

2) when /bin/B attempts to connect, the kernel will make it wait in the
accept queue;

3) when A.service starts, it will inherit the already-operational socket fd
from systemd;

4) when A finally enters its accept() loop, B's connection attempt will
resume normally.

(The same mechanism is used by inetd/xinetd in its 'wait' mode, as well as
launchd.)

A.socket:
 [Unit]
 DescriptionA socket
 [Socket]
 ListenStream=/path
 SocketMode=0600
 Service=A.service


This Service= setting is redundant.

B.service:
 [Unit]
 Description=B, a tool talking to A
 Requires=A.service


Instead of this, use Requires=A.socket + After=A.socket.

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

Re: [systemd-devel] /usr vs /etc for default distro units enablement

[Didier Roche]

Le 05/12/2014 16:42, Lennart Poettering a écrit :

On Fri, 05.12.14 16:02, Didier Roche (didro...@ubuntu.com) wrote:




This would also only fix the newly installed case, not the upgrade with
new distro defaults or various purge vs remove ones. That's why I think some
kind of previous state db can help getting all those requirements met as you
propose, and doing some comparisons between states (only when they deviated
from defaults).
Then, we can run preset on packages that matches previous defaults (meaning:
where the admin didn't override the default choice) as a dpkg trigger (when
new units are installed/upgraded and on a new/updated preset file shipped).
Would that makes sense?

Not sure I grok what you are proposing. I'd be very careful with
keeping yet another layer of service enablement states (even if just
as history) in systemd upstream.


I can clearly understand why you don't want to have a database of 
previous default enablement status. (that's what debian/ubuntu is doing 
right now in /var, having a bunch of symlinks to keep default state).


There are 3 cases that we want to have supported (ideally with preset-only):

1. upgrade with default policy change:
* foo.service is enabled in a target (with an [Install] section). Preset 
says 'enable *' (== no preset stenza) by default.

* sysadmin didn't enable/disable it.
* an upgrade of a package (not necessarily the package containing 
foo.service) ships a new preset file with disable foo.service

- We should have then foo.service disabled as per preset choice.

2. upgrade with dependency change:
* foo.service was WantedBy=bar.target. It was enabled by default.
* sysadmin didn't enable/disable it.
* After an upgrade, the unit contains WantedBy=baz.target (still enabled 
by default)
- We have it still enabled by enabled (as per preset choice), with 
.wants symlink from baz.target


From those 2 cases, we could say: just run systemctl preset on every 
package upgrade or preset change, however, there is as well this case:


3. upgrade with default changes, but sysadmin overrides:
* foo.service was WantedBy=bar.target. It was enabled by default.
* sysadmin run systemctl disable foo.service (or mask it)
* After an upgrade, the unit contains WantedBy=baz.target (still enabled 
by default preset policy)

- We shouldn't have foo.service enabled back as the admin did disable it.

That's why I was evocating keeping a previous state database to detect 
previous default state == current state, and only run preset on the 
package in that case (and new installs).


Is this more clear? Any other idea of on an elegant way of handling 
those without having the previous state database? (in an upstream 
compatible way, if possible)

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

Re: [systemd-devel] [PATCH v2] test: fix some tests when running inside a container

[Lennart Poettering]

On Wed, 10.12.14 10:20, Jan Synacek (jsyna...@redhat.com) wrote:

Applied!

Thanks!

 ---
 v2:
 * don't remove the assert, run in if not in a container
 
  src/test/test-execute.c | 2 +-
  src/test/test-util.c| 4 +++-
  test/udev-test.pl   | 8 
  3 files changed, 12 insertions(+), 2 deletions(-)
 
 diff --git a/src/test/test-execute.c b/src/test/test-execute.c
 index 85deb27..60466f0 100644
 --- a/src/test/test-execute.c
 +++ b/src/test/test-execute.c
 @@ -164,7 +164,7 @@ int main(int argc, char *argv[]) {
  r = manager_new(SYSTEMD_USER, true, m);
  if (IN_SET(r, -EPERM, -EACCES, -EADDRINUSE, -EHOSTDOWN, -ENOENT)) {
  printf(Skipping test: manager_new: %s, strerror(-r));
 -return -EXIT_TEST_SKIP;
 +return EXIT_TEST_SKIP;
  }
  assert_se(r = 0);
  assert_se(manager_startup(m, NULL, NULL) = 0);
 diff --git a/src/test/test-util.c b/src/test/test-util.c
 index 20e711d..fe54586 100644
 --- a/src/test/test-util.c
 +++ b/src/test/test-util.c
 @@ -35,6 +35,7 @@
  #include def.h
  #include fileio.h
  #include conf-parser.h
 +#include virt.h
  
  static void test_streq_ptr(void) {
  assert_se(streq_ptr(NULL, NULL));
 @@ -544,7 +545,8 @@ static void test_get_process_comm(void) {
  assert_se(r = 0 || r == -EACCES);
  log_info(self strlen(environ): '%zd', strlen(env));
  
 -assert_se(get_ctty_devnr(1, h) == -ENOENT);
 +if (!detect_container(NULL))
 +assert_se(get_ctty_devnr(1, h) == -ENOENT);
  
  getenv_for_pid(1, PATH, i);
  log_info(pid1 $PATH: '%s', strna(i));
 diff --git a/test/udev-test.pl b/test/udev-test.pl
 index 14f11df..3e05b61 100755
 --- a/test/udev-test.pl
 +++ b/test/udev-test.pl
 @@ -27,6 +27,7 @@ my $udev_dev= test/dev;
  my $udev_run= test/run;
  my $udev_rules_dir  = $udev_run/udev/rules.d;
  my $udev_rules  = $udev_rules_dir/udev-test.rules;
 +my $EXIT_TEST_SKIP  = 77;
  
  my @tests = (
  {
 @@ -1485,6 +1486,13 @@ if (!($==0)) {
  exit;
  }
  
 +# skip the test when running in a container
 +system(systemd-detect-virt, -c, -q);
 +if ($?  8 == 0) {
 +print Running in a container, skipping the test.\n;
 +exit($EXIT_TEST_SKIP);
 +}
 +
  udev_setup();
  
  my $test_num = 1;
 -- 
 1.9.3
 
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Lennart

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

Re: [systemd-devel] [PATCH] virt: fix container detection when we're not PID 1

[Jan Synacek]

Lennart Poettering lenn...@poettering.net writes:
 On Wed, 10.12.14 09:21, Jan Synacek (jsyna...@redhat.com) wrote:

 systemd-detect-virt would print none when using nspawn to run a shell
 inside a container and then running systemd-detect-virt in it, because
 the shell would be PID 1, not the actuall systemd-detect-virt
 process.

 So, previously the code read the env var directly from
 /proc/1/environ, but that file is only readable with privs, hence I
 added code to PID 1 to write the value of that env var to
 /run/systemd/container which is readable without privs. Now, if you
 run a shell as PID 1 that will obviously not happen and the detection
 won't work after all. 

 Simply relying that $container is inherited from PID 1 down is
 something I'd really like to avoid, though.

Could you please explain why? I don't see why that might be a problem.

 I have now made a change to the code that falls back to
 getenv_for_pid() if /rub/systemd/container does not exist. THis will
 only be ffective with perms however. The new code hence still isn't
 perfect: if you boot up with only a shell as PID 1 and drop privileges
 the code will still not be able to detect the container manager. Not
 sure what other option we have, though.

Thanks!

-- 
Jan Synacek
Software Engineer, Red Hat


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

Re: [systemd-devel] [PATCH] virt: fix container detection when we're not PID 1

[Zbigniew Jędrzejewski-Szmek]

On Wed, Dec 10, 2014 at 01:52:08PM +0100, Jan Synacek wrote:
 Lennart Poettering lenn...@poettering.net writes:
  On Wed, 10.12.14 09:21, Jan Synacek (jsyna...@redhat.com) wrote:
 
  systemd-detect-virt would print none when using nspawn to run a shell
  inside a container and then running systemd-detect-virt in it, because
  the shell would be PID 1, not the actuall systemd-detect-virt
  process.
 
  So, previously the code read the env var directly from
  /proc/1/environ, but that file is only readable with privs, hence I
  added code to PID 1 to write the value of that env var to
  /run/systemd/container which is readable without privs. Now, if you
  run a shell as PID 1 that will obviously not happen and the detection
  won't work after all. 
 
  Simply relying that $container is inherited from PID 1 down is
  something I'd really like to avoid, though.
 
 Could you please explain why? I don't see why that might be a problem.
Because container is a completely generic name, and it is not exported
to children by systemd.
 
  I have now made a change to the code that falls back to
  getenv_for_pid() if /rub/systemd/container does not exist. THis will
  only be ffective with perms however. The new code hence still isn't
  perfect: if you boot up with only a shell as PID 1 and drop privileges
  the code will still not be able to detect the container manager. Not
  sure what other option we have, though.

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

[systemd-devel] [PATCH 2/6] sd-dhcp6-lease: Return only -EINVAL when a NULL lease is supplied

[Patrik Flykt]

Suppyling a NULL lease is not a condition that needs to be asserted,
returning -EINVAL is informative enough to the caller. This simplifies
calling code and doesn't falsely indicate that something erroneous was
attempted.
---
 src/libsystemd-network/sd-dhcp6-lease.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/libsystemd-network/sd-dhcp6-lease.c 
b/src/libsystemd-network/sd-dhcp6-lease.c
index e2715ea..8960fac 100644
--- a/src/libsystemd-network/sd-dhcp6-lease.c
+++ b/src/libsystemd-network/sd-dhcp6-lease.c
@@ -110,9 +110,11 @@ int dhcp6_lease_set_preference(sd_dhcp6_lease *lease, 
uint8_t preference) {
 }
 
 int dhcp6_lease_get_preference(sd_dhcp6_lease *lease, uint8_t *preference) {
-assert_return(lease, -EINVAL);
 assert_return(preference, -EINVAL);
 
+if (!lease)
+return -EINVAL;
+
 *preference = lease-preference;
 
 return 0;
-- 
2.1.3

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

[systemd-devel] [PATCH 4/6] test-dhcp6-client: Add a simple Information Request test case

[Patrik Flykt]

Start the DHCPv6 test case by sending an Information Request, verifying
the reply and continuing at once with the normal address acquisition
procedure. Reuse the DHCPv6 Solicit Reply so that the client code is
verified to ignore any erroneously added IPv6 address information.
---
 src/libsystemd-network/sd-dhcp6-client.c   |   1 +
 src/libsystemd-network/test-dhcp6-client.c | 126 -
 2 files changed, 108 insertions(+), 19 deletions(-)

diff --git a/src/libsystemd-network/sd-dhcp6-client.c 
b/src/libsystemd-network/sd-dhcp6-client.c
index 940a606..017371e 100644
--- a/src/libsystemd-network/sd-dhcp6-client.c
+++ b/src/libsystemd-network/sd-dhcp6-client.c
@@ -1025,6 +1025,7 @@ static int client_start(sd_dhcp6_client *client, enum 
DHCP6State state)
 assert_return(client-index  0, -EINVAL);
 assert_return(client-state != state, -EINVAL);
 
+log_dhcp6_client(client, client state %d new state %d, 
client-state, state);
 client-timeout_resend_expire =
 sd_event_source_unref(client-timeout_resend_expire);
 client-timeout_resend = sd_event_source_unref(client-timeout_resend);
diff --git a/src/libsystemd-network/test-dhcp6-client.c 
b/src/libsystemd-network/test-dhcp6-client.c
index 26b28a2..7590839 100644
--- a/src/libsystemd-network/test-dhcp6-client.c
+++ b/src/libsystemd-network/test-dhcp6-client.c
@@ -41,7 +41,7 @@ static struct ether_addr mac_addr = {
 .ether_addr_octet = {'A', 'B', 'C', '1', '2', '3'}
 };
 
-static bool verbose = false;
+static bool verbose = true;
 
 static sd_event_source *hangcheck;
 static int test_dhcp_fd[2];
@@ -335,13 +335,19 @@ int detect_virtualization(const char **id) {
 return 1;
 }
 
-int dhcp6_network_bind_udp_socket(int index, struct in6_addr *local_address) {
-assert_se(index == test_index);
+static void test_client_solicit_cb(sd_dhcp6_client *client, int event,
+   void *userdata) {
+sd_event *e = userdata;
 
-if (socketpair(AF_UNIX, SOCK_STREAM, 0, test_dhcp_fd)  0)
-return -errno;
+assert_se(e);
+assert_se(event == DHCP6_EVENT_IP_ACQUIRE);
 
-return test_dhcp_fd[0];
+assert_se(sd_dhcp6_client_set_request_option(client, 
DHCP6_OPTION_DNS_SERVERS) == -EBUSY);
+
+if (verbose)
+printf(  got DHCPv6 event %d\n, event);
+
+sd_event_exit(e, 0);
 }
 
 static int test_client_send_reply(DHCP6Message *request) {
@@ -513,6 +519,83 @@ static int test_client_verify_solicit(DHCP6Message 
*solicit, uint8_t *option,
 return 0;
 }
 
+static void test_client_information_cb(sd_dhcp6_client *client, int event,
+   void *userdata) {
+sd_event *e = userdata;
+
+assert_se(e);
+assert_se(event == DHCP6_EVENT_INFORMATION_REQUEST);
+
+if (verbose)
+printf(  got DHCPv6 event %d\n, event);
+
+assert_se(sd_dhcp6_client_set_information_request(client, false) = 0);
+assert_se(sd_dhcp6_client_set_callback(client,
+   test_client_solicit_cb, e) = 
0);
+
+assert_se(sd_dhcp6_client_start(client) = 0);
+}
+
+static int test_client_verify_information_request(DHCP6Message 
*information_request,
+  uint8_t *option, size_t len) 
{
+
+_cleanup_dhcp6_lease_free_ sd_dhcp6_lease *lease = NULL;
+uint8_t *optval;
+uint16_t optcode;
+size_t optlen;
+bool found_clientid = false, found_elapsed_time = false;
+int r;
+struct in6_addr addr;
+uint32_t lt_pref, lt_valid;
+
+assert_se(information_request-type == DHCP6_INFORMATION_REQUEST);
+
+assert_se(dhcp6_lease_new(lease) = 0);
+
+while ((r = dhcp6_option_parse(option, len,
+   optcode, optlen, optval)) = 0) {
+switch(optcode) {
+case DHCP6_OPTION_CLIENTID:
+assert_se(!found_clientid);
+found_clientid = true;
+
+assert_se(optlen == sizeof(test_duid));
+memcpy(test_duid, optval, sizeof(test_duid));
+
+break;
+
+case DHCP6_OPTION_IA_NA:
+assert_not_reached(IA TA option must not be present);
+
+break;
+
+case DHCP6_OPTION_SERVERID:
+assert_not_reached(Server ID option must not be 
present);
+
+break;
+
+case DHCP6_OPTION_ELAPSED_TIME:
+assert_se(!found_elapsed_time);
+found_elapsed_time = true;
+
+assert_se(optlen == 2);
+
+break;
+}
+}
+
+assert_se(r == -ENOMSG);
+assert_se(found_clientid  

[systemd-devel] [PATCH 1/6] sd-dhcp6-client: Make end of successfull option parsing explicit

[Patrik Flykt]

When all DHCPv6 options have been parsed, dhcp6_option_parse() returns
-ENOMSG. Explicitely set the return value to indicate success so that
later code does not need to take this special value into account.
---
 src/libsystemd-network/sd-dhcp6-client.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/libsystemd-network/sd-dhcp6-client.c 
b/src/libsystemd-network/sd-dhcp6-client.c
index 8537d7c..cc5b744 100644
--- a/src/libsystemd-network/sd-dhcp6-client.c
+++ b/src/libsystemd-network/sd-dhcp6-client.c
@@ -770,7 +770,10 @@ static int client_parse_message(sd_dhcp6_client *client,
 }
 }
 
-if ((r  0  r != -ENOMSG) || !clientid) {
+if (r == -ENOMSG)
+r = 0;
+
+if (r  0 || !clientid) {
 log_dhcp6_client(client, %s has incomplete options,
  dhcp6_message_type_to_string(message-type));
 return -EINVAL;
-- 
2.1.3

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

[systemd-devel] [PATCH 3/6] sd-dhcp6-client: Implement Information Request message

[Patrik Flykt]

Implement Information Request message according to RFC 3315, section
18.1.5. with the excepion that the first message is not delayed by a
random amount. Instead systemd-networkd is supposed to take care of
desynchronizing between other clients.

Initialize the DHCPv6 client structure in sd_dhcp6_client_start()
as this allows toggling between information request and normal
DHCPv6 address aquisition modes.
---
 src/libsystemd-network/dhcp6-protocol.h  |   3 +
 src/libsystemd-network/sd-dhcp6-client.c | 144 +++
 src/systemd/sd-dhcp6-client.h|   5 ++
 3 files changed, 117 insertions(+), 35 deletions(-)

diff --git a/src/libsystemd-network/dhcp6-protocol.h 
b/src/libsystemd-network/dhcp6-protocol.h
index eaa6717..3e0f339 100644
--- a/src/libsystemd-network/dhcp6-protocol.h
+++ b/src/libsystemd-network/dhcp6-protocol.h
@@ -51,6 +51,8 @@ enum {
 DHCP6_PORT_CLIENT   = 546,
 };
 
+#define DHCP6_INF_TIMEOUT   1 * USEC_PER_SEC
+#define DHCP6_INF_MAX_RT120 * USEC_PER_SEC
 #define DHCP6_SOL_MAX_DELAY 1 * USEC_PER_SEC
 #define DHCP6_SOL_TIMEOUT   1 * USEC_PER_SEC
 #define DHCP6_SOL_MAX_RT120 * USEC_PER_SEC
@@ -71,6 +73,7 @@ enum {
 
 enum DHCP6State {
 DHCP6_STATE_STOPPED = 0,
+DHCP6_STATE_INFORMATION_REQUEST = 1,
 DHCP6_STATE_SOLICITATION= 2,
 DHCP6_STATE_REQUEST = 3,
 DHCP6_STATE_BOUND   = 4,
diff --git a/src/libsystemd-network/sd-dhcp6-client.c 
b/src/libsystemd-network/sd-dhcp6-client.c
index cc5b744..940a606 100644
--- a/src/libsystemd-network/sd-dhcp6-client.c
+++ b/src/libsystemd-network/sd-dhcp6-client.c
@@ -62,6 +62,7 @@ struct sd_dhcp6_client {
 usec_t transaction_start;
 struct sd_dhcp6_lease *lease;
 int fd;
+bool information_request;
 be16_t *req_opts;
 size_t req_opts_allocated;
 size_t req_opts_len;
@@ -227,6 +228,25 @@ int sd_dhcp6_client_set_duid(sd_dhcp6_client *client, 
uint16_t type, uint8_t *du
 return 0;
 }
 
+int sd_dhcp6_client_set_information_request(sd_dhcp6_client *client,
+bool enabled) {
+assert_return(client, -EINVAL);
+
+client-information_request = enabled;
+
+return 0;
+}
+
+int sd_dhcp6_client_get_information_request(sd_dhcp6_client *client,
+bool *enabled) {
+assert_return(client, -EINVAL);
+assert_return(enabled, -EINVAL);
+
+*enabled = client-information_request;
+
+return 0;
+}
+
 int sd_dhcp6_client_set_request_option(sd_dhcp6_client *client,
uint16_t option) {
 size_t t;
@@ -333,6 +353,11 @@ static int client_send_message(sd_dhcp6_client *client, 
usec_t time_now) {
 message-transaction_id = client-transaction_id;
 
 switch(client-state) {
+case DHCP6_STATE_INFORMATION_REQUEST:
+message-type = DHCP6_INFORMATION_REQUEST;
+
+break;
+
 case DHCP6_STATE_SOLICITATION:
 message-type = DHCP6_SOLICIT;
 
@@ -494,6 +519,12 @@ static int client_timeout_resend(sd_event_source *s, 
uint64_t usec,
 client-timeout_resend = sd_event_source_unref(client-timeout_resend);
 
 switch (client-state) {
+case DHCP6_STATE_INFORMATION_REQUEST:
+init_retransmit_time = DHCP6_INF_TIMEOUT;
+max_retransmit_time = DHCP6_INF_MAX_RT;
+
+break;
+
 case DHCP6_STATE_SOLICITATION:
 
 if (client-retransmit_count  client-lease) {
@@ -744,6 +775,12 @@ static int client_parse_message(sd_dhcp6_client *client,
 break;
 
 case DHCP6_OPTION_IA_NA:
+if (client-state == DHCP6_STATE_INFORMATION_REQUEST) {
+log_dhcp6_client(client, Information request 
ignoring IA NA option);
+
+break;
+}
+
 r = dhcp6_option_parse_ia(optval, optlen, optcode,
   lease-ia);
 if (r  0  r != -ENOMSG)
@@ -779,10 +816,12 @@ static int client_parse_message(sd_dhcp6_client *client,
 return -EINVAL;
 }
 
-r = dhcp6_lease_get_serverid(lease, id, id_len);
-if (r  0)
-log_dhcp6_client(client, %s has no server id,
- dhcp6_message_type_to_string(message-type));
+if (client-state != DHCP6_STATE_INFORMATION_REQUEST) {
+r = dhcp6_lease_get_serverid(lease, id, id_len);
+if (r  0)
+log_dhcp6_client(client, %s has no server id,
+   

[systemd-devel] [PATCH 0/6] DHCPv6 Information request

[Patrik Flykt]

Hi,

This patch set implements DHCPv6 Information request, i.e. the situation
where Router Advertisments announce that only 'Other' information, not
IPv6 addresses, is available via DHCPv6. This patch doesn't have anything
to do with the prefix delegation discussed earlier; it was simply left
half implemented for a while on my machine.

The first two patches clean up the code a bit, so that later additions
are easier to implement.

The third patch adds support for requesting additional information and
ignores any addresses that should not have been sent by the DHCPv6
server anyway. Patch 04 makes a simple test case verifying also that it
is possible to switch from Information request to a normal DHCPv6 address
acquisition procedure.

Patch 05 moves systemd-networkd DHCPv6 initialization and handling into
a file of its own following what's been done for DHCPv4 and IPv4 link
local. Finally patch 06 adds the necessary logic to request the addtional
information from the DHCPv6 server and possibly upgrading the procedure
to the normal IPv6 address aquisition process should the 'Managed' bit
become set in the Router Advertisments. Reversing this procedure, i.e.
downgrading it back to fetching additional information only is not
possible according to RFCs.


Please review,

Patrik


Patrik Flykt (6):
  sd-dhcp6-client: Make end of successfull option parsing explicit
  sd-dhcp6-lease: Return only -EINVAL when a NULL lease is supplied
  sd-dhcp6-client: Implement Information Request message
  test-dhcp6-client: Add a simple Information Request test case
  networkd-dhcp6: Move ICMPv6 and DHCPv6 configuration to new file
  networkd-dhcp6: Support ICMPv6 Other information

 Makefile.am|   1 +
 src/libsystemd-network/dhcp6-protocol.h|   3 +
 src/libsystemd-network/sd-dhcp6-client.c   | 150 -
 src/libsystemd-network/sd-dhcp6-lease.c|   4 +-
 src/libsystemd-network/test-dhcp6-client.c | 126 ++---
 src/network/networkd-dhcp6.c   | 210 +
 src/network/networkd-link.c| 122 +
 src/network/networkd-link.h|   1 +
 src/systemd/sd-dhcp6-client.h  |   5 +
 9 files changed, 445 insertions(+), 177 deletions(-)
 create mode 100644 src/network/networkd-dhcp6.c

-- 
2.1.3

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

[systemd-devel] [PATCH 6/6] networkd-dhcp6: Support ICMPv6 Other information

[Patrik Flykt]

When ICMPv6 Other information is received, enable Information request
in DHCPv6. If the DHCPv6 client already exists, only update the client
if there is a transition from Other to Managed state.
---
 src/network/networkd-dhcp6.c | 55 
 1 file changed, 50 insertions(+), 5 deletions(-)

diff --git a/src/network/networkd-dhcp6.c b/src/network/networkd-dhcp6.c
index bf8d78b..c31bd4e 100644
--- a/src/network/networkd-dhcp6.c
+++ b/src/network/networkd-dhcp6.c
@@ -43,6 +43,7 @@ static void dhcp6_handler(sd_dhcp6_client *client, int event, 
void *userdata) {
 case DHCP6_EVENT_RESEND_EXPIRE:
 case DHCP6_EVENT_RETRANS_MAX:
 case DHCP6_EVENT_IP_ACQUIRE:
+case DHCP6_EVENT_INFORMATION_REQUEST:
 log_link_debug(link, DHCPv6 event %d, event);
 
 break;
@@ -58,13 +59,47 @@ static void dhcp6_handler(sd_dhcp6_client *client, int 
event, void *userdata) {
 }
 }
 
-static int dhcp6_configure(Link *link) {
+static int dhcp6_configure(Link *link, int event) {
 int r;
+bool information_request;
 
 assert_return(link, -EINVAL);
 
-if (link-dhcp6_client)
-return 0;
+if (link-dhcp6_client) {
+if (event != ICMP6_EVENT_ROUTER_ADVERTISMENT_MANAGED)
+return 0;
+
+r = sd_dhcp6_client_get_information_request(link-dhcp6_client,
+information_request);
+if (r  0) {
+log_link_warning(link, Could not get DHCPv6 
Information request setting);
+link-dhcp6_client =
+sd_dhcp6_client_unref(link-dhcp6_client);
+return r;
+}
+
+if (!information_request)
+return r;
+
+r = sd_dhcp6_client_set_information_request(link-dhcp6_client,
+false);
+if (r  0) {
+log_link_warning(link, Could not unset DHCPv6 
Information request);
+link-dhcp6_client =
+sd_dhcp6_client_unref(link-dhcp6_client);
+return r;
+}
+
+r = sd_dhcp6_client_start(link-dhcp6_client);
+if (r  0) {
+log_link_warning(link, Could not restart DHCPv6 after 
enabling Information request);
+link-dhcp6_client =
+sd_dhcp6_client_unref(link-dhcp6_client);
+return r;
+}
+
+return r;
+}
 
 r = sd_dhcp6_client_new(link-dhcp6_client);
 if (r  0)
@@ -97,6 +132,16 @@ static int dhcp6_configure(Link *link) {
 return r;
 }
 
+if (event == ICMP6_EVENT_ROUTER_ADVERTISMENT_OTHER) {
+r = sd_dhcp6_client_set_information_request(link-dhcp6_client,
+true);
+if (r  0) {
+link-dhcp6_client =
+sd_dhcp6_client_unref(link-dhcp6_client);
+return r;
+}
+}
+
 r = sd_dhcp6_client_start(link-dhcp6_client);
 if (r  0)
 link-dhcp6_client = sd_dhcp6_client_unref(link-dhcp6_client);
@@ -116,10 +161,10 @@ static void icmp6_router_handler(sd_icmp6_nd *nd, int 
event, void *userdata) {
 
 switch(event) {
 case ICMP6_EVENT_ROUTER_ADVERTISMENT_NONE:
-case ICMP6_EVENT_ROUTER_ADVERTISMENT_OTHER:
 return;
 
 case ICMP6_EVENT_ROUTER_ADVERTISMENT_TIMEOUT:
+case ICMP6_EVENT_ROUTER_ADVERTISMENT_OTHER:
 case ICMP6_EVENT_ROUTER_ADVERTISMENT_MANAGED:
 break;
 
@@ -134,7 +179,7 @@ static void icmp6_router_handler(sd_icmp6_nd *nd, int 
event, void *userdata) {
 return;
 }
 
-dhcp6_configure(link);
+dhcp6_configure(link, event);
 }
 
 int icmp6_configure(Link *link) {
-- 
2.1.3

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

[systemd-devel] [PATCH 5/6] networkd-dhcp6: Move ICMPv6 and DHCPv6 configuration to new file

[Patrik Flykt]

Handle all aspects of ICMPv6 and DHCPv6 in a file of its own as is done
with DHCPv4 and IPv4LL.
---
 Makefile.am  |   1 +
 src/network/networkd-dhcp6.c | 165 +++
 src/network/networkd-link.c  | 122 +---
 src/network/networkd-link.h  |   1 +
 4 files changed, 168 insertions(+), 121 deletions(-)
 create mode 100644 src/network/networkd-dhcp6.c

diff --git a/Makefile.am b/Makefile.am
index 23210ff..6f02c74 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5247,6 +5247,7 @@ libsystemd_networkd_core_la_SOURCES = \
src/network/networkd-link.c \
src/network/networkd-ipv4ll.c \
src/network/networkd-dhcp4.c \
+   src/network/networkd-dhcp6.c \
src/network/networkd-network.c \
src/network/networkd-address.c \
src/network/networkd-route.c \
diff --git a/src/network/networkd-dhcp6.c b/src/network/networkd-dhcp6.c
new file mode 100644
index 000..bf8d78b
--- /dev/null
+++ b/src/network/networkd-dhcp6.c
@@ -0,0 +1,165 @@
+/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
+
+/***
+  This file is part of systemd.
+
+  Copyright (C) 2014 Intel Corporation. All rights reserved.
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see http://www.gnu.org/licenses/.
+***/
+
+#include netinet/ether.h
+#include linux/if.h
+
+#include networkd-link.h
+#include network-internal.h
+
+#include sd-icmp6-nd.h
+#include sd-dhcp6-client.h
+
+static void dhcp6_handler(sd_dhcp6_client *client, int event, void *userdata) {
+Link *link = userdata;
+
+assert(link);
+assert(link-network);
+assert(link-manager);
+
+if (IN_SET(link-state, LINK_STATE_FAILED, LINK_STATE_LINGER))
+return;
+
+switch(event) {
+case DHCP6_EVENT_STOP:
+case DHCP6_EVENT_RESEND_EXPIRE:
+case DHCP6_EVENT_RETRANS_MAX:
+case DHCP6_EVENT_IP_ACQUIRE:
+log_link_debug(link, DHCPv6 event %d, event);
+
+break;
+
+default:
+if (event  0)
+log_link_warning(link, DHCPv6 error: %s,
+ strerror(-event));
+else
+log_link_warning(link, DHCPv6 unknown event: %d,
+ event);
+return;
+}
+}
+
+static int dhcp6_configure(Link *link) {
+int r;
+
+assert_return(link, -EINVAL);
+
+if (link-dhcp6_client)
+return 0;
+
+r = sd_dhcp6_client_new(link-dhcp6_client);
+if (r  0)
+return r;
+
+r = sd_dhcp6_client_attach_event(link-dhcp6_client, NULL, 0);
+if (r  0) {
+link-dhcp6_client = sd_dhcp6_client_unref(link-dhcp6_client);
+return r;
+}
+
+r = sd_dhcp6_client_set_mac(link-dhcp6_client,
+(const uint8_t *) link-mac,
+sizeof (link-mac), ARPHRD_ETHER);
+if (r  0) {
+link-dhcp6_client = sd_dhcp6_client_unref(link-dhcp6_client);
+return r;
+}
+
+r = sd_dhcp6_client_set_index(link-dhcp6_client, link-ifindex);
+if (r  0) {
+link-dhcp6_client = sd_dhcp6_client_unref(link-dhcp6_client);
+return r;
+}
+
+r = sd_dhcp6_client_set_callback(link-dhcp6_client, dhcp6_handler,
+ link);
+if (r  0) {
+link-dhcp6_client = sd_dhcp6_client_unref(link-dhcp6_client);
+return r;
+}
+
+r = sd_dhcp6_client_start(link-dhcp6_client);
+if (r  0)
+link-dhcp6_client = sd_dhcp6_client_unref(link-dhcp6_client);
+
+return r;
+}
+
+static void icmp6_router_handler(sd_icmp6_nd *nd, int event, void *userdata) {
+Link *link = userdata;
+
+assert(link);
+assert(link-network);
+assert(link-manager);
+
+if (IN_SET(link-state, LINK_STATE_FAILED, LINK_STATE_LINGER))
+return;
+
+switch(event) {
+case ICMP6_EVENT_ROUTER_ADVERTISMENT_NONE:
+case ICMP6_EVENT_ROUTER_ADVERTISMENT_OTHER:
+return;
+
+case ICMP6_EVENT_ROUTER_ADVERTISMENT_TIMEOUT:
+case 

Re: [systemd-devel] [PATCH] virt: fix container detection when we're not PID 1

[Lennart Poettering]

On Wed, 10.12.14 13:52, Jan Synacek (jsyna...@redhat.com) wrote:

 Lennart Poettering lenn...@poettering.net writes:
  On Wed, 10.12.14 09:21, Jan Synacek (jsyna...@redhat.com) wrote:
 
  systemd-detect-virt would print none when using nspawn to run a shell
  inside a container and then running systemd-detect-virt in it, because
  the shell would be PID 1, not the actuall systemd-detect-virt
  process.
 
  So, previously the code read the env var directly from
  /proc/1/environ, but that file is only readable with privs, hence I
  added code to PID 1 to write the value of that env var to
  /run/systemd/container which is readable without privs. Now, if you
  run a shell as PID 1 that will obviously not happen and the detection
  won't work after all. 
 
  Simply relying that $container is inherited from PID 1 down is
  something I'd really like to avoid, though.
 
 Could you please explain why? I don't see why that might be a problem.

Well, systemd when running as PID 1 tries hard to pass a fully cleaned
up environment to system services, so that they always run in the same
clean execution environment. Checking $container of your own process
will hence generally not work unless you do it from PID 1 -- if you
booted with systemd as PID 1. Moreover we really should have a way to
detect containers even if some process way down the tree cleans up the
environment, which many processes actually do.

Then, something not to ignore: $container can be set by an
unprivileged user for any process it launches. Thus, you can
relatively easily programs about the execution context they are
running in, which is particularly dangerous for SUID programs (see the
whole discussion around secure_getenv() regarding this). Hence I am a
lot more comfortable with checking /run/systemd/container and
/proc/1/environ, since neither is fakeable without privileges.

Hope that makese sense,

Lennart

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

Re: [systemd-devel] forever loop during garbage collection

[Umut Tezduyar Lindskog]

On Mon, Dec 8, 2014 at 8:09 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Sun, 30.11.14 14:38, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

 Hi,

 We are experiencing an unbreakable loop in manager_dispatch_gc_queue.
 Problem happens when systemd runs in sysV compatibility mode (Porky
 enables this).

 Seems like manager_dispatch_gc_queue's while loop gets stuck and seems
 like unit_gc_sweep cannot make a decision about the unit. As a result,
 it marks the unit with offset_unsure and adds the unit back to gc
 queue.

 If I am reading the code correctly recursive unit_gc_sweep will never
 be able to remove the unit from the gc queue if it is referenced by
 another unit and if another unit is referenced by the unit.

 A is referenced by B
 B is referenced by A

 So in this case first A will be processed by the GC sweep, it will
 follow the link to B while setting the state to IN_PATH and invoke the
 GC sweep on that. B will then be set to IN_PATH too. GC sweep now
 follows its link back, and up at A again, but this time return quickly
 because its state is set to IN_PATH. Due to this, it will then set B's
 state to UNSURE, and return to A, which in effect will now be set to
 UNSURE too. Now, we return into GC queue dispatch call, which will
 notice that it is UNSURE and uprgade that to BAD, and kill it because
 there's nothin in the unit's dependency network that is clearly a
 GOOD, and hence should be removed.

 The essence of cycle breaking here is really in
 manager_dispatch_gc_queue() which uprgades UNSURE to BAD in the end. I
 am not seeing how this could end up in an endless loop hence.

I have debugged it more and as you have said there is no bug in code
but it takes so long to go out of unit_gc_sweep I thought there is a
forever loop.

Attached is my patch on 216 and
https://drive.google.com/file/d/0B_uiALgWpGXtZ0VidURxSnVhcDA/view?usp=sharing
is a part of the log after patch.

It has been 3 hours since I issued systemctl isolate and according
to the logs I can see that garbage collection logic is making it's way
back up. I guess it will eventually resolve itself but after so many
hours.

(Search for - - and it is happening every 300.000 lines)

Problem seemed to be introduced on 95ed329 - Move handling of sysv
initscripts to a generator.

This is totally due to how sysV generator is linking services but I
think slowness on GC can happen on a complex system with many units
linked with each other.

Thoughts?
Umut



 We have this circular referenced by dependency between units and I am
 quite sure they are due to sysV compatibility.

 I know that systemd does not allow circular dependency between units
 (ex, wants, or after) but do we allow circular referenced by
 dependency? If so, then it is expected that manager_dispatch_gc_queue
 gets stuck.

 We can reproduce it on 216/217 when we isolate a target.

 Note: Line 
 http://cgit.freedesktop.org/systemd/systemd/tree/src/core/manager.c?id=941a643569dc6b53d0b334276d2a3cc0ed159e88#n875
 should be before
 http://cgit.freedesktop.org/systemd/systemd/tree/src/core/manager.c?id=941a643569dc6b53d0b334276d2a3cc0ed159e88#n872
 since unit_gc_sweep() sets the u-in_gc_queue = true if it cannot make
 a decision and we set it back to false.

 This is intended. After the sweep returned back to the anchor we can
 make our decision: either add the unit to the cleanup queue in which
 case it should removed from the GC queue, or it is reinstantated as
 a good unit that should continue to exist, in which case it should be
 removed from the GC queue too.

 Can't see a bug here...

 Can you elaborate on how precisely you are encountering the GC loop?

 Lennart

 --
 Lennart Poettering, Red Hat


0001-Debugging-gc_sweep 1.03.18 PM.patch
Description: Binary data
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v7] run: introduce timer support option

[Jóhann B. Guðmundsson]

On 12/10/2014 12:05 PM, Lennart Poettering wrote:

No. At least on Fedora we only have a limited number of system cron
jobs,


Right less then 45 ( out of 100 in total ) that might have been 
applicable for migration



and I'd rather see those converted natively, rather than
maintaining a compatibility generator for a longer time


Right arguably upstream should never carry generators of anykind ( and 
at one point we will need to drop the legacy sysv initscript 
compatibility otherwise those legacy initscripts will never get migrated 
and their daemon be fixed either if applicable ) and beside the 
limitation that timer units suffer from, cron generators can create 
quite the surprise for administrators, especially on batch servers.


That said out of necessity ( It's easier to write a generator rather 
then go through the leg work and bureaucracy of dealing with 
distribution processes )  there has already been written by Dwayne Bent, 
Konstantin Stepanov, Daniel Schaal and Alexandre Detiste an 
systemd-crontab which includes crontab generator which can be found 
here [1]


But I urge distribution integrators to go the extra mile and rather 
migrate existing cron jobs for components that already depend on systemd 
and or are part of the core/base OS and might thus benefit from that 
migration.


I would have migrating all the relevant cron jobs in Fedora but I had 
enough due to certain corporate attitude towards the project, certain 
part of their employees and their behaviour and as a result of that in 
the end things turned out differently than I had planned or anticipated.


That work would have most likely covered everything that should have 
been migrated in Mageia,OpenSuse and Arch ( Debian is of a different 
Scale ) but you know shit happens and things go unfixed as an result of 
that.


JBG

1. https://github.com/kstep/systemd-crontab-generator
2. https://github.com/systemd-cron/systemd-cron
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Notification socket and chroot vs PrivateNetwork conflict (abstract vs file-system)

[Krzysztof Kotlenga]

On Tue, 2014-12-09 at 17:28 +0100, Lennart Poettering wrote:
 On Tue, 09.12.14 16:24, Krzysztof Kotlenga (k.kotle...@sims.pl) wrote:
 
 Currently notify socket is unavailable in chrooted services (again)
 unless you bind mount it there. Is there perhaps another, less
 cumbersome way?
 
 So far notify socket was:
 [snip change history]
 
 So... would it be acceptable to have two notify sockets, one
 abstract and one normal, the latter only set for services with
 PrivateNetwork or - better maybe - explicitly selectable? Any other
 ideas?
 
 Hmm, but what would you do for a service that has both
 PrivateNetwork and chroot enabled?

Well, PrivateNetwork is clearly asking for trouble... A socket doesn't
really look like a right tool for the job in this case. I know Unix
signals were previously discarded in

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

Dunno what's left.

 Ideas?
 
 I figure we could open a new mount namespace and mount the file
 system socket into the chroot, but not sure I like the idea...

I don't know what else is possible, sorry. Anyone?

-- 
K.


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

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

[Torstein Husebø]

---
 hwdb/70-mouse.hwdb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hwdb/70-mouse.hwdb b/hwdb/70-mouse.hwdb
index 4d38c7b633..0a18ec194e 100644
--- a/hwdb/70-mouse.hwdb
+++ b/hwdb/70-mouse.hwdb
@@ -40,7 +40,7 @@
 #   or, if the frequency is known:
 #   MOUSE_DPI=800@120
 # - a space-separated list of resolutions for multi-resolution mice.
-#   The default resolution must be prefixed by an asterisk, the resultions
+#   The default resolution must be prefixed by an asterisk, the resolutions
 #   in the database must be as shipped by the manufacturer. e.g.
 #   MOUSE_DPI=400 *800 2000
 #
-- 
2.2.0

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

Re: [systemd-devel] [PATCH] hwdb: fix typo

[David Herrmann]

Hi

On Wed, Dec 10, 2014 at 5:41 PM, Torstein Husebø torst...@huseboe.net wrote:
 ---
  hwdb/70-mouse.hwdb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

Applied!

Thanks
David

 diff --git a/hwdb/70-mouse.hwdb b/hwdb/70-mouse.hwdb
 index 4d38c7b633..0a18ec194e 100644
 --- a/hwdb/70-mouse.hwdb
 +++ b/hwdb/70-mouse.hwdb
 @@ -40,7 +40,7 @@
  #   or, if the frequency is known:
  #   MOUSE_DPI=800@120
  # - a space-separated list of resolutions for multi-resolution mice.
 -#   The default resolution must be prefixed by an asterisk, the resultions
 +#   The default resolution must be prefixed by an asterisk, the resolutions
  #   in the database must be as shipped by the manufacturer. e.g.
  #   MOUSE_DPI=400 *800 2000
  #
 --
 2.2.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] Supporting U2F over HID on Linux?

[Andy Lutomirski]

On Tue, Dec 9, 2014 at 12:46 PM, Andy Lutomirski l...@amacapital.net wrote:
 On Mon, Nov 3, 2014 at 12:41 PM, Andy Lutomirski l...@amacapital.net wrote:
 On Mon, Nov 3, 2014 at 12:21 PM, Jiri Kosina jkos...@suse.cz wrote:
 On Mon, 3 Nov 2014, David Herrmann wrote:

  Agreed, mostly.  My only real concern is that this could be annoying
  for the userspace developers who will need to target Linux and HIDAPI
  separately.  Admittedly the Linux support will be trivial.

 I see. I'll not stop you from using hidraw, I'd just not recommend it.
 Especially for security stuff I dislike exposing the whole HID device
 writable. But yeah, I guess you got my point.

 Alright, I am basically thinking loudly now, but how about we allow HID
 drivers that would override default hidraw interface?

 I am very well aware of the fact that this could be opening a can of
 worms, so we'll have to make it very restrictive. How about, let's say, we
 allow HID drivers to provide custom hidraw interface (completely
 overriding the one that HID core would normally create) only for cases
 such as:

 - the intent is to expose only certain parts of a combined device
 - the intent is to introduce some level of access control

 I.e. still no interference of kernel with data parsing allowed.

 Hmm.  Would this be like a filter on hidraw actions?

 How would udev distinguish these special hidraw devices from normal
 hidraw devices?

 Also, for U2F, this could be a little awkward.  There's some crazy
 fragmentation stuff to allow a U2F request to be split across HID
 requests, and I think a kernel driver would much rather get the
 original unfragmented application request.


 I started writing a driver for this.  I got enumeration working.  I
 assume I should create a u2f device class, and then... ?

 Where am I supposed to get my character device from?  Do I register my
 own chrdev major?  Do I use misc?  Is there some input thing I'm
 supposed to use?

Another question:

I'm hitting this in hid_input_report:

if (down_trylock(hid-driver_input_lock)) {
pr_err(HID: trylock failed\n);  // I added this
return -EBUSY;
}

This is a problem for u2f: u2f reports are actual protocol messages,
and there isn't a retransmit mechanism.  Losing messages randomly
causes the handshake to fail, and then nothing works.

I *think* that the only way I can hit that failure is during probe (or
if the USB stack somehow completes two transfers at once). This still
makes it quite awkward to start IO from the probe routine.

I could start a work item to take driver_input_lock, release it again,
and then start the handshake, but that sucks.

Ideas?

--Andy


 Thanks,
 Andy

 --Andy


  I can give the driver a try.  It'll actually be simpler than the spec
  makes it out, since a real kernel driver will have no need to
  arbitrate with itself.

 I'll gladly review any custom HID drivers. Feel free to put me on CC
 when sending to linux-input. There's also a lot of examples in
 drivers/hid/ in case you need a head-start (especially if you need the
 raw_event callback).

 Same here, of course.

 Please always CC me in parallel to sending to linux-input@ to make sure
 that the patch doesn't fall in between cracks.

 Thanks,

 --
 Jiri Kosina
 SUSE Labs



 --
 Andy Lutomirski
 AMA Capital Management, LLC



 --
 Andy Lutomirski
 AMA Capital Management, LLC



-- 
Andy Lutomirski
AMA Capital Management, LLC
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Notification socket and chroot vs PrivateNetwork conflict (abstract vs file-system)

[Lennart Poettering]

On Wed, 10.12.14 16:33, Krzysztof Kotlenga (k.kotle...@sims.pl) wrote:

 On Tue, 2014-12-09 at 17:28 +0100, Lennart Poettering wrote:
  On Tue, 09.12.14 16:24, Krzysztof Kotlenga (k.kotle...@sims.pl) wrote:
  
  Currently notify socket is unavailable in chrooted services (again)
  unless you bind mount it there. Is there perhaps another, less
  cumbersome way?
  
  So far notify socket was:
  [snip change history]
  
  So... would it be acceptable to have two notify sockets, one
  abstract and one normal, the latter only set for services with
  PrivateNetwork or - better maybe - explicitly selectable? Any other
  ideas?
  
  Hmm, but what would you do for a service that has both
  PrivateNetwork and chroot enabled?
 
 Well, PrivateNetwork is clearly asking for trouble... A socket doesn't
 really look like a right tool for the job in this case. I know Unix
 signals were previously discarded in
 
 https://bugzilla.redhat.com/show_bug.cgi?id=833105
 
 Dunno what's left.

AF_UNIX sockets in the file system namespace are unaffected from
PrivateNetwork= really. It's just the combination of file system
rearrangements and PrivateNetwork= that is the problem...

Lennart

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

Re: [systemd-devel] [PATCH 0/6] DHCPv6 Information request

[Tom Gundersen]

Pushed. Thanks!

-t

On Wed, Dec 10, 2014 at 3:17 PM, Patrik Flykt
patrik.fl...@linux.intel.com wrote:

 Hi,

 This patch set implements DHCPv6 Information request, i.e. the situation
 where Router Advertisments announce that only 'Other' information, not
 IPv6 addresses, is available via DHCPv6. This patch doesn't have anything
 to do with the prefix delegation discussed earlier; it was simply left
 half implemented for a while on my machine.

 The first two patches clean up the code a bit, so that later additions
 are easier to implement.

 The third patch adds support for requesting additional information and
 ignores any addresses that should not have been sent by the DHCPv6
 server anyway. Patch 04 makes a simple test case verifying also that it
 is possible to switch from Information request to a normal DHCPv6 address
 acquisition procedure.

 Patch 05 moves systemd-networkd DHCPv6 initialization and handling into
 a file of its own following what's been done for DHCPv4 and IPv4 link
 local. Finally patch 06 adds the necessary logic to request the addtional
 information from the DHCPv6 server and possibly upgrading the procedure
 to the normal IPv6 address aquisition process should the 'Managed' bit
 become set in the Router Advertisments. Reversing this procedure, i.e.
 downgrading it back to fetching additional information only is not
 possible according to RFCs.


 Please review,

 Patrik


 Patrik Flykt (6):
   sd-dhcp6-client: Make end of successfull option parsing explicit
   sd-dhcp6-lease: Return only -EINVAL when a NULL lease is supplied
   sd-dhcp6-client: Implement Information Request message
   test-dhcp6-client: Add a simple Information Request test case
   networkd-dhcp6: Move ICMPv6 and DHCPv6 configuration to new file
   networkd-dhcp6: Support ICMPv6 Other information

  Makefile.am|   1 +
  src/libsystemd-network/dhcp6-protocol.h|   3 +
  src/libsystemd-network/sd-dhcp6-client.c   | 150 -
  src/libsystemd-network/sd-dhcp6-lease.c|   4 +-
  src/libsystemd-network/test-dhcp6-client.c | 126 ++---
  src/network/networkd-dhcp6.c   | 210 
 +
  src/network/networkd-link.c| 122 +
  src/network/networkd-link.h|   1 +
  src/systemd/sd-dhcp6-client.h  |   5 +
  9 files changed, 445 insertions(+), 177 deletions(-)
  create mode 100644 src/network/networkd-dhcp6.c

 --
 2.1.3

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

Re: [systemd-devel] build issues enabled output in `systemctl status`

[Lennart Poettering]

On Wed, 10.12.14 09:55, Mantas Mikulėnas (graw...@gmail.com) wrote:

 Can't get recent systemd-git to build on Arch, likely due to the bus error
 changes:
 
 $ make -j1 V=1
 make --no-print-directory all-recursive
 Making all in .
 
 Meanwhile, I'm using 217-595-g8b5e2af. It seems that, regardless of their
 actual state, `systemctl status` now always shows all units as
 runtime-enabled:
 
  Loaded: loaded (/usr/lib/systemd/system/foo.service; enabled-runtime;
 vendor preset: enabled)
 
 `systemctl is-enabled` shows the correct information. Is this a bug or does
 `systemctl status` simply show a different parameter now?

Both issues should be fixed now, please give git a try!

Lennart

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

[systemd-devel] [PATCH 0/6] Correct spacing near eol in code comments

[Torstein Husebø]

Hi,
this patch set inserts missing spaces and newlines in code comments.
No code change.

Torstein Husebø (6):
  networkd/resolved: correct spacing near eol in code comments
  sd-bus: correct spacing near eol in code comments
  journald: correct spacing near eol code comments
  shared: correct spacing near eol in code comments
  core: correct spacing near eol in code comments
  treewide: correct spacing near eol in code comments

 src/core/device.c | 3 ++-
 src/core/execute.c| 2 +-
 src/core/main.c   | 3 ++-
 src/core/manager.c| 2 +-
 src/core/unit.h   | 2 +-
 src/hostname/hostnamed.c  | 2 +-
 src/journal/journal-file.c| 3 ++-
 src/journal/journal-verify.c  | 3 ++-
 src/journal/journald-server.c | 6 +++---
 src/libsystemd-terminal/term-internal.h   | 2 +-
 src/libsystemd/sd-bus/bus-match.c | 2 +-
 src/libsystemd/sd-bus/bus-message.c   | 6 +++---
 src/libsystemd/sd-bus/sd-bus.c| 2 +-
 src/libsystemd/sd-bus/test-bus-gvariant.c | 2 +-
 src/libsystemd/sd-id128/sd-id128.c| 2 +-
 src/login/logind-dbus.c   | 2 +-
 src/network/networkd-address.c| 2 +-
 src/network/networkd-netdev.c | 2 +-
 src/resolve/resolved-dns-scope.c  | 2 +-
 src/shared/clock-util.c   | 4 ++--
 src/shared/util.c | 6 +++---
 src/systemctl/systemctl.c | 2 +-
 src/systemd/sd-login.h| 2 +-
 src/test/test-strbuf.c| 2 +-
 src/udev/udev-builtin-net_id.c| 2 +-
 25 files changed, 36 insertions(+), 32 deletions(-)

-- 
2.2.0

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

[systemd-devel] [PATCH 3/6] journald: correct spacing near eol code comments

[Torstein Husebø]

---
 src/journal/journal-file.c| 3 ++-
 src/journal/journal-verify.c  | 3 ++-
 src/journal/journald-server.c | 6 +++---
 3 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c
index c5d2d19433..ca28bd53ef 100644
--- a/src/journal/journal-file.c
+++ b/src/journal/journal-file.c
@@ -2527,7 +2527,8 @@ int journal_file_open(
  * currently no usable API to query this, hence let's
  * emulate this via extended attributes. If extended
  * attributes are not supported we'll just skip this,
- * and rely solely on mtime/atime/ctime of the file.*/
+ * and rely solely on mtime/atime/ctime of the file.
+ */
 
 crtime = htole64((uint64_t) now(CLOCK_REALTIME));
 fsetxattr(f-fd, user.crtime_usec, crtime, sizeof(crtime), 
XATTR_CREATE);
diff --git a/src/journal/journal-verify.c b/src/journal/journal-verify.c
index 7e3c974b33..f20798cfad 100644
--- a/src/journal/journal-verify.c
+++ b/src/journal/journal-verify.c
@@ -427,7 +427,8 @@ static int entry_points_to_data(
 
 /* Check if this entry is also in main entry array. Since the
  * main entry array has already been verified we can rely on
- * its consistency.*/
+ * its consistency.
+ */
 
 i = 0;
 n = le64toh(f-header-n_entries);
diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
index 80c9736420..a2a2e197c0 100644
--- a/src/journal/journald-server.c
+++ b/src/journal/journald-server.c
@@ -811,7 +811,7 @@ static void dispatch_message_real(
  * realuid is not root, in order not to accidentally
  * leak privileged information to the user that is
  * logged by a privileged process that is part of an
- * unprivileged session.*/
+ * unprivileged session. */
 journal_uid = owner;
 else
 journal_uid = 0;
@@ -1131,7 +1131,7 @@ int process_datagram(sd_event_source *es, int fd, 
uint32_t revents, void *userda
  * the SELinux people this will change and it
  * will probably be identical to NAME_MAX. For
  * now we use that, but this should be updated
- * one day when the final limit is known.*/
+ * one day when the final limit is known. */
 uint8_t buf[CMSG_SPACE(sizeof(struct ucred)) +
 CMSG_SPACE(sizeof(struct timeval)) +
 CMSG_SPACE(sizeof(int)) + /* fd */
@@ -1158,7 +1158,7 @@ int process_datagram(sd_event_source *es, int fd, 
uint32_t revents, void *userda
  * don't rely on it. */
 (void) ioctl(fd, SIOCINQ, v);
 
-/* Fix it up, if it is too small. We use the same fixed value 
as auditd here. Awful!*/
+/* Fix it up, if it is too small. We use the same fixed value 
as auditd here. Awful! */
 m = PAGE_ALIGN(MAX3((size_t) v + 1,
 (size_t) LINE_MAX,
 ALIGN(sizeof(struct nlmsghdr)) + 
ALIGN((size_t) MAX_AUDIT_MESSAGE_LENGTH)) + 1);
-- 
2.2.0

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

[systemd-devel] [PATCH 4/6] shared: correct spacing near eol in code comments

[Torstein Husebø]

---
 src/shared/clock-util.c | 4 ++--
 src/shared/util.c   | 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/shared/clock-util.c b/src/shared/clock-util.c
index fc49393c72..96684681a4 100644
--- a/src/shared/clock-util.c
+++ b/src/shared/clock-util.c
@@ -121,7 +121,7 @@ int clock_set_timezone(int *min) {
 minutesdelta = tm-tm_gmtoff / 60;
 
 tz.tz_minuteswest = -minutesdelta;
-tz.tz_dsttime = 0; /* DST_NONE*/
+tz.tz_dsttime = 0; /* DST_NONE */
 
 /*
  * If the RTC does not run in UTC but in local time, the very first
@@ -141,7 +141,7 @@ int clock_reset_timewarp(void) {
 struct timezone tz;
 
 tz.tz_minuteswest = 0;
-tz.tz_dsttime = 0; /* DST_NONE*/
+tz.tz_dsttime = 0; /* DST_NONE */
 
 /*
  * The very first call to settimeofday() does time warp magic. Do a
diff --git a/src/shared/util.c b/src/shared/util.c
index 26a4f72b43..6383c0f80a 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -558,7 +558,7 @@ const char* split(const char **state, size_t *l, const char 
*separator, bool quo
 *l = strcspn_escaped(current + 1, quotechars);
 if (current[*l + 1] == '\0' ||
 (current[*l + 2]  !strchr(separator, current[*l + 2]))) {
-/* right quote missing or garbage at the end*/
+/* right quote missing or garbage at the end */
 *state = current;
 return NULL;
 }
@@ -1436,7 +1436,7 @@ char *cunescape_length_with_prefix(const char *s, size_t 
length, const char *pre
 }
 
 case 0:
-/* premature end of string.*/
+/* premature end of string. */
 *(t++) = '\\';
 goto finish;
 
@@ -3662,7 +3662,7 @@ char *unquote(const char *s, const char* quotes) {
 /* This is rather stupid, simply removes the heading and
  * trailing quotes if there is one. Doesn't care about
  * escaping or anything. We should make this smarter one
- * day...*/
+ * day... */
 
 l = strlen(s);
 if (l  2)
-- 
2.2.0

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

Re: [systemd-devel] build issues enabled output in `systemctl status`

[Chris Atkinson]

I had the same problem and can confirm that it now builds for me
(including the Python stuff).

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

Re: [systemd-devel] Problems with resource control delegation

[Lennart Poettering]

On Thu, 27.11.14 11:36, Michal Sekletar (msekl...@redhat.com) wrote:

 Hi list,
 
 This will be about recently added Delegate option. I think that it doesn't 
 work
 as intended. I'll describe simple scenario which exhibits the problem.

Should be fixed in git. Please test!

Thanks,

Lennart

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

Re: [systemd-devel] [PATCH] bus-proxy: cloning smack label

[Lennart Poettering]

On Tue, 09.12.14 18:26, Lennart Poettering (lenn...@poettering.net) wrote:

Przemyslaw,

  +++ b/units/u...@.service.m4.in
  @@ -0,0 +1,23 @@
  +#  This file is part of systemd.
  +#
  +#  systemd is free software; you can redistribute it and/or modify it
  +#  under the terms of the GNU Lesser General Public License as published by
  +#  the Free Software Foundation; either version 2.1 of the License, or
  +#  (at your option) any later version.
  +
  +[Unit]
  +Description=User Manager for UID %i
  +After=systemd-user-sessions.service
  +
  +[Service]
  +User=%i
  +PAMName=systemd-user
  +Type=notify
  +ExecStart=-@rootlibexecdir@/systemd --user
  +Slice=user-%i.slice
  +KillMode=mixed
  +Delegate=yes
  +m4_ifdef(`HAVE_SMACK',
  +Capabilities=cap_mac_admin=i
  +SecureBits=keep-caps
  +)

I have reverted the last bit above again, since it broke bootups in
nspawn machines. I figure the CAP_MAC_ADMIN capability is missing from
the bounding set in an nspawn, and that breaks the caps logic here.

We should find another solution for this. I wanted to get 218 out of
the door, hence I reverted this bit for now, but we really should fine
a longer term solution for this.

I build systemd with SMACK on, but turned off in the kernel. 

Any suggestions what we can do here?

Lennart

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

[systemd-devel] [ANNOUNCE] systemd v218

[Lennart Poettering]

Heya!

Here's the next version of systemd, v218:

http://www.freedesktop.org/software/systemd/systemd-218.tar.xz

Many many bug fixes, some new features, and a lot of code cleanups!

CHANGES WITH 218:

* When querying unit file enablement status (for example via
  systemctl is-enabled), a new state indirect is now known
  which indicates that a unit might not be enabled itself, but
  another unit listed in its Alias= setting might be.

* Similar to the various existing ConditionXYZ= settings for
  units there are now matching AssertXYZ= settings. While
  failing conditions cause a unit to be skipped, but its job
  to succeed, failing assertions declared like this will cause
  a unit start operation and its job to fail.

* hostnamed now knows a new chassis type embedded.

* systemctl gained a new edit command. When used on a unit
  file this allows extending unit files with .d/ drop-in
  configuration snippets or editing the full file (after
  copying it from /usr/lib to /etc). This will invoke the
  user's editor (as configured with $EDITOR), and reload the
  modified configuration after editing.

* systemctl status now shows the suggested enablement state
  for a unit, as declared in the (usually vendor-supplied)
  system preset files.

* nss-myhostname will now resolve the single-label host name
  gateway to the locally configured default IP routing
  gateways, ordered by their metrics. This assigns a stable
  name to the used gateways, regardless which ones are
  currently configured. Note that the name will only be
  resolved after all other name sources (if nss-myhostname is
  configured properly) and should hence not negatively impact
  systems that use the single-label host name gateway in
  other contexts.

* systemd-inhibit now allows filtering by mode when listing
  inhibitors.

* Scope and service units gained a new Delegate boolean
  property, which when set allows processes running inside the
  unit to further partition resources. This is primarily
  useful for systemd user instances as well as container
  managers.

* journald will now pick up audit messages directly from
  the kernel, and log them like any other log message. The
  audit fields are split up and fully indexed. This means that
  journalctl in many ways is now a (nicer!) alternative to
  ausearch, the traditional audit client. Note that this
  implements only a minimal audit client, if you want the
  special audit modes like reboot-on-log-overflow, please use
  the traditional auditd instead, which can be used in
  parallel to journald.

* The ConditionSecurity= unit file option now understands the
  special string audit to check whether auditing is
  available.

* journalctl gained two new commands --vacuum-size= and
  --vacuum-time= to delete old journal files until the
  remaining ones take up no more the specified size on disk,
  or are not older than the specified time.

* A new, native PPPoE library has been added to sd-network,
  systemd's library of light-weight networking protocols. This
  library will be used in a future version of networkd to
  enable PPPoE communication without an external pppd daemon.

* The busctl tool now understands a new capture verb that
  works similar to monitor, but writes a packet capture
  trace to STDOUT that can be redirected to a file which is
  compatible with libcap's capture file format. This can then
  be loaded in Wireshark and similar tools to inspect bus
  communication.

* The busctl tool now understands a new tree verb that shows
  the object trees of a specific service on the bus, or of all
  services.

* The busctl tool now understands a new introspect verb that
  shows all interfaces and members of objects on the bus,
  including their signature and values. This is particularly
  useful to get more information about bus objects shown by
  the new busctl tree command.

* The busctl tool now understands new verbs call,
  set-property and get-property for invoking bus method
  calls, setting and getting bus object properties in a
  friendly way.

* busctl gained a new --augment-creds= argument that controls
  whether the tool shall augment credential information it
  gets from the bus with data from /proc, in a possibly
  race-ful way.

* nspawn's --link-journal= switch gained two new values
  try-guest and try-host that work like guest and
  host,