Re: [systemd-devel] Manpage updates
On Monday 2013-07-15 07:17, David Strauss wrote: >On Sun, Jul 14, 2013 at 4:19 PM, Jan Engelhardt wrote: >>[recipe on how I generated the patches] > >Please cut the snark; it's not welcome here. You sent your submission >into this list 12 days ago with no summary beyond what's obvious from >the diffstat. That is not true. There is a, even if short, three-point list summarizing the edits by category, above the diffstat in http://lists.freedesktop.org/archives/systemd-devel/2013-July/011665.html , just like git-send-email outputs it. >If you want feedback or to get your work committed, provide it in a way >that's easy to review. The established method on this list is git >send-email [1], though there's flexibility around non-git unified diff >patches, too. Other members of this list may be more charitable, but >I'm not going to spend time cloning your repository, creating the >patch, and posting it here so it's convenient for everyone to review. Excuse me?! I did use git-send-email (together with --compose and placing git-request-pull's output into the cover mail). If you do not believe it, you should check the headers in the mbox file that mailman keeps. In the archives, you will also see that the patch _was_ in fact posted (011665.html) and not just a bare pull request (011664.html). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Unbuffered stderr for my systemd service?
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 :) Here's my foobar.service: -- [Service] Type=oneshot ExecStart=-/bin/foobar.sh StandardInput=null StandardOutput=syslog StandardError=syslog+console -- My foobar.sh: -- #!/bin/sh echo "Here we go" for i in `seq 1 10`; do echo -n a >&2 sleep 0.1 done -- If run `/bin/foobar.sh` directly, I get char 'a' popping up to console one by one each 0.1 second. And this is what I expect. But if I run `systemctl restart foobar.service`, a string "aa" altogether pops up after 1 second. I've got a ugly workaround by redirecting stderr to /dev/console. However, I lost the systemd journal feature though :( I look into the systemd.exec(5), it says in the "StandardOutput=" part: "[..]syslog+console, journal+console and kmsg+console work similarly but copy the output to the system console as well" So systemd first write to syslog/journal then copy the output to console. And it looks like systemd would use line buffering for both stdout and stderr. I'm wondering if there's a way to change the output buffer mode to unbuffered for a systemd service. If not, should systemd change stderr buffer mode to unbuffered? Like the most common situations in Linux. Also I want to mention that with line buffering, it's impossible to update information in-place (something like calling times of echo -e "blah\r", later output will override the former one). Any comments are welcome! Thanks! WANG Chao ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Manpage updates
'Twas brillig, and Jan Engelhardt at 15/07/13 09:23 did gyre and gimble: >> >If you want feedback or to get your work committed, provide it in a way >> >that's easy to review. The established method on this list is git >> >send-email [1], though there's flexibility around non-git unified diff >> >patches, too. Other members of this list may be more charitable, but >> >I'm not going to spend time cloning your repository, creating the >> >patch, and posting it here so it's convenient for everyone to review. > Excuse me?! I did use git-send-email (together with --compose and > placing git-request-pull's output into the cover mail). If you do not > believe it, you should check the headers in the mbox file that mailman > keeps. In the archives, you will also see that the patch _was_ in fact > posted (011665.html) and not just a bare pull request (011664.html). Also Zbigniew already committed it just 12 hours after the initial post so no need to do any further review (well, more review is obviously always nice!) I think some threading/mail client mixup on David's part has resulted in him not seeing all that was posted to the list which was done pretty much exactly how things should be done (the only confusion being the cover mail which talked about another repo etc. but that's certainly not "wrong"!) All the best. 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] Manpage updates
On Mon, Jul 15, 2013 at 12:28 PM, Colin Guthrie wrote: > I think some threading/mail client mixup on David's part has resulted in > him not seeing all that was posted Most probably due to GMail (or something similar) ignoring In-Reply-To, and instead grouping messages by Subject. -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] journald tiered logging for embedded system with flash?
Hello. I'm looking at journald.conf for a way to log all messages to ram but only messages lower than a certain level to disk (which in this case is flash and is slow/has a limited number of write cycles). I see MaxLevelStore etc and Storage but I don't see any combination that would work as desired. I tried to find information about embedded use of journald via a web search but nothing came up. Chris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2, ping?] tmpfiles, man: Add xattr support to tmpfiles
This patch makes it possible to set extended attributes on files created
by tmpfiles. This can be especially used to set SMACK security labels on
volatile files and directories.
It is done by adding new line of type "t". Such line should contain
attributes in Argument field, using following format:
name=value
All other fields are ignored.
If value contains spaces, then it must be surrounded by quotation marks.
User can also put quotation mark in value by escaping it with backslash.
Example:
D /var/run/cups - - - -
t /var/run/cups - - - - security.SMACK64=printing
---
I've used "t" because IMHO "a" will be better for acl. To sum up: when
"t" is met and it's not in hashmap, then it will be added. Then if other
line for the same file appears, then it replaces SET_XATTR item in
hashmap and has extended attributes added. If item earler existed in
hashmap, then extended attributes are merged to existing entry. This
means that there can be more than one "t" lines for one file. There is
also posibility to have standalone "t" line. I hope that this is desired
behaviour.
regards,
Maciej
---
man/tmpfiles.d.xml | 26 -
src/tmpfiles/tmpfiles.c | 274 ++--
2 files changed, 285 insertions(+), 15 deletions(-)
diff --git a/man/tmpfiles.d.xml b/man/tmpfiles.d.xml
index 519f9bc..92157b5 100644
--- a/man/tmpfiles.d.xml
+++ b/man/tmpfiles.d.xml
@@ -229,6 +229,21 @@ L/tmp/foobar ----
/dev/null
place of normal path
names.
+
+
+t
+Set extended
+attributes on item. It should be
+used with conjunction with other
+types (only d, D, f, F, L, p, c, b, z
+makes sense). If used as a standalone
+line, then systemd-tmpfiles
+ will try to set extended
+attributes on specified path.
+This can be especially used to set
+SMACK labels.
+
+
@@ -242,7 +257,7 @@ L/tmp/foobar ----
/dev/null
objects. For z, Z lines if omitted or when set
to - the file access mode will not be
modified. This parameter is ignored for x, r,
-R, L lines.
+R, L, t lines.
@@ -254,7 +269,7 @@ L/tmp/foobar ----
/dev/null
omitted or when set to - the default 0 (root)
is used. For z, Z lines when omitted or when set to -
the file ownership will not be modified.
-These parameters are ignored for x, r, R, L
lines.
+These parameters are ignored for x, r, R, L, t
lines.
@@ -307,8 +322,10 @@ L/tmp/foobar ----
/dev/null
minor formatted as integers, separated by :,
e.g. "1:3". For f, F, w may be used to specify
a short string that is written to the file,
-suffixed by a newline. Ignored for all other
+suffixed by a newline. Fot t determines extended
+attributes to be set. Ignored for all other
lines.
+
@@ -320,7 +337,8 @@ L/tmp/foobar ----
/dev/null
screen needs two directories
created at boot with specific modes and ownership.
d /var/run/screens 1777 root root 10d
-d /var/run/uscreens 0755 root root 10d12h
+d /var/run/uscreens 0755 root root 10d12h
+t /var/run/screen - - - - user.name="John Koval"
security.SMACK64=screen
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 555347a..098413f 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -39,6 +39,9 @@
#include
#include
#include
+#ifdef HAVE_XATTR
+#include
+#endif
#include "log.h"
#include "util.h"
@@ -75,7 +78,10 @@ typedef enum ItemType {
REMOVE_PATH = 'r',
RECURSIVE_REMOVE_PATH = 'R',
RELABEL_PATH = 'z',
-RECURSIVE_RELABEL_PATH = 'Z'
+RECURSIVE_RELABEL_PATH = 'Z',
+
+/* These ones are options/additional operations */
+SET_XATTR = 't'
} ItemType;
typedef struct Item {
@@ -83,
Re: [systemd-devel] journald tiered logging for embedded system with flash?
Hi Chris, As far as I know journal doesn't have per log severity storage option setting. But you could use an external logging program like rsyslog to do what you would like to do. In your case, journal forwards messages with desired severity to the rsyslog and rsyslog stores messages in flash. If you are resource limited you could implement your own application to fetch messages from a datagram socket (syslog.socket) and write them on flash. Take a look at following tokens in journald.conf Storage=volatile MaxLevelSyslog= ForwardToSyslog= Thanks, On Mon, Jul 15, 2013 at 2:27 PM, Chris Morgan wrote: > Hello. > > I'm looking at journald.conf for a way to log all messages to ram but > only messages lower than a certain level to disk (which in this case > is flash and is slow/has a limited number of write cycles). I see > MaxLevelStore etc and Storage but I don't see any combination that > would work as desired. > > I tried to find information about embedded use of journald via a web > search but nothing came up. > > Chris > ___ > 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] fstab Mounts Not Getting Waken Up
Andrey Borzenkov: В Fri, 12 Jul 2013 10:00:32 -0700 cac...@quantum-sci.com пишет: Reindl Harald: the example settings below mean i have 30 seconds which my ssh-tunnels and connections are surviving network downtime for whatever reason Server (/etc/ssh/sshd_config): TCPKeepAlive yes KeepAlive yes ClientAliveCountMax 10 ClientAliveInterval 20 Client (/etc/ssh/ssh_config or ~/.ssh/config) KeepAlive yes ServerAliveCountMax 10 ServerAliveInterval 20 __ this is *really* not a systemd problem Thank you, I'll give it a try. All I knew was this started when I went to a systemd distro. Which means you changed far more than just systemd. I suspect your old distribution was using pm-utils to remount (network-)fileystems across suspend/resume and new distro does not. In this case systemd still provides hooks so you can call similar scripts if needed. Which means it is something else, because --this does not work--. ___ 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, Jul 15, 2013 at 05:56:29PM +0800, WANG Chao 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 :) > > Here's my foobar.service: > -- > [Service] > Type=oneshot > ExecStart=-/bin/foobar.sh > StandardInput=null > StandardOutput=syslog > StandardError=syslog+console > -- > > My foobar.sh: > -- > #!/bin/sh > echo "Here we go" > for i in `seq 1 10`; do > echo -n a >&2 > sleep 0.1 > done > -- > > If run `/bin/foobar.sh` directly, I get char 'a' popping up to console > one by one each 0.1 second. And this is what I expect. > > But if I run `systemctl restart foobar.service`, a string "aa" > altogether pops up after 1 second. > > I've got a ugly workaround by redirecting stderr to /dev/console. > However, I lost the systemd journal feature though :( > > I look into the systemd.exec(5), it says in the "StandardOutput=" part: > "[..]syslog+console, journal+console and kmsg+console work similarly but > copy the output to the system console as well" > > So systemd first write to syslog/journal then copy the output to > console. And it looks like systemd would use line buffering for both > stdout and stderr. > > I'm wondering if there's a way to change the output buffer mode to > unbuffered for a systemd service. > > If not, should systemd change stderr buffer mode to unbuffered? Like the > most common situations in Linux. > > Also I want to mention that with line buffering, it's impossible to > update information in-place (something like calling times of echo -e > "blah\r", later output will override the former one). 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. Thanks Vivek > > Any comments are welcome! Thanks! > WANG Chao ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] PATCH: handle ncp just like ncpfs in fstab-generator
Hi all, the attached patch fixes an issue with ncp mount points not being recognized as network mount points (ncp is alias for ncpfs). -- Frederic Crozat SUSE >From 6bf298c8626cbfc3c3b0bd92fd2437260ce7610c Mon Sep 17 00:00:00 2001 From: Frederic Crozat Date: Mon, 15 Jul 2013 10:27:31 +0200 Subject: [PATCH] util: recognize 'ncp' as an alias to 'ncpfs' ncp is also used for Netware mount point, recognize it as such. Fixes https://bugzilla.novell.com/show_bug.cgi?id=828905. --- src/shared/util.c | 1 + 1 file changed, 1 insertion(+) Index: systemd-195/src/shared/util.c === --- systemd-195.orig/src/shared/util.c +++ systemd-195/src/shared/util.c @@ -2114,6 +2114,7 @@ bool fstype_is_network(const char *fstyp "cifs\0" "smbfs\0" "ncpfs\0" +"ncp\0" "nfs\0" "nfs4\0" "gfs\0" ___ 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, Jul 15, 2013 at 5:32 PM, Vivek Goyal wrote:
> 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.
The journal works the same way as syslog has worked for ages – have
you ever seen an animated progress bar in your /var/log/syslog? I'd
guess no, because syslog wouldn't accept it, and most services do not
display those in the first place – they either write periodic *full*
messages (e.g. every 10%) to the log, or have a way to check progress
via their own fooservicectl tools. systemd also provides a way to
display arbitrary text in `systemctl status` using the "notify"
feature; see systemd-notify(1) and sd_notify(3).
The only exception I can think of is the boot fsck service
(systemd-fsck@.service), which needs to run before `systemctl` or the
syslog become accessible. And it uses /dev/console for this:
console = fopen("/dev/console", "w");
…
while (!feof(f)) {
…
p = percent(pass, cur, max);
fprintf(console, "\r%s: fsck %3.1f%% complete...\r%n",
device, p, &m);
fflush(console);
…
}
--
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] detect-virt: detect User-Mode Linux
In a User-Mode Linux session:
$ systemd-detect-virt
none
Although it is possible to reliably detect virtualization:
$ cat /proc/cpuinfo
processor : 0
vendor_id : User Mode Linux
model name : UML
mode: skas
host: Linux kytes 3.11.0-rc1-9-ge5fd680 (...)
bogomips: 7007.43
So, grep for the string "User Mode Linux" in /proc/cpuinfo, and say
"uml" when asked.
Cc: Lennart Poettering
Signed-off-by: Ramkumar Ramachandra
---
It seems that UM does not have a proper tty system; I force
systemd to use the /dev/console by doing:
$ mv
/etc/systemd/system/getty.target.wants/{getty@tty1.service,getty@console.service}
The first step towards supporting UM properly is to detect it, right?
So, here's a small patch. I tested it briefly.
src/shared/virt.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/shared/virt.c b/src/shared/virt.c
index 1c86a3d..25b3016 100644
--- a/src/shared/virt.c
+++ b/src/shared/virt.c
@@ -67,6 +67,7 @@ int detect_vm(const char **id) {
const char *j, *k;
bool hypervisor;
_cleanup_free_ char *hvtype = NULL;
+_cleanup_free_ char *cpuinfo_contents = NULL;
int r;
/* Try high-level hypervisor sysfs file first:
@@ -164,6 +165,16 @@ int detect_vm(const char **id) {
}
#endif
+
+/* Detect User-Mode Linux by reading /proc/cpuinfo */
+r = read_full_file("/proc/cpuinfo", &cpuinfo_contents, NULL);
+if (r < 0)
+return r;
+if (strstr(cpuinfo_contents, "User Mode Linux")) {
+*id = "uml";
+return 1;
+}
+
return 0;
}
--
1.8.3.2.736.g869de25
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] detect-virt: detect User-Mode Linux
On Mon, Jul 15, 2013 at 10:33:13PM +0530, Ramkumar Ramachandra wrote: > In a User-Mode Linux session: > > $ systemd-detect-virt > none > > Although it is possible to reliably detect virtualization: > > $ cat /proc/cpuinfo > processor : 0 > vendor_id : User Mode Linux > model name : UML > mode: skas > host: Linux kytes 3.11.0-rc1-9-ge5fd680 (...) > bogomips: 7007.43 > > So, grep for the string "User Mode Linux" in /proc/cpuinfo, and say > "uml" when asked. Could you extend ConditionVirtualization= with ”uml”, also? -- Tomasz Torcz Morality must always be based on practicality. xmpp: zdzich...@chrome.pl-- Baron Vladimir Harkonnen ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v3] 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 | 28
src/shared/util.h | 1 +
5 files changed, 45 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 @@
+_CAP_EFFECTIVE=
+
+The effective
capabilities7
of
+the process the journal entry
+originates from.
+
+
+
+
_AUDIT_SESSION=
_AUDIT_LOGINUID=
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..66bfdc8 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -726,6 +726,34 @@ 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, "CapEff:\t");
+if (!t)
+return -ENOENT;
+
+*capeff = strndup(t + strlen("CapEff:\t"), 16);
+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] detect-virt: detect User-Mode Linux
On Mon, 15.07.13 19:27, Tomasz Torcz (to...@pipebreaker.pl) wrote: > On Mon, Jul 15, 2013 at 10:33:13PM +0530, Ramkumar Ramachandra wrote: > > In a User-Mode Linux session: > > > > $ systemd-detect-virt > > none > > > > Although it is possible to reliably detect virtualization: > > > > $ cat /proc/cpuinfo > > processor : 0 > > vendor_id : User Mode Linux > > model name : UML > > mode: skas > > host: Linux kytes 3.11.0-rc1-9-ge5fd680 (...) > > bogomips: 7007.43 > > > > So, grep for the string "User Mode Linux" in /proc/cpuinfo, and say > > "uml" when asked. > > Could you extend ConditionVirtualization= with ”uml”, also? That happens implicitly if detect_vm() is updated. 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] kmod-static-nodes.service doesn't care about udev?
On Fri, Jul 12, 2013 at 7:57 PM, Zbigniew Jędrzejewski-Szmek 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] Manpage updates
On Mon, Jul 15, 2013 at 4:32 AM, Tom Gundersen wrote: > Most probably due to GMail (or something similar) ignoring > In-Reply-To, and instead grouping messages by Subject. Oh, my apologies! I do use GMail, and all I saw was the "[systemd-devel] Manpage updates" message with no replies or patches. I assumed it was the only submission to the list, which seemed consistent with Jan's reply to my request. I'll break out Evolution next time before jumping to conclusions. Again, sorry. --David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Broken build and CI strategy
On Sun, Jul 14, 2013 at 10:40 PM, Holger Hans Peter Freyther wrote: > Maybe do "echo 'Not running tests as they always fail in this setup.'" > is better? There were several fanboys sending me private mail claiming > that the tests were run because of the 'make test'. Done. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ 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] Unbuffered stderr for my systemd service?
On Mon, Jul 15, 2013 at 10:47:23PM +0200, Lennart Poettering wrote: > 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... That's fine. But that means services have to change now. In the past stdout/stderr was not logged by default. So fancy outputs could go to stdout/stderr without any issues. Now stdout/stderr is being logged. Well, for my use case change is easy and we have already done it. So we will stick to it. Thanks Vivek ___ 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 16:54, Vivek Goyal (vgo...@redhat.com) wrote: > > On Mon, Jul 15, 2013 at 10:47:23PM +0200, Lennart Poettering wrote: > > 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... > > That's fine. But that means services have to change now. In the > past stdout/stderr was not logged by default. So fancy outputs could > go to stdout/stderr without any issues. Now stdout/stderr is being > logged. Yupp, this indeed is a change of behaviour due to system. You can revert to the old behaviour by using StandardOutput=console or so, but you already figured that out... ;-) 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] detect-virt: detect User-Mode Linux
On Mon, 15.07.13 22:33, Ramkumar Ramachandra (artag...@gmail.com) wrote: > In a User-Mode Linux session: > > $ systemd-detect-virt > none > > Although it is possible to reliably detect virtualization: > > $ cat /proc/cpuinfo > processor : 0 > vendor_id : User Mode Linux > model name : UML > mode: skas > host: Linux kytes 3.11.0-rc1-9-ge5fd680 (...) > bogomips: 7007.43 > > So, grep for the string "User Mode Linux" in /proc/cpuinfo, and say > "uml" when asked. Looks pretty good! Just one change request: I am a bit afraid that the check is a bit too broad. I'd really prefer if we could at least check that this occurs on a line of its own. Maybe look for "\nvendor_id", then skip all spaces from there, and check if this is followed by ": User Mode Linux\n"? That should be a pretty safe check I figure, since newlines are used as field separators in the file and it appears unlikely that they'd appear unescaped in any of the other fields... And it would still grant the kernel folks the right to add more inner spaces for alignment if they wish... (also, probably needs some minor man page additions) Thanks! 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: handle ncp just like ncpfs in fstab-generator
On Mon, 15.07.13 18:33, Frederic Crozat (fcro...@suse.com) wrote: > Hi all, > > the attached patch fixes an issue with ncp mount points not being > recognized as network mount points (ncp is alias for ncpfs). Thanks! Applied! 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:
> +
> +t
> +Set 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] journald tiered logging for embedded system with flash?
On Mon, 15.07.13 08:27, Chris Morgan (chmor...@gmail.com) wrote: > Hello. > > I'm looking at journald.conf for a way to log all messages to ram but > only messages lower than a certain level to disk (which in this case > is flash and is slow/has a limited number of write cycles). I see > MaxLevelStore etc and Storage but I don't see any combination that > would work as desired. We currently do not support a scheme like this. We either usr /var, or we use /run, but not both. I see the usecase though, and it sounds like a worthwile addition, and due to journalctl's automatic interleaving would be pretty seamless. Added to the TODO list! 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 v3] journal: add logging of effective capabilities _CAP_EFFECTIVE
On Mon, 15.07.13 10:44, Shawn Landden (shawnland...@gmail.com) wrote:
> +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, "CapEff:\t");
> +if (!t)
> +return -ENOENT;
Hmm, I am a bit concerned about broad checks like this, I'd always
prefer if we could at least look for a newline before and after the
relevant line. In this case this should be simple to fix, by looking for
"\nCapEff:\t". Otherwise, an evil user might be able to change the name
of its process to "CappEff\t" and our code would be throughly confused
and parse the wrong line from the file...
\n is used as record separator by the kernel here, so let's rely on
this. If the process name includes a \n, then it's the job of the kernel
to escape it.
> +
> +*capeff = strndup(t + strlen("CapEff:\t"), 16);
> +if (!*capeff)
> +return -ENOMEM;
The number of capabilities is probably going to grow over time. I am a
bit concerned of always just reading 16 bytes here... Better: read until
the next newline.
Hmm, and if we take the strings 1:1 then there is the problem that if
the number of caps is increased, then they search keys might need to
change over time too, which sucks for compatibility reasons. Hence I'd
recommend simply dropping all initial "0" chars (except for the entirely
empty caps set where i'd leave one "0" in). That way there's exactly one
representation for each capability set, instead of many, if you follow
what I mean.
Example:
On a current kernel a process might have the CapEff field set to
"003f". If the kernel caps set size is one day increased to
twice the number of bits we'd read "003f"
instead. Both are the exact same sets though. Hence if you look for the
value made on a new kernel you couldn't find the entries of the old one
anymore, and vice versa. Hence my recommendation to store this as
"3f" instead, which avoids this ambuigity. Hope that makes
sense?
Otherwise looks fine.
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
Re: [systemd-devel] Forward systemd's sleep.target to a systemd user session
On Sun, 14.07.13 08:59, Jörg Thalheim (jo...@higgsboson.tk) wrote: > Am 12.07.2013 00:51, schrieb Lennart Poettering: > > On Wed, 10.07.13 21:04, Jörg Thalheim (jo...@higgsboson.tk) wrote: > > > >> How I can trigger sleep.target in systemd --user session? > > What precisely are you trying to do with this? > >> My use case is to logout my jabber client before suspend (I hope this > >> does not sounds to trivial compared to your serious problems, but you > >> might come up with other use cases). > > It's probably a better idea to patch the client to use a delay inhibitor > > for this: > > > > http://www.freedesktop.org/wiki/Software/systemd/inhibit/ > > Inhibitor locks seams to be the perfect answer. > Is "systemd --user" aware of this feature? No. The inhibitor lock stuff is an API for programs to use, regardless of user apps or system services. > It would be useful to spawn a service/unit before suspend/shutdown. Well, this is not supported and is much nastier than it sounds due to the security issues related to allowing user processes to block suspend. We cannot allow this undefinitely to normal users. The inhibition stuff for delay blockers cares for all that, but it is an API, not something you can use to run arbitrary processes then. There's currently no nice solution for your problem I fear. 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 1/3 v2] cryptsetup: Move password query out of main
On Sat, 13.07.13 13:19, Jan Janssen (medhe...@web.de) wrote: > Also use _cleanup_free_ where possible. Applied all three! Thanks a ton! 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] "No such file or directory" when enabling a service
On Thu, 27.06.13 20:14, Lars Kellogg-Stedman (l...@oddbit.com) wrote: > I'm running systemd 204 under Fedora 19 (beta). I have > /etc/systemd/system/postfix-update-hook.service installed as a symlink > to /etc/postfix/support/postfix-update-hook.service. > > I can start it: > > # systemctl start postfix-update-hook > > And check the status: > > # systemctl status postfix-update-hook > postfix-update-hook.service >Loaded: loaded (/etc/postfix/support/postfix-update-hook.service; > linked) >Active: active (running) since Thu 2013-06-27 19:59:28 UTC; 25s ago > Main PID: 19276 (postfix-update-) >CGroup: name=systemd:/system/postfix-update-hook.service >└─19276 /bin/sh /etc/postfix/support/postfix-update-hook > > But I can't enable it: > > # systemctl enable postfix-update-hook > Failed to issue method call: No such file or directory > > If I replace the symlink in /etc/systemd/system with an actual file, > then it works just fine: > > # cd /etc/systemd/system > # mv postfix-update-hook.service postfix-update-hook.service.symlink > # cp postfix-update-hook.service.symlink postfix-update-hook.service > # systemctl enable postfix-update-hook > ln -s '/etc/systemd/system/postfix-update-hook.service' > '/etc/systemd/system/multi-user.target.wants/postfix-update-hook.service' > > Is this expected behavior? Yes. "enable" is fir managing the symlinks in /etc really, and it does so based on the data in unit files themselves. But it won't use the symlinks to find those units, because that would not be symmetric anymore so that enable and disable would work be complimentary... 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 @@
+_CAP_EFFECTIVE=
+
+The effective
capabilities7
of
+the process the journal entry
+originates from.
+
+
+
+
_AUDIT_SESSION=
_AUDIT_LOGINUID=
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 > > 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] runtime directories for services vs. tmpfiles
2013/7/16 Michael Biebl : > 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/. Bah, sorry for the confusion: I meant 2/ over 1/. I.e. we recommended to use a tmpfiles snippet over ExecStartPre ___ 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 > > > > 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 @@
>
>
>
> +
> _CAP_EFFECTIVE=
> +
> +The effective
> capabilities7
> of
> +the process the journal entry
> +originates from.
> +
> +
> +
> +
>
> _AUDIT_SESSION=
>
> _AUDIT_LOGINUID=
>
> 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 > wrote: > > > 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
