Re: [systemd-devel] Confusing journal information - journal size
David Sommerseth wrote on 17/07/15 14:28: On 17/07/15 13:31, Mantas Mikulėnas wrote: On Fri, Jul 17, 2015 at 2:13 PM, David Sommerseth dav...@redhat.com mailto:dav...@redhat.com wrote: Hi, I'm looking through some journals now, and even though I've seen it a few times I haven't thought about it until now. systemd-journal[1151]: Runtime journal is using 8.0M (max allowed 4.0G, trying to leave 4.0G free of 63.7G available → current limit 4.0G). Could this line be cleaned up so you don't have to look up a man page to try to figure out what this really means? Here's my uneducated guess and confusion of this line: * Runtime journal is using 8.0M - Okay, so currently the journal uses 8MB of disk-space. No problem. * max allowed 4.0G - Okay, so the journal should not grow beyond 4GB, makes sense. No problem. * trying to leave 4.0G free of 63.7G available - Uhm, what!? So it will grow until there is 4GB left on the filesystem? Not so okay. It chooses the /smallest/ limit, not largest. (Common sense...) For example, if you had only 5 GB space available, the journal would not grow beyond 1 GB. * current limit 4.0G - Ehh ... okay ... so make up your mind, please! So will the journal grow until 4GB or 59.7GB. This *is* it making up its mind: min(limit 1, limit 2) → resulting limit But then I looked into /var/log/journal ... # du --si -s /var/log/journal/ 4.3G /var/log/journal/ I do see that both system,journal and user-UID.journal are both 8.4MB, and from that I can guess what the log entry tried to tell me with Runtime journal ... but how is /that/ information useful for me, from a sys-admin point of view? Runtime here means /run, as opposed to persistent in /var. They have separately configurable limits, since /run is in RAM and /var is usually on disk. (Though, I'm not entirely sure what purpose the runtime journal even serves, when /var is available.) Fair enough. But you are missing my point. How this information is presented do require some detail knowledge of the journal. Don't think like a developer who have poked at the journal code. Think like a sys-admin who looks through the logs looking for issues. Then you want to have the answer straight in your face, not needing to go elsewhere to read about these things. In fact most admins will probably have forgotten what they were going to look for when they move their eyes of the log data. If it is considered important information, fine. But present it in a far more understandable way for those who just uses the journal. Right now, I'm not surprised if most sys-admins read that line as useless gibberish - Yeah, yeah, journal will waste some space on my drive. Yeah, I can't disagree with David. Not sure how best to tidy it up, but some rework would definitely be nice. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-bus: use isempty() consistently
On 07/19/2015 11:01 AM, Namhyung Kim wrote:
Signed-off-by: Namhyung Kim namhy...@gmail.com
Looks good, thanks! However, it does not apply against current master.
Care to rebase? Also, we generally prefer GitHub pull requests these
days. And you can leave off the Signed-off-by line, we don't use that in
the systemd project.
Thanks,
Daniel
---
src/libsystemd/sd-bus/bus-control.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/libsystemd/sd-bus/bus-control.c
b/src/libsystemd/sd-bus/bus-control.c
index a38c5c5..80f4760 100644
--- a/src/libsystemd/sd-bus/bus-control.c
+++ b/src/libsystemd/sd-bus/bus-control.c
@@ -1131,7 +1131,7 @@ static int add_name_change_match(sd_bus *bus,
/* If the old name is unset or empty, then
* this can match against added names */
-if (!old_owner || old_owner[0] == 0) {
+if (isempty(old_owner)) {
item-type = KDBUS_ITEM_NAME_ADD;
r = ioctl(bus-input_fd, KDBUS_CMD_MATCH_ADD, m);
@@ -1141,7 +1141,7 @@ static int add_name_change_match(sd_bus *bus,
/* If the new name is unset or empty, then
* this can match against removed names */
-if (!new_owner || new_owner[0] == 0) {
+if (isempty(new_owner)) {
item-type = KDBUS_ITEM_NAME_REMOVE;
r = ioctl(bus-input_fd, KDBUS_CMD_MATCH_ADD, m);
@@ -1185,7 +1185,7 @@ static int add_name_change_match(sd_bus *bus,
/* If the old name is unset or empty, then this can
* match against added ids */
-if (!old_owner || old_owner[0] == 0) {
+if (isempty(old_owner)) {
item-type = KDBUS_ITEM_ID_ADD;
r = ioctl(bus-input_fd, KDBUS_CMD_MATCH_ADD, m);
@@ -1195,7 +1195,7 @@ static int add_name_change_match(sd_bus *bus,
/* If thew new name is unset or empty, then this can
* match against removed ids */
-if (!new_owner || new_owner[0] == 0) {
+if (isempty(new_owner)) {
item-type = KDBUS_ITEM_ID_REMOVE;
r = ioctl(bus-input_fd, KDBUS_CMD_MATCH_ADD, m);
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Asking for advice - two network interfaces in a container
On Tue, Jul 14, 2015 at 12:26:23PM +0300, Peter Lemenkov wrote:
Hello All!
My system has two network planes - control plane (several 10.0.0.0/8
networks) and data plane (non-RFC1918 network, visible to end-users).
These two networks separated by two different bridges and some
iptables magic. All my business logic is handled using control plane
(using various network protocols).
So far all my containers connected to a control plane only - I have a
lot of them actually. They work fine, orchestrated properly (with high
availability, load balancing etc).
Also I've got three VMs (KVM if it matters) which provides a different
services to the end-users. Thus they has to be connected to a data
plane. So all of them have two separate NICs - one for end user
interaction, and another one for control plane. Although it's possible
to handle all the business logic via data plane I'd rather to avoid
that.
Could anyone give me an advice/hint on how to design something like
this properly? So far I don't see a standard method for systemd-nspawn
to assign more that one NIC to the container.
There's --network-interface=INTERFACE, which can be specified multiple
times to *move* interfaces from your host network namespace into your
guest network namespaces.
So you could do this by setting up those interfaces externally and moving them
in. e.g. make some veth pairs and bridge them onto the data plane interface.
Alternatively if your networking is simple enough, you can use
--network-{mac,ip}vlan=$DATA_PLANE_INTERFACE to have systemd bridge the
container onto an existing device, similar to how KVM's macvtap works.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Typo fix in systemd.preset manpage
On 07/17/2015 02:12 PM, Vivenzio Pagliari wrote: --- man/systemd.preset.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Now merged through https://github.com/systemd/systemd/pull/626 Thanks! Daniel diff --git a/man/systemd.preset.xml b/man/systemd.preset.xml index 2f9add8..b716401 100644 --- a/man/systemd.preset.xml +++ b/man/systemd.preset.xml @@ -106,7 +106,7 @@ one takes precedence over all others./para paraEach preset file shall be named in the style of -filenamelt;prioritygt;-lt;programgt;.conf/filename. Files +filenamelt;prioritygt;-lt;policy-namegt;.preset/filename. Files in filename/etc//filename override files with the same name in filename/usr/lib//filename and filename/run//filename. Files in filename/run//filename override files with the same ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Packaging systemd user-instance service files
Ahmed S. Darwish wrote on 18/07/15 01:44: Hi Mantas, On Sat, Jul 18, 2015 at 12:17:51AM +0300, Mantas Mikulėnas wrote: On Fri, Jul 17, 2015 at 9:38 PM, Ahmed S. Darwish darwish...@gmail.com wrote: Hi everyone, I'm currently transforming a network daemon to become a native ``Type=notify'' systemd service. This daemon uses native PulseAudio simple APIs for output. Due to the PulseAudio dependency, the service needs to run under the user session. Otherwise, all PulseAudio APIs [e.g. pa_simple_new()] returns a ``Connection Refused'' error. [1] Given the above, I've built the following service file: [Unit] Description=AirTunes Synchronous Audio Service [Service] Type=notify ExecStart=/usr/local/bin/shairport-sync [Install] WantedBy=default.target And the following snippet in the package Makefile.am: cp scripts/shairport-sync.service /usr/lib/systemd/user/ systemctl --user daemon-reload systemctl --user enable shairport-sync.service systemctl --user start shairport-sync.service So the real problem is not that it *doesn't work*, but rather that it *shouldn't be done*. That makefile is mixing entirely separate things – installation (packaging), global configuration, and per-user configuration. This is a small github project, and you have to handle the standard `./confugre', `make' and `sudo make install' sequence out of the box. There's no fancy Debian or Fedora packages for it even yet. The per-use configuration part was forced upon us due to our dependency on native PulseAudio APIs; APIs which do not work except when our daemon is run from the same session PulseAudio is running from. (Not to mention the dangerous assumptions that 1) there's exactly one user logged in during installation, and 2) that they'll actually want to run the program right now...) Yes, `systemctl --user' is wrong and specific only to the current user, but that's why I was asking for an alernative, more generic, solution that will fit all users in the first place :-) As you can see, the service is properly installed under ``/usr/lib/systemd/user/'' to run under the systemd user instance. Now the problem is that the Makefile commands above run as root, and thus all the ``systemctl --user'' commands fail with: Failed to get D-Bus connection: Connection refused So, the question is, can I start ``systemctl --user daemon-reload'' and ``systemctl --user enable'' above in some form while the Makefile is run from root? No, but you don't need to. Just install the file to /usr/lib/systemd/user, and that's it. It'll be available to all users. If you want to forcefully enable the service for all users, then also symlink it into /usr/lib/systemd/user/default.target.wants/, which is almost exactly what `systemctl enable` does (except system-wide). That'll make it start on login for everyone. Excellent! `systemctl --user enable' always did the symbolic link under `$HOME/.config/systemd/user/'; I mistakenly thought that it must be done _only_ this way for each and every user. Now I understand; it seems it was done that way just not to affect other users of the system. It couldn't be done any other way due to the system permissions of /usr/lib/systemd/user Note, that this *forces* it on every user, you can also enable it for every user as part of package installation by running systemctl --global enable yourservice The --global flag means globally for all users (it only applies to the user instance, so the --user part is not needed). This writes the enablement symlink into /etc/systemd/user/default.target.wants/ (or whatever your service file states as it's WantedBy= directive). Ultimately this is a packaging issue, so I would suggest that your make install does not write anything here, but your document things for packagers that *iff* they want the package to be enabled by all users, then they run systemctl --global enable yourservice on initial package installation (or better run systemctl --global preset yourservice to allow package preset system to take on board the distro-wide defaults from *.preset files (see man 5 systemd.preset) This is ultimately what PulseAudio itself does/recommends when started from the user session as you are trying to do, so I'd suggest you follow suit. But the general rule is, do not start user-session processes from system tasks. Having the service installed `per-user' was something that was unfortunately forced. I will still inspect what will happen when two logged-in users lead to two instances of the daemon running :-( Ultimately, if your daemon connects to PA, then you could react appropriately. e.g. if PA is suspended because the user no longer has access to the h/w devices, this information will be made available via PA APIs and your daemon can react accordingly. e.g. if you have two users, and one user wants this service and one does not, then you can react
[systemd-devel] Use of capabilities in default service files
There are a few examples similar to these in the source tree: [Unit] Description=Legacy D-Bus Protocol Compatibility Daemon [Service] ExecStart=@rootlibexecdir@/systemd-bus-proxyd --address=kernel:path=/sys/fs/kdbus/0-system/bus NotifyAccess=main CapabilityBoundingSet=CAP_IPC_OWNER CAP_SETUID CAP_SETGID CAP_SETPCAP m4_ifdef(`HAVE_SMACK', CAP_MAC_ADMIN ) … [Unit] Description=Hostname Service Documentation=man:systemd-hostnamed.service(8) man:hostname(5) man:machine-info(5) Documentation=http://www.freedesktop.org/wiki/Software/systemd/hostnamed [Service] ExecStart=@rootlibexecdir@/systemd-hostnamed BusName=org.freedesktop.hostname1 CapabilityBoundingSet=CAP_SYS_ADMIN … [Unit] Description=Locale Service Documentation=man:systemd-localed.service(8) man:locale.conf(5) man:vconsole.conf(5) Documentation=http://www.freedesktop.org/wiki/Software/systemd/localed [Service] ExecStart=@rootlibexecdir@/systemd-localed BusName=org.freedesktop.locale1 CapabilityBoundingSet= … What's the intent of these settings? Is it a form of hardening? If yes, it is rather ineffective because UID=0 does not need any capabilities to completely compromise the system. -- Florian Weimer / Red Hat Product Security ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] c/c++ lib for dbus
Hi I need to use functions to call method, get property value etc from dbus. also few utility functions like unit_name_from_dbus_path() from systemd. Can i use systemd as lib ? If yes how , where can I see examples? is there any lib for that in c /c++? Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-bus: use isempty() consistently
On Mon, Jul 20, 2015 at 1:14 PM, Daniel Mack dan...@zonque.org wrote: On 07/19/2015 11:01 AM, Namhyung Kim wrote: Signed-off-by: Namhyung Kim namhy...@gmail.com Looks good, thanks! However, it does not apply against current master. Care to rebase? Also, we generally prefer GitHub pull requests these days. And you can leave off the Signed-off-by line, we don't use that in the systemd project. Does including it hurt though? -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Use of capabilities in default service files
On 07/20/2015 01:52 PM, Reindl Harald wrote: Am 20.07.2015 um 13:24 schrieb Florian Weimer: CapabilityBoundingSet=CAP_IPC_OWNER CAP_SETUID CAP_SETGID CAP_SETPCAP m4_ifdef(`HAVE_SMACK', CAP_MAC_ADMIN ) … What's the intent of these settings? Is it a form of hardening? If yes, it is rather ineffective because UID=0 does not need any capabilities to completely compromise the system. UID=0 *does* need capabilities, drwxr-xr-x. 2 root root 37 Jun 13 10:09 /etc/cron.d -rw-r--r--. 1 root root 3068 Jul 17 19:47 /etc/passwd UID=0 without CAP_DAC_OVERRIDE (or any other capabilities) can write to these locations and escalate fairly directly to full root. that's the whole purpose of CapabilityBoundingSet and so yes it is a form of hardening To me, it looks someone misunderstood the interactions between UID=0 and capabilities. our internal httpd package is using the following options and when you remove CAP_NET_BIND_SERVICE it could not bind to port 80, PrivateTmp=yes PrivateDevices=yes NoNewPrivileges=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID Without code in the daemon to switch away from UID=0, this is not a very strong restriction (but CAP_DAC_OVERRIDE is root-equivalent anyway, so it probably does not matter). I found the “CapabilityBoundingSet=” line (empty set) somewhat worrying, it seems to me that this service should use a separate UID, not 0. -- Florian Weimer / Red Hat Product Security ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Confusing journal information - journal size
- Original Message - From: Colin Guthrie gm...@colin.guthr.ie To: systemd-devel@lists.freedesktop.org Sent: Monday, July 20, 2015 5:38:38 AM Subject: Re: [systemd-devel] Confusing journal information - journal size David Sommerseth wrote on 17/07/15 14:28: On 17/07/15 13:31, Mantas Mikulėnas wrote: On Fri, Jul 17, 2015 at 2:13 PM, David Sommerseth dav...@redhat.com mailto:dav...@redhat.com wrote: Hi, I'm looking through some journals now, and even though I've seen it a few times I haven't thought about it until now. systemd-journal[1151]: Runtime journal is using 8.0M (max allowed 4.0G, trying to leave 4.0G free of 63.7G available → current limit 4.0G). Could this line be cleaned up so you don't have to look up a man page to try to figure out what this really means? Here's my uneducated guess and confusion of this line: * Runtime journal is using 8.0M - Okay, so currently the journal uses 8MB of disk-space. No problem. * max allowed 4.0G - Okay, so the journal should not grow beyond 4GB, makes sense. No problem. * trying to leave 4.0G free of 63.7G available - Uhm, what!? So it will grow until there is 4GB left on the filesystem? Not so okay. It chooses the /smallest/ limit, not largest. (Common sense...) For example, if you had only 5 GB space available, the journal would not grow beyond 1 GB. * current limit 4.0G - Ehh ... okay ... so make up your mind, please! So will the journal grow until 4GB or 59.7GB. This *is* it making up its mind: min(limit 1, limit 2) → resulting limit But then I looked into /var/log/journal ... # du --si -s /var/log/journal/ 4.3G /var/log/journal/ I do see that both system,journal and user-UID.journal are both 8.4MB, and from that I can guess what the log entry tried to tell me with Runtime journal ... but how is /that/ information useful for me, from a sys-admin point of view? Runtime here means /run, as opposed to persistent in /var. They have separately configurable limits, since /run is in RAM and /var is usually on disk. (Though, I'm not entirely sure what purpose the runtime journal even serves, when /var is available.) Fair enough. But you are missing my point. How this information is presented do require some detail knowledge of the journal. Don't think like a developer who have poked at the journal code. Think like a sys-admin who looks through the logs looking for issues. Then you want to have the answer straight in your face, not needing to go elsewhere to read about these things. In fact most admins will probably have forgotten what they were going to look for when they move their eyes of the log data. If it is considered important information, fine. But present it in a far more understandable way for those who just uses the journal. Right now, I'm not surprised if most sys-admins read that line as useless gibberish - Yeah, yeah, journal will waste some space on my drive. Yeah, I can't disagree with David. Not sure how best to tidy it up, but some rework would definitely be nice. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel After seeing the explanation, the best complete and correct (AFAICT) formulation I could come up with was, Runtime journal is using 8.0M (max allowed = min(4.0G, S s.t. total memory(63.7 G) - S = 4.0 G (59.7 G), available memory (16.2 G)) = 4.0G) which is compelled to use math speak for clarity and succinctness. Dunno how happy most sys-admins would be with that. - mulhern ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-bus: use isempty() consistently
Hi, On Mon, Jul 20, 2015 at 06:14:22AM -0400, Daniel Mack wrote: On 07/19/2015 11:01 AM, Namhyung Kim wrote: Signed-off-by: Namhyung Kim namhy...@gmail.com Looks good, thanks! However, it does not apply against current master. Care to rebase? Also, we generally prefer GitHub pull requests these days. Okay, I'll send a PR on github after rebasing onto the current master. And you can leave off the Signed-off-by line, we don't use that in the systemd project. Will do. Thanks, Namhyung ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-bus: use isempty() consistently
On 07/20/2015 02:06 PM, Mantas Mikulėnas wrote: On Mon, Jul 20, 2015 at 1:14 PM, Daniel Mack dan...@zonque.org mailto:dan...@zonque.org wrote: On 07/19/2015 11:01 AM, Namhyung Kim wrote: Signed-off-by: Namhyung Kim namhy...@gmail.com mailto:namhy...@gmail.com Looks good, thanks! However, it does not apply against current master. Care to rebase? Also, we generally prefer GitHub pull requests these days. And you can leave off the Signed-off-by line, we don't use that in the systemd project. Does including it hurt though? We don't use them, so they shouldn't be there. Leaving them around in some commits but not in others just causes confusion for people reading the logs. Everyone with push access usually removes those tags manually. Thanks, Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Changing configure.ac to make LTO optional.
There is a bug in GCC LTO such that it ignores assembler directives. This patch makes LTO enabled by default but also allows it to be disabled if required. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47785 Ray Kinsella --- configure.ac | 17 - 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/configure.ac b/configure.ac index 999f9f8..294c440 100644 --- a/configure.ac +++ b/configure.ac @@ -194,11 +194,18 @@ AS_CASE([$CC], [*clang*], -Wno-gnu-variable-sized-type-not-at-end \ ])]) -AS_CASE([$CFLAGS], [*-O[[12345sz\ ]]*], -[CC_CHECK_FLAGS_APPEND([with_cflags], [CFLAGS], [\ - -flto -ffat-lto-objects])], -[AC_MSG_RESULT([skipping -flto, optimization not enabled])]) -AC_SUBST([OUR_CFLAGS], $with_cflags $sanitizer_cflags) +AC_ARG_ENABLE(lto, +[AS_HELP_STRING([--enable-lto], [Enable link time optimization])], + enable_lto=$enableval, + enable_lto=yes; default_enable_lto=yes) + +if test x$enable_lto != xno; then +AS_CASE([$CFLAGS], [*-O[[12345sz\ ]]*], +[CC_CHECK_FLAGS_APPEND([with_cflags], [CFLAGS], [\ +-flto -ffat-lto-objects])], +[AC_MSG_RESULT([skipping -flto, optimization not enabled])]) +AC_SUBST([OUR_CFLAGS], $with_cflags $sanitizer_cflags) +fi AS_CASE([$CFLAGS], [*-O[[12345sz\ ]]*], [CC_CHECK_FLAGS_APPEND([with_cppflags], [CPPFLAGS], [\ -- 2.1.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Changing configure.ac to make LTO optional.
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:1437404176.3279.2.camel%40intel.com -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Confusing journal information - journal size
David Sommerseth wrote on 20/07/15 16:29: On 20/07/15 15:31, Anne Mulhern wrote: - Original Message - From: Colin Guthrie gm...@colin.guthr.ie To: systemd-devel@lists.freedesktop.org Sent: Monday, July 20, 2015 5:38:38 AM Subject: Re: [systemd-devel] Confusing journal information - journal size David Sommerseth wrote on 17/07/15 14:28: On 17/07/15 13:31, Mantas Mikulėnas wrote: On Fri, Jul 17, 2015 at 2:13 PM, David Sommerseth dav...@redhat.com mailto:dav...@redhat.com wrote: Hi, I'm looking through some journals now, and even though I've seen it a few times I haven't thought about it until now. systemd-journal[1151]: Runtime journal is using 8.0M (max allowed 4.0G, trying to leave 4.0G free of 63.7G available → current limit 4.0G). Could this line be cleaned up so you don't have to look up a man page to try to figure out what this really means? Here's my uneducated guess and confusion of this line: * Runtime journal is using 8.0M - Okay, so currently the journal uses 8MB of disk-space. No problem. * max allowed 4.0G - Okay, so the journal should not grow beyond 4GB, makes sense. No problem. * trying to leave 4.0G free of 63.7G available - Uhm, what!? So it will grow until there is 4GB left on the filesystem? Not so okay. It chooses the /smallest/ limit, not largest. (Common sense...) For example, if you had only 5 GB space available, the journal would not grow beyond 1 GB. * current limit 4.0G - Ehh ... okay ... so make up your mind, please! So will the journal grow until 4GB or 59.7GB. This *is* it making up its mind: min(limit 1, limit 2) → resulting limit But then I looked into /var/log/journal ... # du --si -s /var/log/journal/ 4.3G /var/log/journal/ I do see that both system,journal and user-UID.journal are both 8.4MB, and from that I can guess what the log entry tried to tell me with Runtime journal ... but how is /that/ information useful for me, from a sys-admin point of view? Runtime here means /run, as opposed to persistent in /var. They have separately configurable limits, since /run is in RAM and /var is usually on disk. (Though, I'm not entirely sure what purpose the runtime journal even serves, when /var is available.) Fair enough. But you are missing my point. How this information is presented do require some detail knowledge of the journal. Don't think like a developer who have poked at the journal code. Think like a sys-admin who looks through the logs looking for issues. Then you want to have the answer straight in your face, not needing to go elsewhere to read about these things. In fact most admins will probably have forgotten what they were going to look for when they move their eyes of the log data. If it is considered important information, fine. But present it in a far more understandable way for those who just uses the journal. Right now, I'm not surprised if most sys-admins read that line as useless gibberish - Yeah, yeah, journal will waste some space on my drive. Yeah, I can't disagree with David. Not sure how best to tidy it up, but some rework would definitely be nice. Col After seeing the explanation, the best complete and correct (AFAICT) formulation I could come up with was, Runtime journal is using 8.0M (max allowed = min(4.0G, S s.t. total memory(63.7 G) - S = 4.0 G (59.7 G), available memory (16.2 G)) = 4.0G) which is compelled to use math speak for clarity and succinctness. Dunno how happy most sys-admins would be with that. - mulhern But is all that information really needed? If I try to see this from a sys-admin point of view there are two numbers which are important to me: 1) Current state 2) Final journal limit size. From how I see it, how the journal code ends up with a certain number is only useful when you're developing/debugging the journal. Remember: Less is more. Well I guess you could just log something like: Runtime journal is using 8.0M (see 'journalctl status' for more info) Then you add a journalctl status verb that explained the current status of journal (e.g. number of files on disk and in memory, how the file size and rotation will work etc) That might be more practically useful, but it won't explain things as calculated at the time that log entry was created, so can I suggest that an additional _CALCULATION field (or soemthing similarly named) is added into that log message that is not shown by default but is stored) so that the typical administrator looking at the log out put will not see the detail, but it is logged. The journalctl status command could even pull out the last messages in the journal (via it's message id) and then get the _CALCULATION field and show it in a nice, verbose way to the user. That keeps it simple by default
Re: [systemd-devel] Confusing journal information - journal size
On 20/07/15 15:31, Anne Mulhern wrote: - Original Message - From: Colin Guthrie gm...@colin.guthr.ie To: systemd-devel@lists.freedesktop.org Sent: Monday, July 20, 2015 5:38:38 AM Subject: Re: [systemd-devel] Confusing journal information - journal size David Sommerseth wrote on 17/07/15 14:28: On 17/07/15 13:31, Mantas Mikulėnas wrote: On Fri, Jul 17, 2015 at 2:13 PM, David Sommerseth dav...@redhat.com mailto:dav...@redhat.com wrote: Hi, I'm looking through some journals now, and even though I've seen it a few times I haven't thought about it until now. systemd-journal[1151]: Runtime journal is using 8.0M (max allowed 4.0G, trying to leave 4.0G free of 63.7G available → current limit 4.0G). Could this line be cleaned up so you don't have to look up a man page to try to figure out what this really means? Here's my uneducated guess and confusion of this line: * Runtime journal is using 8.0M - Okay, so currently the journal uses 8MB of disk-space. No problem. * max allowed 4.0G - Okay, so the journal should not grow beyond 4GB, makes sense. No problem. * trying to leave 4.0G free of 63.7G available - Uhm, what!? So it will grow until there is 4GB left on the filesystem? Not so okay. It chooses the /smallest/ limit, not largest. (Common sense...) For example, if you had only 5 GB space available, the journal would not grow beyond 1 GB. * current limit 4.0G - Ehh ... okay ... so make up your mind, please! So will the journal grow until 4GB or 59.7GB. This *is* it making up its mind: min(limit 1, limit 2) → resulting limit But then I looked into /var/log/journal ... # du --si -s /var/log/journal/ 4.3G /var/log/journal/ I do see that both system,journal and user-UID.journal are both 8.4MB, and from that I can guess what the log entry tried to tell me with Runtime journal ... but how is /that/ information useful for me, from a sys-admin point of view? Runtime here means /run, as opposed to persistent in /var. They have separately configurable limits, since /run is in RAM and /var is usually on disk. (Though, I'm not entirely sure what purpose the runtime journal even serves, when /var is available.) Fair enough. But you are missing my point. How this information is presented do require some detail knowledge of the journal. Don't think like a developer who have poked at the journal code. Think like a sys-admin who looks through the logs looking for issues. Then you want to have the answer straight in your face, not needing to go elsewhere to read about these things. In fact most admins will probably have forgotten what they were going to look for when they move their eyes of the log data. If it is considered important information, fine. But present it in a far more understandable way for those who just uses the journal. Right now, I'm not surprised if most sys-admins read that line as useless gibberish - Yeah, yeah, journal will waste some space on my drive. Yeah, I can't disagree with David. Not sure how best to tidy it up, but some rework would definitely be nice. Col After seeing the explanation, the best complete and correct (AFAICT) formulation I could come up with was, Runtime journal is using 8.0M (max allowed = min(4.0G, S s.t. total memory(63.7 G) - S = 4.0 G (59.7 G), available memory (16.2 G)) = 4.0G) which is compelled to use math speak for clarity and succinctness. Dunno how happy most sys-admins would be with that. - mulhern But is all that information really needed? If I try to see this from a sys-admin point of view there are two numbers which are important to me: 1) Current state 2) Final journal limit size. From how I see it, how the journal code ends up with a certain number is only useful when you're developing/debugging the journal. Remember: Less is more. -- kind regards, David Sommerseth ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Confusing journal information - journal size
- Original Message - From: David Sommerseth dav...@redhat.com To: Anne Mulhern amulh...@redhat.com Cc: systemd-devel@lists.freedesktop.org Sent: Monday, July 20, 2015 11:29:22 AM Subject: Re: [systemd-devel] Confusing journal information - journal size On 20/07/15 15:31, Anne Mulhern wrote: - Original Message - From: Colin Guthrie gm...@colin.guthr.ie To: systemd-devel@lists.freedesktop.org Sent: Monday, July 20, 2015 5:38:38 AM Subject: Re: [systemd-devel] Confusing journal information - journal size David Sommerseth wrote on 17/07/15 14:28: On 17/07/15 13:31, Mantas Mikulėnas wrote: On Fri, Jul 17, 2015 at 2:13 PM, David Sommerseth dav...@redhat.com mailto:dav...@redhat.com wrote: Hi, I'm looking through some journals now, and even though I've seen it a few times I haven't thought about it until now. systemd-journal[1151]: Runtime journal is using 8.0M (max allowed 4.0G, trying to leave 4.0G free of 63.7G available → current limit 4.0G). Could this line be cleaned up so you don't have to look up a man page to try to figure out what this really means? Here's my uneducated guess and confusion of this line: * Runtime journal is using 8.0M - Okay, so currently the journal uses 8MB of disk-space. No problem. * max allowed 4.0G - Okay, so the journal should not grow beyond 4GB, makes sense. No problem. * trying to leave 4.0G free of 63.7G available - Uhm, what!? So it will grow until there is 4GB left on the filesystem? Not so okay. It chooses the /smallest/ limit, not largest. (Common sense...) For example, if you had only 5 GB space available, the journal would not grow beyond 1 GB. * current limit 4.0G - Ehh ... okay ... so make up your mind, please! So will the journal grow until 4GB or 59.7GB. This *is* it making up its mind: min(limit 1, limit 2) → resulting limit But then I looked into /var/log/journal ... # du --si -s /var/log/journal/ 4.3G /var/log/journal/ I do see that both system,journal and user-UID.journal are both 8.4MB, and from that I can guess what the log entry tried to tell me with Runtime journal ... but how is /that/ information useful for me, from a sys-admin point of view? Runtime here means /run, as opposed to persistent in /var. They have separately configurable limits, since /run is in RAM and /var is usually on disk. (Though, I'm not entirely sure what purpose the runtime journal even serves, when /var is available.) Fair enough. But you are missing my point. How this information is presented do require some detail knowledge of the journal. Don't think like a developer who have poked at the journal code. Think like a sys-admin who looks through the logs looking for issues. Then you want to have the answer straight in your face, not needing to go elsewhere to read about these things. In fact most admins will probably have forgotten what they were going to look for when they move their eyes of the log data. If it is considered important information, fine. But present it in a far more understandable way for those who just uses the journal. Right now, I'm not surprised if most sys-admins read that line as useless gibberish - Yeah, yeah, journal will waste some space on my drive. Yeah, I can't disagree with David. Not sure how best to tidy it up, but some rework would definitely be nice. Col After seeing the explanation, the best complete and correct (AFAICT) formulation I could come up with was, Runtime journal is using 8.0M (max allowed = min(4.0G, S s.t. total memory(63.7 G) - S = 4.0 G (59.7 G), available memory (16.2 G)) = 4.0G) which is compelled to use math speak for clarity and succinctness. Dunno how happy most sys-admins would be with that. - mulhern But is all that information really needed? If I try to see this from a sys-admin point of view there are two numbers which are important to me: 1) Current state 2) Final journal limit size. From how I see it, how the journal code ends up with a certain number is only useful when you're developing/debugging the journal. Remember: Less is more. -- kind regards, David Sommerseth That seems reasonable to me. And Runtime journal is using 8.0M (max allowed = 4.0G) is telling it like it is (for this system). The additional info really does seem like its appropriate situation is in debugging output. Also, now that I look at the source it seems like my formulation was wrong, journal is claiming that current limit is s-cached_available_space + sum, which isn't really the minimum of any of the other values mentioned. So something more is going on. - mulhern
Re: [systemd-devel] sd-bus object manager question
On Sat, Jun 27, 2015 at 09:22:45AM +0200, David Härdeman wrote:
On Thu, Jun 25, 2015 at 04:25:29PM +0200, David Herrmann wrote:
On Tue, Jun 23, 2015 at 2:41 PM, David Härdeman da...@hardeman.nu wrote:
...
Now, a question...how is an object manager supposed to be implemented in
sd-bus?
I've seen that there's a sd_bus_add_object_manager() function in sd-bus.h,
but how would I notify the object manager when objects are added and
removed?
Two likely candidates seemed to be:
sd_bus_emit_object_added()
sd_bus_emit_object_removed()
But calling them did not seem to do the right thing. And there seems to be
zero usage of sd_bus_add_object_manager() in the systemd tree itself (though
plenty of calls to sd_bus_add_node_enumerator() which might be related?).
Not sure where the confusion is. Those calls generate the
InterfacesAdded/Removed signals that the objectmanager API specifies.
They collect the interfaces based on the vtables you registered on a
given path. have a look at test-bus-objects.c which uses these
interfaces.
I've done some more experimentation and I think I've got a better idea
of what's going on. Sorry if my first email was a bit confusing.
My problem is that I couldn't get the sd-bus object manager to properly
notify clients when objects are added or removed.
I'm testing my sd-bus server with a gdbus client. The
GDBusObjectManagerClient should normally generate signals (gobject
signals, that is) when objects are added or removed.
Anyway, I tried implementing an object manager server with gdbus as
well, and when talking to the gdbus server, the client is notified of
object additions/removals, so I used used busctl to monitor the signals
that were generated. I think I've found the problem.
Assume there's an object manager at /org/example/mgr and that a new
object is created at /org/example/mgr/object1.
With sd-bus, I'd call:
sd_bus_emit_object_added(bus, /org/example/mgr/object1);
The generated signal would be:
‣ Type=signal Endian=l Flags=1 Version=1 Priority=0 Cookie=11
Sender=:1.297 Path=/org/example/mgr/object1
Interface=org.freedesktop.DBus.ObjectManager Member=InterfacesAdded
UniqueName=:1.297
MESSAGE oa{sa{sv}} {
OBJECT_PATH /org/example/mgr/object1;
With gdbus, the generated signal is instead:
The generated signal would be:
‣ Type=signal Endian=l Flags=1 Version=1 Priority=0 Cookie=21
Sender=:1.297 Path=/org/example/mgr
Interface=org.freedesktop.DBus.ObjectManager Member=InterfacesAdded
UniqueName=:1.297
MESSAGE oa{sa{sv}} {
OBJECT_PATH /org/example/mgr/object1;
Note the difference in the sender path.
The GDBusObjectManagerClient seems to ignore the signal sd-bus generates
because of the different path.
I think that means that sd_bus_emit_object_added() would need to take
both the object manager path and the object path as arguments instead of
a single path?
Ping?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Confusing journal information - journal size
On 20/07/15 17:49, Colin Guthrie wrote: David Sommerseth wrote on 20/07/15 16:29: On 20/07/15 15:31, Anne Mulhern wrote: [...snip...] After seeing the explanation, the best complete and correct (AFAICT) formulation I could come up with was, Runtime journal is using 8.0M (max allowed = min(4.0G, S s.t. total memory(63.7 G) - S = 4.0 G (59.7 G), available memory (16.2 G)) = 4.0G) which is compelled to use math speak for clarity and succinctness. Dunno how happy most sys-admins would be with that. - mulhern But is all that information really needed? If I try to see this from a sys-admin point of view there are two numbers which are important to me: 1) Current state 2) Final journal limit size. From how I see it, how the journal code ends up with a certain number is only useful when you're developing/debugging the journal. Remember: Less is more. Well I guess you could just log something like: Runtime journal is using 8.0M (see 'journalctl status' for more info) Then you add a journalctl status verb that explained the current status of journal (e.g. number of files on disk and in memory, how the file size and rotation will work etc) That might be more practically useful, but it won't explain things as calculated at the time that log entry was created, so can I suggest that an additional _CALCULATION field (or soemthing similarly named) is added into that log message that is not shown by default but is stored) so that the typical administrator looking at the log out put will not see the detail, but it is logged. The journalctl status command could even pull out the last messages in the journal (via it's message id) and then get the _CALCULATION field and show it in a nice, verbose way to the user. That keeps it simple by default but has all the juicy details there should they be needed. Just a thought. +1 ... This makes a lot of sense! I like the journalctl status approach, as that can provide even more details with some more explanations when needed. But I see the benefits of having more hidden fields with details. -- kind regards, David Sommerseth ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] offline updates
[resending with the right systemd-devel address, sorry for that]
Here are some thoughts on offline updates resulting from testing
the new dnf fedup plugin developed by Will Woods
[https://github.com/wgwoods/dnf-plugin-fedup].
I ran an update using dnf fedup and it works (or would have worked, if
stuff didn't happen), which is already great for something so simple,
but it exposes some shortcomings in the Offline Update spec itself
[http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/].
The main issues are:
- what happens when multiple offline mechanisms are present
- how is failure handled
On my test system, I had packagekit-offline-update.service already
present when I installed the plugin and fedup-system-upgrade.service.
After running 'dnf fedup download ...' and 'dnf fedup reboot'
I saw something like this:
Jul 20 21:54:55 fedora22 systemd[1]:
ConditionPathExists=/system-update/.fedup-system-upgrade succeeded for
fedup-system-up
Jul 20 21:54:55 fedora22 systemd[1]: About to execute: /usr/bin/dnf
--releasever=${RELEASEVER} fedup upgrade
Jul 20 21:54:55 fedora22 systemd[1]: Forked /usr/bin/dnf as 655
Jul 20 21:54:55 fedora22 systemd[1]: fedup-system-upgrade.service changed dead
- start
Jul 20 21:54:55 fedora22 systemd[1]: Starting System Upgrade...
Jul 20 21:54:55 fedora22 systemd[655]: Executing: /usr/bin/dnf
--releasever=rawhide fedup upgrade
Jul 20 21:54:55 fedora22 systemd[1]: About to execute:
/usr/libexec/pk-offline-update
Jul 20 21:54:55 fedora22 systemd[1]: Forked /usr/libexec/pk-offline-update as
657
Jul 20 21:54:55 fedora22 systemd[1]: packagekit-offline-update.service changed
dead - running
Jul 20 21:54:55 fedora22 systemd[1]: Job
packagekit-offline-update.service/start finished, result=done
Jul 20 21:54:55 fedora22 systemd[657]: Executing: /usr/libexec/pk-offline-update
Jul 20 21:54:55 fedora22 systemd[1]: Started Updates the operating system
whilst offline.
Jul 20 21:54:55 fedora22 systemd[1]: Starting Updates the operating system
whilst offline...
fedup-system-upgrade.service uses an additional flag file which is
checked with ConditionPathExists so it will not run if 'dnf fedup reboot'
did not create the flag, even if we go into system-upgrade.target.
packagekit-offline-update.service does not have anything like this, and
is always run in system-upgrade.target.
Running two upgrade mechanisms in parallel does not seem like a good
idea. (Even if they use a lock file to prevent concurrent access to
the rpm database, they are bound to interfere with one another: the
first finishes and decides to reboot, or the first updates some
packages and messes up the state for the second one...) It seems that
*some* mechanism to run only one upgrade mechanism is wanted. The approach
that dnf-plugin-fedup uses seems reasonable: it creates the file only when
a reboot with 'dnf fedup reboot' is requested.
As an alternative we could allow only one upgrade mechanism to be enabled.
Dunno.
... continuing ...
Jul 20 21:55:00 fedora22 pk-offline-update[657]: percentage 14%
Jul 20 21:55:00 fedora22 pk-offline-update[657]: sent msg to plymouth
'Installing Updates - 14%'
Jul 20 21:55:00 fedora22 dnf[655]: bablx86_64
0.1.12-3.fc23@commandline 235 k
Jul 20 21:55:00 fedora22 dnf[655]: baekmuk-bdf-fonts noarch
2.2-17.fc23 @commandline 6.9 M
Jul 20 21:55:00 fedora22 dnf[655]: baekmuk-ttf-batang-fontsnoarch
2.2-39.fc23 @commandline 3.6 M
...
Jul 20 21:55:00 fedora22 pk-offline-update[657]: status download
Jul 20 21:55:00 fedora22 pk-offline-update[657]: package downloading
gstreamer1-1.4.5-1.fc22.x86_64 (fedora)
Jul 20 21:55:00 fedora22 pk-offline-update[657]: status finished
Jul 20 21:55:00 fedora22 pk-offline-update[657]: writing failed results
Jul 20 21:55:00 fedora22 pk-offline-update[657]: failed to update system:
cannot download Packages/g/gstreamer1-1.4.5-1.fc2
...
Jul 20 21:55:16 fedora22 systemd[1]: Trying to enqueue job
reboot.target/start/replace
Jul 20 21:55:16 fedora22 systemd[1]: Job system-update.target/start finished,
result=canceled
Jul 20 21:55:16 fedora22 systemd[1]: Installed new job
system-update.target/stop as 762
...
Jul 20 21:55:16 fedora22 systemd[1]: Spawning new thread for sync
Jul 20 21:55:16 fedora22 systemd[1]: Installed new job time-sync.target/stop as
736
Jul 20 21:55:16 fedora22 systemd[1]: Installed new job
lvm2-lvmetad.service/stop as 753
Jul 20 21:55:16 fedora22 systemd[1]: Job fedup-system-upgrade.service/start
finished, result=canceled
Jul 20 21:55:16 fedora22 systemd[1]: Installed new job
fedup-system-upgrade.service/stop as 769
Jul 20 21:55:16 fedora22 systemd[1]: Enqueued job reboot.target/start as 658
Jul 20 21:55:16 fedora22 systemd[1]: packagekit-offline-update.service failed.
...
Jul 20 21:55:11 fedora22 systemd[1]: packagekit-offline-update.service: main
process exited, code=exited, status=1/FAILURE
Jul 20 21:55:11 fedora22 systemd[1]:
