On Jan 3, 2014 1:16 PM, "Suvayu Ali" fatkasuvayu+linux@gmail.com wrote:
Hi Pete,
You seem to be well-versed with journalctl. I hope you don't mind my asking a few questions.
Sure. I rearranged some things when composing, and as I review, I see I did so poorly...
On Thu, Jan 02, 2014 at 09:07:29PM -0700, Pete Travis wrote:
$ su -c 'crontab -l'
- echo "TEST TEST"
$ crontab -l
- LARSHAPPY="no"; if [[ "$LARSHAPPY" == "no" ]]; then echo -e
"This isn't the same.\nNew Things are Different.\nSome people like the old thing.";fi
$ journalctl SYSLOG_IDENTIFIER=CROND -f #filtered for convenience
How do you know which IDENTIFIER to use? I could guess it should be CROND if I were to look at the output of journalctl in this case; but is there any canonical way to find this out? Or is it just the unit file name?
I picked that by looking at the messages and pairing up the identifier with my messages. It's reasonable to assume this will be consistent for cron jobs, so I didn't demonstrate that part.
The syslog identifier is not the same as the unit file. `journalctl -u crond ` gives only stdout of crond itself, not the jobs. iirc, applications using the journal API can choose the syslog identifier for their messages, and one is chosen for them if not. I don't know the details behind that choice, but I would suspect it comes from the calling binary or service somehow.
But wait! These things could get all mixed up on a busy machine, you say! Let's take a closer look at a message:
MESSAGE=(pete) CMDOUT (New Things are Different.) _AUDIT_SESSION=83 _SYSTEMD_CGROUP=/user.slice/user-1000.slice/session-83.scope _SYSTEMD_SESSION=83 _SYSTEMD_UNIT=session-83.scope SYSLOG_PID=8141 _PID=8141 _SOURCE_REALTIME_TIMESTAMP=1388719561402125 Thu 2014-01-02 20:26:01.402133 MST
[s=04f24177eb10446c94ea389f0e5adb2f;i=49d85;b=0557929cbde247928f945d8b53a6e067;m=b529d73d;t=4ef0878266935;x=ade119e61f79d8c4]
PRIORITY=6 _UID=0 _MACHINE_ID=0fb42f5d126e4f4e8b94045b4652c0f2 _HOSTNAME=ruminant-randomuser-lan _CAP_EFFECTIVE=1fffffffff _TRANSPORT=syslog SYSLOG_FACILITY=9 _COMM=crond _EXE=/usr/sbin/crond _SELINUX_CONTEXT=system_u:system_r:crond_t:s0-s0:c0.c1023 _GID=1000 _AUDIT_LOGINUID=1000 _SYSTEMD_OWNER_UID=1000 _SYSTEMD_SLICE=user-1000.slice SYSLOG_IDENTIFIER=CROND _CMDLINE=/usr/sbin/CROND -n _BOOT_ID=0557929cbde247928f945d8b53a6e067How did you get this output; I'm confused.
`journalctl -o verbose' gives the extra metadata. There are other output formats, ie json, but this seemed most useful here.
`journalctl --show-cursor` gives the cursor at the end of the query.
I'll agree that this isn't as *simple* as banging out a four letter word and reading message, but the journal can provide context, too. If
Could you please point me to some documentation that explains how a user can use this? Some examples beyond SYSTEMD_UNIT=bla would be great. I find it very difficult to use journalctl effectively without knowing any of the internal details you are using in the examples. Is there some discussion on this that I can read for my understanding?
I pulled all of that from `man journalctl` , /usr/share/doc/ , examining the metadata provided by "-o verbose", and generous mashing of the tab key. There is a section in the System Administrators Guide on the journal, which I will probably update this weekend since the usage is newly fresh in my mind. It won't be published for f20 immediately, but I can push a draft if anyone is interested in reviewing. (Hint, readers, speak up, or I won't do the extra work)
$ journalctl SYSLOG_IDENTIFIER=CROND _AUDIT_SESSION=83 -b --show-cursor|tail -1
- -- cursor:
s=04f24177eb10446c94ea389f0e5adb2f;i=49d85;b=0557929cbde247928f945d8b53a6e067;m=b529d73d;t=4ef0878266935;x=ade119e61f79d8c4
It is not clear to me what is meant by cursor here (I read journalctl(1)); moreover I could not find an option to journalctl called `--show-cursor'.
Think of the cursor as a unique key for the entry in a journal - but as I understand it, it references that point in the journal, not the specific entry. I have not read the code, so it is easier to demonstrate usage than explain the internals. In practice, a script or application tracking the journal can stop and resume at a specific point with more granularity and reliability than a timestamp, because timestamps may not be unique.
If you don't mind could you share some of your journalctl understanding on another thread I started?
https://lists.fedoraproject.org/pipermail/users/2014-January/444479.html
Thanks a lot for your time.
Cheers,
-- Suvayu
No problem. I'll dig up that thread and see if I can help.
--Pete