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:
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?
(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
(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.
(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?
-u is now implemented, will also upload this to F18, soon.
systemd-195-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/systemd-195-1.fc18
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).
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).
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.