Hi Lennart, Thanks for the reply.
I can't understand the user-generated sshd log being put into it's own journal out of distrust, isn't that just paranoia? I don't see the practicality of it. Either way, it's still getting logged. Does it matter that it's not in the main journal? Can you elaborate on this please? As for the _EXE and _COMM 'race' issue you mentioned; are you really sure that's a kernel problem..? I'm not clear enough (or qualified enough) on the internals to speculate, but it sounds more like a mishandling on systemd's behalf... Also: I'd really like to see regular expression capability built into journalctl :) Cheers, Jake On 20 November 2012 18:40, Lennart Poettering <lenn...@poettering.net> wrote: > On Fri, 26.10.12 11:11, Jake Rooney (tehe...@gmail.com) wrote: > >> Hi, >> >> Couple of questions... >> >> At the moment (195) journalctl _SYSTEMD_UNIT=sshd.service prints out >> most sshd logs, but skips user disconnections/logouts. These seem to >> be logged under the UID of the user that logged out and are stored in >> a separate journal. Why is this? > > This is because sshd gets moved into the per-session cgroup, and that's > what we are looking for. > > The disconnect message is that generated from UID 0 or the actual user? > If it is run as UID of the user we really shouldn't trust the code, and > hence splitting things off in the per-user journal sounds like the right > thing to do? > >> journalctl _COMM=sshd matches all logs, including disconnects, but >> _EXE=/usr/sbin/sshd skips disconnections. There seems to be some >> inconsistency here, so I was wondering what's the "best" way to filter >> for all sshd info, rather than having to resort to dumping the journal >> and grep'ing. > > This part really sounds as if it is simply an instance of a common race > that we still need to fix in the kernel: the journal will receive > UID/GID/PID credentials of the sender of a message along with the > message, and then uses that to lookup _EXE, _COMM and other fields. Now, > if by the time where the message has been received and we begin to > lookup up those extra fields the client side already exited we cannot > gather that information. > > This is someting to fix in the kernel: we'd really like an interface > that can send along _EXE, _COMM and suchlike right-away, so that we have > it without having to actually gather it explicitly, so that the race is > gone. > > Lennart > > -- > Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel