Re: [systemd-devel] kmod-static-nodes.service doesn't care about udev?
On Fri, Jul 12, 2013 at 7:57 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: I see another problem: in a container, this unit fails with: # /usr/bin/kmod static-nodes --format=tmpfiles --output=/run/tmpfiles.d/kmod.conf Error: could not open /lib/modules/3.9.6-301.fc19.x86_64/modules.devname - No such file or directory There was no requirement to have the kernel installation available before, and it'd be stupid to add it just for that. This has been fixed in kmod git. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unbuffered stderr for my systemd service?
On Mon, 15.07.13 17:56, WANG Chao (chaow...@redhat.com) wrote: Hi, I have a service (a script) running under systemd and need its stderr to be output'd immediately, not line buffered. I tried serveral ways but didn't work out. I hope to get some feedback here :) This is not supported. Logging doesn't deal in individual characters, really, but in log lines. Syslog doesn't do that, and neither does the Journal. And we will never support that, as allowing this would require us to always store the context a character was printed in so that lines could later be reassembled. But we cannot really do that. So, I fear I have to tell you that this is not supported and never will... Here's my foobar.service: (Humm, please do not use -- on a single line in the middle of an email, that's indication for many MUAs that this is where the signature starts, and they chop this off when replying...) Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unbuffered stderr for my systemd service?
On Mon, 15.07.13 10:32, Vivek Goyal (vgo...@redhat.com) wrote: CCing Lennart. This is important functionality for us. makeudmpfile utility (utility which filters kernel crash dump and shows the progress bar), run in kdump kernel. For large machines it displays the progress bar in kernel. Right now all the code runs from initramfs in the context of a service and we don't get progress messages. Just we get a 100% message at the end. Right now we bypassed journal by sending everything to /dev/console but it is a generic question that any serivce displaying some kind of progress bar, how is it handled with current journal mechanism. if you want to do fancier output then do facnier ouput directly on the console, but do not pumpt this through a log system, that's really not what it is for... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2, ping?] tmpfiles, man: Add xattr support to tmpfiles
On Mon, 15.07.13 15:22, Maciej Wereski (m.were...@partner.samsung.com) wrote: +varlistentry +termvarnamet/varname/term +listitemparaSet extended +attributes on item. It should be +used with conjunction with other Well, I'd use the wording may be used, not should be used here... +if (!i-xattrs) +return 0; We usually use strv_isempty() for that, which checks a bit more, but this doesn't really matter in this case... +STRV_FOREACH(x, i-xattrs) { +value = *x; +name = strsep(value, =); I'd really prefer if we didn't corrupt the string here. Maybe use strv_split_quoted() here? That handles all the values for you anyway... +n = strlen(value); +if (i-type == CREATE_SYMLINK) { +if (lsetxattr(path, name, value, n+1, 0) 0) { +log_error(Setting extended attribute %s=%s on symlink %s failed: %m, name, value, path); +free(value); +return -errno; +} +} +else if (setxattr(path, name, value, n+1, 0) 0) { +log_error(Setting extended attribute %s=%s on %s failed: %m, name, value, path); +free(value); +return -errno; +} +free(value); Hmm, the two if branches look like something you could combine further: if (i-type == CREATE_SYMLINK) r = lsetxattr(...); else r = setxattr(...); And note that log_error() guarantees that errno stays untouched. +if (i-xattrs) { +r = item_set_xattrs(i, i-path); +if (r 0) +return r; +} Checking i-xattrs outside and inside the function is redundand, no? +for (n = 0; n strv_length(tmp); ++n) { +len = strlen(tmp[n]); +strncpy(xattr, tmp[n], len+1); +p = strchr(xattr, '='); +if (!p) { +log_error(%s: Attribute has incorrect format., i-path); +return -EBADMSG; +} +if (p[1] == '\') { +while (true) { +if (!p) +p = tmp[n]; +else +p += 2; +p = strchr(p, '\'); +if (p xattr[p-xattr-1] != '\\') +break; +p = NULL; +++n; +if (n == strv_length(tmp)) +break; +len += strlen(tmp[n]) + 1; +strncat(xattr, , 1); +strncat(xattr, tmp[n], len); +} +} +strstrip(xattr); +f = i-xattrs; +i-xattrs = strv_append(i-xattrs, xattr); +if (!i-xattrs){ +strv_free(f); +return log_oom(); +} For this stuf I'd really prefer using one of our already existing quoting APIs, like strv_spit_quoted() or FOREACH_WORD_QUOTED or so. int r = 0, k; _cleanup_globfree_ glob_t g = {}; @@ -674,6 +799,12 @@ static int create_item(Item *i) { if (r 0) return r; +if (i-xattrs) { +r = item_set_xattrs(i, i-path); +if (r 0) +return r; +} + item_set_xattrs already checks i-xattrs for empty anyway, so this could be shortened quite a bit (as above and a couple of more times) +static int copy_item_contents(Item *dest, const Item *src) { Hmm, not following why you need to copy any items ever. Either you add a new item, or you patch the existing one, but why ever copy one? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix assertions while disabling unexisting target units
On Mon, 15.07.13 05:00, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: # systemctl enable kmsconvt@tty5.service ln -s '/etc/systemd/system/kmsconvt@.service' '/etc/systemd/system/getty.target.wants/kmsconvt@tty5.service' # systemctl disable kmsconvt@tty5.service rm '/etc/systemd/system/autovt@.service' rm '/etc/systemd/system/getty.target.wants/kmsconvt@.service' rm '/etc/systemd/system/getty.target.wants/kmsconvt@tty5.service' Basically the whole idea of removing all symlinks pointing to the template is borked. Hmm, this really looks wrong. I figure disabling an instance should just remove that symlink, and disabling a template should remove all instances. Added to the TODO list so that we don't forget about this. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v4] journal: add logging of effective capabilities _CAP_EFFECTIVE
I think this is the most important of the capabilities bitmasks to log. --- TODO | 2 -- man/systemd.journal-fields.xml | 9 + src/journal/journald-server.c | 7 +++ src/shared/util.c | 34 ++ src/shared/util.h | 1 + 5 files changed, 51 insertions(+), 2 deletions(-) diff --git a/TODO b/TODO index 5d4ba8f..0782038 100644 --- a/TODO +++ b/TODO @@ -208,8 +208,6 @@ Features: * teach ConditionKernelCommandLine= globs or regexes (in order to match foobar={no,0,off}) -* we should log capabilities too - * Support SO_REUSEPORT with socket activation: - Let systemd maintain a pool of servers. - Use for seamless upgrades, by running the new server before stopping the diff --git a/man/systemd.journal-fields.xml b/man/systemd.journal-fields.xml index ed62edc..452406c 100644 --- a/man/systemd.journal-fields.xml +++ b/man/systemd.journal-fields.xml @@ -197,6 +197,15 @@ /varlistentry varlistentry +termvarname_CAP_EFFECTIVE=/varname/term +listitem +paraThe effective citerefentryrefentrytitlecapabilities/refentrytitlemanvolnum7/manvolnum/citerefentry of +the process the journal entry +originates from./para +/listitem +/varlistentry + +varlistentry termvarname_AUDIT_SESSION=/varname/term termvarname_AUDIT_LOGINUID=/varname/term listitem diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c index 6beaa8a..332ba41 100644 --- a/src/journal/journald-server.c +++ b/src/journal/journald-server.c @@ -578,6 +578,13 @@ static void dispatch_message_real( IOVEC_SET_STRING(iovec[n++], x); } +r = get_process_capeff(ucred-pid, t); +if (r = 0) { +x = strappenda(_CAP_EFFECTIVE=, t); +free(t); +IOVEC_SET_STRING(iovec[n++], x); +} + #ifdef HAVE_AUDIT r = audit_session_from_pid(ucred-pid, audit); if (r = 0) { diff --git a/src/shared/util.c b/src/shared/util.c index ceee6f2..7e9c8ea 100644 --- a/src/shared/util.c +++ b/src/shared/util.c @@ -726,6 +726,40 @@ int is_kernel_thread(pid_t pid) { return 0; } +int get_process_capeff(pid_t pid, char **capeff) { +const char *p; +_cleanup_free_ char *status = NULL; +char *t = NULL; +int r; + +assert(capeff); +assert(pid = 0); + +if (pid == 0) +p = /proc/self/status; +else +p = procfs_file_alloca(pid, status); + +r = read_full_file(p, status, NULL); +if (r 0) +return r; + +t = strstr(status, \nCapEff:\t); +if (!t) +return -ENOENT; + +for (t += strlen(\nCapEff:\t); t[0] == '0'; t++) +continue; + +if (t[0] == '\n') +t--; + +*capeff = strndup(t, strchr(t, '\n') - t); +if (!*capeff) +return -ENOMEM; + +return 0; +} int get_process_exe(pid_t pid, char **name) { const char *p; diff --git a/src/shared/util.h b/src/shared/util.h index ddb21b4..fac08ca 100644 --- a/src/shared/util.h +++ b/src/shared/util.h @@ -210,6 +210,7 @@ int get_process_cmdline(pid_t pid, size_t max_length, bool comm_fallback, char * int get_process_exe(pid_t pid, char **name); int get_process_uid(pid_t pid, uid_t *uid); int get_process_gid(pid_t pid, gid_t *gid); +int get_process_capeff(pid_t pid, char **capeff); char hexchar(int x) _const_; int unhexchar(char c) _const_; -- 1.8.3.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] RFC: journald: Allow to cache the cg_get_root_path
On Thu, 27.06.13 18:30, Holger Hans Peter Freyther (hol...@freyther.de) wrote: From: Holger Hans Peter Freyther hol...@moiji-mobile.com Allow to cache the cg_get_root_path and introduce a new method cg_pid_get_path_shifted_with_root that can use the cached version instead of allocating a new string. Sorry for the delay in reviewing. THe general approach of caching the result of cg_get_root_path() is a good one, but I am not fond of placing this in a static variable. We try to avoid that where possible, especially if we have some kind of context object around anyway where we could place this. +if (!cg_root) +return -1; We use negative errno-style errors everywhere for indicating errors, not -1. i.e. please use return -EINVAL or suchlike, but not literal numeric constants. Thanks, Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] configure: add -Wno-cast-align to CFLAGS
these warnings on !x86 arches for good code are annoying, and there is no way to mark the offending code safe, so I guess we are just going to have to deal with the resulting problems as we come across them. Also, these warnings are present for armv6+armv7, when they moreso effect armv5. --- configure.ac | 1 + 1 file changed, 1 insertion(+) diff --git a/configure.ac b/configure.ac index afbe8e9..709262e 100644 --- a/configure.ac +++ b/configure.ac @@ -129,6 +129,7 @@ CC_CHECK_FLAGS_APPEND([with_cflags], [CFLAGS], [\ -Wno-unused-parameter \ -Wno-missing-field-initializers \ -Wno-unused-result \ +-Wno-cast-align \ -Werror=overflow \ -ffast-math \ -fno-common \ -- 1.8.3.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] runtime directories for services vs. tmpfiles
Hi, an interesting issue was raised as part of reviewing a patch for iodione [1], a system service which needs a runtime directory. We thought this might need further dicussion, so reposting the issue to systemd-devel: For system services needing a runtime directory, we basically have two (three) options nowadays 1/ use ExecStartPre=/usr/bin/mkdir /var/run/foo 2/ use a tmpfile snippet (3/ let the daemon create the runtime directory itself) In [1] we recommended the the usage of 1/ over 2/. The main reason for that were, that systemd-tmpfiles properly handles applying security policies, like SELinux labels, and it avoids spawning unnecessary processes (every ExecStartPre=/usr/bin/mkdir is a separate process) Zbyszek is arguing, that splitting the configuration over two files, a tmpfile and a service file, complicates things for the administrator, as things are no longer in a single place. He also argues, that tmpfiles are active, independently of the service, which needs them. Which can lead to unused runtime directories. One suggestion that came up was, to specficy runtime directories in a declarative fashion in the .service file itself, which means it would be only be created if the service itself is enabled. I think this idea warrants further discussion, so I'm posting it here. Michael [1] http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/Week-of-Mon-20130715/000147.html -- 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 1/2] RFC: journald: Allow to cache the cg_get_root_path
On Mon, 08.07.13 18:39, Karol Lewandowski (k.lewando...@samsung.com) wrote: On 06/27/2013 06:30 PM, Holger Hans Peter Freyther wrote: From: Holger Hans Peter Freyther hol...@moiji-mobile.com Allow to cache the cg_get_root_path and introduce a new method cg_pid_get_path_shifted_with_root that can use the cached version instead of allocating a new string. My 2c, I have been thinking about something similar albeit a bit more generic. According to my analysis /proc access is costly and it would be best to cache the result for later use. Difficulty comes from trying to keep cache up to date, though. We can't really cache this. This stuff is already racy, as by the time we read the attributes the process might already be gone. I think the best way to deal with the performance issue here is the stuff discussed here: https://bugzilla.redhat.com/show_bug.cgi?id=963620 i.e. just have the kernel augment our messages with the data we need, unconditionally. That way we fix both the race issue, and the performance issue, since the data is just there and we can make use of it without any further work. I've just started looking into connector's cn_proc which _seem_ to offer all the required functionality (fork, exec, exit notifications). I have to finish my prototype to verify if it's worth complications it brings. cn_proc is asynchronous, so you get even more race problems like this, where processes are already gone by the time you get the message about them. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4] journal: add logging of effective capabilities _CAP_EFFECTIVE
On Mon, 15.07.13 18:10, Shawn Landden (shawnland...@gmail.com) wrote: I think this is the most important of the capabilities bitmasks to log. Applied! Thanks! --- TODO | 2 -- man/systemd.journal-fields.xml | 9 + src/journal/journald-server.c | 7 +++ src/shared/util.c | 34 ++ src/shared/util.h | 1 + 5 files changed, 51 insertions(+), 2 deletions(-) diff --git a/TODO b/TODO index 5d4ba8f..0782038 100644 --- a/TODO +++ b/TODO @@ -208,8 +208,6 @@ Features: * teach ConditionKernelCommandLine= globs or regexes (in order to match foobar={no,0,off}) -* we should log capabilities too - * Support SO_REUSEPORT with socket activation: - Let systemd maintain a pool of servers. - Use for seamless upgrades, by running the new server before stopping the diff --git a/man/systemd.journal-fields.xml b/man/systemd.journal-fields.xml index ed62edc..452406c 100644 --- a/man/systemd.journal-fields.xml +++ b/man/systemd.journal-fields.xml @@ -197,6 +197,15 @@ /varlistentry varlistentry + termvarname_CAP_EFFECTIVE=/varname/term +listitem +paraThe effective citerefentryrefentrytitlecapabilities/refentrytitlemanvolnum7/manvolnum/citerefentry of +the process the journal entry +originates from./para +/listitem +/varlistentry + +varlistentry termvarname_AUDIT_SESSION=/varname/term termvarname_AUDIT_LOGINUID=/varname/term listitem diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c index 6beaa8a..332ba41 100644 --- a/src/journal/journald-server.c +++ b/src/journal/journald-server.c @@ -578,6 +578,13 @@ static void dispatch_message_real( IOVEC_SET_STRING(iovec[n++], x); } +r = get_process_capeff(ucred-pid, t); +if (r = 0) { +x = strappenda(_CAP_EFFECTIVE=, t); +free(t); +IOVEC_SET_STRING(iovec[n++], x); +} + #ifdef HAVE_AUDIT r = audit_session_from_pid(ucred-pid, audit); if (r = 0) { diff --git a/src/shared/util.c b/src/shared/util.c index ceee6f2..7e9c8ea 100644 --- a/src/shared/util.c +++ b/src/shared/util.c @@ -726,6 +726,40 @@ int is_kernel_thread(pid_t pid) { return 0; } +int get_process_capeff(pid_t pid, char **capeff) { +const char *p; +_cleanup_free_ char *status = NULL; +char *t = NULL; +int r; + +assert(capeff); +assert(pid = 0); + +if (pid == 0) +p = /proc/self/status; +else +p = procfs_file_alloca(pid, status); + +r = read_full_file(p, status, NULL); +if (r 0) +return r; + +t = strstr(status, \nCapEff:\t); +if (!t) +return -ENOENT; + +for (t += strlen(\nCapEff:\t); t[0] == '0'; t++) +continue; + +if (t[0] == '\n') +t--; + +*capeff = strndup(t, strchr(t, '\n') - t); +if (!*capeff) +return -ENOMEM; + +return 0; +} int get_process_exe(pid_t pid, char **name) { const char *p; diff --git a/src/shared/util.h b/src/shared/util.h index ddb21b4..fac08ca 100644 --- a/src/shared/util.h +++ b/src/shared/util.h @@ -210,6 +210,7 @@ int get_process_cmdline(pid_t pid, size_t max_length, bool comm_fallback, char * int get_process_exe(pid_t pid, char **name); int get_process_uid(pid_t pid, uid_t *uid); int get_process_gid(pid_t pid, gid_t *gid); +int get_process_capeff(pid_t pid, char **capeff); char hexchar(int x) _const_; int unhexchar(char c) _const_; Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] configure: add -Wno-cast-align to CFLAGS
On Mon, 15.07.13 18:22, Shawn Landden (shawnland...@gmail.com) wrote: these warnings on !x86 arches for good code are annoying, and there is no way to mark the offending code safe, so I guess we are just going to have to deal with the resulting problems as we come across them. Also, these warnings are present for armv6+armv7, when they moreso effect armv5. Hmm, can you elaborate on the particular places where this happens? I have not been aware of any issues regarding this (not surprising since I am a boring x86 user...) Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unbuffered stderr for my systemd service?
On 07/15/13 at 10:46pm, Lennart Poettering wrote: On Mon, 15.07.13 17:56, WANG Chao (chaow...@redhat.com) wrote: Hi, I have a service (a script) running under systemd and need its stderr to be output'd immediately, not line buffered. I tried serveral ways but didn't work out. I hope to get some feedback here :) This is not supported. Logging doesn't deal in individual characters, really, but in log lines. Syslog doesn't do that, and neither does the Journal. And we will never support that, as allowing this would require us to always store the context a character was printed in so that lines could later be reassembled. But we cannot really do that. So, I fear I have to tell you that this is not supported and never will... I understand that. Record the context of a character is printed would never be a good idea. But still, I feel pity about line buffered stderr stream in Journal :( Here's my foobar.service: (Humm, please do not use -- on a single line in the middle of an email, that's indication for many MUAs that this is where the signature starts, and they chop this off when replying...) Sorry about --, never thought that would be an issue. Thanks for telling! WANG Chao ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] configure: add -Wno-cast-align to CFLAGS
On Mon, Jul 15, 2013 at 07:55:57PM -0700, Shawn wrote: On Mon, Jul 15, 2013 at 7:26 PM, Lennart Poettering lenn...@poettering.netwrote: On Mon, 15.07.13 18:22, Shawn Landden (shawnland...@gmail.com) wrote: these warnings on !x86 arches for good code are annoying, and there is no way to mark the offending code safe, so I guess we are just going to have to deal with the resulting problems as we come across them. Also, these warnings are present for armv6+armv7, when they moreso effect armv5. Hmm, can you elaborate on the particular places where this happens? I have not been aware of any issues regarding this (not surprising since I am a boring x86 user...) Here is the full build log on armhf. I looked at the source for some of these about a year ago, after the udev merge. Basically, you allocate some type to 1-byte aligned, and then you cast it to a type that requries 4-bytes aligned, and on arches that do not support unaligned accesses, Bad Things (tm) happen. I ran systemd on armv5 for quite some time and never had problems, however, but fewer people are probably testing that now. (I don't have the hardware anymore) malloc(3) says functions return a pointer to the allocated memory that is suitably aligned for any kind of variable, which means that the beginning of the struct is maximally aligned, and then individual fields are also aligned, so everything is OK. But when the pointer to the field is cast to (char*) and back, the compiler thinks that the alignment is random. One gets the same stupid output with clang on amd64. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel