Bug 865128 - RFE: way to filter by unit name in journalctl
RFE: way to filter by unit name in journalctl
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-10 17:26 EDT by Jóhann B. Guðmundsson
Modified: 2012-12-20 10:43 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-20 10:43:31 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jóhann B. Guðmundsson 2012-10-10 17:26:13 EDT
Description of problem:

Just few usability suggestions

Support parsing unit 

in addition or instead of 

journalctl /usr/bin/avahi-daemon

they could also do this

journalctl $UNIT.service ( with and without the relevant type unit ending ) 

as in 

"journalctl avahi-daemon.service" or simply "journalctl avahi-daemon"

This should prove easier for administrator and users alike to use since the always remember which unit they started 

Add a simple -d or --dump switch which jumps all entry's from relevant unit syslog style to a file at some persistent location like /var/log ( comes more naturally to me that journal directory belongs under /var/journal instead of /var/log/journal/ to not confuse users thinking they can use text parsing tools on the file ) for administrators and users alike to view and or attach to bug reports for developers to work with and or log parses to work on

journalctl -d avahi-daemon.service would for example would create avahi-daemon.txt 


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Lennart Poettering 2012-10-12 12:07:12 EDT
Hmm, so we where thinking about adding a new "-u" switch or so which is short for _SYSTEMD_UNIT=something, where something would be mangled by the same rules as it is on a "systemctl status" command line. That way "journalctl -u avahi-daemon" would do what people expect.

For generating those log files, wouldn't "journalctl -u avahi-daemon > /var/log/avahi-daemon.log" already do what you need?
Comment 2 Jóhann B. Guðmundsson 2012-10-12 12:56:48 EDT
(In reply to comment #1)
> Hmm, so we where thinking about adding a new "-u" switch or so which is
> short for _SYSTEMD_UNIT=something, where something would be mangled by the
> same rules as it is on a "systemctl status" command line. That way
> "journalctl -u avahi-daemon" would do what people expect.

No switch as in users only have to type journalctl + unit as in journalctl avahi-daemon for the avahi-daemon. 

( consistent behavior with systemctl start avahi-daemon and that recent patch set ) 

> 
> For generating those log files, wouldn't "journalctl -u avahi-daemon >
> /var/log/avahi-daemon.log" already do what you need?

Again we are trying to simplifying things and here we would eliminate the redirection to a file. 

journalctl -d ( or t for text ) $unit would dump the output for that service to a file that bears the same name as the unit either in the current directory by default or in /var/log/ directory where they are accustom to find it or text log parsing tools might find and parse it.  
( --all which would dump all logs for units in their corresponding name under /var/log ) 

That would allow users for example to use tool like logwatch by simply creating a time unit and have it do

# create text files

ExecStartPre=/usr/bin/journalctl -d --all 

# Use a tool to parse it 

ExecStart=/etc/cron.daily/0logwatch

# Clean those files up if they would not get overwritten each time or rotated
ExecStartPost=/bin/rm /var/log/* 

In it's section or something similar
Comment 3 Bill Nottingham 2012-10-12 13:47:32 EDT
(In reply to comment #2)
> (In reply to comment #1)
> > Hmm, so we where thinking about adding a new "-u" switch or so which is
> > short for _SYSTEMD_UNIT=something, where something would be mangled by the
> > same rules as it is on a "systemctl status" command line. That way
> > "journalctl -u avahi-daemon" would do what people expect.
> 
> No switch as in users only have to type journalctl + unit as in journalctl
> avahi-daemon for the avahi-daemon. 
> 
> ( consistent behavior with systemctl start avahi-daemon and that recent
> patch set ) 

This I would agree with, but...

> > For generating those log files, wouldn't "journalctl -u avahi-daemon >
> > /var/log/avahi-daemon.log" already do what you need?
> 
> Again we are trying to simplifying things and here we would eliminate the
> redirection to a file. 
> 
> journalctl -d ( or t for text ) $unit would dump the output for that service
> to a file that bears the same name as the unit either in the current
> directory by default or in /var/log/ directory where they are accustom to
> find it or text log parsing tools might find and parse it.  
> ( --all which would dump all logs for units in their corresponding name
> under /var/log ) 

This I wouldn't. Standard tool expectation is output goes to stdout by default, or a filename if one is specified with a specific commandline option.

Plus, it's the same semantics as just running 'journalctl' to dump the journal to stdout.
Comment 4 Lennart Poettering 2012-10-12 16:26:43 EDT
(In reply to comment #2)
> (In reply to comment #1)
> > Hmm, so we where thinking about adding a new "-u" switch or so which is
> > short for _SYSTEMD_UNIT=something, where something would be mangled by the
> > same rules as it is on a "systemctl status" command line. That way
> > "journalctl -u avahi-daemon" would do what people expect.
> 
> No switch as in users only have to type journalctl + unit as in journalctl
> avahi-daemon for the avahi-daemon. 

So, I am a bit concerned about this and would like to avoid this. This is because I am a bit afraid of the amiguity this might create. Currently, what happens in "systemctl status" is that if we get a paramater we ask: "Is this a valid unit name?" If yes, then we just use it. If not, then we say "Ah, it's not a unit, but only a unit makes sense here, so let's make it one, and add a prefix, convert it from a path, and so on!".

However, this rule becomes really contractory if applied 1:1 to the journalctl command line: there we are actually looking for matches in the form FOO=BAR, and if something is not a match, then we try to make it one. If we somehow merge these two rules (i.e. "it's not a unit? make it one!" + "it's not a match? make it one!") things become really awkward, since there are matches that qualify as unit name, and unit names that qualify as matches, so you have the ambiguity here what you mean, so that "systemctl status" and "journalctl" might understand things differently after all. Here's an example of how things would be weird if we implemented things the way you'd ask for:

    journalctl FOO=BAR
    → means: dump the journal, filtering for a field FOO having value BAR.

vs:

    systemctl status FOO=BAR
    → means: show status info of a unit file FOO=BAR.service.

And this goes on. Here's another one:

    systemctl status /usr/bin/apache
    → means: show status of "usr-bin-apache.mount" (which might refer to a file bind mount).

vs:

    journalctl /usr/bin/apache
    → means: show logs of the binary /usr/bin/apache, i.e. a short form to type _EXE=/usr/bin/apache

And that's the ambiguity I don't like, because people wouldn't understand this, and it's hard to see in cases like the latter.

If we introduce an explicit option "-u" for journalctl we'd know that the argument for -u needs to be a unit, much like we know for systemctl status, so we wouldn't be tempted to interpret it as a normal match.

I hope that makes some sense?

> journalctl -d ( or t for text ) $unit would dump the output for that service
> to a file that bears the same name as the unit either in the current
> directory by default or in /var/log/ directory where they are accustom to
> find it or text log parsing tools might find and parse it.  
> ( --all which would dump all logs for units in their corresponding name
> under /var/log ) 
> 
> That would allow users for example to use tool like logwatch by simply
> creating a time unit and have it do
> 
> # create text files
> 
> ExecStartPre=/usr/bin/journalctl -d --all 
> 
> # Use a tool to parse it 
> 
> ExecStart=/etc/cron.daily/0logwatch
> 
> # Clean those files up if they would not get overwritten each time or rotated
> ExecStartPost=/bin/rm /var/log/* 
> 
> In it's section or something similar

So, I am not convinced that this is a good idea. I think generating the classic log output of /var/log/messages by default in journalctl made a lot of sense, since the formatting was pretty OK and is easy to read. But generating invidual text log files in /var/log/ is precisely what we wanted to replace with the journal. So while we should make that possible (which we do via shell redirection), we shouldn't make this first class (by supporting it via an argument).

I hope this makes some sense, too?
Comment 5 Lennart Poettering 2012-10-17 08:43:24 EDT
-u is now implemented, will also upload this to F18, soon.
Comment 6 Fedora Update System 2012-10-22 21:04:35 EDT
systemd-195-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/systemd-195-1.fc18
Comment 7 Fedora Update System 2012-10-23 02:48:10 EDT
Package systemd-195-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-195-1.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-16709/systemd-195-1.fc18
then log in and leave karma (feedback).
Comment 8 Fedora Update System 2012-10-26 15:37:27 EDT
Package systemd-195-2.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-195-2.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-16709/systemd-195-2.fc18
then log in and leave karma (feedback).
Comment 9 Fedora Update System 2012-12-20 10:43:33 EST
systemd-195-2.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.