Re: [systemd-devel] systemd-resolved as dnsmasq replacement
On 17 June 2015 at 15:27, Lennart Poettering lenn...@poettering.net 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] [survey] BTRFS_IOC_DEVICES_READY return status
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 kreijackATinwind.it 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] [PATCH v4] watchdog: Don't require WDIOC_SETOPTIONS/WDIOS_ENABLECARD
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] systemd-resolved as dnsmasq replacement
On Wed, 17.06.15 19:48, Igor Bukanov (i...@mir2.org) wrote: On 17 June 2015 at 15:27, Lennart Poettering lenn...@poettering.net 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] systemd-resolved as dnsmasq replacement
On 18 Jun 2015 3:51 am, Lennart Poettering lenn...@poettering.net wrote: On Wed, 17.06.15 19:48, Igor Bukanov (i...@mir2.org) wrote: On 17 June 2015 at 15:27, Lennart Poettering lenn...@poettering.net 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] machinectl status vs show
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 lenn...@poettering.net wrote: On Wed, 17.06.15 10:13, David Herrmann (dh.herrm...@gmail.com mailto:dh.herrm...@gmail.com) wrote: Hi On Wed, Jun 17, 2015 at 5:53 AM, Johannes Ernst johannes.er...@gmail.com 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
On Jun 17, 2015, at 1:07, David Herrmann dh.herrm...@gmail.com wrote: Hi On Tue, Jun 16, 2015 at 11:39 PM, Johannes Ernst johannes.er...@gmail.com 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] machinectl status vs show
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 containername 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
On Jun 17, 2015, at 14:09, Lennart Poettering lenn...@poettering.net 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 containername 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?]] /musing out loud 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] [survey] BTRFS_IOC_DEVICES_READY return status
В Wed, 17 Jun 2015 23:02:02 +0200
Lennart Poettering lenn...@poettering.net пишет:
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
Re: [systemd-devel] [PATCH] zsh-completion: fix completion of --user services
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
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] [PATCH v2] watchdog: Don't require WDIOC_SETOPTIONS/WDIOS_ENABLECARD
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] [PATCH] improve systemctl daemon-reexec and daemon-reload documentation
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 thomas.bl...@suse.com
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
termcommanddaemon-reload/command/term
listitem
-paraReload systemd manager configuration. This will
+paraReload systemd manager client configuration. This will
rerun all generators (see
citerefentryrefentrytitlesystemd.generator/refentrytitlemanvolnum7/manvolnum/citerefentry),
reload all unit files, and recreate the entire dependency
@@ -1385,9 +1385,9 @@ kobject-uevent 1 systemd-udevd-kernel.socket
systemd-udevd.service
listitem
paraReexecute 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 commanddaemon-reload/command.
+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
commanddaemon-reload/command.
While the daemon is being reexecuted, all sockets systemd
listening
on behalf of user configuration will stay accessible.
/para
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] Why we need to read/save random seed?
2015-06-17 16:40 GMT+08:00 Reindl Harald h.rei...@thelounge.net: Am 17.06.2015 um 05:06 schrieb cee1: 2015-06-16 0:21 GMT+08:00 Lennart Poettering lenn...@poettering.net: 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?
Am 17.06.2015 um 14:21 schrieb cee1: 2015-06-17 16:40 GMT+08:00 Reindl Harald h.rei...@thelounge.net: 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] nspawn --ephemeral
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 johannes.er...@gmail.com 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 lenn...@poettering.net 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] [PATCH] improve systemctl daemon-reexec and daemon-reload documentation
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] machinectl status vs show
Hi On Wed, Jun 17, 2015 at 5:53 AM, Johannes Ernst johannes.er...@gmail.com 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] sd-bus vs glib object path node hierarchy
Hi On Tue, Jun 16, 2015 at 11:32 PM, Lennart Poettering lenn...@poettering.net 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] [PATCH 4/5] import/pull: Tag replaced with reference
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 podv...@redhat.com wrote:
Signed-off-by: Pavel Odvody podv...@redhat.com
---
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 podv...@redhat.com
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] /etc/resolv.conf link in container
Hi On Tue, Jun 16, 2015 at 11:39 PM, Johannes Ernst johannes.er...@gmail.com 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] Can kdbus send signal to the source connection?
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 dh.herrm...@gmail.com wrote: Hi On Tue, Jun 16, 2015 at 12:07 PM, eshark eshar...@163.com wrote: At 2015-06-16 15:54:10, David Herrmann dh.herrm...@gmail.com 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_bus_broadc // if (conn_dst-id == kmsg-msg.src_id) //continue; Does everything work perfectly well without kdbus? As for network, it did work well without my patch. Is the missing DHCP connectivity the only difference you see with kdbus? Acctually, I cannot connet to the device by adb. But I did run netcfg in the terminal, and eth0 didn't get ip as before. What kdbus version do you run? kdbus-4.1-rc1 What kdbus tree do you use? https://git.kernel.org/cgit/linux/kernel/git/gregkh/char-misc.git/ What systemd version do you use? (in case of git: which commit?) systemd v219 commit: d736e4f3e76daca4ab1b1fc444737e5ee20a27cd Did you pass --enable-kdbus to systemd? Yes , I did. What upstream kernel version do you use? 3.10.33, we back-ported the kdbus to our kernel. Any obscure messages in the system-log that you didn't see before? From dmesg , I can see that the systemd process calls kdbus_bus_broadcast() endlessly, and the condition if (conn_dst-id == kmsg-msg.src_id) is always true. It seems that when booting, the systemd process enters a dead loop by sending some signal to the source connection. So , systemd cannot boot any service , including network. Thanks! Li Cheng ... Please try to paste as much information as possible. Otherwise, it's really a hassle to ask for each piece of information separately. 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
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 johannes.er...@gmail.com 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] [PATCH v2] watchdog: Don't require WDIOC_SETOPTIONS/WDIOS_ENABLECARD
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
[systemd-devel] [PATCH v2] watchdog: Don't require WDIOC_SETOPTIONS/WDIOS_ENABLECARD
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
Re: [systemd-devel] Why we need to read/save random seed?
Am 17.06.2015 um 05:06 schrieb cee1: 2015-06-16 0:21 GMT+08:00 Lennart Poettering lenn...@poettering.net: 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] Can kdbus send signal to the source connection?
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 eshar...@163.com 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 dh.herrm...@gmail.com wrote: Hi On Tue, Jun 16, 2015 at 12:07 PM, eshark eshar...@163.com wrote: At 2015-06-16 15:54:10, David Herrmann dh.herrm...@gmail.com 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
[systemd-devel] [PATCH] improve systemctl daemon-reexec and daemon-reload documentation
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 thomas.bl...@suse.com
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
termcommanddaemon-reload/command/term
listitem
-paraReload systemd manager configuration. This will
+paraReload systemd manager client configuration. This will
rerun all generators (see
citerefentryrefentrytitlesystemd.generator/refentrytitlemanvolnum7/manvolnum/citerefentry),
reload all unit files, and recreate the entire dependency
@@ -1385,9 +1385,9 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
listitem
paraReexecute 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 commanddaemon-reload/command.
+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 commanddaemon-reload/command.
While the daemon is being reexecuted, all sockets systemd listening
on behalf of user configuration will stay accessible.
/para
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] Why we need to read/save random seed?
On Wed, Jun 17, 2015 at 2:28 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 17.06.2015 um 14:21 schrieb cee1: 2015-06-17 16:40 GMT+08:00 Reindl Harald h.rei...@thelounge.net: 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
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
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
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
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?
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?
On Wed, 17.06.15 20:21, cee1 (fykc...@gmail.com) wrote: 2015-06-17 16:40 GMT+08:00 Reindl Harald h.rei...@thelounge.net: Am 17.06.2015 um 05:06 schrieb cee1: 2015-06-16 0:21 GMT+08:00 Lennart Poettering lenn...@poettering.net: 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?
Am 17.06.2015 um 14:51 schrieb Kay Sievers: On Wed, Jun 17, 2015 at 2:28 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 17.06.2015 um 14:21 schrieb cee1: 2015-06-17 16:40 GMT+08:00 Reindl Harald h.rei...@thelounge.net: 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?
2015-06-17 22:03 GMT+08:00 Lennart Poettering lenn...@poettering.net: 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?
On Wed, 17.06.15 23:08, cee1 (fykc...@gmail.com) wrote: 2015-06-17 22:03 GMT+08:00 Lennart Poettering lenn...@poettering.net: 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
[systemd-devel] [PATCH v4] watchdog: Don't require WDIOC_SETOPTIONS/WDIOS_ENABLECARD
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
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] [PATCH v2] selinux: fix missing SELinux unit access check
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 d.hatay...@jp.fujitsu.com
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
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 libmount.h, 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] Why we need to read/save random seed?
2015-06-17 23:15 GMT+08:00 Lennart Poettering lenn...@poettering.net: 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
Re: [systemd-devel] Why we need to read/save random seed?
2015-06-17 23:38 GMT+08:00 Reindl Harald h.rei...@thelounge.net: Am 17.06.2015 um 17:08 schrieb cee1: 2015-06-17 22:03 GMT+08:00 Lennart Poettering lenn...@poettering.net: 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
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] [PATCH v3] watchdog: Don't require WDIOC_SETOPTIONS/WDIOS_ENABLECARD
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
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
[systemd-devel] [PATCH v3] watchdog: Don't require WDIOC_SETOPTIONS/WDIOS_ENABLECARD
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?
B1;4002;0cOn Wed, 17.06.15 23:45, cee1 (fykc...@gmail.com) wrote: 2015-06-17 23:15 GMT+08:00 Lennart Poettering lenn...@poettering.net: 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?
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
