Re: [systemd-devel] rc-local.service ordering
On Wed, Mar 2, 2011 at 12:35 AM, Lennart Poettering wrote: > On Wed, 02.03.11 00:07, Andrey Borzenkov (arvidj...@gmail.com) wrote: > >> Have you actually read what I wrote? >> >> "Now, I do not care much about rc-sysinit itself. But I do care that >> services that we want to be started late are *really* started late." >> >> Currently I have impression that rc-local is used as synchronization >> point by explicitly ordering some service after it. My point is >> exactly that this is wrong and if these service need to be started >> late (and I really think some of them need to be started late) some >> other mechanism is required. > > Well, which services are those you believe should be started late? it is not so much about "being started late" as "being executed at specific event before execution continues". Trivial example is fedora-sysinit-(un)hack. On initial startup it creates /etc/.in_sysinit, which is expected to be removed after basic.target is reached (which loosely corresponds to /etc/rc.sysinit in the past). The problem is, we do want file to be removed after everything that basic.target wanted has finished but before anything ordered after basic.target is started. There is no easy way to do it now. or I was just yesterday asked how to start something "after startup is finished". Of course you can add unit ordered After default.target ... except that for him it was broken NFS/autofs mount and he could not login until NFS was restarted. Again - in this case such action would need to hook after - or rather just before - systemd-user-sessions.service, but after everything else that is ordered before is finished. > getty? prefdm? I think it is sufficient to order them against rc-local, > since neither service actually needs to be started that late really. I > see no problem with allowing early logins. Well, I just found that if completion of default.target job is delayed (because some service takes too much time e.g.) logins done before systemd-update-utmp-runlevel has been executed are not entered in wmp. Apparently system never expected that login was possible before run-level had been reached. > In fact I think it is a feature even. Even if it is, the above is indication that it may be unexpected and break things in subtle ways. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] pam: do not leak file descriptor if flock fails
If flock fails, fd is not returned to caller so it cannot clean up.
---
src/pam-module.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/pam-module.c b/src/pam-module.c
index 7f91584..e1a1a50 100644
--- a/src/pam-module.c
+++ b/src/pam-module.c
@@ -198,8 +198,12 @@ static int open_file_and_lock(const char *fn) {
* as the filesystems in question should be local, and only
* locally accessible, and most likely even tmpfs. */
-if (flock(fd, LOCK_EX) < 0)
-return -errno;
+if (flock(fd, LOCK_EX) < 0) {
+int r = -errno;
+
+close_nointr_nofail(fd);
+return r;
+}
return fd;
}
--
tg: (fe783b0..) upstream/pam-flock-fd (depends on: origin/master)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-logger and external syslog daemon
On Wed, Feb 23, 2011 at 10:48 AM, Mike Kazantsev wrote: > How the kmsg-syslogd->rsyslog migration (for systemd output) is supposed > to work? > As I just went through all of it ... you absolutely need rsyslog that supports passing sockets from systemd. Otherwise it is race condition - rsyslog will remove and recreate /dev/log on activation so you end up with a) some processes still connected to removed /dev/log and passing messages to /dev/kmsg this way b) losing some messages for as long as /dev/log does not exist Unless you have rsyslog that really supports it - do not stop systemd-kmsg-syslogd! It will result in process blocking on accessing it creating all sorts of interesting deadlocks. I managed to completely lock out any user this way ... :) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] man: trivial typo in systemd(1)
--- man/systemd.xml |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/man/systemd.xml b/man/systemd.xml index 2c42a02..6b1a4c9 100644 --- a/man/systemd.xml +++ b/man/systemd.xml @@ -269,7 +269,7 @@ syslog, syslog+console, kmsg, -kmsg-console. If the +kmsg+console. If the argument is omitted it defaults to inherit. -- tg: (fe783b0..) upstream/systemd-man-typo (depends on: origin/master) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-logger and external syslog daemon
On Thu, 10 Mar 2011 19:14:29 +0300 Andrey Borzenkov wrote: > On Wed, Feb 23, 2011 at 10:48 AM, Mike Kazantsev wrote: > > > How the kmsg-syslogd->rsyslog migration (for systemd output) is supposed > > to work? > > > > As I just went through all of it ... > > you absolutely need rsyslog that supports passing sockets from > systemd. Otherwise it is race condition - rsyslog will remove and > recreate /dev/log on activation so you end up with > The behaviour I've described is what actually happened to me with git version of rsyslog from the master branch (that's what I meant by "latest scm version") - it's 6-git version. If that doesn't support passsing sockets from systemd, I don't think any other version does ;) I seem to be doing something wrong there though, since it obviously doesn't work for me. Checking rsyslog build system I probably found my mistake - since I've used local unit files and not the ones shipped upstream, I didn't had "--with-systemdsystemunitdir=DIR" enabled, and that option, despite the name, seem to affect all aspects of rsyslog-systemd integration, not just installing unit files. Gotta test it, but looks like that's what I've been missing, thanks for pushing me into the right direction. > a) some processes still connected to removed /dev/log and passing > messages to /dev/kmsg this way > > b) losing some messages for as long as /dev/log does not exist > > Unless you have rsyslog that really supports it - do not stop > systemd-kmsg-syslogd! It will result in process blocking on accessing > it creating all sorts of interesting deadlocks. I managed to > completely lock out any user this way ... :) Yes, I've seen that as well, although never starting kmsg-syslogd seem to work without problems for cases of uncooperative syslogd. -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] pam: do not leak file descriptor if flock fails
On Thu, 10.03.11 17:39, Andrey Borzenkov (arvidj...@gmail.com) wrote: > If flock fails, fd is not returned to caller so it cannot clean up. Applied. 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] man: trivial typo in systemd(1)
On Thu, 10.03.11 20:31, Andrey Borzenkov (arvidj...@gmail.com) wrote: Applied. Thanks! > --- > man/systemd.xml |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/man/systemd.xml b/man/systemd.xml > index 2c42a02..6b1a4c9 100644 > --- a/man/systemd.xml > +++ b/man/systemd.xml > @@ -269,7 +269,7 @@ > syslog, > syslog+console, > kmsg, > -kmsg-console. If the > +kmsg+console. If the > argument is omitted it defaults to > inherit. > 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] systemd-logger and external syslog daemon
On Wed, 23.02.11 12:48, Mike Kazantsev (mk.frag...@gmail.com) wrote: > Good day, > > > I've recently deployed systemd on a machine that uses some syslog > monitoring software and the software went nuts because messages from > systemd logger were inconsistent with other logging - they all look > like this: > > kernel.warning kernel[-]: process[pid]: message contents > > Thus, regardless of what systemd.exec(5) states, SyslogFacility= and > SyslogLevel= is irrelevant - to a syslog daemon they will be passed as > "kernel.warning". Hmm, that is borked. We do provider proper error levels when we write things to kmsg. This must get lost later on. But we do strip the facility, so that it gets replaced by "kernel", that is true. The only reason we strip the facility however is because the "dmesg" tool chokes on it. The kernel is completely fine with it. I think if we'd fix dmesg we should have no trouble with making the kernel log buffer a full featured syslog queue like any other. And the "kernel[-]: " syntax must be from your log implementation, too. What syslog implementation is that? > Naturally, the reason is "systemd-kmsg-syslogd" daemon, which spawns > early on boot from syslog.socket and creates /dev/log, which is > accessed by systemd-logger long before external syslog daemon starts. > Syslog daemon (rsyslog in my case) just grabs these from kmsg. > > After that, substituting /dev/log for another socket (like > rsyslog.socket seem to do) or just removing it doesn't seem to > matter - systemd-logger will keep feeding messages to dmesg via > kmsg-syslogd. Well, not anymore if you use a socket activatable syslog daemon. In that case the original socket is just handed over and rsyslog continues dispatching syslog messages where the bridge left of. > I read Kay Sievers's earlier post in this list on the subject, which > states "Syslog services have been patched to be able to seemlessly take > over an already opened /dev/log. rsyslog is upstream already...". > > Yet I've tried latest scm version of rsyslog and it doesn't seem to > "take over an already opened /dev/log" if started via upstream-shipped > rsyslog.socket unit (which just uses "ListenDatagram=/dev/log") line. it does now, since a couple of days, see my headsup message i posted a few days ago. 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] systemd-logger and external syslog daemon
On Thu, 10.03.11 23:08, Mike Kazantsev (mk.frag...@gmail.com) wrote: > On Thu, 10 Mar 2011 19:14:29 +0300 > Andrey Borzenkov wrote: > > > On Wed, Feb 23, 2011 at 10:48 AM, Mike Kazantsev > > wrote: > > > > > How the kmsg-syslogd->rsyslog migration (for systemd output) is supposed > > > to work? > > > > > > > As I just went through all of it ... > > > > you absolutely need rsyslog that supports passing sockets from > > systemd. Otherwise it is race condition - rsyslog will remove and > > recreate /dev/log on activation so you end up with > > > > The behaviour I've described is what actually happened to me with git > version of rsyslog from the master branch (that's what I meant by > "latest scm version") - it's 6-git version. > If that doesn't support passsing sockets from systemd, I don't think any > other version does ;) rsyslog 5.7.7 contains all the necessary glue code. 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] Add Frugalware prefdm service
On Wed, 09.03.11 01:04, Miklos Vajna (vmik...@frugalware.org) wrote: > Hi, > > The mandrive patches made this local patch fail to apply - which > reminded me to submit the attached patch. :) Hmm, prefdm is not supposed to be standardized name. It's something fedora and mandriva specific, and hence stored in the distro-specific dirs. Since frugalware uses a completely different script (/etc/rc.d/rc.4) it should use a more appropriate name. (What makes me wonder though: why is that script named that way? is really everything it does start a DM?) > PS: Yes, in the long run we want to migrate to separate kdm.service, > gdm.service, etc. - but we're not there yet. Yes, absolutely. 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] Add Frugalware prefdm service
On Thu, Mar 10, 2011 at 10:29:47PM +0100, Lennart Poettering wrote: > Hmm, prefdm is not supposed to be standardized name. It's something > fedora and mandriva specific, and hence stored in the distro-specific > dirs. Exactly, that's why I added the service file in the corresponding subdir, so other distros won't be affected by the change. > Since frugalware uses a completely different script (/etc/rc.d/rc.4) it > should use a more appropriate name. (What makes me wonder though: why is > that script named that way? is really everything it does start a DM?) Yeah, that rc.4 comes from Slackware. :) But it basically just reads /etc/sysconfig/desktop and starts kdm/gdm/etc, nothing else. I'm attaching an updated patch that uses directly the display-manager.service name + avoids calling intro rc.4. Thanks. From 43b129123dd137fa3dae5f9a40e99d4f46eabe81 Mon Sep 17 00:00:00 2001 From: Miklos Vajna Date: Wed, 9 Mar 2011 00:49:47 +0100 Subject: [PATCH] Add Frugalware display-manager service --- Makefile.am |5 + units/frugalware/display-manager.service | 19 +++ 2 files changed, 24 insertions(+), 0 deletions(-) create mode 100644 units/frugalware/display-manager.service diff --git a/Makefile.am b/Makefile.am index f867624..4961424 100644 --- a/Makefile.am +++ b/Makefile.am @@ -353,6 +353,11 @@ dist_systemunit_DATA += \ units/fedora/halt-local.service endif +if TARGET_FRUGALWARE +dist_systemunit_DATA += \ + units/frugalware/display-manager.service +endif + if HAVE_PLYMOUTH dist_systemunit_DATA += \ units/plymouth-start.service \ diff --git a/units/frugalware/display-manager.service b/units/frugalware/display-manager.service new file mode 100644 index 000..d7f237f --- /dev/null +++ b/units/frugalware/display-manager.service @@ -0,0 +1,19 @@ +# This file is part of systemd. +# +# systemd is free software; you can redistribute it and/or modify it +# under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. + +[Unit] +Description=Display Manager +After=syslog.target local.service systemd-user-sessions.service + +Conflicts=splashy-quit.service +After=splashy-quit.service + +[Service] +EnvironmentFile=/etc/sysconfig/desktop +ExecStart=$desktop +Restart=always +RestartSec=0 -- 1.7.4.1 pgps8SX7d5AoU.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add Frugalware prefdm service
On Thu, 10.03.11 23:04, Miklos Vajna (vmik...@frugalware.org) wrote: > +[Service] > +EnvironmentFile=/etc/sysconfig/desktop > +ExecStart=$desktop I don't think this works. You cannot use a variable for the binary path, due to some implications with SELinux. If you want to do it nonetheless use something like the stuff used in rescue.service in the fedora-specific part. 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] Add Frugalware prefdm service
On Fri, Mar 11, 2011 at 12:56:58AM +0100, Lennart Poettering
wrote:
> On Thu, 10.03.11 23:04, Miklos Vajna (vmik...@frugalware.org) wrote:
>
> > +[Service]
> > +EnvironmentFile=/etc/sysconfig/desktop
> > +ExecStart=$desktop
>
> I don't think this works.
Don't worry, I tested it before submitting. :)
> You cannot use a variable for the binary
> path, due to some implications with SELinux. If you want to do it
> nonetheless use something like the stuff used in rescue.service in the
> fedora-specific part.
Oh - then I didn't notice that as SELinux is disabled in Frugalware by
default.
Updated patch attached.
Thanks!
From 0771b813d867a5837be865aa80e25434eec54472 Mon Sep 17 00:00:00 2001
From: Miklos Vajna
Date: Wed, 9 Mar 2011 00:49:47 +0100
Subject: [PATCH] Add Frugalware display-manager service
---
Makefile.am |5 +
units/frugalware/display-manager.service | 19 +++
2 files changed, 24 insertions(+), 0 deletions(-)
create mode 100644 units/frugalware/display-manager.service
diff --git a/Makefile.am b/Makefile.am
index f867624..4961424 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -353,6 +353,11 @@ dist_systemunit_DATA += \
units/fedora/halt-local.service
endif
+if TARGET_FRUGALWARE
+dist_systemunit_DATA += \
+ units/frugalware/display-manager.service
+endif
+
if HAVE_PLYMOUTH
dist_systemunit_DATA += \
units/plymouth-start.service \
diff --git a/units/frugalware/display-manager.service
b/units/frugalware/display-manager.service
new file mode 100644
index 000..a092c56
--- /dev/null
+++ b/units/frugalware/display-manager.service
@@ -0,0 +1,19 @@
+# This file is part of systemd.
+#
+# systemd is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+
+[Unit]
+Description=Display Manager
+After=syslog.target local.service systemd-user-sessions.service
+
+Conflicts=splashy-quit.service
+After=splashy-quit.service
+
+[Service]
+EnvironmentFile=/etc/sysconfig/desktop
+ExecStart=/bin/bash -c "exec ${desktop}"
+Restart=always
+RestartSec=0
--
1.7.4.1
pgpb5DlFIUIik.pgp
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-logger and external syslog daemon
On Thu, 10 Mar 2011 22:01:39 +0100 Lennart Poettering wrote: > On Wed, 23.02.11 12:48, Mike Kazantsev (mk.frag...@gmail.com) wrote: > > > Good day, > > > > > > I've recently deployed systemd on a machine that uses some syslog > > monitoring software and the software went nuts because messages from > > systemd logger were inconsistent with other logging - they all look > > like this: > > > > kernel.warning kernel[-]: process[pid]: message contents > > > > Thus, regardless of what systemd.exec(5) states, SyslogFacility= and > > SyslogLevel= is irrelevant - to a syslog daemon they will be passed as > > "kernel.warning". > > Hmm, that is borked. We do provider proper error levels when we write > things to kmsg. This must get lost later on. But we do strip the > facility, so that it gets replaced by "kernel", that is true. > > The only reason we strip the facility however is because the "dmesg" > tool chokes on it. The kernel is completely fine with it. I think if > we'd fix dmesg we should have no trouble with making the kernel log > buffer a full featured syslog queue like any other. > > And the "kernel[-]: " syntax must be from your log implementation, > too. What syslog implementation is that? > The same rsyslog. Format is "facility.priority cmd[pid]: ", but in case of kmsg looks like rsyslog doesn't try to interpret "process[pid]: " prefix, at least, so my guess is that it doesn't try to get any syslog metadata from this messages, just passing them as-is from kernel.warning kernel[-]. > > Naturally, the reason is "systemd-kmsg-syslogd" daemon, which spawns > > early on boot from syslog.socket and creates /dev/log, which is > > accessed by systemd-logger long before external syslog daemon starts. > > Syslog daemon (rsyslog in my case) just grabs these from kmsg. > > > > After that, substituting /dev/log for another socket (like > > rsyslog.socket seem to do) or just removing it doesn't seem to > > matter - systemd-logger will keep feeding messages to dmesg via > > kmsg-syslogd. > > Well, not anymore if you use a socket activatable syslog daemon. In that > case the original socket is just handed over and rsyslog continues > dispatching syslog messages where the bridge left of. > > > I read Kay Sievers's earlier post in this list on the subject, which > > states "Syslog services have been patched to be able to seemlessly take > > over an already opened /dev/log. rsyslog is upstream already...". > > > > Yet I've tried latest scm version of rsyslog and it doesn't seem to > > "take over an already opened /dev/log" if started via upstream-shipped > > rsyslog.socket unit (which just uses "ListenDatagram=/dev/log") line. > > it does now, since a couple of days, see my headsup message i posted a > few days ago. > Thanks, will test it asap. > Lennart > -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PACKAGERS] rsyslog and systemd
On Mon, 7 Mar 2011 23:49:45 +0100 Lennart Poettering wrote: > Heya, > > in the past weeks a couple of folks have been asking about the rsyslog > and systemd glue in systemd, and I never responded since this was still > work in progress. Things should be all resolved now, so here's a > heads-up in how things should work now: > > I have just sent a patch to rsyslog upstream: > > http://0pointer.de/public/0001-systemd-use-standard-syslog.socket-unit.patch Is there any reason why it resorts to "ExecStartPre=/bin/systemctl stop ..." instead of just using "Conflicts=systemd-kmsg-syslogd.service"? Both seem to equally work for me, but I wonder if there's some subtle pitfall in Conflicts= for this case, so you avoid to use it. -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PACKAGERS] rsyslog and systemd
On Fri, Mar 11, 2011 at 7:15 AM, Mike Kazantsev wrote: > On Mon, 7 Mar 2011 23:49:45 +0100 > Lennart Poettering wrote: > >> Heya, >> >> in the past weeks a couple of folks have been asking about the rsyslog >> and systemd glue in systemd, and I never responded since this was still >> work in progress. Things should be all resolved now, so here's a >> heads-up in how things should work now: >> >> I have just sent a patch to rsyslog upstream: >> >> http://0pointer.de/public/0001-systemd-use-standard-syslog.socket-unit.patch > > Is there any reason why it resorts to "ExecStartPre=/bin/systemctl > stop ..." instead of just using "Conflicts=systemd-kmsg-syslogd.service"? > It prevents systemd-kmsg-syslog bridge to be started at all on entering multi-user. Only one of conflicting units can be started during transaction. systemd[1]: Trying to enqueue job multi-user.target/start/replace systemd[1]: Looking at job systemd-kmsg-syslogd.service/stop conflicted_by=yes systemd[1]: Looking at job systemd-kmsg-syslogd.service/start conflicted_by=no systemd[1]: Fixing conflicting jobs by deleting job systemd-kmsg-syslogd.service/start > Both seem to equally work for me, Well ... without systemd-kmsg-syslogd, you rely on kernel to buffer all data until rsyslogd is started;all datagrams beyond backlog size (default 128) are lost. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-logger and external syslog daemon
2011/2/26 Andrey Borzenkov : > On Wed, Feb 23, 2011 at 10:48 AM, Mike Kazantsev wrote: >> >> I've recently deployed systemd on a machine that uses some syslog >> monitoring software and the software went nuts because messages from >> systemd logger were inconsistent with other logging - they all look >> like this: >> >> kernel.warning kernel[-]: process[pid]: message contents >> > > I confirm this at least for one special case - redirecting service > output to syslog. Here is how it looks like: > > Mar 1 06:35:53 localhost kernel: crond[847]: Starting crond: [ OK ]^M[ OK > ] > Mar 1 06:35:53 localhost kernel: atd[850]: Starting atd: [ OK ] For me the log messages actually look slightly different, as I also get the kernel timestamp and I also noticed a different problem: Mar 11 07:56:27 pluto kernel: imklog 5.7.8, log source = /proc/kmsg started. Mar 11 07:56:27 pluto rsyslogd: [origin software="rsyslogd" swVersion="5.7.8" x-pid="25093" x-info="http://www.rsyslog.com";] start Mar 11 07:56:27 pluto kernel: [ 5913.491848] michael[24089]: foo Mar 11 07:56:27 pluto kernel: [ 5918.029738] michael[24911]: bar Mar 11 07:56:27 pluto kernel: [ 5921.140864] michael[25078]: baz As you can see, when rsyslog starts up and flushes the kmsg queue, the log messages all have the same timestamp (Mar 11 07:56:27) and they come after the rsyslog startup message, although they were logged before the rsyslog start. Lennart argues, that this should be handles within the syslogd (in this case rsyslog 5.7.8), which should use the kernel time stamp to compute the correct time when the log message occured. Rainer, can you share any insight on this matter? Cheers, Michael -- 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] systemd-logger and external syslog daemon
2011/3/11 Rainer Gerhards : >> -Original Message- >> From: Michael Biebl [mailto:mbi...@gmail.com] >> Sent: Friday, March 11, 2011 8:04 AM >> Mar 11 07:56:27 pluto kernel: [ 5921.140864] michael[25078]: baz >> >> As you can see, when rsyslog starts up and flushes the kmsg queue, the >> log messages all have the same timestamp (Mar 11 07:56:27) and they >> come after the rsyslog startup message, although they were logged >> before the rsyslog start. >> Lennart argues, that this should be handles within the syslogd (in >> this case rsyslog 5.7.8), which should use the kernel time stamp to >> compute the correct time when the log message occured. >> >> Rainer, can you share any insight on this matter? > > Lennart recommended that to me and I had some code in place to do it. > However, at that time this did not work because the kernel did not record > that timestamp. This was added a while later, but I did not yet revisit that > issue. I was a bit hesitant to dig into this issue as I found no simple > enough method to setup a system with systemd (I know it's important, but > there are many other important things as well...). I'll see that I can at > least see what kernel patch needs to be present. afaik it is not so much a kernel version issue, but a kernel config that needs to be turned on: http://cateee.net/lkddb/web-lkddb/PRINTK_TIME.html says it's available ins 2.6.12 Debian kernels have CONFIG_PRINTK_TIME=y Ubuntu 10.10 and F14 as it seems, too. Cheers, Michael -- 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] systemd-logger and external syslog daemon
On Fri, Mar 11, 2011 at 10:03 AM, Michael Biebl wrote: > For me the log messages actually look slightly different, as I also > get the kernel timestamp and I also noticed a different problem: > > Mar 11 07:56:27 pluto kernel: imklog 5.7.8, log source = /proc/kmsg started. > Mar 11 07:56:27 pluto rsyslogd: [origin software="rsyslogd" > swVersion="5.7.8" x-pid="25093" x-info="http://www.rsyslog.com";] start > Mar 11 07:56:27 pluto kernel: [ 5913.491848] michael[24089]: foo > Mar 11 07:56:27 pluto kernel: [ 5918.029738] michael[24911]: bar > Mar 11 07:56:27 pluto kernel: [ 5921.140864] michael[25078]: baz > > As you can see, when rsyslog starts up and flushes the kmsg queue, the > log messages all have the same timestamp (Mar 11 07:56:27) and they > come after the rsyslog startup message, although they were logged > before the rsyslog start. But that was the case for as long as I remember. It is not systemd specific in any way. > Lennart argues, that this should be handles within the syslogd (in > this case rsyslog 5.7.8), which should use the kernel time stamp to > compute the correct time when the log message occurred. > Sounds quite reasonable :) What would be also really nice - some systemd specific marker so rsyslog could extract syslogd messages from kmsg. Not sure if it is really doable without some gross kernel hack though. Special severity level may be ... PRINTK_SYSTEMD? :) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-logger and external syslog daemon
2011/3/11 Rainer Gerhards : > > So isn't that already a solution? > The problem with PRINTK_TIME afaics is that it needs to be turned on explicitly whereas I'd expect SO_TIMESTAMP will be available always (if the kernel is recent enough)? In any case you'd need to interpret that data on the rsyslog side, to compute a correct time stamp and then (optionally) strip off the [ 5913.491848] markers. Michael -- 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
