F20 - Unintended consequences of no default MTA - How best to fix

[Suvayu Ali]

On Fri, Jan 03, 2014 at 01:56:33PM -0700, Pete Travis wrote:
> On Jan 3, 2014 1:16 PM, "Suvayu Ali" <fatkasuvayu+linux at gmail.com> wrote:
> > 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.

Okay, I think I understand.  And if I add Lars's suggestion about
relying on completion, I think I can start doing some exploring on my
own ;).  Although some authoritative documentation on this would be
really cool, specially to respond to queries on the mailing list.

> > > say! Let's take a closer look at a message:
> > >
> > > MESSAGE=(pete) CMDOUT (New Things are Different.)

 [...chomp...chomp...chomp...]

> > >     _BOOT_ID=0557929cbde247928f945d8b53a6e067
> >
> > How 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.

This is an interesting output flag.  I will play more with it.  I guess
this provides a nice interface if I want to parse journalctl output from
my own scripts (bash, python, whatever).

> 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)

I would love to read that, and if I can give comments.  I usually like
doign documentation 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.

Thank you, I'll play with this myself.  Sounds interesting.

> > 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.
> 
> No problem. I'll dig up that thread and see if I can help.

Thanks a lot!

:)

-- 
Suvayu

Open source is the future. It sets us free.