[systemd-devel] Moving to systemd39: early kernel msg missed in rsylog logs
Hi * I just moved my ArchLinux based server from systemd37 to 39. Basically all went well. For successful logging via rsyslog I do following: 1.symlink /lib/systemd/system/rsyslog.service to /etc/systemd/system/rsyslog.service 2.added in rsyslog.conf entry $SystemLogSocketName /run/systemd/journal/syslog 3.run systemctl enable rsyslog.service System boots OK. Issue which I have is related to logging messages by rsyslog. I don't have first 5-6 sec of booting in rsyslog logs. i.e. first entry in rsylog's generated log files is from 10:42:22, while systemd-journal show very early boot messages from 10:42:17 onward. rsyslog logging start seems to be correlated with start of imklog as by rsyslog files imklog also starts at 10:42:22. All this is little strange for me as before moving production server to systemd39 I make sure all is working OK with systemd39. I do this by mirroring my whole server to VM and do tests. Starting my server under VM gives me rsyslog files with all messages as expected (according to logs imklog starts at very beginning). Only difference between real server and VM is virtualization (CPU speed, RAM and virtualized HW) so maybe may issue is result of some king of races ? May somebody hint me how to resolve this issue ? -br ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Moving to systemd39: early kernel msg missed in rsylog logs
On Fri, 27.01.12 12:46, Warpme (war...@o2.pl) wrote: Hi * I just moved my ArchLinux based server from systemd37 to 39. Basically all went well. For successful logging via rsyslog I do following: 1.symlink /lib/systemd/system/rsyslog.service to /etc/systemd/system/rsyslog.service 2.added in rsyslog.conf entry $SystemLogSocketName /run/systemd/journal/syslog 3.run systemctl enable rsyslog.service System boots OK. Issue which I have is related to logging messages by rsyslog. I don't have first 5-6 sec of booting in rsyslog logs. i.e. first entry in rsylog's generated log files is from 10:42:22, while systemd-journal show very early boot messages from 10:42:17 onward. rsyslog logging start seems to be correlated with start of imklog as by rsyslog files imklog also starts at 10:42:22. All this is little strange for me as before moving production server to systemd39 I make sure all is working OK with systemd39. I do this by mirroring my whole server to VM and do tests. Starting my server under VM gives me rsyslog files with all messages as expected (according to logs imklog starts at very beginning). Only difference between real server and VM is virtualization (CPU speed, RAM and virtualized HW) so maybe may issue is result of some king of races ? May somebody hint me how to resolve this issue ? So, I forgot to mention this, I probably should have in the annoucnement of 38 wiht the journal: There can only be one reader of /proc/kmsg. By default journald upstream is configured to do that, but this will collide with a syslog implementation doing the same. If both a syslog implementation and journald read from /proc/kmsg then it's undefined which of the two will get the data, sometimes one, sometimes the other, it's basically a race. To make this more confusing journald forwards all kernel messages it reads to the real syslog, but the real syslog doesn't send its back. So the syslog will see the full thing, the journal won't, but to syslog some of the kernel messages actually come in via the kernel interface (i.e. /proc/kmsg), while others come in via the userspace interface (i.e. the AF_UNIX/SOCK_DGRAM syslog socket), possibly causing some misattribution. Now, there are two choices here: a) Tell the syslog implementation to stop reading from /proc/kmsg, so that only journald will. You'll have all data in syslog and in the journal, but in syslog they might possibly be misattributed to userspace although they come from kernelspace. b) Tell journald to stop reading from /proc/kmsg (ImportKernel=no in /etc/systemd/systemd-journald.conf). You'll have the complete, correctly attributed data in syslog, but not in the journal. (There's actually a third option: uninstall syslog and only use the journal) We ship with ImportKernel=yes by default from upstream in systemd. In Fedora I will however set that to ImportKernel=no by default (i.e. option b), since we install a syslog implementation by default, and I'd like to avoid the kernel/userspace misattribution problem. No I figure the early boot stuff is missing for you because the journald is written so that i can start as one of the fist processes around, i.e. without /var being around and so on. Syslog implementations are generally not like that. That means their socket is traditionally created much later and hence they lose the early boot messages. 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] logind: add sys_tty_config capability, to let it use VT_ACTIVATE ioctl on activate action
On Wed, 25.01.12 21:20, Mike Kazantsev (mk.frag...@gmail.com) wrote: Good day, Problem is that systemd-loginctl activate session-id gives something like D-Bus call failed: Operation not permitted, while strace of logind process looks like this: epoll_wait(4, {{EPOLLIN, {u32=3, u64=3}}}, 1, -1) = 1 epoll_wait(9, {{EPOLLIN, {u32=166352544, u64=166352544}}}, 1, 0) = 1 recvmsg(8, {msg_name(0)=NULL, msg_iov(1)=[{l\1\0\1\6\0\0\0\2... recvmsg(8, 0xbfc3636c, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable) open(/dev/tty0, O_RDWR|O_NOCTTY|O_LARGEFILE|O_CLOEXEC) = 13 ioctl(13, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 -opost -isig -icanon -echo ...}) = 0 ioctl(13, VT_ACTIVATE, 0x1) = -1 EPERM (Operation not permitted) close(13) = 0 sendmsg(8, {msg_name(0)=NULL, msg_iov(2)=[{l\3\1\1\34\0\0\0\243\0... So it looks like activate fails without that capability. I'm not sure what it's supposed to do though, and stumbled upon it while looking into unrelated issue, so maybe it's supposed to act this way. michich seemed to agree on irc that the cap should be there, but since it doesn't seem to be in git yet, I thought I'd mail the patch. Yupp, makes a lot of sense. Patch 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] build-sys: add creation of /var/lib/systemd path, used by logind
On Wed, 25.01.12 21:52, Mike Kazantsev (mk.frag...@gmail.com) wrote: From c48f23ae82a8efac59f025e2534a97754b279f60 Mon Sep 17 00:00:00 2001 From: Mike Kazantsev mk.frag...@gmail.com Date: Wed, 25 Jan 2012 21:24:02 +0600 Subject: [PATCH] build-sys: add creation of /var/lib/systemd path, used by logind Thanks! Applied! I also added another patch that creates the path at runtime, if necessary. That way we have it robust but since the dir is created at installation time packagers will hopefully notice it and package it, so that the dir is properly owned by a package. 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] login: dbus equivalent of sd_pid_get_session ?
Hi, I am wondering if there is a dbus API equivalent of sd_pid_get_session from sd-login.h I know ConsoleKit provides a dbus API for it but I couldn't find something similar in login1 dbus interface. AIUI login1 is the future so just want to make sure I'm not using anything deprecated. Reason for wanting this call is that in virt-manager we authenticate with libvirt using policykit, and we get perennial bug reports from users launching virt-manager over ssh -X and having policykit opaquely deny them access. In this case I want virt-manager to go out and talk to ConsoleKit or login1 and verify that they don't have a session, then give the user a more helpful error. Thanks, Cole ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel