(sign myself) |
No edit summary |
||
| Line 1: | Line 1: | ||
The journal is a great (I like the per-unit log view nicely shown in systemctl status foo.service), but it is not an equivalent of a syslog. In your description you seem to underestimate the differences. For instance, journal does not write /var/log/messages or /var/log/secure, which people are used to and which a lot of existing documentation refers to. At the very least, the documentation and the release notes will have to explain the differences better. -- michich | The journal is a great (I like the per-unit log view nicely shown in systemctl status foo.service), but it is not an equivalent of a syslog. In your description you seem to underestimate the differences. For instance, journal does not write /var/log/messages or /var/log/secure, which people are used to and which a lot of existing documentation refers to. At the very least, the documentation and the release notes will have to explain the differences better. -- michich | ||
You have to be a bit more specific in claiming the journal and journald do no provide the same and more functionality than syslog and syslogd as in highlight the areas which it does not. | |||
It certainly lacks many enterprise features that rsyslog and syslog-ng provide but it should be sufficient as an "default" once F18 get's released | |||
This proposal is only about disabling rsyslog ( not removing it or anything like that from default installs ) which would help us identifying any problem areas that journal might have and if those areas have not been fixed at feature freeze we could easily back out of it and have systemd put syslogging in forward only mode to rsyslog and enable rsyslog again which is as close to disabling journal as it will get ( afaik ) thus having single logging solution enable as opposed to two ( journal and rsyslog ). | |||
Now if accepted as an default enterprise users and administrators would simply have to enable rsyslog if they require enterprise full feature logger. | |||
The changes in usability arguably is better for novice end users with journal ( single command to view logs as opposed to having to hunt down the relevant msg they are seeking looking potentially by looking through multiple files ) but will certainly take time for experienced/administrative user base to get accustom to as is with all new technology. | |||
I would think that FESCO would accept this features with terms before it can be considered as an default and once those term have been meet ( granted that FESCO does accept it with terms ) it would be come the distributions default. -- johannbg | |||
Latest revision as of 15:32, 5 March 2012
The journal is a great (I like the per-unit log view nicely shown in systemctl status foo.service), but it is not an equivalent of a syslog. In your description you seem to underestimate the differences. For instance, journal does not write /var/log/messages or /var/log/secure, which people are used to and which a lot of existing documentation refers to. At the very least, the documentation and the release notes will have to explain the differences better. -- michich
You have to be a bit more specific in claiming the journal and journald do no provide the same and more functionality than syslog and syslogd as in highlight the areas which it does not.
It certainly lacks many enterprise features that rsyslog and syslog-ng provide but it should be sufficient as an "default" once F18 get's released
This proposal is only about disabling rsyslog ( not removing it or anything like that from default installs ) which would help us identifying any problem areas that journal might have and if those areas have not been fixed at feature freeze we could easily back out of it and have systemd put syslogging in forward only mode to rsyslog and enable rsyslog again which is as close to disabling journal as it will get ( afaik ) thus having single logging solution enable as opposed to two ( journal and rsyslog ).
Now if accepted as an default enterprise users and administrators would simply have to enable rsyslog if they require enterprise full feature logger.
The changes in usability arguably is better for novice end users with journal ( single command to view logs as opposed to having to hunt down the relevant msg they are seeking looking potentially by looking through multiple files ) but will certainly take time for experienced/administrative user base to get accustom to as is with all new technology.
I would think that FESCO would accept this features with terms before it can be considered as an default and once those term have been meet ( granted that FESCO does accept it with terms ) it would be come the distributions default. -- johannbg