Re: [systemd-devel] order of sd_journal_query_unique()?
On Fri, Mar 6, 2015 at 6:45 PM, Daurnimator q...@daurnimator.com wrote: On 6 March 2015 at 16:13, Chris Morgan chmor...@gmail.com wrote: So is SD_JOURNAL_FOREACH_BACKWARDS the fastest way to find the newest journal entry with a given field? journalctl seems a ton faster than my c application is when I search for a given field that is not present. And by search I'm doing: journalctl --user BLAH=1 Chris To find the newest journal entry: - sd_journal_seek_tail - sd_journal_add_match and similar to add criteria - sd_journal_previous Yes, this looks much more efficient. Thank you. Chris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] adjust for time spent in timedated even without dbus timestamp
it is trivial to fall back to our own timestamp v2: use now() --- src/timedate/timedated.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c index 88d57e9..75b1f1b 100644 --- a/src/timedate/timedated.c +++ b/src/timedate/timedated.c @@ -551,6 +551,9 @@ static int method_set_time(sd_bus *bus, sd_bus_message *m, void *userdata, sd_bu if (c-use_ntp) return sd_bus_error_setf(error, BUS_ERROR_AUTOMATIC_TIME_SYNC_ENABLED, Automatic time synchronization is enabled); +/* this only gets used if dbus does not provide a timestamp */ +start = now(CLOCK_MONOTONIC); + r = sd_bus_message_read(m, xbb, utc, relative, interactive); if (r 0) return r; @@ -592,7 +595,7 @@ static int method_set_time(sd_bus *bus, sd_bus_message *m, void *userdata, sd_bu r = sd_bus_message_get_monotonic_usec(m, start); if (r 0 r != -ENODATA) return r; -if (r = 0) +if (r = 0 || r == -ENODATA) timespec_store(ts, timespec_load(ts) + (now(CLOCK_MONOTONIC) - start)); /* Set system clock */ -- 2.2.1.209.g41e5f3a ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] po: update French translation
--- po/fr.po | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/po/fr.po b/po/fr.po index 1cd4b55..b3b17ce 100644 --- a/po/fr.po +++ b/po/fr.po @@ -7,7 +7,7 @@ msgid msgstr Project-Id-Version: systemd\n Report-Msgid-Bugs-To: \n -POT-Creation-Date: 2015-02-18 19:48+0100\n +POT-Creation-Date: 2015-03-06 21:16+0100\n PO-Revision-Date: 2014-12-28 13:04+0100\n Last-Translator: Sylvain Plantefève sylvain.plantef...@gmail.com\n Language-Team: French\n @@ -97,10 +97,20 @@ msgstr Authentification requise pour définir les informations sur la machine locale. #: ../src/import/org.freedesktop.import1.policy.in.h:1 +msgid Import a VM or container image +msgstr Importer une image de machine virtuelle (VM) ou de conteneur + +#: ../src/import/org.freedesktop.import1.policy.in.h:2 +msgid Authentication is required to import a VM or container image +msgstr +Authentification requise pour importer une image de machine virtuelle +(VM) ou de conteneur. + +#: ../src/import/org.freedesktop.import1.policy.in.h:3 msgid Download a VM or container image msgstr Télécharger une image de machine virtuelle (VM) ou de conteneur -#: ../src/import/org.freedesktop.import1.policy.in.h:2 +#: ../src/import/org.freedesktop.import1.policy.in.h:4 msgid Authentication is required to download a VM or container image msgstr Authentification requise pour télécharger une image de machine virtuelle -- 2.1.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] sd_journal_add_match if not using the form of FIELD=value
http://www.freedesktop.org/software/systemd/man/sd_journal_add_match.html is pretty clear that the matches are in the form of 'FIELD=value' but it doesn't mention the why. What if I've written a field like FIELD, can I then match on it as FIELD? I presume that sd_journal_add_match is doing an identical value match that would preclude searching for FIELD=value using just FIELD? Chris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] adjust for time spent in timedated even without dbus timestamp
On Fri, Mar 06, 2015 at 05:22:22PM -0800, Shawn Landden wrote: it is trivial to fall back to our own timestamp v2: use now() --- src/timedate/timedated.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c index 88d57e9..75b1f1b 100644 --- a/src/timedate/timedated.c +++ b/src/timedate/timedated.c @@ -551,6 +551,9 @@ static int method_set_time(sd_bus *bus, sd_bus_message *m, void *userdata, sd_bu if (c-use_ntp) return sd_bus_error_setf(error, BUS_ERROR_AUTOMATIC_TIME_SYNC_ENABLED, Automatic time synchronization is enabled); +/* this only gets used if dbus does not provide a timestamp */ +start = now(CLOCK_MONOTONIC); + r = sd_bus_message_read(m, xbb, utc, relative, interactive); if (r 0) return r; @@ -592,7 +595,7 @@ static int method_set_time(sd_bus *bus, sd_bus_message *m, void *userdata, sd_bu r = sd_bus_message_get_monotonic_usec(m, start); if (r 0 r != -ENODATA) return r; -if (r = 0) +if (r = 0 || r == -ENODATA) Isn't this condition always true if reached? timespec_store(ts, timespec_load(ts) + (now(CLOCK_MONOTONIC) - start)); /* Set system clock */ -- 2.2.1.209.g41e5f3a ___ 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] Notification socket and chroot vs PrivateNetwork conflict (abstract vs file-system)
On 9 December 2014 at 17:28, Lennart Poettering lenn...@poettering.net wrote: On Tue, 09.12.14 16:24, Krzysztof Kotlenga (k.kotle...@sims.pl) wrote: Hi. Currently notify socket is unavailable in chrooted services (again) unless you bind mount it there. Is there perhaps another, less cumbersome way? So far notify socket was: 1. abstract socket commit 8c47c7325fa1ab72febf807f8831ff24c75fbf45 notify: add minimal readiness/status protocol for spawned daemons 2. file-system socket commit 91b22f21f3824c1766d34f622c5bbb70cbe881a8 core: move abstract namespace sockets to /dev/.run Now that we have /dev/.run there's no need to use abstract namespace sockets. So, let's move things to /dev/.run, to make things more easily discoverable and improve compat with chroot() and fs namespacing. 3. abstract socket again commit 29252e9e5bad3b0bcfc45d9bc761aee4b0ece1da manager: turn notify socket into abstract namespace socket again sd_notify() should work for daemons that chroot() as part of their initilization, hence it's a good idea to use an abstract namespace socket which is not affected by chroot. 4. file-system socket again commit 7181dbdb2e3112858d62bdaea4f0ad2ed685ccba core: move notify sockets to /run and $XDG_RUNTIME_DIR A service with PrivateNetwork= cannot access abstract namespace sockets of the host anymore, hence let's better not use abstract namespace sockets for this, since we want to make sure that PrivateNetwork= is useful and doesn't break sd_notify(). So... would it be acceptable to have two notify sockets, one abstract and one normal, the latter only set for services with PrivateNetwork or - better maybe - explicitly selectable? Any other ideas? Hmm, but what would you do for a service that has both PrivateNetwork and chroot enabled? I am all open for shifting things around again, but I inda would prefer a solution that works universally in the end... Ideas? I figure we could open a new mount namespace and mount the file system socket into the chroot, but not sure I like the idea... Maybe that's the way to do it... but where would you bind mount the socket file? in $CHROOT/tmp which should be writeable when PrivateTmp=true? Of course it will not work if the daemon is doing the chroot itself instead of relying on systemd's RootDirectory. The same problem exists even without using PrivateNetwork/RootDirectory when the service starts a container with nspawn --private-network and the program inside the container wants to notify when it's ready. This has the same root cause: the service runs in a new mount/chroot and a new network namespace. There is also the additional problem that the program inside the container runs in a different cgroup (/system.slice/docker-... for docker containers, or /machine.slice... for nspawn containers). There is the tool sdnotify-proxy to proxy the notify socket from systemd to a socket file which can be bind mounted in the container. sdnotify-proxy works, but I would like to know if someone finds a better way for containers :) Alban ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] order of sd_journal_query_unique()?
On 6 March 2015 at 16:13, Chris Morgan chmor...@gmail.com wrote: So is SD_JOURNAL_FOREACH_BACKWARDS the fastest way to find the newest journal entry with a given field? journalctl seems a ton faster than my c application is when I search for a given field that is not present. And by search I'm doing: journalctl --user BLAH=1 Chris To find the newest journal entry: - sd_journal_seek_tail - sd_journal_add_match and similar to add criteria - sd_journal_previous ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] po: update French translation
On Sat, Mar 07, 2015 at 12:56:46AM +0100, Sylvain Plantefève wrote: --- po/fr.po | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] adjust for time spent in timedated even without dbus timestamp
it is trivial to fall back to our own timestamp --- src/timedate/timedated.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c index 88d57e9..7e47348 100644 --- a/src/timedate/timedated.c +++ b/src/timedate/timedated.c @@ -551,6 +551,13 @@ static int method_set_time(sd_bus *bus, sd_bus_message *m, void *userdata, sd_bu if (c-use_ntp) return sd_bus_error_setf(error, BUS_ERROR_AUTOMATIC_TIME_SYNC_ENABLED, Automatic time synchronization is enabled); +/* this only gets used if dbus does not provide a timestamp + * (and ts gets overriden below) */ +r = clock_gettime(CLOCK_MONOTONIC, ts); +if (r 0) +return -errno; +start = timespec_load(ts); + r = sd_bus_message_read(m, xbb, utc, relative, interactive); if (r 0) return r; @@ -592,7 +599,7 @@ static int method_set_time(sd_bus *bus, sd_bus_message *m, void *userdata, sd_bu r = sd_bus_message_get_monotonic_usec(m, start); if (r 0 r != -ENODATA) return r; -if (r = 0) +if (r = 0 || r == -ENODATA) timespec_store(ts, timespec_load(ts) + (now(CLOCK_MONOTONIC) - start)); /* Set system clock */ -- 2.2.1.209.g41e5f3a ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] is there a plan for NIC teaming support ?
2015-03-06 7:09 GMT+03:00 Andrei Borzenkov arvidj...@gmail.com: Linux bonding driver supports LACP (mode 4) As i understand user can't use LACP because it switches does not support it. -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Possible bug when a dummy service declares After= and/or Conflicts= a .mount unit?
2015-03-06 11:20 GMT+01:00 Didier Roche didro...@ubuntu.com: It seems like tmp.mount unit was skipped as nothing declared any explicit dependency against it. What seems to confirm this is that if I add any enabled foo.service which declares After=tmp.mount, or if I add the After= statement to systemd-timesync.service, then I get tmp.mount reliably to start (and it was installed as the journal shows up). Does it make sense? I do have several units which have PrivateTmp=true (cups.service, timesyncd) which *are* started during boot, yet tmp.mount is not being activated. Inspecting the units via systemctl shows e.g. $ systemctl show cups.service -p After -p Requires Requires=basic.target cups.socket -.mount tmp.mount After=cups.socket -.mount system.slice tmp.mount basic.target cups.path systemd-journald.socket Why is tmp.mount then not reliably activated during boot here? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] use dolt.m4 to speedup compilation
On 06.03.2015 01:58, j...@joshtriplett.org wrote: On Fri, Mar 06, 2015 at 12:55:38AM +0100, Michael Biebl wrote: 2015-03-05 11:58 GMT+01:00 har...@redhat.com: From: Harald Hoyer har...@redhat.com The speedup is significant Original libtool $ ccache -C make clean time make -j4 […] real6m4.104s user13m49.234s sys7m37.864s Original libtool + dolt $ ccache -C make clean time make -j4 […] real2m24.869s user7m30.198s sys1m17.813s Hm, the speedup is nowhere near as significant here: without dolt (make): real 4m2.749s user 3m9.304s sys 0m19.032s with dolt (make): real 3m33.756s user 2m59.476s sys 0m17.632s without dolt (make -j6): real 1m42.001s user 5m3.680s sys 0m26.608s with dolt (make -j6) real 1m35.267s user 4m50.956s sys 0m24.724s libtool version is 2.4.2. That's more what I'd expect with current versions of libtool, which has supposedly fixed many of the issues that motivated the creation of dolt in the first place. See https://harald.hoyer.xyz/2015/03/05/libtool-getting-rid-of-18-sed-forks/ to find out about the culprit and a libtool fix. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] vconsole: match on vtcon events, not fbcon ones
Hi On Tue, Feb 24, 2015 at 5:49 PM, Jan Engelhardt jeng...@inai.de wrote: I observe that upon loading of framebuffer drivers, I do not get the desired system font, but the kernel-level defaults (usually lib/fonts/font_8x16.c, but your mileage may vary depending on kernel config and boot options). The fbcon driver may be loaded at a time way before the first framebuffer device is active, such that the vconsole setup helper runs too early. The existing rule is non-fitting. The going live of the fbcon kernel component does not indicate the proper time at which to load the visuals, which really ought to be done when a new vtcon object comes into existence. (The font table is a per-vtcon property.) --- src/vconsole/90-vconsole.rules.in | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) Looks good, applied! Thanks David diff --git a/src/vconsole/90-vconsole.rules.in b/src/vconsole/90-vconsole.rules.in index 0620096..35b9ad5 100644 --- a/src/vconsole/90-vconsole.rules.in +++ b/src/vconsole/90-vconsole.rules.in @@ -5,7 +5,6 @@ # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. -# Kernel resets vconsole state when changing console drivers so run -# systemd-vconsole-setup when fbcon loads - -ACTION==add, SUBSYSTEM==graphics, KERNEL==fbcon, RUN+=@rootlibexecdir@/systemd-vconsole-setup +# Each vtcon keeps its own state of fonts. +# +ACTION==add, SUBSYSTEM==vtconsole, KERNEL==vtcon*, RUN+=@rootlibexecdir@/systemd-vconsole-setup -- 2.1.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd --test fails
Hi, for debugging an ordering cycle during boot I tried to run systemd --test --system --unit=multi-user.target --log-level=debug as user (as it doesn't work as root). The result is just: systemd 210 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX -IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP +APPARMOR) Detected architecture 'x86-64'. Failed to set hostname to wirth: Operation not permitted Failed to open /dev/tty0: Permission denied Using cgroup controller name=systemd. File system hierarchy is at /sys/fs/cgroup/systemd/user.slice/user-0.slice/session-2.scope. Release agent already installed. Failed to create root cgroup hierarchy: Permission denied Failed to allocate manager object: Permission denied With --used the two Failed lines disappear, but nothing else is shown. This is a SLES 12 system. Any idea what I'm doing wrong? What permissions does the user need to run the test mode? Adding him to the root group didn't suffice. Thanks! cu, Frank -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. BioinformatikMail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr. 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: +49 89 2180-99-4049 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. * ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] SELinux labels on unix sockets
Hello, when systemd creates a socket file, it explicitly calls a selinux procedure to label it. I don't think that is needed, as the kernel does the right thing when the socket is created. Am I missing something? Why is the explicit labeling in place? Cheers, -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] doc: replace 'reply_cookie' with 'cookie_reply'
diff --git a/doc/kdbus.message.xml b/doc/kdbus.message.xml
index c25000d..5e7c7a3 100644
--- a/doc/kdbus.message.xml
+++ b/doc/kdbus.message.xml
@@ -393,7 +393,7 @@ struct kdbus_msg {
For a message to be accepted as reply, it must be a direct
message to the original sender (not a broadcast and not a
signal message), and its
- varnamekdbus_msg.reply_cookie/varname must match the
+ varnamekdbus_msg.cookie_reply/varname must match the
previous message's varnamekdbus_msg.cookie/varname.
/parapara
Expected replies also temporarily open the policy of the
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] doc: replace 'reply_cookie' with 'cookie_reply'
Hi
On Fri, Mar 6, 2015 at 2:28 PM, Lukasz Skalski l.skal...@samsung.com wrote:
diff --git a/doc/kdbus.message.xml b/doc/kdbus.message.xml
index c25000d..5e7c7a3 100644
--- a/doc/kdbus.message.xml
+++ b/doc/kdbus.message.xml
@@ -393,7 +393,7 @@ struct kdbus_msg {
For a message to be accepted as reply, it must be a direct
message to the original sender (not a broadcast and not a
signal message), and its
- varnamekdbus_msg.reply_cookie/varname must match the
+ varnamekdbus_msg.cookie_reply/varname must match the
Looks good, but we need a signed-off-by for kernel patches.
Thanks
David
previous message's varnamekdbus_msg.cookie/varname.
/parapara
Expected replies also temporarily open the policy of the
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SELinux labels on unix sockets
On Fri, 06.03.15 13:04, Jan Synáček (jsyna...@redhat.com) wrote: Hello, when systemd creates a socket file, it explicitly calls a selinux procedure to label it. I don't think that is needed, as the kernel does the right thing when the socket is created. Am I missing something? Why is the explicit labeling in place? Well, it's complicated. If we use socket activation we label a socket taking into account the label of the binary that is eventually started for it. And then, for file system sockets the kernel could traditionally only derive the label to use from the directory the socket was created in, which makes it difficult to have multiple sockets in the same directory with different labels, which is pretty frequently done though. That said, I think this limitation was lifted a while back in the kernel, and the policy can now also take the socket file name into consideration and derive different labels automatically. Ultimately, I only superficially understand the selinux code. We rely on patches from Dan co to keep it up-to-date. Better keep him in the loop. 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] doc: replace 'reply_cookie' with 'cookie_reply'
Signed-off-by: Lukasz Skalski l.skal...@samsung.com
diff --git a/doc/kdbus.message.xml b/doc/kdbus.message.xml
index c25000d..5e7c7a3 100644
--- a/doc/kdbus.message.xml
+++ b/doc/kdbus.message.xml
@@ -393,7 +393,7 @@ struct kdbus_msg {
For a message to be accepted as reply, it must be a direct
message to the original sender (not a broadcast and not a
signal message), and its
- varnamekdbus_msg.reply_cookie/varname must match the
+ varnamekdbus_msg.cookie_reply/varname must match the
previous message's varnamekdbus_msg.cookie/varname.
/parapara
Expected replies also temporarily open the policy of the
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind: lid switch action not executed on small open/close delays
Hi On Wed, Jan 28, 2015 at 8:31 PM, Lennart Poettering lenn...@poettering.net wrote: On Sat, 17.01.15 18:36, David Herrmann (dh.herrm...@gmail.com) wrote: I think it's reasonable to allow setting the base-timeout in /etc/systemd/logind.conf, but I want to know Lennart's opinion first. Preferably, this timeout was a kernel-timeout on the bus-probe itself. But we don't have anything like this, so we need the excessive timeouts in user-space as we cannot know whether we're just scheduled late or whether the bus-probe really takes that long... Meh... My system takes 5s to boot, so I could easily set those timeouts to 10s and everything would be fine. And I also don't care for hotplug changes while the system is off/suspended, hence, I could even disable the timeout and everything would just work. Not really sure how to proceed... I think making the timeout configurable in logind.conf would be OK. Done. http://cgit.freedesktop.org/systemd/systemd/commit/?id=9d10cbee89ca7f82d29b9cb27bef11e23e3803ba Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] doc: replace 'reply_cookie' with 'cookie_reply'
Hi
On Fri, Mar 6, 2015 at 2:48 PM, Lukasz Skalski l.skal...@samsung.com wrote:
Signed-off-by: Lukasz Skalski l.skal...@samsung.com
Applied!
Thanks
David
diff --git a/doc/kdbus.message.xml b/doc/kdbus.message.xml
index c25000d..5e7c7a3 100644
--- a/doc/kdbus.message.xml
+++ b/doc/kdbus.message.xml
@@ -393,7 +393,7 @@ struct kdbus_msg {
For a message to be accepted as reply, it must be a direct
message to the original sender (not a broadcast and not a
signal message), and its
- varnamekdbus_msg.reply_cookie/varname must match the
+ varnamekdbus_msg.cookie_reply/varname must match the
previous message's varnamekdbus_msg.cookie/varname.
/parapara
Expected replies also temporarily open the policy of the
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] Add option to enable COW for journal file
On Thu, 05.03.15 21:39, Goffredo Baroncelli (kreij...@libero.it) wrote: Hi All, the enclosed patches add an option to the journald.conf file to allow a COW behavior for the journal files. The commit 11689d2a force the NOCOW flag of the journal files. This was needed because systemd-journald has very poor performance when the filesytem is BTRFS due to its the COW behavior. However removing the COW behavior, the journal file also lost the btrfs checksum protection, and this disables the BTRFS capability to rebuild a corrupted file [1] in a RAID filesystem. So this limits one of the biggest benefit of BTRFS. This patch adds the option CowJournal to the journald.conf to disable/enable the NOCOW flag for the journal file, allowing to revert to the old behavior. These patches are tagged as RFC, because I am not sure about the naming of the option (now CowJournal). I ask some feedback. I am pretty strongly against adding an explicit option for this. I consider this all a temporary stopgap, until btrfs's autodefrag makes the problem go away, and I am very conservative with adding new config options where it is already clear that they will eventually be useless. What I'd be open to is: a) beef up the tmpfiles logic to be able to do the equivalent of /usr/bin/chattr on files. (By adding a new line type, make h or so). b) remove all code that sets NOCOW explicitly on journal files from journald. c) instead ship a tmpfiles snippet making use of a) that sets the NOCOW flag for /var/lib/journal, which results in the flag being inherited by journal files that are created within it. If people then want to opt-out of NOCOW, they can simply override the tmpfiles snippet and all is good. That way we have a way to configure the bit, without actually introducing a high-level config option for this. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] DBus api of systemd user instance
Hey List, Does the user instance of systemd expose a dbus api? If yes, how does one access it? Sincerely, Ragnar Thomsen rthoms...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 0/1] details for starting nfs-idmapd also on clients
Hello, On 03/06/2015 06:15 AM, Martin Pitt wrote: Hello all, Steve Langasek pointed out in [1] that idmapd is also necessary on the client side. It isn't for my very simple NFSv4 test, but then again I don't know that much about the various other modes of operation. This patch starts nfs-idmapd.service on clients too. This is distro specific... Other distros use the key ring based nfsidmap(5) command to do the id mapping. Make note, with new kernels the default upcall is to the nfsdimap command, if that fails then the rpc.idmapd daemon is tried. Meaning there are two upcalls for every id map when rpc.idmapd is used. This was the reason for the switch. steved. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemd: Have rpc-statd-notify.service Require network.target
On 03/03/2015 05:51 PM, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Mar 03, 2015 at 04:37:24PM -0500, Steve Dickson wrote: On 03/03/2015 02:18 PM, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Mar 03, 2015 at 10:06:57PM +0300, Andrei Borzenkov wrote: Indeed. From the man page: -m retry-time Specifies the length of time, in minutes, to continue retry‐ ing notifications to unresponsive hosts. If this option is not specified, sm-notify attempts to send notifications for 15 minutes. Specifying a value of 0 causes sm-notify to continue sending notifications to unresponsive peers until it is manually killed. Notifications are retried if sending fails, the remote does not respond, the remote's NSM service is not registered, or if there is a DNS failure which prevents the remote's mon_name from being resolved to an address. So rpc-statd-notify.service should be fine with being started before the network is up at all. Right... that's the point... we want the service to fork and keep trying in the background ...so like Andrei wrote, the dependency on network.target can be removed (I wasn't sure if it was clear what I meant). I did miss the fact you guys were saying because of the 15min retry network.target is not needed... But, in reality, a network is needed/wanted so leaving it in will document that fact w/out causing any delay. steved. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Possible bug when a dummy service declares After= and/or Conflicts= a .mount unit?
Le 06/03/2015 16:17, Michael Biebl a écrit : 2015-03-06 11:20 GMT+01:00 Didier Roche didro...@ubuntu.com: It seems like tmp.mount unit was skipped as nothing declared any explicit dependency against it. What seems to confirm this is that if I add any enabled foo.service which declares After=tmp.mount, or if I add the After= statement to systemd-timesync.service, then I get tmp.mount reliably to start (and it was installed as the journal shows up). Does it make sense? I do have several units which have PrivateTmp=true (cups.service, timesyncd) which *are* started during boot, yet tmp.mount is not being activated. Inspecting the units via systemctl shows e.g. $ systemctl show cups.service -p After -p Requires Requires=basic.target cups.socket -.mount tmp.mount After=cups.socket -.mount system.slice tmp.mount basic.target cups.path systemd-journald.socket Why is tmp.mount then not reliably activated during boot here? Right, that's the question, my feeling is that PrivateTmp=true isn't mapped right away as corresponding to tmp.mount at boot time, and so, as nothing refers to tmp.mount explicitly, systemd doesn't take that unit into account. Then, it's present later (after boot time) and that's why starting or restarting an unit with PrivateTmp=true would then pull it. That would also explains why if you enable a service like foo.service declaring a relationship to tmp.mount (like After=tmp.mount), this one is reliably seen at boot time from systemd, and thus, reliably started, even when booting by any units declaring PrivateTmp=true. Would that be the bug? Cheers, Didier ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Possible bug when a dummy service declares After= and/or Conflicts= a .mount unit?
Le 04/03/2015 13:40, Lennart Poettering a écrit : On Wed, 04.03.15 13:19, Didier Roche (didro...@ubuntu.com) wrote: Before=systemd-timesyncd.service foo.service local-fs.target umount.target systemd-timesyncd.service though is condition failed: Condition: start condition failed at Wed 2015-03-04 13:09:09 CET; 3min 10s ago ConditionVirtualization=no was not met So, even if the condition for an unit failed, the Requires= are started? Yes. ConditionXYZ= only shortcuts the executon of the service, all its deps are pulled in. The condition is checked at the time the unit is about to be started, which means that at that time the dependencies usually are fulfilled anyway already. Also see docs about this in the man page. I noted that on boot where the tmpfs isn't mounted, systemd-timesyncd.service stays inactive: Active: inactive (dead) ExecMainStartTimestampMonotonic=0 ExecMainExitTimestampMonotonic=0 and if I try to start it (and we get the condition fail), the Requires (tmp.mount in that case) is started. It seems there are 2 issues: - systemd-timesyncd.service is seldomly activated on boot on those machines. (I'll dive into why) - if an unit as a Condition failing, the Requirements of those units are still activated. Yes, absolutely, see man pages. Thanks for your answers. So, from this, we should see systemd-timesyncd.service always trying to be activated (failing due to conditions) and bringing up tmp.mount unit with it. However, in a vm (and it seems in some systems), we are seeing different behaviors. Let's focus on the vm which has a minimal environment and the easiest to reproduce: $ systemctl show -p RequiredBy tmp.mount RequiredBy=systemd-timesyncd.service and systemd-timesyncd.service is enabled. We can end up with systemd-timesyncd.service inactive because of condition failed, but tmp.mount is inactive as well: $ systemctl status systemd-timesyncd.service ● systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled) Drop-In: /lib/systemd/system/systemd-timesyncd.service.d └─disable-with-time-daemon.conf Active: inactive (dead) Condition: start condition failed at Fri 2015-03-06 10:36:21 CET; 29s ago ConditionVirtualization=no was not met Docs: man:systemd-timesyncd.service(8) Mar 06 10:36:21 autopkgtest systemd[1]: ConditionFileIsExecutable=!/usr/sbin/chronyd succeeded for systemd-timesyncd.service. Mar 06 10:36:21 autopkgtest systemd[1]: ConditionFileIsExecutable=!/usr/sbin/openntpd succeeded for systemd-timesyncd.service. Mar 06 10:36:21 autopkgtest systemd[1]: ConditionFileIsExecutable=!/usr/sbin/ntpd succeeded for systemd-timesyncd.service. Mar 06 10:36:21 autopkgtest systemd[1]: ConditionVirtualization=no failed for systemd-timesyncd.service. Mar 06 10:36:21 autopkgtest systemd[1]: Starting of systemd-timesyncd.service requested but condition failed. Not starting unit. Mar 06 10:36:21 autopkgtest systemd[1]: Job systemd-timesyncd.service/start finished, result=done Mar 06 10:36:21 autopkgtest systemd[1]: Started Network Time Synchronization. $ systemctl status tmp.mount ● tmp.mount - Temporary Directory Loaded: loaded (/lib/systemd/system/tmp.mount; disabled; vendor preset: enabled) Active: inactive (dead) Where: /tmp What: tmpfs Docs: man:hier(7) http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems journald content with debug mode: Mar 06 10:36:21 autopkgtest systemd[1]: ConditionFileIsExecutable=!/usr/sbin/chronyd succeeded for systemd-timesyncd.service. Mar 06 10:36:21 autopkgtest systemd[1]: ConditionFileIsExecutable=!/usr/sbin/openntpd succeeded for systemd-timesyncd.service. Mar 06 10:36:21 autopkgtest systemd[1]: ConditionFileIsExecutable=!/usr/sbin/ntpd succeeded for systemd-timesyncd.service. Mar 06 10:36:21 autopkgtest systemd[1]: ConditionVirtualization=no failed for systemd-timesyncd.service. Mar 06 10:36:21 autopkgtest systemd[1]: Starting of systemd-timesyncd.service requested but condition failed. Not starting unit. Mar 06 10:36:21 autopkgtest systemd[1]: Job systemd-timesyncd.service/start finished, result=done With no mention at all about tmp.mount in the journal (even no Installed new job tmp.mount/start as …). Shouldn't we get tmp.mount always activated if I follow correctly what you told (and the man page)? It seems like tmp.mount unit was skipped as nothing declared any explicit dependency against it. What seems to confirm this is that if I add any enabled foo.service which declares After=tmp.mount, or if I add the After= statement to systemd-timesync.service, then I get tmp.mount reliably to start (and it was installed as the journal shows up). Does it make sense? Cheers, Didier PS: we are discussing independently about enabling or not tmp.mount in debian/ubuntu (but it's quite late for this cycle and not everyone is
[systemd-devel] [PATCH] systemd: start nfs-idmapd also on clients
idmapd is needed on clients too, so start it from nfs-client.target and stop binding to it in nfs-server.service. https://launchpad.net/bugs/1428961 --- systemd/nfs-client.target | 4 ++-- systemd/nfs-idmapd.service | 2 -- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/systemd/nfs-client.target b/systemd/nfs-client.target index 9b792a3..b12d830 100644 --- a/systemd/nfs-client.target +++ b/systemd/nfs-client.target @@ -5,8 +5,8 @@ Wants=remote-fs-pre.target # Note: we don't Wants=rpc-statd.service as mount.nfs will arrange to # start that on demand if needed. -Wants=nfs-blkmap.service rpc-statd-notify.service -After=nfs-blkmap.service +Wants=nfs-blkmap.service rpc-statd-notify.service nfs-idmapd.service +After=nfs-blkmap.service nfs-idmapd.service # GSS services dependencies and ordering Wants=auth-rpcgss-module.service diff --git a/systemd/nfs-idmapd.service b/systemd/nfs-idmapd.service index df3dd9d..90d3731 100644 --- a/systemd/nfs-idmapd.service +++ b/systemd/nfs-idmapd.service @@ -4,8 +4,6 @@ DefaultDependencies=no Requires=var-lib-nfs-rpc_pipefs.mount After=var-lib-nfs-rpc_pipefs.mount local-fs.target -BindsTo=nfs-server.service - Wants=nfs-config.service After=nfs-config.service -- 2.1.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 0/1] details for starting nfs-idmapd also on clients
Hello all, Steve Langasek pointed out in [1] that idmapd is also necessary on the client side. It isn't for my very simple NFSv4 test, but then again I don't know that much about the various other modes of operation. This patch starts nfs-idmapd.service on clients too. Thanks, Martin [1] https://launchpad.net/bugs/1428961 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] Add option to enable COW for journal file
On 2015-03-06 13:31, Lennart Poettering wrote: On Thu, 05.03.15 21:39, Goffredo Baroncelli (kreij...@libero.it) wrote: Hi All, the enclosed patches add an option to the journald.conf file to allow a COW behavior for the journal files. [...] I am pretty strongly against adding an explicit option for this. I consider this all a temporary stopgap, until btrfs's autodefrag makes the problem go away, and I am very conservative with adding new config options where it is already clear that they will eventually be useless. What I'd be open to is: a) beef up the tmpfiles logic to be able to do the equivalent of /usr/bin/chattr on files. (By adding a new line type, make h or so). b) remove all code that sets NOCOW explicitly on journal files from journald. c) instead ship a tmpfiles snippet making use of a) that sets the NOCOW flag for /var/lib/journal, which results in the flag being inherited by journal files that are created within it. If people then want to opt-out of NOCOW, they can simply override the tmpfiles snippet and all is good. That way we have a way to configure the bit, without actually introducing a high-level config option for this. This seems reasonable; I will work on a proposal like this one. 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
[systemd-devel] order of sd_journal_query_unique()?
I was using a journal iterator to search from the newest journal entry backwards for a matching field, using SD_JOURNAL_FOREACH_BACKWARDS. This appears to be pretty slow but journalctl is really fast. I went looking and found sd_journal_query_unique() (although I'm not 100% positive this is why journalctl is faster). Looking at http://www.freedesktop.org/software/systemd/man/sd_journal_query_unique.html there isn't any mention of ordering or direction. Is this search finding journal entries that are newest to oldest or??? Chris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] order of sd_journal_query_unique()?
On 6 March 2015 at 14:25, Chris Morgan chmor...@gmail.com wrote: I was using a journal iterator to search from the newest journal entry backwards for a matching field, using SD_JOURNAL_FOREACH_BACKWARDS. This appears to be pretty slow but journalctl is really fast. I went looking and found sd_journal_query_unique() (although I'm not 100% positive this is why journalctl is faster). Looking at http://www.freedesktop.org/software/systemd/man/sd_journal_query_unique.html there isn't any mention of ordering or direction. Is this search finding journal entries that are newest to oldest or??? sd_journal_query_unique() finds unique *field names*. Not journal entries. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Reliably waiting for udevd to finish processing triggered events
Hi, I'm looking at some issues with the plymouth boot splash system, and why it intermittently fails to get graphics on screen. plymouth watches for the creation of drm display devices during boot. If it finds one, it starts a graphical splash and that is that. However, if the system finishes loading drivers and no drm device is available, it falls back onto a fbdev-based splash or a text-based boot. Once it has made that choice there is no turning back, it basically ignores drm devices if they become available later. In order to know when the system has finished loading drivers, plymouth does the same as udevadm settle - it uses udev API's to inotify-monitor /run/udev, and it assumes that when the queue file is deleted, all driver load events have been processed. But there seem to be a couple of problems associated with this. Firstly, plymouth does the above when it loads in the initramfs. The initramfs will trigger udev events for all devices, but if systemd finds the root filesystem before plymouth finds the drm device, udevd is immediately killed by systemd as it changes to switch-root.target. udevd has not processed the drm device at this point, so udev_device_get_is_initialized() returns false when plymouth inquires. As udevd is killed, it removes /run/udev/queue in its exit path; plymouth sees this and (like udevsettle would) assumes that this apparently empty queue means that driver loading is complete. But no drm devices are available and initialized, so it falls back to textual boot for the rest of boot. The killing of udev seems heavy-handed here, and the way it removes the queue file on exit (without first at least going through the already-pending events) seems to kill any possibility of a program like udevsettle or plymouth knowing if udev finished loading all drivers while the initramfs transitions to the real root. Secondly, there is a race during startup. udevd launches and it actually removes /run/udev/queue (if it were to exist) in the first iteration of the mainloop - even before it checked if any events were available to process. Anyway, we would normally expect the queue to be empty here, it is only after udevd has started up that systemd then goes on to run udevadm trigger and generate events for udevd to handle. In the case where plymouth is run from the real root (instead of the initramfs), once trigger has exited, systemd starts plymouth, which then starts immediately using udev_queue_get_queue_is_empty() to do the detection described above. If plymouth happens to do that before udevd has gotten around to processing the first event generated by udevtrigger, the queue is reported as empty (udevd has not created the marker yet), so plymouth concludes that driver loading has completed. Oops. I believe the same race exists with udevadm settle, if it is launched at that same moment it could hit the same race. The only difference is that udevadm settle uses some internal udev API that actually sends a ping to udevd before it checks the queue status. That likely reduces the probability of the race, but I think it is still there, as I can't see any guarantee that udevd would create the queue file before responding to the ping (it only creates the queue file at the start of the next iteration of the main loop, assuming that it had noted the pending events in the previous iteration where it also handled the ping). If there's a way of running udevadm trigger and then reliably knowing that udevd has finished processing those events, I haven't found it. Any hints much appreciated. Thanks, Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] order of sd_journal_query_unique()?
On Fri, Mar 6, 2015 at 2:38 PM, Daurnimator q...@daurnimator.com wrote: On 6 March 2015 at 14:25, Chris Morgan chmor...@gmail.com wrote: I was using a journal iterator to search from the newest journal entry backwards for a matching field, using SD_JOURNAL_FOREACH_BACKWARDS. This appears to be pretty slow but journalctl is really fast. I went looking and found sd_journal_query_unique() (although I'm not 100% positive this is why journalctl is faster). Looking at http://www.freedesktop.org/software/systemd/man/sd_journal_query_unique.html there isn't any mention of ordering or direction. Is this search finding journal entries that are newest to oldest or??? sd_journal_query_unique() finds unique *field names*. Not journal entries. Hmm So is SD_JOURNAL_FOREACH_BACKWARDS the fastest way to find the newest journal entry with a given field? journalctl seems a ton faster than my c application is when I search for a given field that is not present. And by search I'm doing: journalctl --user BLAH=1 Chris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core/socket: Add REMOTE_IP environment variable for Accept=true
On Thu, Mar 5, 2015 at 3:18 AM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 04.03.15 15:18, Shawn Landden (sh...@churchofgit.com) wrote: Can't this just use getpeername_pretty()? Then I can't force it to only ipv4 and ipv6. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Shawn Landden ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] DBus api of systemd user instance
On Fri, Mar 6, 2015 at 6:23 PM, Ragnar Thomsen rthoms...@gmail.com wrote: Hey List, Does the user instance of systemd expose a dbus api? Yes, that's what `systemctl` uses. If yes, how does one access it? Much like the system instance – either over the DBus user bus, or over the dedicated private socket ($XDG_RUNTIME_DIR/systemd/private). ~ Although, to have the user bus, you'll need to obtain user/dbus.service user/dbus.socket from somewhere. They were added DBus 1.9 just a few weeks ago, but you can also get them separately from https://wiki.archlinux.org/index.php/Systemd/User#D-Bus. ...and then you might (or might not, I forgot) need to point user@.service at it: # system/user@.service.d/bus.conf [Service] Environment=DBUS_SESSION_BUS_ADDRESS=kernel:path=/dev/kdbus/%I-user/bus;unix:path=/run/user/%I/bus ~ So you'll still need to use the private socket (at least as fallback), I think. -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
