Re: [systemd-devel] [PATCH 4/5] import/pull: Tag replaced with reference

[Pavel Odvody]

On Tue, 2015-06-16 at 19:53 +0200, Thomas H.P. Andersen wrote:
> On Thu, May 7, 2015 at 5:47 PM, Pavel Odvody  wrote:
> > Signed-off-by: Pavel Odvody 
> > ---
> >  src/import/pull.c | 28 +---
> >  1 file changed, 17 insertions(+), 11 deletions(-)
> >
> > diff --git a/src/import/pull.c b/src/import/pull.c
> > index ef7b035..8054612 100644
> > --- a/src/import/pull.c
> > +++ b/src/import/pull.c
> > @@ -227,7 +227,7 @@ static void on_dkr_finished(DkrPull *pull, int error, 
> > void *userdata) {
> >  static int pull_dkr(int argc, char *argv[], void *userdata) {
> >  _cleanup_(dkr_pull_unrefp) DkrPull *pull = NULL;
> >  _cleanup_event_unref_ sd_event *event = NULL;
> > -const char *name, *tag, *local;
> > +const char *name, *reference, *local, *digest;
> >  int r;
> >
> >  if (!arg_dkr_index_url) {
> > @@ -240,13 +240,19 @@ static int pull_dkr(int argc, char *argv[], void 
> > *userdata) {
> >  return -EINVAL;
> >  }
> >
> > -tag = strchr(argv[1], ':');
> > -if (tag) {
> > -name = strndupa(argv[1], tag - argv[1]);
> > -tag++;
> > +digest = strchr(argv[1], '@');
> > +if (digest) {
> > +reference = digest + 1;
> > +name = strndupa(argv[1], digest - argv[1]);
> > +}
> > +
> > +reference = strchr(argv[1], ':');
> > +if (reference) {
> > +name = strndupa(argv[1], reference - argv[1]);
> > +reference++;
> >  } else {
> >  name = argv[1];
> > -tag = "latest";
> > +reference = "latest";
> >  }
> 
> This part does not look correct. Any value that we set for
> reference/name in the digest part will be overwritten in the next
> block. I do not know the format of the string so I cannot create a
> patch for this. Can you take a look Pavel?
> 

I think you're right, will take a look later today and submit a patch.

The digest reference looks like this:

fedora@sha256:cc47966101aeba8015c933f9c3854811a27363f93fa4e0e52e6c55181c56c66c


> >
> >  if (!dkr_name_is_valid(name)) {
> > @@ -254,8 +260,8 @@ static int pull_dkr(int argc, char *argv[], void 
> > *userdata) {
> >  return -EINVAL;
> >  }
> >
> > -if (!dkr_tag_is_valid(tag)) {
> > -log_error("Tag name '%s' is not valid.", tag);
> > +if (!dkr_ref_is_valid(reference)) {
> > +log_error("Tag name '%s' is not valid.", reference);
> >  return -EINVAL;
> >  }
> >
> > @@ -288,9 +294,9 @@ static int pull_dkr(int argc, char *argv[], void 
> > *userdata) {
> >  }
> >  }
> >
> > -log_info("Pulling '%s' with tag '%s', saving as '%s'.", 
> > name, tag, local);
> > +log_info("Pulling '%s' with reference '%s', saving as 
> > '%s'.", name, reference, local);
> >  } else
> > -log_info("Pulling '%s' with tag '%s'.", name, tag);
> > +log_info("Pulling '%s' with reference '%s'.", name, 
> > reference);
> >
> >  r = sd_event_default(&event);
> >  if (r < 0)
> > @@ -304,7 +310,7 @@ static int pull_dkr(int argc, char *argv[], void 
> > *userdata) {
> >  if (r < 0)
> >  return log_error_errno(r, "Failed to allocate puller: %m");
> >
> > -r = dkr_pull_start(pull, name, tag, local, arg_force);
> > +r = dkr_pull_start(pull, name, reference, local, arg_force, 
> > PULL_V2);
> >  if (r < 0)
> >  return log_error_errno(r, "Failed to pull image: %m");
> >
> > --
> > 2.1.0
> >
> >
> >
> >
> > ___
> > systemd-devel mailing list
> > systemd-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> >


-- 
Pavel Odvody 
Software Engineer - EMEA ENG Developer Experience
5EC1 95C1 8E08 5BD9 9BBF 9241 3AFA 3A66 024F F68D
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno



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

Re: [systemd-devel] nspawn --ephemeral

[Tobias Hunger]

Hi Johannes,

there is a tmpfiles.d rule in your container that creates that
snapshot if it is not there yet.

I started to create a var/lib/machines directory in the container as
part of the container creation process, which prevents systemd 219
from creating the btrfs snapshot there.

Alternatively you could also remove the /var/lib/machines line from
usr/lib/tmpfiles.d/var.conf inside the container.

Best Regards,
Tobias


On Wed, Jun 17, 2015 at 1:14 AM, Johannes Ernst
 wrote:
> Aha! Works in 220. (It’s still in testing in Arch, so I had been on 219)
>
> I’m still unclear why there’s an (empty) /var/lib/machines in the container.
>
>
> On Jun 16, 2015, at 15:22, Lennart Poettering 
> wrote:
>
> On Tue, 16.06.15 14:53, Johannes Ernst (johannes.er...@gmail.com) wrote:
>
> I have a root filesystem directory in foo/
>
> I boot with nspawn, and immediately, in the container:
>systemctl poweroff
>
> This works fine if invoked as:
>sudo systemd-nspawn --directory foo --boot -n
>
> But if I add --ephemeral (and it is a btrfs filesystem)
>sudo systemd-nspawn --directory foo --boot -n --ephemeral
> I get:
>Sending SIGTERM to remaining processes...
>Sending SIGKILL to remaining processes...
>Powering off.
>Container ... has been shut down.
>Cannot remove subvolume '/home/.../.#foo...', ignoring: Directory not
> empty
>
> btrfs subvolume list reports two new subvolumes:
>…/.#foo...
>…/.#foo.../var/lib/machines
>
> Indeed I cannot remove subvol …/.#foo… unless I first remove subvol
> …/.#foo.../var/lib/machines
>
> Further, foo/ does not actually contain /var/lib/machines
> but in the booted container, it actually lists two subvolumes with that
> path:
># btrfs subvolume list /
>ID 351 gen 250192 top level 5 path var/lib/machines
>ID 371 gen 256382 top level 5 path home/…/.#foo
>ID 372 gen 256382 top level 371 path var/lib/machines
> On the host, we have the same, but the second one has the prefix i.e.
> home/…/.#foo/var/lib/machines
>
> Hmm …?
>
>
> Do you use systemd v220? only in v220 we support recursively removing
> subvolumes, and there's a tmpfiles snippet that creates
> /var/lib/machines as subvolume.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>
>
>
> ___
> 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] sd-bus vs glib object path node hierarchy

[David Herrmann]

Hi

On Tue, Jun 16, 2015 at 11:32 PM, Lennart Poettering
 wrote:
> On Tue, 16.06.15 22:54, Krzesimir Nowak (krzesi...@endocode.com) wrote:
>> That reminds me of a bug (or not-a-bug) in go-dbus [1] - it also generates
>> flat hierarchy. This is a problem for tools like d-feet - they fail to
>> introspect services with flat hierarchy. Of course, it might be a bug in
>> d-feet itself.
>>
>> [1] https://github.com/godbus/dbus/issues/14
>
> Unless I misunderstand this sd-bus and go-dbus actually work very
> differently here: sd-bus actually synthesizes an object and suppresses
> it in the introspection. go-dbus doesn't even synthesize it. That
> means that if d-feet asks the intermediary objects on an sd-bus server
> all is good even if the service will never announce it voluntarily...
>
> I also just verified that d-feet works fine with sd-bus services.

Maybe someone can fix d-feet to do what `busctl tree` does? That is,
if introspection for '/' returns a node at '/foo/bar' then better
continue at '/foo/bar' instead of '/foo'. Not sure why d-feet chops
those paths off?

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

Re: [systemd-devel] /etc/resolv.conf link in container

[David Herrmann]

Hi

On Tue, Jun 16, 2015 at 11:39 PM, Johannes Ernst
 wrote:
> I have a root filesystem in directory foo/
> It has symlink
> foo/etc/resolv.conf -> /run/systemd/resolve/resolv.conf
>
> When I’m booting the container:
> sudo systemd-nspawn --directory foo --boot
>
> I’m getting:
> Failed to copy /etc/resolv.conf to /home/…./foo/etc/resolv.conf: Too many 
> levels of symbolic links
>
> This message makes very little sense to me. Why is a copy necessary? and is 
> that indeed /etc/resolv.conf or foo/etc/resolv.conf?
>
> If I boot with -n, I don’t seem to get the error.

If you pass --private-network / -n, then we never touch resolv.conf.
In all other cases, we copy resolv.conf from the host into the
container. We usually assume that if your container runs in the same
network as the host, then the container must also use the DNS features
of the host.

The error code of "Too many levels of symbolic links" is ELOOP. This
is returned by open() in many cases. In this example, it is returned
because we passed O_NOFOLLOW to open(), but the final part of the path
is a symlink. In that case, the kernel returns ELOOP to tell us that
we're dealing with a symlink.

Maybe Lennart or Tom have some comments on that? Your example use-case
(resolved in the container, even with shared network namespace) looks
valid, though odd. I mean, what's the reason not to use "-n"? Anyway,
maybe we can deal with ELOOP in setup_resolv_conf() and just print a
big fat warning?
But lets people who know that stuff comment first..

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

Re: [systemd-devel] machinectl status vs show

[David Herrmann]

Hi

On Wed, Jun 17, 2015 at 5:53 AM, Johannes Ernst
 wrote:
> Are those supposed to produce the same information, just formatted 
> differently (man vs machine per man page)?
>
> I’m failing to convince ‘show’ to give me the container’s IP address, while 
> ‘status’ has all of them.

As with almost all *ctl tools in systemd, 'show' is used to print DBus
properties of the object in question. 'status' on the other hand
prints a human-readable, pre-selected set of attributes of an object.

With machinectl, the 'show' command must be used with a parameter. So
`machinectl --all show $machine` should contain the same information
as `machinectl status $machine`, and even more. If that's not the
case, please post an example.

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

Re: [systemd-devel] Why we need to read/save random seed?

[Reindl Harald]

Am 17.06.2015 um 05:06 schrieb cee1:

2015-06-16 0:21 GMT+08:00 Lennart Poettering :

On Mon, 15.06.15 23:33, cee1 (fykc...@gmail.com) wrote:

Hi,

I maybe got confused.

First, systemd-random-seed.service will save a "seed" from
/dev/urandom when shutdown, and load that "seed" to /dev/urandom when
next boot up.

My questions are:
1. Can we not save a seed, but load a seed that is read from **
/dev/random ** to ** /dev/urandom **?


The seed is used for both. Then you'd feed the stuff you got from the
RNG back into the RNG which is a pointless excercise.


systemd-random-seed.service will load the "seed on disk" to
/dev/urandom, and save a "seed" to disk when shutdown, right?

The article at http://www.2uo.de/myths-about-urandom/ suggests us
saving the seed as soon as there is enough entropy(means read from
/dev/random? if returns, there's enough entropy),


well, so you read the seed and inject it to /dev/random followed by read 
/dev/random and overwrite the seed for the next boot - don't sounds that 
good



Saving the seed early, make it more tolerant against the case of
system crashes - that means not shutdown properly(which maybe the case
on some mobile device such as STB


if a system don't shut down properly all the time fix that problem



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

Re: [systemd-devel] machinectl status vs show

[Lennart Poettering]

On Wed, 17.06.15 10:13, David Herrmann (dh.herrm...@gmail.com) wrote:

> Hi
> 
> On Wed, Jun 17, 2015 at 5:53 AM, Johannes Ernst
>  wrote:
> > Are those supposed to produce the same information, just formatted 
> > differently (man vs machine per man page)?
> >
> > I’m failing to convince ‘show’ to give me the container’s IP address, while 
> > ‘status’ has all of them.
> 
> As with almost all *ctl tools in systemd, 'show' is used to print DBus
> properties of the object in question. 'status' on the other hand
> prints a human-readable, pre-selected set of attributes of an object.
> 
> With machinectl, the 'show' command must be used with a parameter. So
> `machinectl --all show $machine` should contain the same information
> as `machinectl status $machine`, and even more. If that's not the
> case, please post an example.

Well, "machinectl status" also shows the cgroup tree, which
"machinectl show" currently does not.

The IP addresses are not exposed as property, they are exposed
as method, since acquiring them is relatively complex due to
transitioning into the containers... That means they show up in
"machinectl status", because that code explicitly calls that method,
but not in "machinectl show" which shows the plain props, and nothing
else.

Note that "systemctl show" and "systemctl status" have a similar
relationship as "machinectl show" and "machinectl status".

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 v2] watchdog: Don't require WDIOC_SETOPTIONS/WDIOS_ENABLECARD

[Jean Delvare]

Not all watchdog drivers implement WDIOC_SETOPTIONS. Drivers which do
not implement it have their device always enabled. So it's fine to
report an error if WDIOS_DISABLECARD is passed and the ioctl is not
implemented, however failing when WDIOS_ENABLECARD is passed and the
ioctl is not implemented is not good: if the device was already
enabled then WDIOS_ENABLECARD was a no-op and wasn't needed in the
first place. So we can just ignore the error and continue.
---
Lennart, would that be OK with you?

Changes since v1:
 * Log WDIOC_SETOPTIONS/WDIOS_ENABLECARD failure at debug level if
   ENOTTY is returned. Suggested by Lennart Poettering.

 src/shared/watchdog.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

--- systemd.orig/src/shared/watchdog.c  2015-06-15 18:51:40.811989627 +0200
+++ systemd/src/shared/watchdog.c   2015-06-17 11:20:01.798331790 +0200
@@ -60,8 +60,13 @@ static int update_timeout(void) {
 
 flags = WDIOS_ENABLECARD;
 r = ioctl(watchdog_fd, WDIOC_SETOPTIONS, &flags);
-if (r < 0)
-return log_warning_errno(errno, "Failed to enable 
hardware watchdog: %m");
+if (r < 0) {
+   /* ENOTTY means the watchdog is always enabled so we're 
fine */
+log_full(errno == ENOTTY ? LOG_DEBUG : LOG_WARNING,
+ "Failed to enable hardware watchdog: %m");
+if (errno != ENOTTY)
+   return errno;
+}
 
 r = ioctl(watchdog_fd, WDIOC_KEEPALIVE, 0);
 if (r < 0)


-- 
Jean Delvare
SUSE L3 Support
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] improve systemctl daemon-reexec and daemon-reload documentation

[Thomas Blume]

The systemctl daemon-reexec and daemon-reload documentation
in the manpage is a bit ambiguous. It suggests that daemon-reload reloads the
configuration of the manager itself (e.g. the [Manager] section in
/etc/systemd/system.conf). It should be pointed out that it only reloads the
configuration for the manager clients and that for reloading the manager
configuration, daemon-reexec must be used.


Regards

Thomas Blume

--
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham 
Norton, HRB 21284 (AG Nürnberg)
Maxfeldstr. 5 / D-90409 Nürnberg / Phone: +49-911-740 53 - 0 / VOIP: 3919
GPG 2048R/2CD4D3E8 9A50 048F 1C73 59AA 4D2E  424E B3C6 3FD9 2CD4 D3E8From 198dbd4fdc4a4cccef24aa9fd97ceb328c87c52d Mon Sep 17 00:00:00 2001
From: Thomas Blume 
Date: Wed, 17 Jun 2015 11:03:52 +0200
Subject: [PATCH] The systemctl daemon-reexec and daemon-reload documentation
 in the manpage is a bit ambiguous. It suggests that daemon-reload reloads the
 configuration of the manager itself (e.g. the [Manager] section in
 /etc/systemd/system.conf). It should be pointed out that it only reloads the
 configuration for the manager clients and that for reloading the manager
 configuration, daemon-reexec must be used.

---
 man/systemctl.xml | 8 
 src/systemctl/systemctl.c | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/man/systemctl.xml b/man/systemctl.xml
index 338c1d3..6c94255 100644
--- a/man/systemctl.xml
+++ b/man/systemctl.xml
@@ -1367,7 +1367,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
   daemon-reload
 
   
-Reload systemd manager configuration. This will
+Reload systemd manager client configuration. This will
 rerun all generators (see
 systemd.generator7),
 reload all unit files, and recreate the entire dependency
@@ -1385,9 +1385,9 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
   
 Reexecute the systemd manager. This will serialize the
 manager state, reexecute the process and deserialize the
-state again. This command is of little use except for
-debugging and package upgrades. Sometimes, it might be
-helpful as a heavy-weight daemon-reload.
+state again. It updates the systemd manager configuration
+after changes in the system config file (/etc/systemd/system.conf).
+Sometimes, it might be helpful as a heavy-weight daemon-reload.
 While the daemon is being reexecuted, all sockets systemd listening
 on behalf of user configuration will stay accessible.
 
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 41f7b9f..ce7c540 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -6035,7 +6035,7 @@ static void systemctl_help(void) {
"  unset-environment NAME...   Unset one or more environment variables\n"
"  import-environment [NAME...]Import all or some environment variables\n\n"
"Manager Lifecycle Commands:\n"
-   "  daemon-reload   Reload systemd manager configuration\n"
+   "  daemon-reload   Reload systemd manager client configuration\n"
"  daemon-reexec   Reexecute systemd manager\n\n"
"System Commands:\n"
"  is-system-running   Check whether system is fully running\n"
-- 
2.1.4

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

Re: [systemd-devel] [PATCH v2] watchdog: Don't require WDIOC_SETOPTIONS/WDIOS_ENABLECARD

[Lennart Poettering]

On Wed, 17.06.15 11:26, Jean Delvare (jdelv...@suse.de) wrote:

> Not all watchdog drivers implement WDIOC_SETOPTIONS. Drivers which do
> not implement it have their device always enabled. So it's fine to
> report an error if WDIOS_DISABLECARD is passed and the ioctl is not
> implemented, however failing when WDIOS_ENABLECARD is passed and the
> ioctl is not implemented is not good: if the device was already
> enabled then WDIOS_ENABLECARD was a no-op and wasn't needed in the
> first place. So we can just ignore the error and continue.
> ---
> Lennart, would that be OK with you?

Generally yes.

But: indentation is borked, there some whitespace issues, I cannot
even apply this. 

Please have a look at CODING_STYLE.

Also, please build the stuff locally before commit and send to the
ML. We have a git commit hook that checks for weird whitespace at time
of commit. It's enables as soon as you run "autogen.sh" once...

> 
> Changes since v1:
>  * Log WDIOC_SETOPTIONS/WDIOS_ENABLECARD failure at debug level if
>ENOTTY is returned. Suggested by Lennart Poettering.
> 
>  src/shared/watchdog.c |9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> --- systemd.orig/src/shared/watchdog.c2015-06-15 18:51:40.811989627 
> +0200
> +++ systemd/src/shared/watchdog.c 2015-06-17 11:20:01.798331790 +0200
> @@ -60,8 +60,13 @@ static int update_timeout(void) {
>  
>  flags = WDIOS_ENABLECARD;
>  r = ioctl(watchdog_fd, WDIOC_SETOPTIONS, &flags);
> -if (r < 0)
> -return log_warning_errno(errno, "Failed to enable 
> hardware watchdog: %m");
> +if (r < 0) {
> + /* ENOTTY means the watchdog is always enabled
>  so we're fine */

multiples of 8 space indenting, please.

> +log_full(errno == ENOTTY ? LOG_DEBUG : LOG_WARNING,
> + "Failed to enable hardware watchdog: %m");
> +if (errno != ENOTTY)
> + return errno;

multiples of 8 space indenting, please.

> +}
>  
>  r = ioctl(watchdog_fd, WDIOC_KEEPALIVE, 0);
>  if (r < 0)
> 
> 
> -- 
> Jean Delvare
> SUSE L3 Support
> 


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] Can kdbus send signal to the source connection?

[eshark]

Hi,
 With my kdbus broadcast patch, I found that the "systemd" process would 
endlessly emit the signal "type=signal sender=:1.2 destination=n/a 
object=/org/freedesktop/systemd1/agent interface=org.freedesktop.systemd1.Agent 
member=Released ".What does this signal  mean ?


I searched the source codes, and found that systemd-cgroups-agent would  
send this signal. But from the log, systemd-cgroups-agent only send this signal 
several times , not endlessly.


And I cannot locate the place where "systemd" send such signal. 


Following are the logs:


<27>[3.633361@3] systemd-cgroups-agent[196]: Lch-sd_bus_emit_signal 
org.freedesktop.systemd1.Agent Released
<27>[3.633660@2] systemd-cgroups-agent[216]: Lch-sd_bus_emit_signal 
org.freedesktop.systemd1.Agent Released
<6>[3.633989@2] Lch-kdbus_bus_broadcast: conn_dst->id = 0x14, pid = 216, 
pid name = systemd-cgroups, tid = 216, tid name = systemd-cgroups
<30>[3.634008@2] systemd-cgroups-agent[216]: Lch-Sent message type=signal 
sender=n/a destination=n/a object=/org/freedesktop/systemd1/agent 
interface=org.freedesktop.systemd1.Agent member=Released cooki
e=1 reply_cookie=0 error=n/a
<30>[3.648452@0] systemd[1]: Lch-Got message type=signal sender=:1.2 
destination=n/a object=/org/freedesktop/systemd1/agent 
interface=org.freedesktop.systemd1.Agent member=Released cookie=1 reply_cookie
=0 error=n/a
<6>[3.650378@0] EXT4-fs (mmcblk0p9): re-mounted. Opts: (null)
<6>[3.652074@3] Lch-kdbus_bus_broadcast: conn_dst->id = 0x12, pid = 196, 
pid name = systemd-cgroups, tid = 196, tid name = systemd-cgroups
<30>[3.652220@3] systemd-cgroups-agent[196]: Lch-Sent message type=signal 
sender=n/a destination=n/a object=/org/freedesktop/systemd1/agent 
interface=org.freedesktop.systemd1.Agent member=Released cooki
e=1 reply_cookie=0 error=n/a
<6>[3.652284@3] Lch-kdbus_bus_broadcast: conn_dst->id = 0x2, pid = 1, pid 
name = systemd, tid = 1, tid name = systemd
<30>[3.653329@3] systemd[1]: Lch-Sent message type=signal sender=:1.2 
destination=n/a object=/org/freedesktop/systemd1/agent 
interface=org.freedesktop.systemd1.Agent member=Released cookie=1 reply_cooki
e=0 error=n/a


<30>[3.654166@3] systemd[1]: Lch-Got message type=signal sender=:1.20 
destination=n/a object=/org/freedesktop/systemd1/agent 
interface=org.freedesktop.systemd1.Agent member=Released cookie=1 reply_cooki
e=0 error=n/a
<6>[3.654642@3] Lch-kdbus_bus_broadcast: conn_dst->id = 0x2, pid = 1, pid 
name = systemd, tid = 1, tid name = systemd
<30>[3.654784@3] systemd[1]: Lch-Sent message type=signal sender=:1.20 
destination=n/a object=/org/freedesktop/systemd1/agent 
interface=org.freedesktop.systemd1.Agent member=Released cookie=1 reply_cook
ie=0 error=n/a
<30>[3.654958@3] systemd[1]: Lch-Got message type=signal sender=:1.18 
destination=n/a object=/org/freedesktop/systemd1/agent 
interface=org.freedesktop.systemd1.Agent member=Released cookie=1 reply_cooki
e=0 error=n/a
...


<6>[  809.109334@1] Lch-kdbus_bus_broadcast: conn_dst->id = 0x2, pid = 1, pid 
name = systemd, tid = 1, tid name = systemd
<30>[  809.109397@1] systemd[1]: Lch-Sent message type=signal sender=:1.2 
destination=n/a object=/org/freedesktop/systemd1/agent 
interface=org.freedesktop.systemd1.Agent member=Released cookie=1 reply_cooki
e=0 error=n/a
<30>[  809.109481@1] systemd[1]: Lch-Got message type=signal sender=:1.2 
destination=n/a object=/org/freedesktop/systemd1/agent 
interface=org.freedesktop.systemd1.Agent member=Released cookie=1 reply_cookie
=0 error=n/a
<6>[  809.109726@1] Lch-kdbus_bus_broadcast: conn_dst->id = 0x2, pid = 1, pid 
name = systemd, tid = 1, tid name = systemd
<30>[  809.109789@1] systemd[1]: Lch-Sent message type=signal sender=:1.2 
destination=n/a object=/org/freedesktop/systemd1/agent 
interface=org.freedesktop.systemd1.Agent member=Released cookie=1 reply_cooki
e=0 error=n/a
<30>[  809.109872@1] systemd[1]: Lch-Got message type=signal sender=:1.2 
destination=n/a object=/org/freedesktop/systemd1/agent 
interface=org.freedesktop.systemd1.Agent member=Released cookie=1 reply_cookie
=0 error=n/a






Thanks！
Li Cheng



At 2015-06-17 14:11:11, "eshark"  wrote:

Hi,
   I'm so sorry for not giving you more details,  I'm a freshman here, but I'll 
try to do better in the future.
I will give the answers under each of the questions .

At 2015-06-16 18:54:23, "David Herrmann"  wrote:
>Hi
>
>On Tue, Jun 16, 2015 at 12:07 PM, eshark  wrote:
>> At 2015-06-16 15:54:10, "David Herrmann"  wrote:
>>>Can you be more specific, please? What do you mean by "network module
>>>of our systemd cannot work OK"?
>>
>

>Does this only happen with kdbus?
Yes.  It's OK with DBus.
>Does this only happen with you kdbus-patch to make broadcasts being
>sent to oneself?
Yes. Without modifying kdbus_bus_broadcast(),  I can always get the ip.
>Or does it happen with unmodified kdbus, too?
Never.
>What exactly changes?
I just commented out the following two lines in the kdbus

Re: [systemd-devel] [PATCH] improve systemctl daemon-reexec and daemon-reload documentation

[Lennart Poettering]

On Wed, 17.06.15 11:22, Thomas Blume (thomas.bl...@suse.com) wrote:

> The systemctl daemon-reexec and daemon-reload documentation
> in the manpage is a bit ambiguous. It suggests that daemon-reload reloads the
> configuration of the manager itself (e.g. the [Manager] section in
> /etc/systemd/system.conf). It should be pointed out that it only reloads the
> configuration for the manager clients and that for reloading the manager
> configuration, daemon-reexec must be used.

"clients"? I am not sure what that term is supposed to refer to?

The reason we say it's the "manager" configuration is because people
should distuingish "systemctl daemon-reload" from "systemctl reload"
where the latter just asks a service to reload its own configuration,
but systemd (aka "the manager") stays unaffected.

I think "systemctl daemon-reload" should probably reload system.conf,
too though, hence I'd like to avoid documenting this behaviour now,
but rather consider this a bug we should fix. Documenting behaviour
now and then changing it later is worse than simply leaving it vague
for now, and correcting it later. I will add that to the TODO list.

> From 198dbd4fdc4a4cccef24aa9fd97ceb328c87c52d Mon Sep 17 00:00:00 2001
> From: Thomas Blume 
> Date: Wed, 17 Jun 2015 11:03:52 +0200
> Subject: [PATCH] The systemctl daemon-reexec and daemon-reload documentation
>  in the manpage is a bit ambiguous. It suggests that daemon-reload reloads the
>  configuration of the manager itself (e.g. the [Manager] section in
>  /etc/systemd/system.conf). It should be pointed out that it only reloads the
>  configuration for the manager clients and that for reloading the manager
>  configuration, daemon-reexec must be used.
> 
> ---
>  man/systemctl.xml | 8 
>  src/systemctl/systemctl.c | 2 +-
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/man/systemctl.xml b/man/systemctl.xml
> index 338c1d3..6c94255 100644
> --- a/man/systemctl.xml
> +++ b/man/systemctl.xml
> @@ -1367,7 +1367,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket 
> systemd-udevd.service
>daemon-reload
>  
>
> -Reload systemd manager configuration. This will
> +Reload systemd manager client configuration. This will
>  rerun all generators (see
>  
> systemd.generator7),
>  reload all unit files, and recreate the entire dependency
> @@ -1385,9 +1385,9 @@ kobject-uevent 1 systemd-udevd-kernel.socket 
> systemd-udevd.service
>
>  Reexecute the systemd manager. This will serialize the
>  manager state, reexecute the process and deserialize the
> -state again. This command is of little use except for
> -debugging and package upgrades. Sometimes, it might be
> -helpful as a heavy-weight daemon-reload.
> +state again. It updates the systemd manager configuration
> +after changes in the system config file 
> (/etc/systemd/system.conf).
> +Sometimes, it might be helpful as a heavy-weight 
> daemon-reload.
>  While the daemon is being reexecuted, all sockets systemd 
> listening
>  on behalf of user configuration will stay accessible.
>  
> diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
> index 41f7b9f..ce7c540 100644
> --- a/src/systemctl/systemctl.c
> +++ b/src/systemctl/systemctl.c
> @@ -6035,7 +6035,7 @@ static void systemctl_help(void) {
> "  unset-environment NAME...   Unset one or more 
> environment variables\n"
> "  import-environment [NAME...]Import all or some 
> environment variables\n\n"
> "Manager Lifecycle Commands:\n"
> -   "  daemon-reload   Reload systemd manager 
> configuration\n"
> +   "  daemon-reload   Reload systemd manager 
> client configuration\n"
> "  daemon-reexec   Reexecute systemd 
> manager\n\n"
> "System Commands:\n"
> "  is-system-running   Check whether system is 
> fully running\n"
> -- 
> 2.1.4
> 

> ___
> 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] improve systemctl daemon-reexec and daemon-reload documentation

[Thomas Blume]

On Mittwoch 2015-06-17 13:16, Lennart Poettering wrote:



The systemctl daemon-reexec and daemon-reload documentation
in the manpage is a bit ambiguous. It suggests that daemon-reload reloads the
configuration of the manager itself (e.g. the [Manager] section in
/etc/systemd/system.conf). It should be pointed out that it only reloads the
configuration for the manager clients and that for reloading the manager
configuration, daemon-reexec must be used.


"clients"? I am not sure what that term is supposed to refer to?


I just wanted to refer to the fact that it only reloads the unit files but not
the configuration of the systemd manager itself.


The reason we say it's the "manager" configuration is because people
should distuingish "systemctl daemon-reload" from "systemctl reload"
where the latter just asks a service to reload its own configuration,
but systemd (aka "the manager") stays unaffected.

I think "systemctl daemon-reload" should probably reload system.conf,
too though, hence I'd like to avoid documenting this behaviour now,
but rather consider this a bug we should fix. Documenting behaviour
now and then changing it later is worse than simply leaving it vague
for now, and correcting it later. I will add that to the TODO list.



Ah ok, I thought it was intended that daemon-reload doesn't reload system.conf.
I will try to provide a new patch.


Thanks

Thomas Blume

--
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham 
Norton, HRB 21284 (AG Nürnberg)
Maxfeldstr. 5 / D-90409 Nürnberg / Phone: +49-911-740 53 - 0 / VOIP: 3919
GPG 2048R/2CD4D3E8 9A50 048F 1C73 59AA 4D2E  424E B3C6 3FD9 2CD4 D3E8___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v2] watchdog: Don't require WDIOC_SETOPTIONS/WDIOS_ENABLECARD

[Jean Delvare]

On Wed, 17 Jun 2015 12:02:27 +0200, Lennart Poettering wrote:
> On Wed, 17.06.15 11:26, Jean Delvare (jdelv...@suse.de) wrote:
> 
> > Not all watchdog drivers implement WDIOC_SETOPTIONS. Drivers which do
> > not implement it have their device always enabled. So it's fine to
> > report an error if WDIOS_DISABLECARD is passed and the ioctl is not
> > implemented, however failing when WDIOS_ENABLECARD is passed and the
> > ioctl is not implemented is not good: if the device was already
> > enabled then WDIOS_ENABLECARD was a no-op and wasn't needed in the
> > first place. So we can just ignore the error and continue.
> > ---
> > Lennart, would that be OK with you?
> 
> Generally yes.
> 
> But: indentation is borked, there some whitespace issues, I cannot
> even apply this. 
> 
> Please have a look at CODING_STYLE.

Oops, sorry about that. I had read CODING_STYLE, and paid attention for
the first submission, but then forgot to double-check the indentation
after doing the requested changes. All other projects I'm working on
use tabs, not spaces, so that's my editor does unless I fix it manually.

> Also, please build the stuff locally before commit and send to the
> ML. We have a git commit hook that checks for weird whitespace at time
> of commit. It's enables as soon as you run "autogen.sh" once...

I always test-build. But I won't get to commit the patch myself, which
is why I did not get the warning.

> > Changes since v1:
> >  * Log WDIOC_SETOPTIONS/WDIOS_ENABLECARD failure at debug level if
> >ENOTTY is returned. Suggested by Lennart Poettering.
> > 
> >  src/shared/watchdog.c |9 +++--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> > 
> > --- systemd.orig/src/shared/watchdog.c  2015-06-15
> > 18:51:40.811989627 +0200 +++ systemd/src/shared/watchdog.c
> > 2015-06-17 11:20:01.798331790 +0200 @@ -60,8 +60,13 @@ static int
> > update_timeout(void) { 
> >  flags = WDIOS_ENABLECARD;
> >  r = ioctl(watchdog_fd, WDIOC_SETOPTIONS, &flags);
> > -if (r < 0)
> > -return log_warning_errno(errno, "Failed to
> > enable hardware watchdog: %m");
> > +if (r < 0) {
> > +   /* ENOTTY means the watchdog is always
> > enabled so we're fine */
> 
> multiples of 8 space indenting, please.
> 
> > +log_full(errno == ENOTTY ? LOG_DEBUG :
> > LOG_WARNING,
> > + "Failed to enable hardware
> > watchdog: %m");
> > +if (errno != ENOTTY)
> > +   return errno;
> 
> multiples of 8 space indenting, please.
> 
> > +}
> >  
> >  r = ioctl(watchdog_fd, WDIOC_KEEPALIVE, 0);
> >  if (r < 0)
> > 

Both fixed, I'll resubmit shortly, sorry again and thanks for the
review.

-- 
Jean Delvare
SUSE L3 Support
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Why we need to read/save random seed?

[cee1]

2015-06-17 16:40 GMT+08:00 Reindl Harald :
>
> Am 17.06.2015 um 05:06 schrieb cee1:
>>
>> 2015-06-16 0:21 GMT+08:00 Lennart Poettering :
>>>
>>> On Mon, 15.06.15 23:33, cee1 (fykc...@gmail.com) wrote:

 Hi,

 I maybe got confused.

 First, systemd-random-seed.service will save a "seed" from
 /dev/urandom when shutdown, and load that "seed" to /dev/urandom when
 next boot up.

 My questions are:
 1. Can we not save a seed, but load a seed that is read from **
 /dev/random ** to ** /dev/urandom **?
>>>
>>>
>>> The seed is used for both. Then you'd feed the stuff you got from the
>>> RNG back into the RNG which is a pointless excercise.
>>
>>
>> systemd-random-seed.service will load the "seed on disk" to
>> /dev/urandom, and save a "seed" to disk when shutdown, right?
>>
>> The article at http://www.2uo.de/myths-about-urandom/ suggests us
>> saving the seed as soon as there is enough entropy(means read from
>> /dev/random? if returns, there's enough entropy),
>
>
> well, so you read the seed and inject it to /dev/random followed by read
> /dev/random and overwrite the seed for the next boot - don't sounds that
> good

What I means is:
1. Load a saved seed to /dev/urandom.
2. The service read /dev/random, which will block until kernel thinks
there's enough entropy - then the Random Number should be good?
3. Save the random number returned in step 2 on disk.



-- 
Regards,

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

Re: [systemd-devel] Why we need to read/save random seed?

[Reindl Harald]

Am 17.06.2015 um 14:21 schrieb cee1:

2015-06-17 16:40 GMT+08:00 Reindl Harald :

systemd-random-seed.service will load the "seed on disk" to
/dev/urandom, and save a "seed" to disk when shutdown, right?

The article at http://www.2uo.de/myths-about-urandom/ suggests us
saving the seed as soon as there is enough entropy(means read from
/dev/random? if returns, there's enough entropy),


well, so you read the seed and inject it to /dev/random followed by read
/dev/random and overwrite the seed for the next boot - don't sounds that
good


What I means is:
1. Load a saved seed to /dev/urandom.
2. The service read /dev/random, which will block until kernel thinks
there's enough entropy - then the Random Number should be good?
3. Save the random number returned in step 2 on disk


oh yeah block at boot sounds what we want.




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

Re: [systemd-devel] Why we need to read/save random seed?

[Kay Sievers]

On Wed, Jun 17, 2015 at 2:28 PM, Reindl Harald  wrote:
>
> Am 17.06.2015 um 14:21 schrieb cee1:
>>
>> 2015-06-17 16:40 GMT+08:00 Reindl Harald :

 systemd-random-seed.service will load the "seed on disk" to
 /dev/urandom, and save a "seed" to disk when shutdown, right?

 The article at http://www.2uo.de/myths-about-urandom/ suggests us
 saving the seed as soon as there is enough entropy(means read from
 /dev/random? if returns, there's enough entropy),
>>>
>>>
>>> well, so you read the seed and inject it to /dev/random followed by read
>>> /dev/random and overwrite the seed for the next boot - don't sounds that
>>> good
>>
>>
>> What I means is:
>> 1. Load a saved seed to /dev/urandom.
>> 2. The service read /dev/random, which will block until kernel thinks
>> there's enough entropy - then the Random Number should be good?
>> 3. Save the random number returned in step 2 on disk
>
>
> oh yeah block at boot sounds what we want.

The suggestion is reasonable and part of a useful technical discussion.

Your reply is not constructive or funny, and even plain wrong in its
assumptions. Please keep such comments to yourself or you will be
moderated again.

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

[systemd-devel] systemd-resolved as dnsmasq replacement

[Igor Bukanov]

Hello,

perhaps I missed something, but it seems that systemd-resolved cannot
be configured to serve the same role as dnsmasq and be a DNS server
for local machine.  I.e. I cannot just have nameserver 127.0.0.1 in
/ertc/resolv.conf and get LLMNR resolution working for progams that
only use nameservers from /etc/resolv.conf .

Is it really true and this is indeed an unimplemented feature?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-resolved as dnsmasq replacement

[Lennart Poettering]

On Wed, 17.06.15 15:19, Igor Bukanov (i...@mir2.org) wrote:

> Hello,
> 
> perhaps I missed something, but it seems that systemd-resolved cannot
> be configured to serve the same role as dnsmasq and be a DNS server
> for local machine.  I.e. I cannot just have nameserver 127.0.0.1 in
> /ertc/resolv.conf and get LLMNR resolution working for progams that
> only use nameservers from /etc/resolv.conf .

The semantics of LLMNR are quite different from DNS. Translating DNS
requests to LLMNR is not really a good idea. For example, DNS clients
generally have no concept of address scopes, while they are pretty
much essential for LLMNR, because that is usually used in conjuntion
with ipv4ll and ipv6 link local addresses.

Hence: we will not do translation like that. And we won't add that for
mDNS (which I plan to add support for soon) either.

> Is it really true and this is indeed an unimplemented feature?

THis is not intended to be available. To hook up local name service
clients people should use the "nss-resolve" NSS module, which ensures
that gethostbyname() and friends use resolved as backend.

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] 628c89cc (tentative devices) + disk/by-label udev rule

[Peter Mattern]

The messages about several sysfs paths per device aren't caused by 
volume labels as seen in /dev/disk/by-label only.
On GPT systems they seem to be triggered by identical partition labels 
corresponding to variable PARTLABEL in output of blkid as well.
Also, they can be seen launching Arch Linux installer's live system the 
file system handling of which I don't know well enough to tell what 
exactly is happening.


I guess the solution to just suppress the messages will still be the 
same but thought it may make sense to quickly mention those findings 
here as the thread had been limited to labels in /dev/disk/by-label so far.


On a side note several partitions tagged by the same partition label 
will probably exist on nearly every system. As /dev/disk/by-partlabel  
seems to reference only one per label I wonder whether this directory 
makes any sense at all.


Regards,

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

Re: [systemd-devel] 628c89cc (tentative devices) + disk/by-label udev rule

[Lennart Poettering]

On Wed, 17.06.15 15:44, Peter Mattern (matte...@arcor.de) wrote:

> The messages about several sysfs paths per device aren't caused by volume
> labels as seen in /dev/disk/by-label only.
> On GPT systems they seem to be triggered by identical partition labels
> corresponding to variable PARTLABEL in output of blkid as well.
> Also, they can be seen launching Arch Linux installer's live system the file
> system handling of which I don't know well enough to tell what exactly is
> happening.
> 
> I guess the solution to just suppress the messages will still be the same
> but thought it may make sense to quickly mention those findings here as the
> thread had been limited to labels in /dev/disk/by-label so far.
> 
> On a side note several partitions tagged by the same partition label will
> probably exist on nearly every system. As /dev/disk/by-partlabel  seems to
> reference only one per label I wonder whether this directory makes any sense
> at all.

Depends on the setup. I mean, if you refernces devices by its part
label, then you better make sure the part label is unique enough so
that it doesn't explode in your face right-away...

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] Why we need to read/save random seed?

[Reindl Harald]

Am 17.06.2015 um 14:51 schrieb Kay Sievers:

On Wed, Jun 17, 2015 at 2:28 PM, Reindl Harald  wrote:

Am 17.06.2015 um 14:21 schrieb cee1:


2015-06-17 16:40 GMT+08:00 Reindl Harald :


systemd-random-seed.service will load the "seed on disk" to
/dev/urandom, and save a "seed" to disk when shutdown, right?

The article at http://www.2uo.de/myths-about-urandom/ suggests us
saving the seed as soon as there is enough entropy(means read from
/dev/random? if returns, there's enough entropy),



well, so you read the seed and inject it to /dev/random followed by read
/dev/random and overwrite the seed for the next boot - don't sounds that
good



What I means is:
1. Load a saved seed to /dev/urandom.
2. The service read /dev/random, which will block until kernel thinks
there's enough entropy - then the Random Number should be good?
3. Save the random number returned in step 2 on disk


oh yeah block at boot sounds what we want.


The suggestion is reasonable and part of a useful technical discussion.


what is there reasonable?

suck out /dev/random at boot completly defeats the reason the service 
exists at all and there is no need for a great technical discussion



Your reply is not constructive or funny, and even plain wrong in its
assumptions


it was not meant funny


Please keep such comments to yourself or you will be
moderated again


you threaten everytime you personally don't agree is a better style?



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

Re: [systemd-devel] Why we need to read/save random seed?

[Lennart Poettering]

On Wed, 17.06.15 20:21, cee1 (fykc...@gmail.com) wrote:

> 2015-06-17 16:40 GMT+08:00 Reindl Harald :
> >
> > Am 17.06.2015 um 05:06 schrieb cee1:
> >>
> >> 2015-06-16 0:21 GMT+08:00 Lennart Poettering :
> >>>
> >>> On Mon, 15.06.15 23:33, cee1 (fykc...@gmail.com) wrote:
> 
>  Hi,
> 
>  I maybe got confused.
> 
>  First, systemd-random-seed.service will save a "seed" from
>  /dev/urandom when shutdown, and load that "seed" to /dev/urandom when
>  next boot up.
> 
>  My questions are:
>  1. Can we not save a seed, but load a seed that is read from **
>  /dev/random ** to ** /dev/urandom **?
> >>>
> >>>
> >>> The seed is used for both. Then you'd feed the stuff you got from the
> >>> RNG back into the RNG which is a pointless excercise.
> >>
> >>
> >> systemd-random-seed.service will load the "seed on disk" to
> >> /dev/urandom, and save a "seed" to disk when shutdown, right?
> >>
> >> The article at http://www.2uo.de/myths-about-urandom/ suggests us
> >> saving the seed as soon as there is enough entropy(means read from
> >> /dev/random? if returns, there's enough entropy),
> >
> >
> > well, so you read the seed and inject it to /dev/random followed by read
> > /dev/random and overwrite the seed for the next boot - don't sounds that
> > good
> 
> What I means is:
> 1. Load a saved seed to /dev/urandom.
> 2. The service read /dev/random, which will block until kernel thinks
> there's enough entropy - then the Random Number should be good?
> 3. Save the random number returned in step 2 on disk.

Blocking at boot for this doesn't really sound like an option. But the
kernel does not provide us with any nice notifications about when the
RNG pool is complete. If we want to do this kind of polishing, then
that'd be great, but we'd need sane notifiers for that, blocking
syscalls are not an option.

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] Why we need to read/save random seed?

[Lennart Poettering]

On Wed, 17.06.15 16:04, Reindl Harald (h.rei...@thelounge.net) wrote:

> >Please keep such comments to yourself or you will be
> >moderated again
> 
> you threaten everytime you personally don't agree is a better style?

Congratulations, I just put you back on moderation.

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] Why we need to read/save random seed?

[cee1]

2015-06-17 22:03 GMT+08:00 Lennart Poettering :
> On Wed, 17.06.15 20:21, cee1 (fykc...@gmail.com) wrote:
>>
>> What I means is:
>> 1. Load a saved seed to /dev/urandom.
>> 2. The service read /dev/random, which will block until kernel thinks
>> there's enough entropy - then the Random Number should be good?
>> 3. Save the random number returned in step 2 on disk.
>
> Blocking at boot for this doesn't really sound like an option. But the
> kernel does not provide us with any nice notifications about when the
> RNG pool is complete. If we want to do this kind of polishing, then
> that'd be great, but we'd need sane notifiers for that, blocking
> syscalls are not an option.

That don't mean blocking boot, but a service, let's say
systemd-random-seed.service:
1. systemd-random-seed.service loads a seed from disk to /dev/urandom
2. systemd-random-seed.service tells systemd "I'm ready" (sd_notify())
3. Instead of quitting immediately, systemd-random-seed.service tries
to read /dev/random, and it blocks ...
4. systemd-random-seed.service at last gets a 'good random number',
and saves it on disk

This can save a seed as soon as possible, as suggested in the article
http://www.2uo.de/myths-about-urandom/:
"""
On Linux it isn't too bad, because Linux distributions save some
random numbers when booting up the system (but after they have
gathered some entropy, since the startup script doesn't run
immediately after switching on the machine) into a seed file that is
read next time the machine is booting.

Obviously that isn't as good as if you let the shutdown scripts write
out the seed, because in that case there would have been much more
time to gather entropy. The advantage is obviously that this does not
depend on a proper shutdown with execution of the shutdown scripts (in
case the computer crashes, for example).
"""



-- 
Regards,

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

Re: [systemd-devel] Why we need to read/save random seed?

[Lennart Poettering]

On Wed, 17.06.15 23:08, cee1 (fykc...@gmail.com) wrote:

> 2015-06-17 22:03 GMT+08:00 Lennart Poettering :
> > On Wed, 17.06.15 20:21, cee1 (fykc...@gmail.com) wrote:
> >>
> >> What I means is:
> >> 1. Load a saved seed to /dev/urandom.
> >> 2. The service read /dev/random, which will block until kernel thinks
> >> there's enough entropy - then the Random Number should be good?
> >> 3. Save the random number returned in step 2 on disk.
> >
> > Blocking at boot for this doesn't really sound like an option. But the
> > kernel does not provide us with any nice notifications about when the
> > RNG pool is complete. If we want to do this kind of polishing, then
> > that'd be great, but we'd need sane notifiers for that, blocking
> > syscalls are not an option.
> 
> That don't mean blocking boot, but a service, let's say
> systemd-random-seed.service:
> 1. systemd-random-seed.service loads a seed from disk to /dev/urandom
> 2. systemd-random-seed.service tells systemd "I'm ready" (sd_notify())
> 3. Instead of quitting immediately, systemd-random-seed.service tries
> to read /dev/random, and it blocks ...
> 4. systemd-random-seed.service at last gets a 'good random number',
> and saves it on disk

i'd be willing to take a patch for such a change.

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] Why we need to read/save random seed?

[cee1]

2015-06-17 23:15 GMT+08:00 Lennart Poettering :
>> That don't mean blocking boot, but a service, let's say
>> systemd-random-seed.service:
>> 1. systemd-random-seed.service loads a seed from disk to /dev/urandom
>> 2. systemd-random-seed.service tells systemd "I'm ready" (sd_notify())
>> 3. Instead of quitting immediately, systemd-random-seed.service tries
>> to read /dev/random, and it blocks ...
>> 4. systemd-random-seed.service at last gets a 'good random number',
>> and saves it on disk
>
> i'd be willing to take a patch for such a change.

The type of this systemd-random-seed.service should be "notify", right?



-- 
Regards,

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

[systemd-devel] [PATCH v3] watchdog: Don't require WDIOC_SETOPTIONS/WDIOS_ENABLECARD

[Jean Delvare]

Not all watchdog drivers implement WDIOC_SETOPTIONS. Drivers which do
not implement it have their device always enabled. So it's fine to
report an error if WDIOS_DISABLECARD is passed and the ioctl is not
implemented, however failing when WDIOS_ENABLECARD is passed and the
ioctl is not implemented is not good: if the device was already
enabled then WDIOS_ENABLECARD was a no-op and wasn't needed in the
first place. So we can just ignore the error and continue.
---
Changes since v2:
 * Fix indentation (spaces not tabs.)

Changes since v1:
 * Log WDIOC_SETOPTIONS/WDIOS_ENABLECARD failure at debug level if
   ENOTTY is returned. Suggested by Lennart Poettering.

 src/shared/watchdog.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

--- systemd.orig/src/shared/watchdog.c  2015-06-17 13:09:40.808480605 +0200
+++ systemd/src/shared/watchdog.c   2015-06-17 13:09:50.633687681 +0200
@@ -60,8 +60,13 @@ static int update_timeout(void) {
 
 flags = WDIOS_ENABLECARD;
 r = ioctl(watchdog_fd, WDIOC_SETOPTIONS, &flags);
-if (r < 0)
-return log_warning_errno(errno, "Failed to enable 
hardware watchdog: %m");
+if (r < 0) {
+/* ENOTTY means the watchdog is always enabled so 
we're fine */
+log_full(errno == ENOTTY ? LOG_DEBUG : LOG_WARNING,
+ "Failed to enable hardware watchdog: %m");
+if (errno != ENOTTY)
+return errno;
+}
 
 r = ioctl(watchdog_fd, WDIOC_KEEPALIVE, 0);
 if (r < 0)


-- 
Jean Delvare
SUSE L3 Support
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Why we need to read/save random seed?

[Lennart Poettering]

B1;4002;0cOn Wed, 17.06.15 23:45, cee1 (fykc...@gmail.com) wrote:

> 2015-06-17 23:15 GMT+08:00 Lennart Poettering :
> >> That don't mean blocking boot, but a service, let's say
> >> systemd-random-seed.service:
> >> 1. systemd-random-seed.service loads a seed from disk to /dev/urandom
> >> 2. systemd-random-seed.service tells systemd "I'm ready" (sd_notify())
> >> 3. Instead of quitting immediately, systemd-random-seed.service tries
> >> to read /dev/random, and it blocks ...
> >> 4. systemd-random-seed.service at last gets a 'good random number',
> >> and saves it on disk
> >
> > i'd be willing to take a patch for such a change.
> 
> The type of this systemd-random-seed.service should be "notify", right?

yes, if sd_notify("READY=1") is used then the type should be "notify".

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] Why we need to read/save random seed?

[cee1]

2015-06-17 23:38 GMT+08:00 Reindl Harald :
>
>
> Am 17.06.2015 um 17:08 schrieb cee1:
>>
>> 2015-06-17 22:03 GMT+08:00 Lennart Poettering :
>>>
>>> On Wed, 17.06.15 20:21, cee1 (fykc...@gmail.com) wrote:


 What I means is:
 1. Load a saved seed to /dev/urandom.
 2. The service read /dev/random, which will block until kernel thinks
 there's enough entropy - then the Random Number should be good?
 3. Save the random number returned in step 2 on disk.
>>>
>>>
>>> Blocking at boot for this doesn't really sound like an option. But the
>>> kernel does not provide us with any nice notifications about when the
>>> RNG pool is complete. If we want to do this kind of polishing, then
>>> that'd be great, but we'd need sane notifiers for that, blocking
>>> syscalls are not an option.
>>
>>
>> That don't mean blocking boot, but a service, let's say
>> systemd-random-seed.service:
>> 1. systemd-random-seed.service loads a seed from disk to /dev/urandom
>> 2. systemd-random-seed.service tells systemd "I'm ready" (sd_notify())
>> 3. Instead of quitting immediately, systemd-random-seed.service tries
>> to read /dev/random, and it blocks ...
>> 4. systemd-random-seed.service at last gets a 'good random number',
>> and saves it on disk
>
>
> * the purpose of systemd-random-seed.service is to seed
>   /dev/random realy at boot so that other services like
>   sshd, vpn, webservers have a random source

First it seeds /dev/urandom
Second, seed /dev/random will not increase the entropy without using
ioctl (please see
https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg32555.html)

Though, some other services may read /dev/random, and the suggested
logic may exhaust the very little entropy, hence blocks "those other
services"?

May use getrandom(as mentioned in http://www.2uo.de/myths-about-urandom):
"""
This syscall does the right thing: blocking until it has gathered
enough initial entropy, and never blocking after point.
"""



-- 
Regards,

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

Re: [systemd-devel] [PATCH v3] watchdog: Don't require WDIOC_SETOPTIONS/WDIOS_ENABLECARD

[Lennart Poettering]

On Wed, 17.06.15 17:49, Jean Delvare (jdelv...@suse.de) wrote:

> Not all watchdog drivers implement WDIOC_SETOPTIONS. Drivers which do
> not implement it have their device always enabled. So it's fine to
> report an error if WDIOS_DISABLECARD is passed and the ioctl is not
> implemented, however failing when WDIOS_ENABLECARD is passed and the
> ioctl is not implemented is not good: if the device was already
> enabled then WDIOS_ENABLECARD was a no-op and wasn't needed in the
> first place. So we can just ignore the error and continue.
> ---
> Changes since v2:
>  * Fix indentation (spaces not tabs.)
> 
> Changes since v1:
>  * Log WDIOC_SETOPTIONS/WDIOS_ENABLECARD failure at debug level if
>ENOTTY is returned. Suggested by Lennart Poettering.
> 
>  src/shared/watchdog.c |9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> --- systemd.orig/src/shared/watchdog.c2015-06-17 13:09:40.808480605 
> +0200
> +++ systemd/src/shared/watchdog.c 2015-06-17 13:09:50.633687681 +0200
> @@ -60,8 +60,13 @@ static int update_timeout(void) {
>  
>  flags = WDIOS_ENABLECARD;
>  r = ioctl(watchdog_fd, WDIOC_SETOPTIONS, &flags);
> -if (r < 0)
> -return log_warning_errno(errno, "Failed to enable 
> hardware watchdog: %m");
> +if (r < 0) {
> +/* ENOTTY means the watchdog is always enabled so 
> we're fine */
> +log_full(errno == ENOTTY ? LOG_DEBUG : LOG_WARNING,
> + "Failed to enable hardware watchdog: %m");
> +if (errno != ENOTTY)
> +return errno;
> +}

Sorry, not sure how I missed that, but we return error as negative
integers. Must be "return -errno" instead of "return errno" hence. See
CODING_STYLE on this.

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] Why we need to read/save random seed?

[Lennart Poettering]

On Thu, 18.06.15 00:00, cee1 (fykc...@gmail.com) wrote:

> First it seeds /dev/urandom
> Second, seed /dev/random will not increase the entropy without using
> ioctl (please see
> https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg32555.html)
> 
> Though, some other services may read /dev/random, and the suggested
> logic may exhaust the very little entropy, hence blocks "those other
> services"?
> 
> May use getrandom(as mentioned in http://www.2uo.de/myths-about-urandom):
> """
> This syscall does the right thing: blocking until it has gathered
> enough initial entropy, and never blocking after point.
> """

We already make use of getrandom() elsewhere, hence it's OK to
use. However, given how new the call is there should be a fallback to
/dev/random in place, even if that makes us lose the entropy...

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 v3] watchdog: Don't require WDIOC_SETOPTIONS/WDIOS_ENABLECARD

[Jean Delvare]

On Wed, 17 Jun 2015 18:00:58 +0200, Lennart Poettering wrote:
> On Wed, 17.06.15 17:49, Jean Delvare (jdelv...@suse.de) wrote:
> 
> > Not all watchdog drivers implement WDIOC_SETOPTIONS. Drivers which do
> > not implement it have their device always enabled. So it's fine to
> > report an error if WDIOS_DISABLECARD is passed and the ioctl is not
> > implemented, however failing when WDIOS_ENABLECARD is passed and the
> > ioctl is not implemented is not good: if the device was already
> > enabled then WDIOS_ENABLECARD was a no-op and wasn't needed in the
> > first place. So we can just ignore the error and continue.
> > ---
> > Changes since v2:
> >  * Fix indentation (spaces not tabs.)
> > 
> > Changes since v1:
> >  * Log WDIOC_SETOPTIONS/WDIOS_ENABLECARD failure at debug level if
> >ENOTTY is returned. Suggested by Lennart Poettering.
> > 
> >  src/shared/watchdog.c |9 +++--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> > 
> > --- systemd.orig/src/shared/watchdog.c  2015-06-17 13:09:40.808480605 
> > +0200
> > +++ systemd/src/shared/watchdog.c   2015-06-17 13:09:50.633687681 +0200
> > @@ -60,8 +60,13 @@ static int update_timeout(void) {
> >  
> >  flags = WDIOS_ENABLECARD;
> >  r = ioctl(watchdog_fd, WDIOC_SETOPTIONS, &flags);
> > -if (r < 0)
> > -return log_warning_errno(errno, "Failed to enable 
> > hardware watchdog: %m");
> > +if (r < 0) {
> > +/* ENOTTY means the watchdog is always enabled so 
> > we're fine */
> > +log_full(errno == ENOTTY ? LOG_DEBUG : LOG_WARNING,
> > + "Failed to enable hardware watchdog: %m");
> > +if (errno != ENOTTY)
> > +return errno;
> > +}
> 
> Sorry, not sure how I missed that, but we return error as negative
> integers. Must be "return -errno" instead of "return errno" hence. See
> CODING_STYLE on this.

I feel even more sorry, I should have seen that :-( Patch v4 coming...

-- 
Jean Delvare
SUSE L3 Support
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 4/5] import/pull: Tag replaced with reference

[Lennart Poettering]

On Wed, 17.06.15 09:09, Pavel Odvody (podv...@redhat.com) wrote:

> > > -tag = "latest";
> > > +reference = "latest";
> > >  }
> > 
> > This part does not look correct. Any value that we set for
> > reference/name in the digest part will be overwritten in the next
> > block. I do not know the format of the string so I cannot create a
> > patch for this. Can you take a look Pavel?
> > 
> 
> I think you're right, will take a look later today and submit a patch.
> 
> The digest reference looks like this:
> 
> fedora@sha256:cc47966101aeba8015c933f9c3854811a27363f93fa4e0e52e6c55181c56c66c

There's now a PR for this:

https://github.com/systemd/systemd/pull/247

Please follow up with the discussions there.

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 v2] selinux: fix missing SELinux unit access check

[Lennart Poettering]

On Wed, 10.06.15 14:40, HATAYAMA Daisuke (d.hatay...@jp.fujitsu.com) wrote:

> From 398deee74edb06b54b8a74c25697cd6d977d8f2d Mon Sep 17 00:00:00 2001
> From: HATAYAMA Daisuke 
> Date: Wed, 10 Jun 2015 14:10:31 +0900
> Subject: [PATCH] selinux: fix missing SELinux unit access check
> 
> Currently, SELinux unit access check is not performed if a given unit
> file has not been registered in a hash table. This is because function
> manager_get_unit() only tries to pick up a Unit object from a Unit
> hash table. Instead, we use function manager_load_unit() searching
> Unit file pathes for the given Unit file.
> ---
>  src/core/selinux-access.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> v2:
> - checking an error status by u->load_error to cover UNIT_ERROR case.
> 
> diff --git a/src/core/selinux-access.c b/src/core/selinux-access.c
> index decd42f..ac52906 100644
> --- a/src/core/selinux-access.c
> +++ b/src/core/selinux-access.c
> @@ -292,8 +292,12 @@ int mac_selinux_unit_access_check_strv(char **units,
>  int r;
>  
>  STRV_FOREACH(i, units) {
> -u = manager_get_unit(m, *i);
> +r = manager_load_unit(m, *i, NULL, error, &u);
> +if (r < 0)
> +return r;
>  if (u) {
> +if (u->load_error != 0)
> +return u->load_error;
>  r = mac_selinux_unit_access_check(u, message, 
> permission, error);
>  if (r < 0)
>  return r;

I commented on the issue now in github, could you please follow up
there?

https://github.com/systemd/systemd/pull/145

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] mount: use libmount to monitor mountinfo & utab

[Lennart Poettering]

On Wed, 03.06.15 14:59, Karel Zak (k...@redhat.com) wrote:

> The current implementation directly monitor /proc/self/mountinfo and
> /run/mount/utab files. It's really not optimal because utab file is
> private libmount stuff without any official guaranteed semantic.
> 
> The libmount since v2.26 provides API to monitor mount kernel &
> userspace changes. This patch replaces the current implementation with
> libmount based solution.
> 
> Now the manager.h includes , so $MOUNT_CFLAGS has been
> necessary to add to many tests CFLAGS.
> 
> Note that mnt_monitor_event_cleanup() in v2.26 is broken, so the patch
> uses mnt_monitor_next_change(). It's exactly the same solution which
> uses the current libmount HEAD (mnt_monitor_event_cleanup() is API
> shorcut only).

For the sake of the archives, this is now tracked on github:

https://github.com/systemd/systemd/pull/194

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] zsh-completion: fix completion of --user services

[Lennart Poettering]

On Mon, 18.05.15 18:45, Eric Cook (l...@gmx.com) wrote:

> By the time __systemctl is called, --user/--system are shifted out of
> `words' by _arguments. This patch queries the array sooner. 
> 
> In the case that both --user and --system are on the line when compsys runs,
> _sys_service_mgr is set to the latter. Which is seemingly how systemctl 
> behaves.
> 
> If neither are on the line, --system is set; for system services to be 
> completed.

Is this still an issue? If so, could you post this patch as a PR on
github for review?

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 v4] watchdog: Don't require WDIOC_SETOPTIONS/WDIOS_ENABLECARD

[Jean Delvare]

Not all watchdog drivers implement WDIOC_SETOPTIONS. Drivers which do
not implement it have their device always enabled. So it's fine to
report an error if WDIOS_DISABLECARD is passed and the ioctl is not
implemented, however failing when WDIOS_ENABLECARD is passed and the
ioctl is not implemented is not good: if the device was already
enabled then WDIOS_ENABLECARD was a no-op and wasn't needed in the
first place. So we can just ignore the error and continue.
---
Changes since v3:
 * Return negative error number.

Changes since v2:
 * Fix indentation (spaces not tabs.)

Changes since v1:
 * Log WDIOC_SETOPTIONS/WDIOS_ENABLECARD failure at debug level if
   ENOTTY is returned. Suggested by Lennart Poettering.

 src/shared/watchdog.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

--- systemd.orig/src/shared/watchdog.c  2015-06-17 18:11:23.056059315 +0200
+++ systemd/src/shared/watchdog.c   2015-06-17 18:51:16.980269395 +0200
@@ -60,8 +60,13 @@ static int update_timeout(void) {
 
 flags = WDIOS_ENABLECARD;
 r = ioctl(watchdog_fd, WDIOC_SETOPTIONS, &flags);
-if (r < 0)
-return log_warning_errno(errno, "Failed to enable 
hardware watchdog: %m");
+if (r < 0) {
+/* ENOTTY means the watchdog is always enabled so 
we're fine */
+log_full(errno == ENOTTY ? LOG_DEBUG : LOG_WARNING,
+ "Failed to enable hardware watchdog: %m");
+if (errno != ENOTTY)
+return -errno;
+}
 
 r = ioctl(watchdog_fd, WDIOC_KEEPALIVE, 0);
 if (r < 0)


-- 
Jean Delvare
SUSE L3 Support
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v4] watchdog: Don't require WDIOC_SETOPTIONS/WDIOS_ENABLECARD

[Lennart Poettering]

On Wed, 17.06.15 18:57, Jean Delvare (jdelv...@suse.de) wrote:

> Not all watchdog drivers implement WDIOC_SETOPTIONS. Drivers which do
> not implement it have their device always enabled. So it's fine to
> report an error if WDIOS_DISABLECARD is passed and the ioctl is not
> implemented, however failing when WDIOS_ENABLECARD is passed and the
> ioctl is not implemented is not good: if the device was already
> enabled then WDIOS_ENABLECARD was a no-op and wasn't needed in the
> first place. So we can just ignore the error and continue.

Thanks! Applied!

> ---
> Changes since v3:
>  * Return negative error number.
> 
> Changes since v2:
>  * Fix indentation (spaces not tabs.)
> 
> Changes since v1:
>  * Log WDIOC_SETOPTIONS/WDIOS_ENABLECARD failure at debug level if
>ENOTTY is returned. Suggested by Lennart Poettering.
> 
>  src/shared/watchdog.c |9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> --- systemd.orig/src/shared/watchdog.c2015-06-17 18:11:23.056059315 
> +0200
> +++ systemd/src/shared/watchdog.c 2015-06-17 18:51:16.980269395 +0200
> @@ -60,8 +60,13 @@ static int update_timeout(void) {
>  
>  flags = WDIOS_ENABLECARD;
>  r = ioctl(watchdog_fd, WDIOC_SETOPTIONS, &flags);
> -if (r < 0)
> -return log_warning_errno(errno, "Failed to enable 
> hardware watchdog: %m");
> +if (r < 0) {
> +/* ENOTTY means the watchdog is always enabled so 
> we're fine */
> +log_full(errno == ENOTTY ? LOG_DEBUG : LOG_WARNING,
> + "Failed to enable hardware watchdog: %m");
> +if (errno != ENOTTY)
> +return -errno;
> +}
>  
>  r = ioctl(watchdog_fd, WDIOC_KEEPALIVE, 0);
>  if (r < 0)
> 
> 
> -- 
> Jean Delvare
> SUSE L3 Support
> 


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] systemd-resolved as dnsmasq replacement

[Igor Bukanov]

On 17 June 2015 at 15:27, Lennart Poettering  wrote:
> To hook up local name service
> clients people should use the "nss-resolve" NSS module, which ensures
> that gethostbyname() and friends use resolved as backend.

I suppose then non-glibc clients should deal with that on its own. I
thought converting LLMNR into DNS would be a reasonable hack, but then
if the translation requires too much insanity, then indeed it is
better not to do that.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-resolved as dnsmasq replacement

[Lennart Poettering]

On Wed, 17.06.15 19:48, Igor Bukanov (i...@mir2.org) wrote:

> On 17 June 2015 at 15:27, Lennart Poettering  wrote:
> > To hook up local name service
> > clients people should use the "nss-resolve" NSS module, which ensures
> > that gethostbyname() and friends use resolved as backend.
> 
> I suppose then non-glibc clients should deal with that on its own. I
> thought converting LLMNR into DNS would be a reasonable hack, but then
> if the translation requires too much insanity, then indeed it is
> better not to do that.

If people use libraries to do DNS manually, then they'll do *DNS*
manually, and we shouldn't interfere with that really.

Usually people pick non-libc DNS libraries because they need async
behaviour. I am pretty sure that's a pretty bad reason though and if
you want async behaviour you should use sd-resolve or so.

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 v4] watchdog: Don't require WDIOC_SETOPTIONS/WDIOS_ENABLECARD

[Jean Delvare]

On Wed, 17 Jun 2015 19:04:34 +0200, Lennart Poettering wrote:
> On Wed, 17.06.15 18:57, Jean Delvare (jdelv...@suse.de) wrote:
> 
> > Not all watchdog drivers implement WDIOC_SETOPTIONS. Drivers which do
> > not implement it have their device always enabled. So it's fine to
> > report an error if WDIOS_DISABLECARD is passed and the ioctl is not
> > implemented, however failing when WDIOS_ENABLECARD is passed and the
> > ioctl is not implemented is not good: if the device was already
> > enabled then WDIOS_ENABLECARD was a no-op and wasn't needed in the
> > first place. So we can just ignore the error and continue.
> 
> Thanks! Applied!

Thank you very much for the reviews and your patience.

-- 
Jean Delvare
SUSE L3 Support
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [survey] BTRFS_IOC_DEVICES_READY return status

[Goffredo Baroncelli]

On 2015-06-15 19:38, Lennart Poettering wrote:
> On Mon, 15.06.15 19:23, Goffredo Baroncelli (kreij...@inwind.it) wrote:
> 
>> On 2015-06-15 12:46, Lennart Poettering wrote:
>>> On Sat, 13.06.15 17:09, Goffredo Baroncelli (kreij...@libero.it) wrote:
>>>
> Further, the problem will be more intense in this eg. if you use dd
> and copy device A to device B. After you mount device A, by just
> providing device B in the above two commands you could let kernel
> update the device path, again all the IO (since device is mounted)
> are still going to the device A (not B), but /proc/self/mounts and
> 'btrfs fi show' shows it as device B (not A).
>
> Its a bug. very tricky to fix.

 In the past [*] I proposed a mount.btrfs helper . I tried to move the 
 logic outside the kernel.
 I think that the problem is that we try to manage all these cases
 from a device point of view: when a device appears, we register the
 device and we try to mount the filesystem... This works very well
 when there is 1-volume filesystem. For the other cases there is a
 mess between the different layers:
>>>
 - kernel
 - udev/systemd
 - initrd logic

 My attempt followed a different idea: the mount helper waits the
 devices if needed, or if it is the case it mounts the filesystem in
 degraded mode. All devices are passed as mount arguments
 (--device=/dev/sdX), there is no a device registration: this avoids
 all these problems.
>>>
>>> Hmm, no. /bin/mount should not block for devices. That's generally
>>> incompatible with how the tool is used, and in particular from
>>> systemd. We would not make use for such a scheme in
>>> systemd. /bin/mount should always be short-running.
>>
>> Apart systemd, which are these incompatibilities ? 
> 
> Well, /bin/mount is not a daemon, and it should not be one.

My helper is not a deamon; you was correct the first time: it blocks until all 
needed/enough devices are appeared.
Anyway this should not be different from mounting a nfs filesystem. Even in 
this case the mount helper blocks until the connection happened. The block time 
is not negligible, even tough not long as a device timeout ... 

> 
>>> I am pretty sure that if such automatic degraded mounting should be
>>> supported, then this should be done with some background storage
>>> daemon that alters the effect of the READY ioctl somehow after the
>>> timeout, and then retriggers the devcies so that systemd takes
>>> note. (or, alternatively: such a scheme could even be implemented all
>>> in kernel, based on some configurable kernel setting...)
>>
>> I recognize that this solution provides the maximum compatibility
>> with the current implementation. However it seems too complex to
>> me. Re-trigging a devices seems to me more a workaround than a
>> solution.
> 
> Well, it's not really ugly. I mean, if the state or properties of a
> device change, then udev should update its information about it, and
> that's done via a retrigger. We do that all the time already, for
> example when an existing loopback device gets a backing file assigned
> or removed. I am pretty sure that loopback case is very close to what
> you want to do here, hence retriggering (either from the kernel side,
> or from userspace), appears like an OK thing to do.

What seems strange to me is that in this case the devices don't have changed 
their status.
How this problem is managed in the md/dm raid cases ?

> 
>> Could a generator do this job ? I.e. this generator (or storage
>> daemon) waits that all (or enough) devices are appeared, then it
>> creates a .mount unit: do you think that it is doable ?
> 
> systemd generators are a way to extend the systemd unit dep tree with
> units. They are very short running, and are executed only very very
> early at boot. They cannot wait for anything, they don#t have access
> to devices and are not run when they are appear.
> 
> Lennart
> 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli 
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] machinectl status vs show

[Johannes Ernst]

In which case:

1. The man pages, to me, imply that I should be able to get everything that 
‘status' shows using ‘show' because it says:

"This function is intended to generate human-readable output. If you are 
looking for computer-parsable output, use show instead.” (and vice versa)

This sentence may need a revision.

2. So how do I get at the IP address of the container in a way that is easily 
parseable?

Cheers,


Johannes.


> On Jun 17, 2015, at 1:42, Lennart Poettering  wrote:
> 
> On Wed, 17.06.15 10:13, David Herrmann (dh.herrm...@gmail.com 
> ) wrote:
> 
>> Hi
>> 
>> On Wed, Jun 17, 2015 at 5:53 AM, Johannes Ernst
>>  wrote:
>>> Are those supposed to produce the same information, just formatted 
>>> differently (man vs machine per man page)?
>>> 
>>> I’m failing to convince ‘show’ to give me the container’s IP address, while 
>>> ‘status’ has all of them.
>> 
>> As with almost all *ctl tools in systemd, 'show' is used to print DBus
>> properties of the object in question. 'status' on the other hand
>> prints a human-readable, pre-selected set of attributes of an object.
>> 
>> With machinectl, the 'show' command must be used with a parameter. So
>> `machinectl --all show $machine` should contain the same information
>> as `machinectl status $machine`, and even more. If that's not the
>> case, please post an example.
> 
> Well, "machinectl status" also shows the cgroup tree, which
> "machinectl show" currently does not.
> 
> The IP addresses are not exposed as property, they are exposed
> as method, since acquiring them is relatively complex due to
> transitioning into the containers... That means they show up in
> "machinectl status", because that code explicitly calls that method,
> but not in "machinectl show" which shows the plain props, and nothing
> else.
> 
> Note that "systemctl show" and "systemctl status" have a similar
> relationship as "machinectl show" and "machinectl status".
> 
> 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] /etc/resolv.conf link in container

[Johannes Ernst]

> On Jun 17, 2015, at 1:07, David Herrmann  wrote:
> 
> Hi
> 
> On Tue, Jun 16, 2015 at 11:39 PM, Johannes Ernst
>  wrote:
>> I have a root filesystem in directory foo/
>> It has symlink
>>foo/etc/resolv.conf -> /run/systemd/resolve/resolv.conf
>> 
>> When I’m booting the container:
>>sudo systemd-nspawn --directory foo --boot
>> 
>> I’m getting:
>>Failed to copy /etc/resolv.conf to /home/…./foo/etc/resolv.conf: Too many 
>> levels of symbolic links
>> 
>> This message makes very little sense to me. Why is a copy necessary? and is 
>> that indeed /etc/resolv.conf or foo/etc/resolv.conf?
>> 
>> If I boot with -n, I don’t seem to get the error.
> 
> If you pass --private-network / -n, then we never touch resolv.conf.
> In all other cases, we copy resolv.conf from the host into the
> container. We usually assume that if your container runs in the same
> network as the host, then the container must also use the DNS features
> of the host.
> 
> The error code of "Too many levels of symbolic links" is ELOOP. This
> is returned by open() in many cases. In this example, it is returned
> because we passed O_NOFOLLOW to open(), but the final part of the path
> is a symlink. In that case, the kernel returns ELOOP to tell us that
> we're dealing with a symlink.
> 
> Maybe Lennart or Tom have some comments on that? Your example use-case
> (resolved in the container, even with shared network namespace) looks
> valid, though odd. I mean, what's the reason not to use "-n”?

Well, if there isn’t a reason, why does the mode exist?

> Anyway,
> maybe we can deal with ELOOP in setup_resolv_conf() and just print a
> big fat warning?
> But lets people who know that stuff comment first..
> 
> Thanks
> David

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

Re: [systemd-devel] [survey] BTRFS_IOC_DEVICES_READY return status

[Lennart Poettering]

On Wed, 17.06.15 21:10, Goffredo Baroncelli (kreij...@libero.it) wrote:

> > Well, /bin/mount is not a daemon, and it should not be one.
> 
> My helper is not a deamon; you was correct the first time: it blocks
> until all needed/enough devices are appeared.
> Anyway this should not be different from mounting a nfs
> filesystem. Even in this case the mount helper blocks until the
> connection happened. The block time is not negligible, even tough
> not long as a device timeout ...

Well, the mount tool doesn't wait for the network to be configured or
so. It just waits for a response from the server. That's quite a
difference.

> > Well, it's not really ugly. I mean, if the state or properties of a
> > device change, then udev should update its information about it, and
> > that's done via a retrigger. We do that all the time already, for
> > example when an existing loopback device gets a backing file assigned
> > or removed. I am pretty sure that loopback case is very close to what
> > you want to do here, hence retriggering (either from the kernel side,
> > or from userspace), appears like an OK thing to do.
> 
> What seems strange to me is that in this case the devices don't have changed 
> their status.
> How this problem is managed in the md/dm raid cases ?

md has a daemon mdmon to my knowledge.

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] machinectl status vs show

[Lennart Poettering]

On Wed, 17.06.15 13:34, Johannes Ernst (johannes.er...@gmail.com) wrote:

> In which case:
> 
> 1. The man pages, to me, imply that I should be able to get everything that 
> ‘status' shows using ‘show' because it says:
> 
> "This function is intended to generate human-readable output. If you are 
> looking for computer-parsable output, use show instead.” (and vice versa)
> 
> This sentence may need a revision.

Added to the TODO list

> 
> 2. So how do I get at the IP address of the container in a way that
> is easily parseable?

make sure "nss-mymachines" is installed and enabled (see its man page
for details). With that in place the container name is resolvable
using normal libc calls, i.e. "ping " will work then,
and all other commands too.

Use "getent hosts foobar" to resolve hostnames from the command line,
in a generic, parsable way. It will then work both for containers as
well as for any other kind of host name.

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] machinectl status vs show

[Johannes Ernst]

> On Jun 17, 2015, at 14:09, Lennart Poettering  wrote:
> 
> On Wed, 17.06.15 13:34, Johannes Ernst (johannes.er...@gmail.com) wrote:
> 
>> 2. So how do I get at the IP address of the container in a way that
>> is easily parseable?
> 
> make sure "nss-mymachines" is installed and enabled (see its man page
> for details). With that in place the container name is resolvable
> using normal libc calls, i.e. "ping " will work then,
> and all other commands too.
> 
> Use "getent hosts foobar" to resolve hostnames from the command line,
> in a generic, parsable way. It will then work both for containers as
> well as for any other kind of host name.

Duh. In hindsight, that’s sort of obvious, sorry for missing it.

[[Meta-comment: I’m finding that systemd is a rather amazing set of 
technologies, doing much more than is generally known. It’s all very nicely 
integrated, too, BUT: for somebody like me who doesn’t live on the inside of 
the project, it's not obvious how things fit together or are intended to be 
used, so they ask silly questions on the mailing list like I have been doing.

I wonder whether one of the Linux magazines would be interested in doing a 
“following systemd” kind of regular piece in which they would go through one 
use case after another with full shell transcripts, depending on what’s new 
this month. Or does that exist already?]]



Thanks for the help,


Johannes.

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

Re: [systemd-devel] systemd-resolved as dnsmasq replacement

[Daurnimator]

On 18 Jun 2015 3:51 am, "Lennart Poettering"  wrote:
>
> On Wed, 17.06.15 19:48, Igor Bukanov (i...@mir2.org) wrote:
>
> > On 17 June 2015 at 15:27, Lennart Poettering 
wrote:
> > > To hook up local name service
> > > clients people should use the "nss-resolve" NSS module, which ensures
> > > that gethostbyname() and friends use resolved as backend.
> >
> > I suppose then non-glibc clients should deal with that on its own. I
> > thought converting LLMNR into DNS would be a reasonable hack, but then
> > if the translation requires too much insanity, then indeed it is
> > better not to do that.
>
> If people use libraries to do DNS manually, then they'll do *DNS*
> manually, and we shouldn't interfere with that really.
>
> Usually people pick non-libc DNS libraries because they need async
> behaviour. I am pretty sure that's a pretty bad reason though and if
> you want async behaviour you should use sd-resolve or so.

I've also used them because I
  - need other record types (e.g. SRV)
  - want to use DNSSEC
  - Want to choose between recursive and stub resolvers

FWIW, I use http://25thandclement.com/~william/projects/dns.c.html in many
projects.
It parses nsswitch.conf, but only cares about a few predetermined values.
Maybe it should gain some features in this area?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] zsh-completion: fix completion of --user services

[Eric Cook]

On 06/17/2015 12:34 PM, Lennart Poettering wrote:
> On Mon, 18.05.15 18:45, Eric Cook (l...@gmx.com) wrote:
> 
>> By the time __systemctl is called, --user/--system are shifted out of
>> `words' by _arguments. This patch queries the array sooner. 
>>
>> In the case that both --user and --system are on the line when compsys runs,
>> _sys_service_mgr is set to the latter. Which is seemingly how systemctl 
>> behaves.
>>
>> If neither are on the line, --system is set; for system services to be 
>> completed.
> 
> Is this still an issue? If so, could you post this patch as a PR on
> github for review?
> 
> Lennart
> 
It was submitted on github and merged a while ago. So no, but thank you for 
checking up on it.
https://github.com/systemd/systemd/commit/68c4f6d406a2bdac6957a67a077f182b0287cc3b
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [survey] BTRFS_IOC_DEVICES_READY return status

[Andrei Borzenkov]

В Wed, 17 Jun 2015 23:02:02 +0200
Lennart Poettering  пишет:

> On Wed, 17.06.15 21:10, Goffredo Baroncelli (kreij...@libero.it) wrote:
> 
> > > Well, /bin/mount is not a daemon, and it should not be one.
> > 
> > My helper is not a deamon; you was correct the first time: it blocks
> > until all needed/enough devices are appeared.
> > Anyway this should not be different from mounting a nfs
> > filesystem. Even in this case the mount helper blocks until the
> > connection happened. The block time is not negligible, even tough
> > not long as a device timeout ...
> 
> Well, the mount tool doesn't wait for the network to be configured or
> so. It just waits for a response from the server. That's quite a
> difference.
> 
> > > Well, it's not really ugly. I mean, if the state or properties of a
> > > device change, then udev should update its information about it, and
> > > that's done via a retrigger. We do that all the time already, for
> > > example when an existing loopback device gets a backing file assigned
> > > or removed. I am pretty sure that loopback case is very close to what
> > > you want to do here, hence retriggering (either from the kernel side,
> > > or from userspace), appears like an OK thing to do.
> > 
> > What seems strange to me is that in this case the devices don't have 
> > changed their status.
> > How this problem is managed in the md/dm raid cases ?
> 
> md has a daemon mdmon to my knowledge.
> 

No, mdmon does something different. What mdadm does is to start timer
when RAID is complete enough to be started in degraded mode. If
notifications for missing devices appear after that, RAID is started
normally. If no notification appears until timer is expired, RAID is
started in degraded mode. 

ACTION=="add|change", IMPORT{program}="BINDIR/mdadm --incremental --export 
$devnode --offroot ${DEVLINKS}"
ACTION=="add|change", ENV{MD_STARTED}=="*unsafe*", ENV{MD_FOREIGN}=="no", 
ENV{SYSTEMD_WANTS}+="mdadm-last-resort@$env{MD_DEVICE}.timer"

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