Cristian Rodríguez wrote:
El 15/09/12 11:49, Per Jessen escribió:
I do want to log, but I've looked at the journal already and didn't see anything that wasn't already in /var/log/messages, /var/log/mail etc. Seems like a duplication of effort and a waste of space in /var/log/journal. (which afaict can just be deleted).
It is significantly more powerful than traditional logging:
For example
journalctl /usr/bin/foo --> get messages from program foo
journalctl /dev/sda --> hard-drive problems ?
journalctl -p error --> only errors
--- I assume the full power of linux's text utilities can be used on them - like grep, sort, awk, perl... vim...
Having logs recorded in a non-text binary format tends to make MS logs out-a-sight, out-a-mind, where as I often go and poke around in /var/log and look to see if I notice anything 'new'.
If I can't look at the whole stream as a text (messages, warnings, etc), I don't get a field for what is right or wrong behavior and certainly wouldn't be able to pick out an anomaly if I had to query each item separately -- that global view is a good way to look for 'warts'...
MS makes it much to painful to do hat -- 1 error / page, everything in 300 separate queries ... ug!
Currently it is not a full replacement for syslog but I suggest you to check it out.
I tend to use ngsyslog for the filtering benefits. -- really has some powerful filtering in the 2.x line -- had to label ng3x taboo, so it won't overwrite a working config with a non working config...
Linda Walsh wrote:
Cristian Rodríguez wrote:
El 15/09/12 11:49, Per Jessen escribió:
I do want to log, but I've looked at the journal already and didn't see anything that wasn't already in /var/log/messages, /var/log/mail etc. Seems like a duplication of effort and a waste of space in /var/log/journal. (which afaict can just be deleted).
It is significantly more powerful than traditional logging:
For example
journalctl /usr/bin/foo --> get messages from program foo
journalctl /dev/sda --> hard-drive problems ?
journalctl -p error --> only errors
I assume the full power of linux's text utilities can be used on them - like grep, sort, awk, perl... vim...
Having logs recorded in a non-text binary format tends to make MS logs out-a-sight, out-a-mind, where as I often go and poke around in /var/log and look to see if I notice anything 'new'.
Same here.
If I can't look at the whole stream as a text (messages, warnings, etc), I don't get a field for what is right or wrong behavior and certainly wouldn't be able to pick out an anomaly if I had to query each item separately -- that global view is a good way to look for 'warts'...
I think I tried "journalctl" - without arguments you get the whole log (afaict).
Currently it is not a full replacement for syslog but I suggest you to check it out.
I tend to use ngsyslog for the filtering benefits. -- really has some powerful filtering in the 2.x line
Ditto - also much easier to configure than rsyslog.
On Wednesday 19 September 2012, Per Jessen wrote:
Linda Walsh wrote:
Cristian Rodríguez wrote:
El 15/09/12 11:49, Per Jessen escribió:
I do want to log, but I've looked at the journal already and didn't see anything that wasn't already in /var/log/messages, /var/log/mail etc. Seems like a duplication of effort and a waste of space in /var/log/journal. (which afaict can just be deleted).
It is significantly more powerful than traditional logging:
For example
journalctl /usr/bin/foo --> get messages from program foo
journalctl /dev/sda --> hard-drive problems ?
journalctl -p error --> only errors
I assume the full power of linux's text utilities can be used on them - like grep, sort, awk, perl... vim...
Having logs recorded in a non-text binary format tends to make MS logs out-a-sight, out-a-mind, where as I often go and poke around in /var/log and look to see if I notice anything 'new'.
Same here.
If I can't look at the whole stream as a text (messages, warnings, etc), I don't get a field for what is right or wrong behavior and certainly wouldn't be able to pick out an anomaly if I had to query each item separately -- that global view is a good way to look for 'warts'...
I think I tried "journalctl" - without arguments you get the whole log (afaict).
Unfortunately you can do this only on machines where journalctl is installed/available. I assume that you can't read the journald logs on most existing systems.
Currently it is not a full replacement for syslog but I suggest you to check it out.
I tend to use ngsyslog for the filtering benefits. -- really has some powerful filtering in the 2.x line
Ditto - also much easier to configure than rsyslog.
-- Per Jessen, Zürich (12.4°C)
cu, Rudi
Ruediger Meier wrote:
On Wednesday 19 September 2012, Per Jessen wrote:
If I can't look at the whole stream as a text (messages, warnings, etc), I don't get a field for what is right or wrong behavior and certainly wouldn't be able to pick out an anomaly if I had to query each item separately -- that global view is a good way to look for 'warts'...
I think I tried "journalctl" - without arguments you get the whole log (afaict).
Unfortunately you can do this only on machines where journalctl is installed/available. I assume that you can't read the journald logs on most existing systems.
Hi Rudi
On 12.2, journalctl is called 'systemd-journalctl'.
On Wed, Sep 19, 2012 at 7:26 AM, Ruediger Meier sweet_f_a@gmx.de wrote:
Unfortunately you can do this only on machines where journalctl is installed/available. I assume that you can't read the journald logs on most existing systems.
Just a matter of building journalctl from source I'd imagine, as would be the case if you were missing grep.
I happen to agree that the binary format is unnecessary, but it also happens to be a discretionary power of the author, and as soon as there's a working and ubiquitous "journalctl" to parse it... and its accompanying documentations... complaining will only start flame wars.
El 19/09/12 11:20, Claudio Freire escribió:
On Wed, Sep 19, 2012 at 7:26 AM, Ruediger Meier sweet_f_a@gmx.de wrote:
Unfortunately you can do this only on machines where journalctl is installed/available. I assume that you can't read the journald logs on most existing systems.
Just a matter of building journalctl from source I'd imagine, as would be the case if you were missing grep.
Or export them to text .. peraphs to json which is much more easy to parse with automated tools...
I happen to agree that the binary format is unnecessary,
Ok, then how you implement all those features mentioned in the design document to work fast ?
On Wed, Sep 19, 2012 at 12:49 PM, Cristian Rodríguez crrodriguez@opensuse.org wrote:
Just a matter of building journalctl from source I'd imagine, as would be the case if you were missing grep.
Or export them to text .. peraphs to json which is much more easy to parse with automated tools...
Wasn't the idea of binary formats to make it easy for tools to parse?
How does that line "parse" then? Export to text to make the supposedly-very-machine-readable format easier to parse? Why not use text from the beginning then?
El mié 19 sep 2012 13:08:17 CLST, Claudio Freire escribió:
On Wed, Sep 19, 2012 at 12:49 PM, Cristian Rodríguez crrodriguez@opensuse.org wrote:
Just a matter of building journalctl from source I'd imagine, as would be the case if you were missing grep.
Or export them to text .. peraphs to json which is much more easy to parse with automated tools...
Wasn't the idea of binary formats to make it easy for tools to parse?
How does that line "parse" then? Export to text to make the supposedly-very-machine-readable format easier to parse? Why not use text from the beginning then?
Please read the design document so you understand what we are talking about here.
On Wed, Sep 19, 2012 at 1:09 PM, Cristian Rodríguez crrodriguez@opensuse.org wrote:
Or export them to text .. peraphs to json which is much more easy to parse with automated tools...
Wasn't the idea of binary formats to make it easy for tools to parse?
How does that line "parse" then? Export to text to make the supposedly-very-machine-readable format easier to parse? Why not use text from the beginning then?
Please read the design document so you understand what we are talking about here.
Which one? This[0] one?
Doesn't say much.
[0] https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUE...
* Claudio Freire klaussfreire@gmail.com [2012-09-19 18:14]:
On Wed, Sep 19, 2012 at 1:09 PM, Cristian Rodríguez crrodriguez@opensuse.org wrote:
Or export them to text .. peraphs to json which is much more easy to parse with automated tools...
Wasn't the idea of binary formats to make it easy for tools to parse?
How does that line "parse" then? Export to text to make the supposedly-very-machine-readable format easier to parse? Why not use text from the beginning then?
Please read the design document so you understand what we are talking about here.
Which one? This[0] one?
Doesn't say much.
[0] https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUE...
It's also full of FUD about supposed limitations of syslog since it conveniently leaves out the advancements of modern syslog implementations like rsyslog or syslog-ng which are mostly on-par or superior in terms of features and functionality (well execept the log sealing feature but that seems inherently racy and is probably useless to those settings where log integrity is important). I haven't seen any hard evidence of higher performance of the "journal" compared to those syslog implementations. So the "journal's" raison d'être pretty much boild down to NIH.
BTW, tha fact that you can't turn this completely useless stuff off is an execellent example of what is wrong with the new world order you're buying in when switching to systemd (rather than nebulous feeleings people have expressed here or the fact that the boot process and ui differ from sysvinit).
El 19/09/12 14:02, Guido Berhoerster escribió:
BTW, tha fact that you can't turn this completely useless stuff off is an execellent example of what is wrong with the new world order you're buying in when switching to systemd
It is called, making design descisions :-) and if you have sound arguments against it please make them heard.
"Is binary", "is FUD", "I do not know how it works" are not arguments, but excuses.
* Cristian Rodríguez crrodriguez@opensuse.org [2012-09-19 19:48]:
El 19/09/12 14:02, Guido Berhoerster escribió:
BTW, tha fact that you can't turn this completely useless stuff off is an execellent example of what is wrong with the new world order you're buying in when switching to systemd
It is called, making design descisions :-) and if you have sound arguments against it please make them heard.
Well, it makes a logging solution mandatory which probably noone would use based on technical merits over other implementations.
"Is binary", "is FUD", "I do not know how it works" are not arguments, but excuses.
The ignorance is only on your part, much of the FUD was refuted when this "design document" was first published, check e.g. the rsyslogd authors' blog, and even since then several functionality gaps have been closed in both rsyslog and syslog-ng.
Guido,
I'm not an expert in this, but I have one question and this is a one time intervention... Can journald perform remote logs? That's all I need.
NM
2012/9/19 Guido Berhoerster gber@opensuse.org:
- Cristian Rodríguez crrodriguez@opensuse.org [2012-09-19 19:48]:
El 19/09/12 14:02, Guido Berhoerster escribió:
BTW, tha fact that you can't turn this completely useless stuff off is an execellent example of what is wrong with the new world order you're buying in when switching to systemd
It is called, making design descisions :-) and if you have sound arguments against it please make them heard.
Well, it makes a logging solution mandatory which probably noone would use based on technical merits over other implementations.
"Is binary", "is FUD", "I do not know how it works" are not arguments, but excuses.
The ignorance is only on your part, much of the FUD was refuted when this "design document" was first published, check e.g. the rsyslogd authors' blog, and even since then several functionality gaps have been closed in both rsyslog and syslog-ng. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 19/09/12 19:07, Nelson Marques escribió:
Guido,
I'm not an expert in this, but I have one question and this is a one time intervention... Can journald perform remote logs? That's all I need.
Not at the moment, as I have explained before, it is not still a full replacment for syslog. there will be a network protocol with push/pull abilitites.
Cristian Rodríguez wrote: .. Can journald perform remote logs? That's all I
need.
Not at the moment, as I have explained before, it is not still a full replacment for syslog. there will be a network protocol with push/pull abilitites.
---- Halt stop crash !!!
I have to give up syslogng and all the filtering scripts I've written for it?
I need to redo all of system log filtering by filtering some arcane, non-unix binary stream?
Sorry, that's not a unix utility. That needs to be fixed.
Can't it send it's messages to a pipe in text and any one of several log deamons that have been developed over the years to hand logs, do their job?
Or are you saying this tool doesn't play nice with with existing linux tools and tell everyone to "get a life and learn the window-ms way"?
Yeah -- I can dump a winlog in XML, -- it's a pain in the *** to parse.
I had to write a special perl prog just to count up error occurrences of a program... on linux, it would have been a grep|wc.
I assume of course -- that the log entries will also stll hold to the unix of 1-2 lines/message 1 if it can possibly do it (even overly long)??
I'm feeling a bit nervous about this -- like I'm gonna spend the next 5-7 years learning a new windows-like interface -- with a service manager to control boot and a binary log with awful filtering abilities...
That isn't unix/linux... MS has been trying to tell linux that their way is the way of the future for a long time... is this another way for them to get in the backdoor?
El 25/09/12 17:45, Linda Walsh escribió:
I have to give up syslogng and all the filtering scripts I've written for it?
No! , simply installing syslog-ng will give you the exact functionality.
Can't it send it's messages to a pipe in text and any one of several log deamons that have been developed over the years to hand logs, do their job?
Yes it can, in a wide variety of ways.
That isn't unix/linux...
So be it.
On 09/25/2012 10:45 PM, Linda Walsh wrote:
Cristian Rodríguez wrote: .. Can journald perform remote logs? That's all I
need.
Not at the moment, as I have explained before, it is not still a full replacment for syslog. there will be a network protocol with push/pull abilitites.
Halt stop crash !!!
I have to give up syslogng and all the filtering scripts I've written for it?
No.
As I wrote in another thread a few days ago: you can safely "rm -fr /var/log/journal" and use syslog-ng just as ever before (you don't need to delete it, but it can save a few hundred megabytes of disk space...). syslog-ng even detects if it runs under sysvinit or systemd, so there is no need to rewrite the configuration file...
(I know, as I'm from the syslog-ng team, researched it, tested it, and talked to systemd/journal developers in person about it)
Bye,
Peter Czanik (CzP) BalaBit IT Security / syslog-ng upstream http://czanik.blogs.balabit.com/
Peter Czanik wrote:
On 09/25/2012 10:45 PM, Linda Walsh wrote:
Cristian Rodríguez wrote: .. Can journald perform remote logs? That's all I
need.
Not at the moment, as I have explained before, it is not still a full replacment for syslog. there will be a network protocol with push/pull abilitites.
Halt stop crash !!!
I have to give up syslogng and all the filtering scripts I've written for it?
No.
As I wrote in another thread a few days ago: you can safely "rm -fr /var/log/journal" and use syslog-ng just as ever before (you don't need to delete it, but it can save a few hundred megabytes of disk space...). syslog-ng even detects if it runs under sysvinit or systemd, so there is no need to rewrite the configuration file...
(I know, as I'm from the syslog-ng team, researched it, tested it, and talked to systemd/journal developers in person about it)
I can confirm that it works just fine, I've been adjusting a couple of my systems in the last week.
On Wednesday 26 September 2012, Per Jessen wrote:
Peter Czanik wrote:
On 09/25/2012 10:45 PM, Linda Walsh wrote:
Cristian Rodríguez wrote: .. Can journald perform remote logs? That's all I
need.
Not at the moment, as I have explained before, it is not still a full replacment for syslog. there will be a network protocol with push/pull abilitites.
Halt stop crash !!!
I have to give up syslogng and all the filtering scripts I've written for it?
No.
As I wrote in another thread a few days ago: you can safely "rm -fr /var/log/journal" and use syslog-ng just as ever before (you don't need to delete it, but it can save a few hundred megabytes of disk space...). syslog-ng even detects if it runs under sysvinit or systemd, so there is no need to rewrite the configuration file...
(I know, as I'm from the syslog-ng team, researched it, tested it, and talked to systemd/journal developers in person about it)
I can confirm that it works just fine, I've been adjusting a couple of my systems in the last week.
But what I understand is that syslog styled /var/log/messages shall be removed per default? That's odd and will confuse many users and break a lot of existing setups.
cu, Rudi
Quoting Ruediger Meier sweet_f_a@gmx.de:
But what I understand is that syslog styled /var/log/messages shall be removed per default? That's odd and will confuse many users and break a lot of existing setups.
Not having /var/log/messages does not "break" anything, does it? I can perfectly remove that file and my system keeps on running.
The only 'breakage' is documentation... which, of course, needs to be adjusted to represent that.
Dominique
On Wednesday 26 September 2012, Dominique Leuenberger a.k.a DimStar wrote:
Quoting Ruediger Meier sweet_f_a@gmx.de:
But what I understand is that syslog styled /var/log/messages shall be removed per default? That's odd and will confuse many users and break a lot of existing setups.
Not having /var/log/messages does not "break" anything, does it? I can perfectly remove that file and my system keeps on running.
That's fine for you but there are a log of monitoring and security robots which are configured to watch /var/log/messages. Many users have advanced syslog setups running, so please don't remove syslog at least in "zypper dup" case.
The only 'breakage' is documentation... which, of course, needs to be adjusted to represent that.
Dominique
cu, Rudi
On 26/09/12 10:28, Ruediger Meier wrote:
That's fine for you but there are a log of monitoring and security robots which are configured to watch /var/log/messages. Many users have advanced syslog setups running, so please don't remove syslog at least in "zypper dup" case.
huh ? Existing installations are not altered.. NEW installs will not have syslog by default.
On Wednesday 26 September 2012, Cristian Rodríguez wrote:
On 26/09/12 10:28, Ruediger Meier wrote:
That's fine for you but there are a log of monitoring and security robots which are configured to watch /var/log/messages. Many users have advanced syslog setups running, so please don't remove syslog at least in "zypper dup" case.
huh ? Existing installations are not altered.. NEW installs will not have syslog by default.
That's nice to hear but was not clear to me in the light of recent openSUSE development style where nobody seems to care about user's existing systems.
cu, Rudi
Quoting Ruediger Meier sweet_f_a@gmx.de:
That's fine for you but there are a log of monitoring and security robots which are configured to watch /var/log/messages. Many users have advanced syslog setups running, so please don't remove syslog at least in "zypper dup" case.
That's probably not the 'standard user profile', but surely a valid point; and as Peter pointed out often yet, syslog remains compatible with systemd.
"zypper dup" might need to find a reasonable way of identifying if you're a 'standard user' or 'advanced user': the pure presence of /var/log/messages and/or syslog packages does not indicate anything here (as all existing users have those... but only a fraction of "all users" have setups as described by you).
Best regards, Dominique
On Wednesday 26 September 2012, Dominique Leuenberger a.k.a DimStar wrote:
Quoting Ruediger Meier sweet_f_a@gmx.de:
That's fine for you but there are a log of monitoring and security robots which are configured to watch /var/log/messages. Many users have advanced syslog setups running, so please don't remove syslog at least in "zypper dup" case.
That's probably not the 'standard user profile', but surely a valid point; and as Peter pointed out often yet, syslog remains compatible with systemd.
"zypper dup" might need to find a reasonable way of identifying if you're a 'standard user' or 'advanced user': the pure presence of /var/log/messages and/or syslog packages does not indicate anything here (as all existing users have those... but only a fraction of "all users" have setups as described by you).
Please don't break setups for "only" a fracton of all users on purpose for no good reason...
cu, Rudi
On Wednesday, September 26, 2012 15:28:24 Ruediger Meier wrote:
On Wednesday 26 September 2012, Dominique Leuenberger a.k.a DimStar
wrote:
Quoting Ruediger Meier sweet_f_a@gmx.de:
But what I understand is that syslog styled /var/log/messages shall be removed per default? That's odd and will confuse many users and break a lot of existing setups.
Not having /var/log/messages does not "break" anything, does it? I can perfectly remove that file and my system keeps on running.
That's fine for you but there are a log of monitoring and security robots which are configured to watch /var/log/messages. Many users have advanced syslog setups running, so please don't remove syslog at least in "zypper dup" case.
The proposal is to remove it from the default isntall, not from the repos.
So, if you update, you'll keep syslog. If you do a new install, you won't get it but can install it in addition...
Andreas
* Nelson Marques nmo.marques@gmail.com [2012-09-20 00:08]:
Guido,
I'm not an expert in this, but I have one question and this is a one time intervention... Can journald perform remote logs? That's all I need.
If you're talking about forwarding via TCP/UDP, then no, you need a capable syslog implementation for that.
2012/9/19 Guido Berhoerster gber@opensuse.org:
- Nelson Marques nmo.marques@gmail.com [2012-09-20 00:08]:
Guido,
I'm not an expert in this, but I have one question and this is a one time intervention... Can journald perform remote logs? That's all I need.
If you're talking about forwarding via TCP/UDP, then no, you need a capable syslog implementation for that.
And we can have both working together? If so, there's no real harm :)
NM
Le mercredi 19 septembre 2012 à 23:44 +0100, Nelson Marques a écrit :
2012/9/19 Guido Berhoerster gber@opensuse.org:
- Nelson Marques nmo.marques@gmail.com [2012-09-20 00:08]:
Guido,
I'm not an expert in this, but I have one question and this is a one time intervention... Can journald perform remote logs? That's all I need.
If you're talking about forwarding via TCP/UDP, then no, you need a capable syslog implementation for that.
And we can have both working together? If so, there's no real harm :)
Yes, you can.
For most purpose, only installing journal will be enough, IMHO. For other "expert" features (like remote logging), a syslog implementation should be used.
Frederic Crozat wrote:
Le mercredi 19 septembre 2012 à 23:44 +0100, Nelson Marques a écrit :
2012/9/19 Guido Berhoerster gber@opensuse.org:
- Nelson Marques nmo.marques@gmail.com [2012-09-20 00:08]:
Guido,
I'm not an expert in this, but I have one question and this is a one time intervention... Can journald perform remote logs? That's all I need.
If you're talking about forwarding via TCP/UDP, then no, you need a capable syslog implementation for that.
And we can have both working together? If so, there's no real harm :)
Yes, you can.
For most purpose, only installing journal will be enough, IMHO. For other "expert" features (like remote logging), a syslog implementation should be used.
What about the standard syslog setup that we use, does systemd journal support that at the moment or will everything just be written to the journal and then only filtered out when displayed?
This is perhaps not the right thread, but how functional is systemd-journal really at the moment?
- where do I change the timestamp format? - what are the fields that are mentioned in the man page? - I was trying to get systemd-journal to show me what would normally go into /var/log/firewall, how do I do that?
El 20/09/12 13:39, Per Jessen escribió:
Looks like you have not understand the purpose of the journal and the design descisions it has.
- where do I change the timestamp format?
You dont.
- what are the fields that are mentioned in the man page?
http://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html
- I was trying to get systemd-journal to show me what would normally go into /var/log/firewall, how do I do that?
You dont.
The whole purpose of the journal is to provide **structured logging** in a single,consistent format.
Cristian Rodríguez wrote:
El 20/09/12 13:39, Per Jessen escribió:
Looks like you have not understand the purpose of the journal and the design descisions it has.
Certainly, I admit that. I am hoping somebody else will kindly enlighten me.
- where do I change the timestamp format?
You dont.
Okay. Let me rephrase the question: How do I get output from the journal with timestamps in the format I desire?
- what are the fields that are mentioned in the man page?
Http://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html
Thanks.
- I was trying to get systemd-journal to show me what would normally
go into /var/log/firewall, how do I do that?
You dont.
The whole purpose of the journal is to provide **structured logging** in a single,consistent format.
Okay, another rephrase: I want to see the messages logged by iptables (in my firewall script). How do I do that?
Le jeudi 20 septembre 2012 à 19:14 +0200, Per Jessen a écrit :
Cristian Rodríguez wrote:
El 20/09/12 13:39, Per Jessen escribió:
Looks like you have not understand the purpose of the journal and the design descisions it has.
Certainly, I admit that. I am hoping somebody else will kindly enlighten me.
- where do I change the timestamp format?
You dont.
Okay. Let me rephrase the question: How do I get output from the journal with timestamps in the format I desire?
How about waiting for systemd 190 to land in Factory (probably next week), which will have a much better journalctl (compared to the one we have in 12.2) ?
Okay, another rephrase: I want to see the messages logged by iptables (in my firewall script). How do I do that?
Wait for systemd 189 (or later) + kernel 3.5 (or later), they will support kernel structured logging in the journal.
On Thu, Sep 20, 2012 at 1:43 PM, Cristian Rodríguez crrodriguez@opensuse.org wrote:
- where do I change the timestamp format?
You dont.
- I was trying to get systemd-journal to show me what would normally go into /var/log/firewall, how do I do that?
You dont.
The whole purpose of the journal is to provide **structured logging** in a single,consistent format.
Well, that "purpose" is misguided.
Removing freedom from the user and, incidentally, the sysadmin, is Windows' modus operandi, not Linux's. You won't be able to force that down linux users' throats, because linux users use linux exactly because of the freedom it provides.
The binary format already contains everything loggable, so the customizable tool has to be journalctl.
Kind of journalctl --format="%t %h: blah"
That accomplishes journal's "purpose" without alienating users. Ie: the tools that want to analyze logs can dictate output format.
El 20/09/12 14:15, Claudio Freire escribió:
Well, that "purpose" is misguided.
No, it is not.
Removing freedom from the user and, incidentally, the sysadmin, is Windows' modus operandi, not Linux's. You won't be able to force that down linux users' throats, because linux users use linux exactly because of the freedom it provides.
Heh, "removing freedom".. ?
http://1cruzdelsur.files.wordpress.com/2011/09/mel-1995.jpg
lets repeat, unfortunately this does not seem to get across yet.. ***no one is forcing you to use this distribution, or journald, or whatever ** please abandon victimhood, thanks !
The binary format already contains everything loggable, so the customizable tool has to be journalctl.
Kind of journalctl --format="%t %h: blah"
That accomplishes journal's "purpose" without alienating users. Ie: the tools that want to analyze logs can dictate output format.
It could , yes. however that is not implemented. you could though write a very small script to obtain that result in a few minutes though, just use the --output switch with value "json" and process accordingly.
On Thu, Sep 20, 2012 at 2:40 PM, Cristian Rodríguez crrodriguez@opensuse.org wrote:
The binary format already contains everything loggable, so the customizable tool has to be journalctl.
Kind of journalctl --format="%t %h: blah"
That accomplishes journal's "purpose" without alienating users. Ie: the tools that want to analyze logs can dictate output format.
It could , yes. however that is not implemented. you could though write a very small script to obtain that result in a few minutes though, just use the --output switch with value "json" and process accordingly.
I guess I could do that. But that's because I'm a programmer, not all sysadmins are.
On Thu, Sep 20, 2012 at 2:40 PM, Cristian Rodríguez crrodriguez@opensuse.org wrote:
lets repeat, unfortunately this does not seem to get across yet.. ***no one is forcing you to use this distribution, or journald, or whatever ** please abandon victimhood, thanks !
Well.... because that's a lame answer not worth considering.
I'm an administrator and lead developer on a few projects, and I can tell you, I don't work to increase the amount of disk usage on SourceForge or to cater to the needs of a very few people I like... the more my project's used, the better I feel. In essence, opensource projects strive, usually, to be useful for as many as possible and manageable.
So you can't tell me "nobody's forcing you to use this distro", because... well... this distro isn't being maintained so that only OBS can use it. It's for *general* use, and it has to cater to *general* needs and public.
Last I checked, openSUSE was good for both, desktop, laptop and server. If you want to drop some of those explicitly, that would have to be announced. It hasn't, or at least I didn't see the announcement.
Right now, in this particular point, we're talking about server (sysadmins tend to manage servers, but that's not always true).
Claudio Freire wrote:
On Thu, Sep 20, 2012 at 2:40 PM, Cristian Rodríguez crrodriguez@opensuse.org wrote:
lets repeat, unfortunately this does not seem to get across yet.. ***no one is forcing you to use this distribution, or journald, or whatever ** please abandon victimhood, thanks !
Well.... because that's a lame answer not worth considering.
+1. I'm amazed at the complete disrespect for the openSUSE users though.
Hello,
Before we all end up in flames, a hopefully not too biased view from syslog-ng upstream :-)
First of all, systemd journal is a perfect solution for about 90%+ of openSUSE users, which have stand alone workstations and don't care at all about logging. They don't need rsyslog or syslog-ng. The journal collects logs under /var/log/journal into some binary files. By default it does not take more than 5% of available disk space, so logs can't fill up the partition accidentally. It's very limited, but user friendly. Actually I don't really understand, why syslog is still installed on openSUSE (ArchLinux removed syslog from systemd based installations to avoid dual logging...), but this is a different questions...
For the remaining <10%, see some information below.
On 09/20/2012 06:39 PM, Per Jessen wrote:
What about the standard syslog setup that we use, does systemd journal support that at the moment or will everything just be written to the journal and then only filtered out when displayed?
The good news is, that standard syslog setup is supported. One can almost completely get rid of systemd journal. Just "rm -fr /var/log/journal". It's safe, systemd journal will still keep enough information in tmpfs to provide information about running services. It still takes over /dev/log, but forwards all information to /var/run/systemd/journal/syslog so syslog-ng can read local logs from there instead of /dev/log. The bad news is, that this info is not mentioned in any man pages installed on openSUSE. So, if you still want a flexible logging solution, like syslog-ng, on a server, or a networked workstation, just do that "rm -fr /var/log/journal". This way even that 5% of the partition is not wasted, and you can configure your favorite logger to your liking. You will have all the usual formatting templates, networking possibilities, filters, patterndb, etc.
I hope this helps, and flames are extinguished :) Bye, Peter Czanik (CzP) BalaBit IT Security / syslog-ng upstream http://czanik.blogs.balabit.com/
On Thu, Sep 20, 2012 at 4:51 PM, Peter Czanik pczanik@fang.fa.gau.hu wrote:
Before we all end up in flames, a hopefully not too biased view from syslog-ng upstream :-)
Yep, sorry about that. I was prodded and reacted before I noticed.
First of all, systemd journal is a perfect solution for about 90%+ of openSUSE users, which have stand alone workstations and don't care at all about logging. They don't need rsyslog or syslog-ng. The journal collects logs under /var/log/journal into some binary files. By default it does not take more than 5% of available disk space, so logs can't fill up the partition accidentally. It's very limited, but user friendly. Actually I don't really understand, why syslog is still installed on openSUSE (ArchLinux removed syslog from systemd based installations to avoid dual logging...), but this is a different questions...
Strangely enough, I agree. I complain about the binary log because it's unnecessary complexity and obscurity, but the fact that workstation users rarely need to bother reading the logs kind of dilutes the effects of all that, and the fact that syslog is still functional in openSUSE is a very very good thing for those that do.
Having it run, by default, in tandem with journal was, AFAIK, a transitional measure. Because all init stuff goes into the journal, and users new to systemd won't know where to find all those messages and be unable to fix boot problems. Now, systemd is fixing the tty "bug" that made it not show those messages to the console, meaning users will *see* what's wrong, and syslog will cease to be useful in the default installation.
Claudio Freire wrote:
On Thu, Sep 20, 2012 at 4:51 PM, Peter Czanik pczanik@fang.fa.gau.hu wrote:
Before we all end up in flames, a hopefully not too biased view from syslog-ng upstream :-)
Yep, sorry about that. I was prodded and reacted before I noticed.
First of all, systemd journal is a perfect solution for about 90%+ of openSUSE users, which have stand alone workstations and don't care at all about logging. They don't need rsyslog or syslog-ng. The journal collects logs under /var/log/journal into some binary files. By default it does not take more than 5% of available disk space, so logs can't fill up the partition accidentally. It's very limited, but user friendly. Actually I don't really understand, why syslog is still installed on openSUSE (ArchLinux removed syslog from systemd based installations to avoid dual logging...), but this is a different questions...
Strangely enough, I agree. I complain about the binary log because it's unnecessary complexity and obscurity, but the fact that workstation users rarely need to bother reading the logs kind of dilutes the effects of all that, and the fact that syslog is still functional in openSUSE is a very very good thing for those that do.
Leaving out syslog from the standard pattern(s) just means more work for those of us with more than a single workstation. I am slowly beginning to see the necessity of using autoyast (to maintain my own standard installation pattern).
On Sun, Sep 23, 2012 at 12:34 PM, Per Jessen per@computer.org wrote:
Leaving out syslog from the standard pattern(s) just means more work for those of us with more than a single workstation. I am slowly beginning to see the necessity of using autoyast (to maintain my own standard installation pattern).
That's a good idea regardless of journal and systemd anyway.
On Thursday, September 20, 2012 21:51:35 Peter Czanik wrote:
Hello,
Before we all end up in flames, a hopefully not too biased view from syslog-ng upstream :-)
First of all, systemd journal is a perfect solution for about 90%+ of openSUSE users, which have stand alone workstations and don't care at all about logging. They don't need rsyslog or syslog-ng. The journal collects logs under /var/log/journal into some binary files. By default it does not take more than 5% of available disk space, so logs can't fill up the partition accidentally. It's very limited, but user friendly. Actually I don't really understand, why syslog is still installed on openSUSE (ArchLinux removed syslog from systemd based installations to avoid dual logging...), but this is a different questions...
Thanks Peter for the info. So, let's remove syslog/rsyslog from the default install now.
Coolo, could you do the change - if you agree with it, please?
Frederic, could you send Karl Eichwalder an update for the 12.3 release notes mentioning this?
Thanks, Andreas
For the remaining <10%, see some information below.
On 09/20/2012 06:39 PM, Per Jessen wrote:
What about the standard syslog setup that we use, does systemd journal support that at the moment or will everything just be written to the journal and then only filtered out when displayed?
The good news is, that standard syslog setup is supported. One can almost completely get rid of systemd journal. Just "rm -fr /var/log/journal". It's safe, systemd journal will still keep enough information in tmpfs to provide information about running services. It still takes over /dev/log, but forwards all information to /var/run/systemd/journal/syslog so syslog-ng can read local logs from there instead of /dev/log. The bad news is, that this info is not mentioned in any man pages installed on openSUSE. So, if you still want a flexible logging solution, like syslog-ng, on a server, or a networked workstation, just do that "rm -fr /var/log/journal". This way even that 5% of the partition is not wasted, and you can configure your favorite logger to your liking. You will have all the usual formatting templates, networking possibilities, filters, patterndb, etc.
I hope this helps, and flames are extinguished :) Bye, Peter Czanik (CzP) BalaBit IT Security / syslog-ng upstream http://czanik.blogs.balabit.com/
On 25.09.2012 11:42, Andreas Jaeger wrote:
On Thursday, September 20, 2012 21:51:35 Peter Czanik wrote:
Hello,
Before we all end up in flames, a hopefully not too biased view from syslog-ng upstream :-)
First of all, systemd journal is a perfect solution for about 90%+ of openSUSE users, which have stand alone workstations and don't care at all about logging. They don't need rsyslog or syslog-ng. The journal collects logs under /var/log/journal into some binary files. By default it does not take more than 5% of available disk space, so logs can't fill up the partition accidentally. It's very limited, but user friendly. Actually I don't really understand, why syslog is still installed on openSUSE (ArchLinux removed syslog from systemd based installations to avoid dual logging...), but this is a different questions...
Thanks Peter for the info. So, let's remove syslog/rsyslog from the default install now.
Coolo, could you do the change - if you agree with it, please?
So this kind of puts the last nail in the sysvinit coffin?
Greetings, Stephan
On Tuesday, September 25, 2012 12:39:59 Stephan Kulow wrote:
On 25.09.2012 11:42, Andreas Jaeger wrote:
On Thursday, September 20, 2012 21:51:35 Peter Czanik wrote:
Hello,
Before we all end up in flames, a hopefully not too biased view from syslog-ng upstream :-)
First of all, systemd journal is a perfect solution for about 90%+ of openSUSE users, which have stand alone workstations and don't care at all about logging. They don't need rsyslog or syslog-ng. The journal collects logs under /var/log/journal into some binary files. By default it does not take more than 5% of available disk space, so logs can't fill up the partition accidentally. It's very limited, but user friendly. Actually I don't really understand, why syslog is still installed on openSUSE (ArchLinux removed syslog from systemd based installations to avoid dual logging...), but this is a different questions...
Thanks Peter for the info. So, let's remove syslog/rsyslog from the default install now.
Coolo, could you do the change - if you agree with it, please?
So this kind of puts the last nail in the sysvinit coffin?
Ah, you're right - let's do it one by one and not start from the end.
Frederic, what steps do you propose - here's my suggestion: 1. update to systemd 185 2. Change grub to not offer switch for init packages 3. Change sysvinit-init package (or however it's called) 4. Remove syslog from default install.
Andreas
* Nelson Marques nmo.marques@gmail.com [2012-09-20 00:44]:
2012/9/19 Guido Berhoerster gber@opensuse.org:
- Nelson Marques nmo.marques@gmail.com [2012-09-20 00:08]:
Guido,
I'm not an expert in this, but I have one question and this is a one time intervention... Can journald perform remote logs? That's all I need.
If you're talking about forwarding via TCP/UDP, then no, you need a capable syslog implementation for that.
And we can have both working together? If so, there's no real harm :)
Rather side by side, so be sure to disable logging to /var/log/journal or it'll take twice the space.
El 19/09/12 17:58, Guido Berhoerster escribió:
The ignorance is only on your part, much of the FUD was refuted when this "design document" was first published,
The misconceptions and obvious bias from that article has been already addressed.
Let's see what of the competing solutions get adopted and goes forward, good luck with that, though.
On Wed, Sep 19, 2012 at 12:49 PM, Cristian Rodríguez crrodriguez@opensuse.org wrote:
I happen to agree that the binary format is unnecessary,
Ok, then how you implement all those features mentioned in the design document to work fast ?
So, quoting the doc:
Simplicity: little code with few dependencies and minimal waste through abstraction.
Text files are as simple as it gets.
Zero Maintenance: logging is crucial functionality to debug and monitor systems, as such it should not be a problem source of its own, and work as well as it can even in dire circumstances. For example, that means the system needs to react gracefully to problems such as limited disk space or /var not being available, and avoid triggering disk space problems on its own (e.g. by implementing journal file rotation right in the daemon at the time a journal file is extended).
Nothing to do with text files or not, it's an implementation issue.
Robustness: data files generated by the journal should be directly accessible to administrators and be useful when copied to different hosts with tools like “scp” or “rsync”. Incomplete copies should be processed gracefully. Journal file browsing clients should work without the journal daemon being around.
Text files provide this natively
Portable: journal files should be usable across the full range of Linux systems, regardless which CPU or endianess is used. Journal files generated on an embedded ARM system should be viewable on an x86 desktop, as if it had been generated locally.
ASCII text is the epitome of portability. Use UTF-8 if you need unicode support. In any case, highly portable.
Performance: journal operations for appending and browsing should be fast in terms of complexity. O(log n) or better is highly advisable, in order to provide for organization-wide log monitoring with good performance
Appending is O(1) (assuming constant line length) on text files. If browsing means reading the first, second, third etc entries sorted by time, then browsing is also O(1) in text files. If browsing means reading the entry at time X (for arbitrary time X), then it's O(log n) in text files by means of bisection, as text-based logs are naturally sorted by timestamp.
If you need to search by other fields, you need indices. This can be done with text files, but syslog-ng already supports a better way: just dump everything into a (pattern) database as it comes. In any case, if you introduce indices, appending is no longer O(1).
Integration: the journal should be closely integrated with the rest of the system, so that logging is so basic for a service, that it would need to opt-out of it in order to avoid it. Logging is a core responsibility for a service manager, and it should be integrated with it reflecting that.
Again, has nothing to do with text or not.
Minimal Footprint: journal data files should be small in disk size, especially in the light that the amount of data generated might be substantially bigger than on classic syslog.
While text files have a tendency to include some bloat, both because of the format and because of the verbose nature of human-readable messages, data compression can easily compensate those redundancies, and it has been the mainstream for logging for ages. The fact that compression happens at log rotation does not detract from its effectiveness, and some compression schemes are even random-readable (think bzip2). Other compression schemes are packetizable (deflate), making them suitable for record-by-record on-the-fly compression. Compressed formats are technically binary, but in practice, due to the ubiquity and transparency of decompression tools, rather equivalent to text files. You can even zless and zgrep.
General Purpose Event Storage: the journal should be useful to store any kind of journal entry, regardless of its format, its meta data or size.
Text files can contain arbitrary data, so there's nothing more general-purpose than text files. If you need binary blobs, you have various codings that will result in ASCII-safe text representing it. Just to mention two, hex and base-64.
Unification: the numerous different logging technologies should be unified so that all loggable events end up in the same data store, so that global context of the journal entries is stored and available later. e.g. a firmware entry is often followed by a kernel entry, and ultimately a userspace entry. It is key that the relation between the three is not lost when stored on disk. Base for Higher Level Tools: the journal should provide a generally useful API which can be used by health monitors, recovery tools, crash report generators and other higher level tools to access the logged journal data. Universality: as a basic building block of the OS the journal should be universal enough and extensible to cater for application-specific needs. The format needs to be extensible, and APIs need to be available. Clustering & Network: Today computers seldom work in isolation. It is crucial that logging caters for that and journal files and utilities are from the ground on developed to support big multi-host installations.
Unrelated to store format. "Data store" here can easily be a series of text files.
Scalability: the same way as Linux scales from embedded machines to super computers and clusters, the journal should scale, too. Logging is key when developing embedded devices, and also essential at the other end of the spectrum, for maintaining clusters. The journal needs to focus on generalizing the common use patterns while catering for the specific differences, and staying minimal in footprint.
Again, no reason why text files can't scale. There's no need to stuff everything into a single text file, and abstraction APIs can easily query several text files in tandem. Text-vs-binary provides no features in this regard.
Security: Journal files should be authenticated to make undetected manipulation impossible.
Text-based log lines can also be authenticated.You have MACs, PGP ASCII armor, etc... Even assuming MACs on both implementations, I seriously doubt journal files are safer from tampering by root, though, leaving it in the same situation as syslog is. If root can create a log file, root can tamper with it.
Am 19.09.2012 17:49, schrieb Cristian Rodríguez:
El 19/09/12 11:20, Claudio Freire escribió:
On Wed, Sep 19, 2012 at 7:26 AM, Ruediger Meier sweet_f_a@gmx.de wrote:
Unfortunately you can do this only on machines where journalctl is installed/available. I assume that you can't read the journald logs on most existing systems.
Just a matter of building journalctl from source I'd imagine, as would be the case if you were missing grep.
Or export them to text .. peraphs to json which is much more easy to parse with automated tools...
Unfortunately, there is no tool to read or export the BLOB put onto my disk and fragmenting my filesystem like hell, see
https://bugzilla.novell.com/817778
Yay. Never had that with text logs. Maybe they were missing a few lines after a crash, or they had some kB of binary garbage interspersed, but I could always read them.
I happen to agree that the binary format is unnecessary,
Ok, then how you implement all those features mentioned in the design document to work fast ?
I give a sh*t on that design document, as long as I can not read my logs, it is the end of the month and they would be very useful to do my accounting.
Fun facts about sytemd-journal: * it logs to a binary database * it can not filter out the user session logs from the system logs * if the database is broken, i tells you (journalctl --verify) * but it can not repair or recover it * even if the database is not broken, it can not read it (bnc#817778) * fills the disk way beyound its configured limits (bnc#817780)
...well, only "fun" if you have a strange definition of "fun".
* Stefan Seyfried stefan.seyfried@googlemail.com [2013-04-30 08:46]:
Am 19.09.2012 17:49, schrieb Cristian Rodríguez:
El 19/09/12 11:20, Claudio Freire escribió:
On Wed, Sep 19, 2012 at 7:26 AM, Ruediger Meier sweet_f_a@gmx.de wrote:
Unfortunately you can do this only on machines where journalctl is installed/available. I assume that you can't read the journald logs on most existing systems.
Just a matter of building journalctl from source I'd imagine, as would be the case if you were missing grep.
Or export them to text .. peraphs to json which is much more easy to parse with automated tools...
Unfortunately, there is no tool to read or export the BLOB put onto my disk and fragmenting my filesystem like hell, see
https://bugzilla.novell.com/817778
Yay. Never had that with text logs. Maybe they were missing a few lines after a crash, or they had some kB of binary garbage interspersed, but I could always read them.
I happen to agree that the binary format is unnecessary,
Ok, then how you implement all those features mentioned in the design document to work fast ?
I give a sh*t on that design document, as long as I can not read my logs, it is the end of the month and they would be very useful to do my accounting.
Fun facts about sytemd-journal:
- it logs to a binary database
- it can not filter out the user session logs from the system logs
- if the database is broken, i tells you (journalctl --verify)
- but it can not repair or recover it
- even if the database is not broken, it can not read it (bnc#817778)
- fills the disk way beyound its configured limits (bnc#817780)
...well, only "fun" if you have a strange definition of "fun".
That's probably the reason why no other distro has chosen to rely on it exclusively (not even Fedora!), so the oS userbase doing beta-testing. It should probably be noted in the release notes that users who rely on logs (and/or have significant amounts of log messages) should install rsyslog.
On 04/30/2013 02:46 AM, Stefan Seyfried wrote:
I give a sh*t on that design document, as long as I can not read my logs, it is the end of the month and they would be very useful to do my accounting.
Fun facts about sytemd-journal:
- it logs to a binary database
Yes.
- it can not filter out the user session logs from the system logs
Something can be done about that..I thought it was able to so
- if the database is broken, i tells you (journalctl --verify)
- but it can not repair or recover it
That's why it is called --verify and not --repair .. (not implemented yet, never advertised as repair either)
- even if the database is not broken, it can not read it (bnc#817778)
Yes, it can be slow, anyway that looks more like a bug.
- fills the disk way beyound its configured limits (bnc#817780)
"the journald states in the logs: "Allowing runtime journal files to grow to 394.8M."
but: susi:~ # journalctl --disk-usage Journals take up 501.9M on disk.
epic fail :-) "
Yes, epic fail of **your understanding** of the message you are seeing.
It says "Allowing **runtime** journal files" .. "runtime journal files" are those living in /run not the ones living in /var/log/journal.
journalctl --disk-usage accounts for total size of runtime+ system.
On Tuesday 30 April 2013, Cristian Rodríguez wrote:
On 04/30/2013 02:46 AM, Stefan Seyfried wrote:
I give a sh*t on that design document, as long as I can not read my logs, it is the end of the month and they would be very useful to do my accounting.
Fun facts about sytemd-journal:
- it logs to a binary database
Yes.
- it can not filter out the user session logs from the system logs
Something can be done about that..I thought it was able to so
- if the database is broken, i tells you (journalctl --verify)
- but it can not repair or recover it
That's why it is called --verify and not --repair .. (not implemented yet, never advertised as repair either)
How can such untested alpha quality stuff make it into a distro?
cu, Rudi
On 2013-04-30T11:38:19, Ruediger Meier sweet_f_a@gmx.de wrote:
That's why it is called --verify and not --repair .. (not implemented yet, never advertised as repair either)
How can such untested alpha quality stuff make it into a distro?
Because the community didn't object when it was merged, or during the beta phase.
Regards, Lars
Am 30.04.2013 12:21, schrieb Lars Marowsky-Bree:
On 2013-04-30T11:38:19, Ruediger Meier sweet_f_a@gmx.de wrote:
That's why it is called --verify and not --repair .. (not implemented yet, never advertised as repair either)
How can such untested alpha quality stuff make it into a distro?
Because the community didn't object when it was merged, or during the beta phase.
If I did not know that you are not taking drugs, I would now wonder which one is adjusting your view of the reality :-)
Hay, I am in danger of doing a Linus here ... As he so often says "the kernel WILL not break user space", and so Distributions MUST not (a) break users, (b) fail to test properly, themselves, (c) Passively accept the latest crap.
If they do accept crap they reinforce the vicious circle of Projects shipping barely alpha code as 'finished'. It tool me minutes to conclude Kmail2 was a stinking pile of manure, a day to decide that regressing to Kmail1 would be unnecessarily difficult and a morning to get Claws Mail working, including fixing Mdir mailboxes.
The next time I will dump all KDE.
Cheers, omb
Am Tue, 30 Apr 2013 12:58:20 +0200, scheib Stefan Seyfried:
Am 30.04.2013 12:21, schrieb Lars Marowsky-Bree:
On 2013-04-30T11:38:19, Ruediger Meier sweet_f_a@gmx.de wrote:
That's why it is called --verify and not --repair .. (not implemented yet, never advertised as repair either)
How can such untested alpha quality stuff make it into a distro?
Because the community didn't object when it was merged, or during the beta phase.
If I did not know that you are not taking drugs, I would now wonder which one is adjusting your view of the reality :-) -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Lars Marowsky-Bree wrote:
On 2013-04-30T11:38:19, Ruediger Meier sweet_f_a@gmx.de wrote:
That's why it is called --verify and not --repair .. (not implemented yet, never advertised as repair either)
How can such untested alpha quality stuff make it into a distro?
Because the community didn't object when it was merged, or during the beta phase.
Oh, many of us objected, but were ignored. In fact, look at Christian's reaction to Stefan's bug report -- no comment needed, denial at its best.
Joachim
El 30/04/13 21:04, Joachim Schrod escribió:
Lars Marowsky-Bree wrote:
On 2013-04-30T11:38:19, Ruediger Meier sweet_f_a@gmx.de wrote:
That's why it is called --verify and not --repair .. (not implemented yet, never advertised as repair either)
How can such untested alpha quality stuff make it into a distro?
Because the community didn't object when it was merged, or during the beta phase.
Oh, many of us objected, but were ignored.
Objecting does not mean anything, those who do the work are the ones that take decisions.
In fact, look at
Christian's reaction to Stefan's bug report -- no comment needed, denial at its best.
What denial ? He pointed out 3 problems,
- one bogus based on the a misunderstading on what "runtime journal files" mean.
- The other one is where he says --verify does not fix broken journal files, this is expected, it has never gained the capability of fixing the files nor it was advertised that it did, what the command line flags do is clearly documented in the manual.
- The other problem he mentioned I told it was a bug.
Cristian Rodríguez wrote:
El 30/04/13 21:04, Joachim Schrod escribió:
Lars Marowsky-Bree wrote:
On 2013-04-30T11:38:19, Ruediger Meier sweet_f_a@gmx.de wrote:
That's why it is called --verify and not --repair .. (not implemented yet, never advertised as repair either)
How can such untested alpha quality stuff make it into a distro?
Because the community didn't object when it was merged, or during the beta phase.
Oh, many of us objected, but were ignored.
Objecting does not mean anything, those who do the work are the ones that take decisions.
Yes, that's the bad thing -- I accept that I'm not as relevant as I'm to busy looking for the next TeX-Live that must go out and CTAN must stay running, but -- can't you folks take some hints from Linus that backward compatibility and robustness is a MUST HAVE, not a NICE to HAVE thing?
In fact, look at
Christian's reaction to Stefan's bug report -- no comment needed, denial at its best.
What denial ? He pointed out 3 problems,
- The other one is where he says --verify does not fix broken
journal files, this is expected, it has never gained the capability of fixing the files nor it was advertised that it did, what the command line flags do is clearly documented in the manual.
That's the denial I meant. That something is documented in the manual doesn't mean that it ain't a bug, and a show-stopper for putting things in a distribution, even though some folks like to think it is.
Don't understand me wrong -- I think systemd has a lot of good ideas and a sound concept. The introduction in oS was too rushed, and its tendency to subsume all other system service are frightening from a sysadmin maintenance perspective.
I've read your joke yesterday about CUPS not being subsumed by systemd right yet -- but I wouldn't hold my breath for it. crond is next [*], what comes afterwards? Are you sure that printers are not something that might appear and disappear and thus something that systemd developers might want to start to their we-control-it list? Since, that's the pattern -- ``everything that might come up or go down asynchronously has to be managed by systemd'' (TM).
For developer's laptops, that's nice, but on servers the current state of affair is not adequate.
Joachim
[*] Note: My problem ain't because systemd is not able to issue time-event based activations. It's clear that it is. It's because cron is already completely inadequate for any professional job scheduling tasks -- and systemd is worse, instead of being better. The actual problem is decoupling: substitution of cron jobs in a given distribution seems to be easier than decoupling from the integration that's planned for systemd as a cron replacement. Well, we'll see how that turns out;
El 30/04/13 21:59, Joachim Schrod escribió:
That's the denial I meant. That something is documented in the manual doesn't mean that it ain't a bug, and a show-stopper for putting things in a distribution, even though some folks like to think it is.
There is no bug, what is happening here is that a the feature required to "fsck" the journal files has not been implemented yet.
I've read your joke yesterday about CUPS not being subsumed by systemd right yet -- but I wouldn't hold my breath for it.crond is next [*],
No, again you did not understood what I said. (I am expressing myself bad maybe?) what I said was that there will be no wrapper or otherwise an intervention in cron or the at daemon in the systemd side at all. people will be able to run cron or at without any change whatsoever. But we may migrate the cron scripts shipped with the distribution to native systemd timers (at some point in the future) and thus making cron unnecessary as a default component.
what comes afterwards?
Here is the list http://cgit.freedesktop.org/systemd/systemd/tree/TODO of things that come in the systemd side, there is no intention of replacing any other major component.(apart from getting the DBUS protocol support in the kernel and making systemd use it to drop the circular dependency between dbus and systemd, Greg KH is working on that, so I am confident it will go OK)
On Tue, 30 Apr 2013 22:30:26 -0400 Cristian Rodríguez crrodriguez@opensuse.org wrote:
There is no bug, what is happening here is that a the feature required to "fsck" the journal files has not been implemented yet.
With frequency of difficulties it has to actually do logging, not implemented repair facility has the same effect as a bug.
(And, I am one of annoyed users now. You know problems with imperfections of journalctrl.)
Am 01.05.2013 04:30, schrieb Cristian Rodríguez:
El 30/04/13 21:59, Joachim Schrod escribió:
That's the denial I meant. That something is documented in the manual doesn't mean that it ain't a bug, and a show-stopper for putting things in a distribution, even though some folks like to think it is.
There is no bug, what is happening here is that a the feature required to "fsck" the journal files has not been implemented yet.
The fun thing is, that exactly the thing happened that journal critics had foreseen and which were dismissed as "will not happen" by systemd upstream.
* binary format with no tool to read or fix it in case of the slightest problem.
All the proposed goodness of the journal is totally useless if you cannot read the logs.
If I have a few bytes of garbage in a journal file, it is toast. With the default of one file being 256MB in size (my root partition is 20GB), this will amount to > 3 months of logs lost.
With traditional logging, a few bytes of garbage in the logfile will be exactly that: a few bytes of garbage. Nobody will care. I can still extract everything.
It is the old problem of data protection vs. data security. The data in the journal is well protected. Protected from getting used by me.
On Wed, 01 May 2013 11:10:32 +0200 Stefan Seyfried stefan.seyfried@googlemail.com wrote:
With traditional logging, a few bytes of garbage in the logfile will be exactly that: a few bytes of garbage. Nobody will care. I can still extract everything.
Nobody will care only if log presence is important only to troubleshoot technical problems, but usually it will raise a flag about possibility that someone else fiddled with logs, which is not a good sign.
I looked for more debugging information in journal (12.2), so when I stumbled over missing entries before certain time, I spent some time looking at the system using Live USB. Why? Because I wasn't sure what happened. Problem with logging can be a bug (which is harmless), or sign that somebody cracked the system.
I found out that journal had 2 log files covering all the time from installation to present, but it was ignoring presence of older file and nothing will tell me that there is another log. This is probably yet another not implemented functionality, at least in 12.2.
What is annoying from my prospective is that almost everyone is learning systemd and journal and udev (and hopefully nothing more), and availability of user to user help is sparse at best. When you are stuck with a problem, you are on your own most of the time, which grants days of fun, for those that have no other ways to have it.
When you have problem with 12.2, which has older version of systemd and journald, you are on your own as those that know the best (Frederic and Cristian) have very little interest to help with stuff that is solved in a newer version, and on the other side, there is no new systemd port to 12.2. Frederic mentioned that changes are too intrusive to create port, which tells me that two systemd versions are not backwards compatible and he will have to spend too much time redesigning 12.2.
While I like to solve technical puzzles, amount that is now pushed on users like me is overwhelming and I look for other areas that need help to contribute to openSUSE for time being, ie. until number of changes in certain time frame subside.
El 01/05/13 10:08, Rajko escribió:
I found out that journal had 2 log files covering all the time from installation to present, but it was ignoring presence of older file and nothing will tell me that there is another log. This is probably yet another not implemented functionality, at least in 12.2.
This was fixed in systemd 201 and backported to 12.3
which tells me that two systemd versions are not backwards compatible and he will have to spend too much time redesigning 12.2.
It is not backward compatible in the same sense kernel 3.0 is not source compatible with 3.9, backward compatibility is there for the interfaces that are exposed to the user or callers, not internal ones on which all SUSE specific additions depend on.
Rajko wrote:
On Wed, 01 May 2013 11:10:32 +0200 Stefan Seyfried stefan.seyfried@googlemail.com wrote:
With traditional logging, a few bytes of garbage in the logfile will be exactly that: a few bytes of garbage. Nobody will care. I can still extract everything.
Nobody will care only if log presence is important only to troubleshoot technical problems, but usually it will raise a flag about possibility that someone else fiddled with logs,
--- Not at all -- it is FAR more likely that the logging daemon didn't shut down the log properly and garbage got put there. HW & SW malfunctions are far more likely to be the cause of something than tampering.
Regardless, w/text logs there is nothing preventing you from recovering the undamaged portions, but conversely, you are raising the issue of how easy it is for a hacker to cover their tracks -- just a few bytes in the log and it is corrupt and can't be recovered.
You think that is better?
There are no benefits of binary logs to system owners, but there is large benefit for those who want to easily cover their tracks.
On 04/30/2013 09:36 PM, Cristian Rodríguez pecked at the keyboard and wrote:
El 30/04/13 21:04, Joachim Schrod escribió:
Lars Marowsky-Bree wrote:
On 2013-04-30T11:38:19, Ruediger Meier sweet_f_a@gmx.de wrote:
That's why it is called --verify and not --repair .. (not implemented yet, never advertised as repair either)
How can such untested alpha quality stuff make it into a distro?
Because the community didn't object when it was merged, or during the beta phase.
Oh, many of us objected, but were ignored.
Objecting does not mean anything, those who do the work are the ones that take decisions.
And here I thought this was a community distro, but I see it's more of a dictatorship. :-)
El 30/04/13 22:11, Ken Schneider - openSUSE escribió:
And here I thought this was a community distro, but I see it's more of a dictatorship. :-)
It is more a DOocracy that a dictatorship.
On 04/30/2013 10:33 PM, Cristian Rodríguez pecked at the keyboard and wrote:
El 30/04/13 22:11, Ken Schneider - openSUSE escribió:
And here I thought this was a community distro, but I see it's more of a dictatorship. :-)
It is more a DOocracy that a dictatorship.
I see, DO it my way or go elsewhere.
My final comments:
openSUSE a.k.a. SuSE used to be one of the most stable distros available. Of late many apps have been forced on the users that were *clearly* pre-alpha. I don't remember the releases but the first major fuckup was zypper (or it's backend) that clearly was forced out before it was ready. The next I recall was KDE4 that was clearly pre-alpha when made the default install version. And now systemd has been forced on the masses even though it is not production ready. And this is the point, many sys admins use openSUSE on production servers. Why? Because in the past it was *that* stable. Nowadays not so much. Who in their right mind can risk running a server without boot logs for trouble shooting. Yes, logging has been added but that's not the point. And now if the /binary/ logs become corrupt there is no way to recover them.
It's time for openSUSE to become a leader again instead of doing things just because Fedora does it.
Just my .02¢
On Tue, Apr 30, 2013 at 11:57 PM, Ken Schneider - openSUSE suse-list3@bout-tyme.net wrote:
On 04/30/2013 10:33 PM, Cristian Rodríguez pecked at the keyboard and wrote:
El 30/04/13 22:11, Ken Schneider - openSUSE escribió:
And here I thought this was a community distro, but I see it's more of a dictatorship. :-)
It is more a DOocracy that a dictatorship.
I see, DO it my way or go elsewhere.
My final comments:
openSUSE a.k.a. SuSE used to be one of the most stable distros available. Of late many apps have been forced on the users that were *clearly* pre-alpha. I don't remember the releases but the first major fuckup was zypper (or it's backend) that clearly was forced out before it was ready. The next I recall was KDE4 that was clearly pre-alpha when made the default install version. And now systemd has been forced on the masses even though it is not production ready. And this is the point, many sys admins use openSUSE on production servers. Why? Because in the past it was *that* stable. Nowadays not so much. Who in their right mind can risk running a server without boot logs for trouble shooting. Yes, logging has been added but that's not the point. And now if the /binary/ logs become corrupt there is no way to recover them.
It's time for openSUSE to become a leader again instead of doing things just because Fedora does it.
*That* is what I've always objected to binary log formats. They're fragile.
Systemd's implementation is fragile too. Mapping files into memory gives you zero ordering guarantees and zero capability to maintain consistency in the event of a system crash. And I mean crash, not even power outage. Mapping doesn't work for logging. It should be undone.
Maybe it's only the runtime log the one mapped, but still that's fragile. Because it's always the last log entries the ones I'm interested in, so there's no point in delaying log flushes, or pretending the "runtime" log can be less persistent than the "final" log.
It's quite clear systemd's authors don't get logging at all. Logging can't be fragile.
El 01/05/13 00:41, Claudio Freire escribió:
*That* is what I've always objected to binary log formats. They're fragile.
is mysql/postgresql/sqlite/oracledb fragile ?
Mapping files into memory
gives you zero ordering guarantees and zero capability to maintain consistency in the event of a system crash.
Syslog also has a buffer, if you system crashes, that's it, you are done.
Mapping doesn't work for logging. It should be undone.
Good luck with that, you will have to provide convincing technical arguments + evidence that is wrong and/or code in the process, otherwise no one will listen.
It's quite clear systemd's authors don't get logging at all. Logging can't be fragile.
It is quite clear that you don't get how the system actually works and you are mounting an straw-man argument, comparing the journal to an imaginary logging system that has never existed.
El 01/05/13 00:41, Claudio Freire escribió:
And I mean crash, not even power outage.
The journal TODO list includes :
-import and delete pstore filesystem content at startup
That means, in systems that have the adequate firmware, the journal will import the "last messages" your system produced before rebooting due to crash, straight from the dead..spooky :-)
On Wed, May 1, 2013 at 2:06 AM, Cristian Rodríguez crrodriguez@opensuse.org wrote:
El 01/05/13 00:41, Claudio Freire escribió:
And I mean crash, not even
power outage.
The journal TODO list includes :
-import and delete pstore filesystem content at startup
That means, in systems that have the adequate firmware, the journal will import the "last messages" your system produced before rebooting due to crash, straight from the dead..spooky :-)
No, storage systems don't work like that when you're mapping.
Don't think I don't understand how the system works, because I've read the source. I've written patches for postgres (not upstreamed yet), so I kinda know a little bit about this stuff. Let me tell you.
When you mmap files, you tell the kernel's page cache to do all I/O for you. That's fast, because you've got a zero-copy environment like that. But it's also quite out of your control how writes happen in the end. When you write to a mapped memory location, you make that page dirty. The kernel will flush it whenever it thinks it's necessary, in no particular order.
Pages you dirtied 30 minutes ago can still be unwritten when a page that has been written 1 second ago is flushed, because somehow the kernel thinks that old page is hot and so won't flush it unless it's told to. You tell it to with msync. Systemd just started using msync for this very reason.
But msync flushes everything. And, again, in no particular order. If there's a crash, or a power outage, you don't know which pages have been written and which haven't. Postgres and most reasonably reliable databases you mention will have a WAL to make sure pages are written in the right order, and no torn pages appear. The WAL is a file opened in sync I/O mode. It's slow, but safe. And it's not too slow since it's append-only, which lets the operating system optimize sync I/O quite a bit.
In append-only mode, you can have only one torn page: the last one. So WAL entries are checksummed, and when WAL is replayed, you know everything up to the first bad checksum is OK. You cannot do that with memory mapped I/O, you have no way to force a specific write order.
So you're left with a system that will work most of the time, when the thing crashing isn't the I/O. But if somehow I/O is interrupted (say a bad interface, a kernel crash, a power outage), the binary format will be messed with little hope of repair. Torn pages will have old info interspersed with new info. Not all dirty pages will have been written, and you have no way to know. If you implemented some kind of page time-stamping, you'd have to be careful to match page size to sector size, and assuming you get that right, you'd loose a lot more info than you would if you hadn't mapped, because you'll have to discard all valid pages after the first corrupted stamp.
So, memory mapped I/O is wrong if you need reliability. It's great read-only, but that's about it.
On Wednesday 2013-05-01 20:52, Claudio Freire wrote:
That means, in systems that have the adequate firmware, the journal will import the "last messages" your system produced before rebooting due to crash, straight from the dead..spooky :-)
Don't think I don't understand how the system works, because I've read the source. I've written patches for postgres (not upstreamed yet), so I kinda know a little bit about this stuff. Let me tell you.
When you mmap files,[...] it's also quite out of your control how writes happen in the end.[...] Pages you dirtied 30 minutes ago can still be unwritten[...] You tell it [the kernel] to [flush] with msync. [...] But msync flushes everything. And, again, in no particular order. If there's a crash, or a power outage, you don't know which pages have been written and which haven't. Postgres and most reasonably reliable databases you mention will have a WAL to make sure pages are written in the right order, and no torn pages appear. The WAL is a file opened in sync I/O mode. It's slow, but safe.[...] with memory mapped I/O, you have no way to force a specific write order.
You can have order with mmap. In fact, OpenLDAP developer Howard Chu presented the inner workings of a new MDB backend last year at LinuxCon Europe. mdb is all about mmap and uses COW with 2 snapshots {current,previous} at any time,[1,2] ensuring reliability whilst keeping speed.
[1] www.openldap.org/pub/hyc/mdm-paper.pdf [2] www.openldap.org/pub/hyc/mdm-slides.pdf
On Thu, 2 May 2013 06:26, Jan Engelhardt <jengelh@...> wrote:
On Wednesday 2013-05-01 20:52, Claudio Freire wrote:
[snip]
particular order. If there's a crash, or a power outage, you don't know which pages have been written and which haven't. Postgres and most reasonably reliable databases you mention will have a WAL to make sure pages are written in the right order, and no torn pages appear. The WAL is a file opened in sync I/O mode. It's slow, but safe.[...] with memory mapped I/O, you have no way to force a specific write order.
You can have order with mmap. In fact, OpenLDAP developer Howard Chu presented the inner workings of a new MDB backend last year at LinuxCon Europe. mdb is all about mmap and uses COW with 2 snapshots {current,previous} at any time,[1,2] ensuring reliability whilst keeping speed.
[1] www.openldap.org/pub/hyc/mdm-paper.pdf [2] www.openldap.org/pub/hyc/mdm-slides.pdf
Thanks for the links, but keep one thing in mind:
In LDAP there are much more reads than writes.
Syslogs are mostly writes ans little reads. That, coupled with the need of reliable crash recovery, makes mmap and consorts much less suited for the use in logging esp. Syslog.
Personally I deem the binary format of systemd-journal for one of the biggest dips in the toilet since the start of Unix, even json would be a big improvement.
Maybe the package systemd-logger should not made available until the jounal has gotten a complete overhaul.
Looking at the code, there are big ideas, but then the ball was dropped, fast and deep.
mmap makes sense for readonly (e.g. libs), or read mostly (e.g. webserver, ldap), with a msync after a write, but for a log? - Just no.
And the binary format does not help any, checksums can be added to text formats, and what sense does the added cryptography make?
Someone has taken hot fecal matter and used a rotating device to distribute.
Back to the subject: "What is the purpose of the systemd journal service?"
Answer: Forwarder for external or on-system real syslog service.
- Yamaban, who bemoans the lost ours for looking at the code.
On Thu, May 2, 2013 at 2:03 AM, Yamaban foerster@lisas.de wrote:
On Thu, 2 May 2013 06:26, Jan Engelhardt <jengelh@...> wrote:
On Wednesday 2013-05-01 20:52, Claudio Freire wrote:
[snip]
particular order. If there's a crash, or a power outage, you don't know which pages have been written and which haven't. Postgres and most reasonably reliable databases you mention will have a WAL to make sure pages are written in the right order, and no torn pages appear. The WAL is a file opened in sync I/O mode. It's slow, but safe.[...] with memory mapped I/O, you have no way to force a specific write order.
You can have order with mmap. In fact, OpenLDAP developer Howard Chu presented the inner workings of a new MDB backend last year at LinuxCon Europe. mdb is all about mmap and uses COW with 2 snapshots {current,previous} at any time,[1,2] ensuring reliability whilst keeping speed.
[1] www.openldap.org/pub/hyc/mdm-paper.pdf [2] www.openldap.org/pub/hyc/mdm-slides.pdf
Thanks for the links, but keep one thing in mind:
In LDAP there are much more reads than writes.
Syslogs are mostly writes ans little reads. That, coupled with the need of reliable crash recovery, makes mmap and consorts much less suited for the use in logging esp. Syslog.
Not only that. msync only flushes to the file system, but there is no guarantee it will reach the disc. Ie: it flushes dirty pages, but doesn't execute a write barrier. If you map an O_DIRECT file descriptor with msync, the performance is abysmal under heavy writes. Or was last time I tried.
So, LDAP's technique doesn't scale for write-heavy workloads. I will certainly read the papers though...
Hello,
Am Dienstag, 30. April 2013 schrieb Ken Schneider - openSUSE:
openSUSE a.k.a. SuSE used to be one of the most stable distros available. Of late many apps have been forced on the users that were *clearly* pre-alpha. I don't remember the releases but the first major fuckup was zypper (or it's backend) that clearly was forced out before it was ready.
Now you are bashing the wrong target ;-)
You forgot ZENworks / ZMD which was pushed into SUSE Linux[1] 10.1. _That_ was pre-alpha, which resulted in 10.1 being the only release with 9 (!) betas and even a "10.1 Remastered" release.
IMHO even /bin/true was more useful than ZMD ;-) which also means zypper was a big improvement. I agree that the first zypper versions were far from perfect, but they were much better than ZMD (and therefore an improvement).
I commiserate with the poor soul that still has to maintain ZMD for the SLE10 [2] customers...
Regards,
Christian Boltz
[1] yes, 10.1 was still called "SUSE Linux"
[2] assuming it wasn't replaced by zypper with one of the service packs (I don't know much about SLE)
PS: non-random signature ;-)
On 05/01/2013 01:42 PM, Christian Boltz pecked at the keyboard and wrote:
Hello,
Am Dienstag, 30. April 2013 schrieb Ken Schneider - openSUSE:
openSUSE a.k.a. SuSE used to be one of the most stable distros available. Of late many apps have been forced on the users that were *clearly* pre-alpha. I don't remember the releases but the first major fuckup was zypper (or it's backend) that clearly was forced out before it was ready.
Now you are bashing the wrong target ;-)
You forgot ZENworks / ZMD which was pushed into SUSE Linux[1] 10.1. _That_ was pre-alpha, which resulted in 10.1 being the only release with 9 (!) betas and even a "10.1 Remastered" release.
Yes, my memory is not so good lately. :-) I was trying to think of the bastard CLI update program that was forced into the distro by Novell and needed numerous updates itself in the first few weeks of release.
IMHO even /bin/true was more useful than ZMD ;-) which also means zypper was a big improvement. I agree that the first zypper versions were far from perfect, but they were much better than ZMD (and therefore an improvement).
I agree after having been reminded of ZMD.
I commiserate with the poor soul that still has to maintain ZMD for the SLE10 [2] customers...
On 01/05/13 04:57, Ken Schneider - openSUSE wrote:
fuckup was zypper (or it's backend) that clearly was forced out before
The screw up was libzypp 1.x + ZENWorks (both _together_).
Please use the names right, otherwise you will create another stupid myth around the distribution (like: YaST overwrites your config files)
ZENWorks was forced in because of business reasons from the main stakeholder: at that time that were the only reasons because SUSE was the only contributor.
* Cristian Rodríguez crrodriguez@opensuse.org [2013-05-01 04:33]:
El 30/04/13 22:11, Ken Schneider - openSUSE escribió:
And here I thought this was a community distro, but I see it's more of a dictatorship. :-)
It is more a DOocracy that a dictatorship.
Then how about you fix my packages the next time systemd breaks them? Because right now its a few people who make decisions and impose a whole lot more unnecessary (since there is no practical gain) work on others.
On 05/01/2013 03:05 AM, Guido Berhoerster wrote:
- Cristian Rodríguez crrodriguez@opensuse.org [2013-05-01 04:33]:
El 30/04/13 22:11, Ken Schneider - openSUSE escribió:
And here I thought this was a community distro, but I see it's more of a dictatorship. :-)
It is more a DOocracy that a dictatorship.
Then how about you fix my packages the next time systemd breaks them?
If you do not want to maintain packages that keep running correctly with the underlying system changes then you should find another person to take care of them or file a drop request.
Before "systemd breaks them" (not sure what that means, as the unit format and documented/expected behaviour has not changed) they will first break when autotools,compiler, or whatever library they depend changes.
Am 01.05.2013 09:54, schrieb Cristian Rodríguez:
If you do not want to maintain packages that keep running correctly with the underlying system changes then you should find another person to take care of them or file a drop request.
Ok, I'll consider that next time.
Before "systemd breaks them" (not sure what that means, as the unit format and documented/expected behaviour has not changed)
Oh, for example the whole "systemd's friends now take care of power management" which was a subtle change in default that obscurely broke running sytems.
they will first break when autotools,compiler, or whatever library they depend changes.
That's easy breakage: compile failures are easy to fix. They don't silently break a previously running system.
Cristian Rodríguez wrote:
Objecting does not mean anything, those who do the work are the ones that take decisions.
----
So if I am willing to revert the latest changes to push to systemd, that's all that is required to have it happen?
Yeah. Right.
Those who do the work are those who are ***allowed*** to do the work.
Second point -- those who do the work are the ones that take decisions -- so in other words, they don't have to consider anyone else nor be concerned about who's work they break?
Are you going sit back and let someone do the work of reverting all the damage -- no, you'd complain that they broke your new stuff. Well, in you doing your work, you are breaking things that used to work for the rest of us.
If those who do the work break things that work for other people -- they can't just say "not supported". Under those rules, there is no reason why anyone can't "do the work" of reverting the new, incompatible and alpha-level features.
Am 01.05.2013 03:04, schrieb Joachim Schrod:
Lars Marowsky-Bree wrote:
On 2013-04-30T11:38:19, Ruediger Meier sweet_f_a@gmx.de wrote:
That's why it is called --verify and not --repair .. (not implemented yet, never advertised as repair either)
How can such untested alpha quality stuff make it into a distro?
Because the community didn't object when it was merged, or during the beta phase.
Oh, many of us objected, but were ignored. In fact, look at Christian's reaction to Stefan's bug report -- no comment needed, denial at its best.
Even though I don't agree with Cristian completely regarding systemd and journal, I have to defend him here: * he does care for bug reports. * he does fix stuff.
My gripes are more with systemd upstream and the mindset there (and of course it is a good question to blindly follow an upstream, no matter how stupid it might be, but that is a different question).
About "those who are doing the work decide": the problem is, that now the ones trying to keep sysvinit alive are actively combatted by the systemd proponents by removing all the init scripts so that they have to fork the whole distribution and not just maintain a single package.
On Wed, May 01, 2013 at 10:57:48AM +0200, Stefan Seyfried wrote:
About "those who are doing the work decide": the problem is, that now the ones trying to keep sysvinit alive are actively combatted by the systemd proponents by removing all the init scripts so that they have to fork the whole distribution and not just maintain a single package.
Well, after spending some time on making 12.3 work again, I must say that removing the init scripts isn't the real problem. Neither is dropping whole packages, one can just recover the last (or sufficiently recent) working version. The real problem are silent changes removing or breaking functionality not necessary for systemd-only systems, often undocumented or poorly documented. Finding out which particular change broke something can be quite a challenge.
But above all, the "do-ocracy" theory is just a big lie. People wanting working sysvinit didn't have to _do_ anything: it was there and it worked so there was nothing to _do_ for it, just keep it working. And even if we wanted to keeping it working, we weren't allowed because from the very beginning there was a premise that keeping two boot systems is a waste of effort and that systemd is the only one worth having. Period, end of discussion, before it even started. Well, there was a lot of discussion but arguments of people thinking otherwise were never given serious chance. The people with power to decide were already determined to get rid of sysvinit, the only question really considered was how long will it take. And this has nothing to do with "do-ocracy".
Michal Kubeček
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday, 2013-05-02 at 10:35 +0200, Michal Kubecek wrote:
But above all, the "do-ocracy" theory is just a big lie. People wanting working sysvinit didn't have to _do_ anything: it was there and it worked so there was nothing to _do_ for it, just keep it working. And even if we wanted to keeping it working, we weren't allowed because from the very beginning there was a premise that keeping two boot systems is a waste of effort and that systemd is the only one worth having. Period, end of discussion, before it even started. Well, there was a lot of discussion but arguments of people thinking otherwise were never given serious chance. The people with power to decide were already determined to get rid of sysvinit, the only question really considered was how long will it take. And this has nothing to do with "do-ocracy".
+1
- -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar)
On Thu, May 2, 2013 at 5:35 AM, Michal Kubecek mkubecek@suse.cz wrote:
But above all, the "do-ocracy" theory is just a big lie. People wanting working sysvinit didn't have to _do_ anything: it was there and it worked so there was nothing to _do_ for it, just keep it working. And even if we wanted to keeping it working, we weren't allowed because from the very beginning there was a premise that keeping two boot systems is a waste of effort and that systemd is the only one worth having. Period, end of discussion, before it even started. Well, there was a lot of discussion but arguments of people thinking otherwise were never given serious chance. The people with power to decide were already determined to get rid of sysvinit, the only question really considered was how long will it take. And this has nothing to do with "do-ocracy".
Well, TBH, keeping the two boot systems in place, interoperable and easily switchable *was* indeed gonna be a lot of effort. It's the same as maintaining multi-distro packages. I've done a couple of those, and the subtle differences between the distros makes it really difficult, especially deb-based ones which have none of RPM's magic. With sysvinit vs systemd was the same. There was no magic in place to make it easier, and packages that had to interact with either would and had become a lot harder to maintain just because they had to handle two very different init systems.
Stefan Seyfried wrote:
Am 01.05.2013 03:04, schrieb Joachim Schrod:
Oh, many of us objected, but were ignored. In fact, look at Christian's reaction to Stefan's bug report -- no comment needed, denial at its best.
Even though I don't agree with Cristian completely regarding systemd and journal, I have to defend him here:
- he does care for bug reports.
- he does fix stuff.
---- That hasn't been my experience.
Any bug or problem I've submitted and he'd commented on he's told me is my problem and it's no longer supported.
His attitude sucks for someone who is working inside Suse.
The whole attitude of developers like him is that distro's are there to support *them* -- and customers are on their own.
About "those who are doing the work decide": the problem is, that now the ones trying to keep sysvinit alive are actively combatted by the systemd proponents by removing all the init scripts so that they have to fork the whole distribution and not just maintain a single package.
---- Yup.... had to replace all of them -- went back to 11.3 sources on several -- including sysVinit. The deliberate laying of traps and working to destroy compatibility are acts of deliberate malice.
On Sat, May 04, 2013 at 07:03:01AM -0700, Linda Walsh wrote:
Stefan Seyfried wrote:
Am 01.05.2013 03:04, schrieb Joachim Schrod:
Oh, many of us objected, but were ignored. In fact, look at Christian's reaction to Stefan's bug report -- no comment needed, denial at its best.
Even though I don't agree with Cristian completely regarding systemd and journal, I have to defend him here:
- he does care for bug reports.
- he does fix stuff.
That hasn't been my experience.
Any bug or problem I've submitted and he'd commented on he's told me is my problem and it's no longer supported.
His attitude sucks for someone who is working inside Suse.
Cristian is a community member, not a SUSE employee. Just to get this straight.
The whole attitude of developers like him is that distro's are there to support *them* -- and customers are on their own.
Well, see above.
Ciao, Marcus
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday, 2013-04-30 at 12:21 +0200, Lars Marowsky-Bree wrote:
On 2013-04-30T11:38:19, Ruediger Meier <> wrote:
That's why it is called --verify and not --repair .. (not implemented yet, never advertised as repair either)
How can such untested alpha quality stuff make it into a distro?
Because the community didn't object when it was merged, or during the beta phase.
What? :-O
Community objections are routinely ignored. There is no point in objecting :-/
- -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar)
Carlos E. R. wrote:
On Tuesday, 2013-04-30 at 12:21 +0200, Lars Marowsky-Bree wrote:
On 2013-04-30T11:38:19, Ruediger Meier <> wrote:
That's why it is called --verify and not --repair .. (not implemented yet, never advertised as repair either)
How can such untested alpha quality stuff make it into a distro?
Because the community didn't object when it was merged, or during the beta phase.
What? :-O
Community objections are routinely ignored. There is no point in objecting :-/
+1
Lars Marowsky-Bree wrote:
On 2013-04-30T11:38:19, Ruediger Meier sweet_f_a@gmx.de wrote:
That's why it is called --verify and not --repair .. (not implemented yet, never advertised as repair either)
How can such untested alpha quality stuff make it into a distro?
Because the community didn't object when it was merged, or during the beta phase.
====
Many members of the community objected and were put in the developer's kill lists.
Objecting is the quickest way to get ignored and be told that anything bad that happens on your system is your own fault for touching your system.
If people would stop touching their systems and expecting to use them for their own purposes, they wouldn't have any problems with the way they no longer function. ;-|
On Tue, 30 Apr 2013 11:38, Ruediger Meier <sweet_f_a@...> wrote:
On Tuesday 30 April 2013, Cristian Rodríguez wrote:
On 04/30/2013 02:46 AM, Stefan Seyfried wrote:
[snip]
- if the database is broken, i tells you (journalctl --verify)
- but it can not repair or recover it
That's why it is called --verify and not --repair .. (not implemented yet, never advertised as repair either)
How can such untested alpha quality stuff make it into a distro?
Done daily by really big companies: Microsoft, Oracle, ... , the smaller companies take that as example.
And: OSS and Fedora ARE the playgrounds for the Pro-versions: SLE + RHEL
Yes that hurts, but OTOH there's a big cry for the latest features, examples that I'll give you:
- Btrfs - without fs-repair tools for a long time, nice, ne? - systemd in OSS 12.1 + 12.2 was half done at best, 12.3 80-90% done - pulse-audio (did it work anywhere without troubles, yet?)
No, as diving the cry for the latest-greatest is, it also hinders in debugging the existing problems, as a day has only 24 hours, for everybody.
We made our bed, now we have to lay in it.
Back to the Subject: +1 for strong recommend of extra syslog service (syslog-ng / rsyslog). +1 no no recommend, and/or suggest of "systemd-logger" in any package +1 for an added warning in "systemd-logger" Description: "Not ready for use, testing only, logs may disappear with no warning."
- Yamaban.
PS: @Ruediger: did you test? If no, you did not help to find the bugs. Stefan did so, but did not have enough warning to keep another logging service running. And yes, the docu is ambiguous and unclear.
Am 30.04.2013 12:24, schrieb Yamaban:
PS: @Ruediger: did you test? If no, you did not help to find the bugs. Stefan did so, but did not have enough warning to keep another logging service running. And yes, the docu is ambiguous and unclear.
Actually I have, but unfortunately syslog-ng is also buggy since some weeks and stops logging after some period of time :-( https://bugzilla.novell.com/815746
On 04/30/2013 01:00 PM, Stefan Seyfried wrote:
Am 30.04.2013 12:24, schrieb Yamaban:
PS: @Ruediger: did you test? If no, you did not help to find the bugs. Stefan did so, but did not have enough warning to keep another logging service running. And yes, the docu is ambiguous and unclear.
Actually I have, but unfortunately syslog-ng is also buggy since some weeks and stops logging after some period of time :-( https://bugzilla.novell.com/815746
The strange thing is, that we could not reproduce it in house. I was running 3.4 on my machines for weeks without problems before committing it to Factory. One of the core syslog-ng developers is checking the problem in a VM, and I'm also running syslog-ng on my openSUSE desktop all the time and never ran into this problem. We need to be able to reproduce it to fix it... Bye, CzP
El 30/04/13 08:24, Peter Czanik escribió:
The strange thing is, that we could not reproduce it in house.
I also tried to reproduce the problem with no luck, maybe there is something very specific to Stefan's environment/hardware that could possible trigger this issue ? it could also be a bug in glib..
Am 01.05.2013 05:06, schrieb Cristian Rodríguez:
El 30/04/13 08:24, Peter Czanik escribió:
The strange thing is, that we could not reproduce it in house.
I also tried to reproduce the problem with no luck, maybe there is something very specific to Stefan's environment/hardware that could possible trigger this issue ? it could also be a bug in glib..
I'm trying to find out :-) It looks like some subtle race condition which are hard to find / reproduce. I hope the helgrind traces in https://bugzilla.novell.com/815746 might be helpful.
If anyone has ideas on how to debug this or for more helpful helgrind options -- I'm all for it.
Stefan Seyfried wrote:
Am 30.04.2013 12:24, schrieb Yamaban:
PS: @Ruediger: did you test? If no, you did not help to find the bugs. Stefan did so, but did not have enough warning to keep another logging service running. And yes, the docu is ambiguous and unclear.
Actually I have, but unfortunately syslog-ng is also buggy since some weeks and stops logging after some period of time :-( https://bugzilla.novell.com/815746
not version 2.0.9.
I put it in place and made it immutable. It never crashes.
Yeah.. its old, but it works.
Seems to be a good idea to keep around a backup 'root' or two and copy in the working binaries after installing recent updates...
One finds that recent updates install dummy scripts for working binaries. Good to have working binaries.
For those that think systemd = linux, it's not. systemd=windows -- it's a corporate shove down your throat. Gnu-linux has been about there being more than one way to do things. That's an *open* system. Closed ones are where choice is dictated and removed.
On Tuesday 30 April 2013, Yamaban wrote:
On Tue, 30 Apr 2013 11:38, Ruediger Meier <sweet_f_a@...> wrote:
On Tuesday 30 April 2013, Cristian Rodríguez wrote:
On 04/30/2013 02:46 AM, Stefan Seyfried wrote:
[snip]
- if the database is broken, i tells you (journalctl --verify)
- but it can not repair or recover it
That's why it is called --verify and not --repair .. (not implemented yet, never advertised as repair either)
How can such untested alpha quality stuff make it into a distro?
Done daily by really big companies: Microsoft, Oracle, ... , the smaller companies take that as example.
And: OSS and Fedora ARE the playgrounds for the Pro-versions: SLE + RHEL
Yes that hurts, but OTOH there's a big cry for the latest features, examples that I'll give you:
- Btrfs - without fs-repair tools for a long time, nice, ne?
- systemd in OSS 12.1 + 12.2 was half done at best, 12.3 80-90% done
- pulse-audio (did it work anywhere without troubles, yet?)
No, as diving the cry for the latest-greatest is, it also hinders in debugging the existing problems, as a day has only 24 hours, for everybody.
We made our bed, now we have to lay in it.
Back to the Subject: +1 for strong recommend of extra syslog service (syslog-ng / rsyslog). +1 no no recommend, and/or suggest of "systemd-logger" in any package +1 for an added warning in "systemd-logger" Description: "Not ready for use, testing only, logs may disappear with no warning."
- Yamaban.
PS: @Ruediger: did you test? If no, you did not help to find the bugs. Stefan did so, but did not have enough warning to keep another logging service running. And yes, the docu is ambiguous and unclear.
No, I'm a user and don't want to see or fix alpha bugs, specially if they affect things which worked without any problem since always ...
I had run some quick tests of openSUSE 12.1, 12.2, 12.3 which where enough for me to see that they are unusable. I still run 11.4 on all production machines. One of my experimental machines (desktop at home) is 12.2 with sysvinit.
cu, Rudi
I would second the general complaint about software quality, having just 'upgraded' to 12.3, the latest KDE is also a mess especially KMail 2 which is another alpha quality disaster!
There is a patten emerging here, especially in German based projects, of Grand Ideas, that do nothing to meet user need, break existing functionality, and are stoutly defended by evangelists and UI designers.
It may look pretty, but just under the skin it is barely alpha quality crap!
Cheers, omb
Am Tue, 30 Apr 2013 11:38:19 +0200, scheib Ruediger Meier:
On Tuesday 30 April 2013, Cristian Rodríguez wrote:
On 04/30/2013 02:46 AM, Stefan Seyfried wrote:
I give a sh*t on that design document, as long as I can not read my logs, it is the end of the month and they would be very useful to do my accounting.
Fun facts about sytemd-journal:
- it logs to a binary database
Yes.
- it can not filter out the user session logs from the system logs
Something can be done about that..I thought it was able to so
- if the database is broken, i tells you (journalctl --verify)
- but it can not repair or recover it
That's why it is called --verify and not --repair .. (not implemented yet, never advertised as repair either)
How can such untested alpha quality stuff make it into a distro?
cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Apr 30, 2013 at 11:38:19AM +0200, Ruediger Meier wrote:
On Tuesday 30 April 2013, Cristian Rodríguez wrote:
On 04/30/2013 02:46 AM, Stefan Seyfried wrote:
I give a sh*t on that design document, as long as I can not read my logs, it is the end of the month and they would be very useful to do my accounting.
Fun facts about sytemd-journal:
- it logs to a binary database
Yes.
- it can not filter out the user session logs from the system logs
Something can be done about that..I thought it was able to so
- if the database is broken, i tells you (journalctl --verify)
- but it can not repair or recover it
That's why it is called --verify and not --repair .. (not implemented yet, never advertised as repair either)
How can such untested alpha quality stuff make it into a distro?
Fun thing is of course as the "corrupted" journal is cryptographically ensured, it is better not to look at if it is corrupted ;)
Ciao, Marcus
Am 30.04.2013 13:18, schrieb Marcus Meissner:
Fun thing is of course as the "corrupted" journal is cryptographically ensured, it is better not to look at if it is corrupted ;)
My journal files here are not technically corrupt (I removed the ones that failed --verify), but it still can not be read as it puts journalctl in an endless loop.
El 30/04/13 05:38, Ruediger Meier escribió:
How can such untested alpha quality stuff make it into a distro?
is btrfs alpha too ? it also does not have fsck.
On Tuesday 2013-04-30 18:33, Cristian Rodríguez wrote:
El 30/04/13 05:38, Ruediger Meier escribió:
How can such untested alpha quality stuff make it into a distro?
is btrfs alpha too ? it also does not have fsck.
btrfs scrub
On Tuesday 30 April 2013, Cristian Rodríguez wrote:
El 30/04/13 05:38, Ruediger Meier escribió:
How can such untested alpha quality stuff make it into a distro?
is btrfs alpha too ? it also does not have fsck.
Don't know. Last time I've tested it wasn't stable and IMO it still shouldn't be the default. But anyway at least users have the choice to use any other FS.
cu, Rudi
El 30/04/13 13:14, Ruediger Meier escribió:
On Tuesday 30 April 2013, Cristian Rodríguez wrote:
El 30/04/13 05:38, Ruediger Meier escribió:
How can such untested alpha quality stuff make it into a distro?
is btrfs alpha too ? it also does not have fsck.
Don't know. Last time I've tested it wasn't stable and IMO it still shouldn't be the default.
in this world, nothing will be ever stable and production ready if it is not widely tested and used as a default. ever.
Software does not magically becomes stable out of thin air.
On 04/30/2013 09:49 PM, Cristian Rodríguez pecked at the keyboard and wrote:
El 30/04/13 13:14, Ruediger Meier escribió:
On Tuesday 30 April 2013, Cristian Rodríguez wrote:
El 30/04/13 05:38, Ruediger Meier escribió:
How can such untested alpha quality stuff make it into a distro?
is btrfs alpha too ? it also does not have fsck.
Don't know. Last time I've tested it wasn't stable and IMO it still shouldn't be the default.
in this world, nothing will be ever stable and production ready if it is not widely tested and used as a default. ever.
Software does not magically becomes stable out of thin air.
And depending on the dev doing the work it will _never_ be stable. Or they have their head so far up there #$% that they can't be objective about the app they are developing.
On Wednesday 01 May 2013, Cristian Rodríguez wrote:
El 30/04/13 13:14, Ruediger Meier escribió:
On Tuesday 30 April 2013, Cristian Rodríguez wrote:
El 30/04/13 05:38, Ruediger Meier escribió:
How can such untested alpha quality stuff make it into a distro?
is btrfs alpha too ? it also does not have fsck.
Don't know. Last time I've tested it wasn't stable and IMO it still shouldn't be the default.
in this world, nothing will be ever stable and production ready if it is not widely tested and used as a default. ever.
Software does not magically becomes stable out of thin air.
You miss the point that btrfs seems to be pre-stable while systemd is obviously still alpha and it's integration into openSUSE is pre-aplha.
These alpha problems could be surely found and solved before giving it to the masses. But it would need to have some developers and packagers with sense for the interesting use cases in practice (beyond single user laptop) rather than only people who just "want to do the work".
cu, Rudi
On Wed, 1 May 2013 14:21:21 +0200 Ruediger Meier sweet_f_a@gmx.de wrote:
...
But it would need to have some developers and packagers with sense for the interesting use cases in practice (beyond single user laptop)
Better to say developer's laptop, as taking over power management showed that they are really self centric. They wanted to drop all the quirks collected trough time that allowed users to run Linux on hardware (HW) with buggy BIOS.
While in theory bug in BIOS is a problem that hardware provider should solve, in practice, that BIOS works fine in Windows and its vendor will do nothing to fix a problem. User that installs Linux and have a problem will just ditch new toy.
rather than only people who just "want to do the work".
I guess that early adopters, testers and bug reporters are also those that do the work, provided time to catch up with changes. If one pushes more that they can swallow whole idea of testing software falls apart.
It is as simple as a streetcar (tram).
If it stops all passengers will enter. If it slows down, those that can run and jump can enter. If it doesn't slow down only few athletes will be able to catch a moment and enter.
In other words, adjust your speed to ability of "passengers" you want, or you will have no income very soon.
As it is now: * systemd and relatives are requiring days of full time engagement to learn, which excludes all that can't take that much time. Learning at the slow pace is Sisyphus task, as by the time you learn something, there is more to learn and some to forget. * changes are at the level that backport to older openSUSE releases is not viable, which excludes from testing all that have reasons not to use the latest release. One of reasons is, probably, lack of time to port application settings and data every 8 months.
El 01/05/13 11:17, Rajko escribió:
They wanted to drop all the
quirks collected trough time that allowed users to run Linux on hardware (HW) with buggy BIOS.
Well, yeah . because guess what .. workarounds or fixes for buggy BIOS do not belong in userspace, they have to be fixed in the kernel. You are preaching to the wrong choir.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday, 2013-05-01 at 10:17 -0500, Rajko wrote:
On Wed, 1 May 2013 14:21:21 +0200 Ruediger Meier <> wrote:
...
But it would need to have some developers and packagers with sense for the interesting use cases in practice (beyond single user laptop)
Better to say developer's laptop, as taking over power management showed that they are really self centric. They wanted to drop all the quirks collected trough time that allowed users to run Linux on hardware (HW) with buggy BIOS.
While in theory bug in BIOS is a problem that hardware provider should solve, in practice, that BIOS works fine in Windows and its vendor will do nothing to fix a problem. User that installs Linux and have a problem will just ditch new toy.
Indeed.
rather than only people who just "want to do the work".
I guess that early adopters, testers and bug reporters are also those that do the work, provided time to catch up with changes. If one pushes more that they can swallow whole idea of testing software falls apart.
Absolutely!
In other words, adjust your speed to ability of "passengers" you want, or you will have no income very soon.
Right.
As it is now:
- systemd and relatives are requiring days of full time engagement to
learn, which excludes all that can't take that much time. Learning at the slow pace is Sisyphus task, as by the time you learn something, there is more to learn and some to forget.
Yep.
- changes are at the level that backport to older openSUSE releases is
not viable, which excludes from testing all that have reasons not to use the latest release. One of reasons is, probably, lack of time to port application settings and data every 8 months.
Absolutely.
- -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar)
From: Ruediger Meier sweet_f_a@gmx.de To: opensuse-factory@opensuse.org Subject: Re: [opensuse-factory] Re: What is the purpose of the systemd journal service? Date: Wed, 1 May 2013 14:21:21 +0200
On Wednesday 01 May 2013, Cristian Rodríguez wrote:
El 30/04/13 13:14, Ruediger Meier escribió:
On Tuesday 30 April 2013, Cristian Rodríguez wrote:
El 30/04/13 05:38, Ruediger Meier escribió:
How can such untested alpha quality stuff make it into a distro?
is btrfs alpha too ? it also does not have fsck.
Don't know. Last time I've tested it wasn't stable and IMO it still shouldn't be the default.
in this world, nothing will be ever stable and production ready if it is not widely tested and used as a default. ever.
Software does not magically becomes stable out of thin air.
You miss the point that btrfs seems to be pre-stable while systemd is obviously still alpha and it's integration into openSUSE is pre-aplha.
These alpha problems could be surely found and solved before giving it to the masses. But it would need to have some developers and packagers with sense for the interesting use cases in practice (beyond single user laptop) rather than only people who just "want to do the work".
-----Original Message-----
No, still missing points: Btrfs is still an option, one of the many fs available. systemd if forced upon on us, not having an alternative.
On Sat, May 4, 2013 at 8:07 AM, Hans Witvliet suse@a-domani.nl wrote:
On Wednesday 01 May 2013, Cristian Rodríguez wrote:
El 30/04/13 13:14, Ruediger Meier escribió:
On Tuesday 30 April 2013, Cristian Rodríguez wrote:
El 30/04/13 05:38, Ruediger Meier escribió:
How can such untested alpha quality stuff make it into a distro?
is btrfs alpha too ? it also does not have fsck.
Don't know. Last time I've tested it wasn't stable and IMO it still shouldn't be the default.
in this world, nothing will be ever stable and production ready if it is not widely tested and used as a default. ever.
Software does not magically becomes stable out of thin air.
You miss the point that btrfs seems to be pre-stable while systemd is obviously still alpha and it's integration into openSUSE is pre-aplha.
And all of you seem to miss a much more important point.
Filesystems are interchangeable, at least if I'm building a new system (and noone's gonna upgrade to btrfs, manually or automatically, since btrfs is new, and upgrades don't reformat your partitions).
Btrfs is optional, and lots of alternatives are present and usable inside the distribution. Journal is not. One can opt-out of btrfs. One can opt-in, in fact. Not so with journal. It's like trying to opt out of the kernel. Difference (big difference) is, the kernel works. Journal doesn't.
Sure, journal might work some day. But since it's not something that I can opt-in or out, it's that day the day when it should've been introduced into the distro, not today. Now maintainers and everybody is hard-pressed to fix the bugs, or leave for greener lizardless pastures.
Thankfully, I didn't have issues with Journal yet. But, I know better than to deploy any systemd-based openSuse on a server.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday, 2013-04-30 at 21:49 -0400, Cristian Rodríguez wrote:
El 30/04/13 13:14, Ruediger Meier escribió:
On Tuesday 30 April 2013, Cristian Rodríguez wrote:
El 30/04/13 05:38, Ruediger Meier escribió:
How can such untested alpha quality stuff make it into a distro?
is btrfs alpha too ? it also does not have fsck.
Don't know. Last time I've tested it wasn't stable and IMO it still shouldn't be the default.
in this world, nothing will be ever stable and production ready if it is not widely tested and used as a default. ever.
Software does not magically becomes stable out of thin air.
Not completely true :-)
There are businesses that certify complete reliability and fault free software. They charge an insane packet for it.
Supposedly free opensource software is better because there is a whole community of developers verifying the code. >:-P
- -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar)
Am 30.04.2013 18:33, schrieb Cristian Rodríguez:
El 30/04/13 05:38, Ruediger Meier escribió:
How can such untested alpha quality stuff make it into a distro?
is btrfs alpha too ? it also does not have fsck.
Yes, it is alpha. And it is a totally different thing as you can opt-out of btrfs.
El 30/04/13 15:24, Stefan Seyfried escribió:
Am 30.04.2013 18:33, schrieb Cristian Rodríguez:
El 30/04/13 05:38, Ruediger Meier escribió:
How can such untested alpha quality stuff make it into a distro?
is btrfs alpha too ? it also does not have fsck.
Yes, it is alpha. And it is a totally different thing as you can opt-out of btrfs.
If you do not want to use the journal, install a syslog implementation and set Storage=volatile (or "none", if you know what your doing and fully accept that systemctl will not output anything about the service logs, just its status)
Am 30.04.2013 21:44, schrieb Cristian Rodríguez:
El 30/04/13 15:24, Stefan Seyfried escribió:
Am 30.04.2013 18:33, schrieb Cristian Rodríguez:
El 30/04/13 05:38, Ruediger Meier escribió:
How can such untested alpha quality stuff make it into a distro?
is btrfs alpha too ? it also does not have fsck.
Yes, it is alpha. And it is a totally different thing as you can opt-out of btrfs.
If you do not want to use the journal, install a syslog implementation and set Storage=volatile (or "none", if you know what your doing and fully accept that systemctl will not output anything about the service logs, just its status)
Then I still have not opted-out of journald and systemd, which was Rudi's subject. :-)
El 01/05/13 04:47, Stefan Seyfried escribió:
Then I still have not opted-out of journald and systemd, which was Rudi's subject. :-)
You can 't opt out from the journal or systemd, both are required components in the same sense the kernel is required or a shell is required.
I instructed you how to disable the journal storage. I think that is enough.
If you do not want those components, take a look at few distributions that do not currently use systemd ,the list gets shorter and shorter everyday, because systemd has become the de-facto init system by now.currently the exceptions are debian and slackware (but they wont be for much long I think)
On Wed, May 1, 2013 at 4:31 PM, Cristian Rodríguez crrodriguez@opensuse.org wrote:
El 01/05/13 04:47, Stefan Seyfried escribió:
Then I still have not opted-out of journald and systemd, which was Rudi's subject. :-)
You can 't opt out from the journal or systemd, both are required components in the same sense the kernel is required or a shell is required.
I instructed you how to disable the journal storage. I think that is enough.
If you do not want those components, take a look at few distributions that do not currently use systemd ,the list gets shorter and shorter everyday, because systemd has become the de-facto init system by now.currently the exceptions are debian and slackware (but they wont be for much long I think)
I wonder if it would be possible or desirable to write storage plug-ins (or modules) for journal. I imagine one based on a sane DB engine might be useful.
El 01/05/13 15:50, Claudio Freire escribió:
I wonder if it would be possible or desirable to write storage plug-ins (or modules) for journal. I imagine one based on a sane DB engine might be useful.
There is no API for storage plugins, if you need the journal data to be stored somewhere else you will be able to consume it via a webservice that will be provided by systemd-journal-gatewayd or simply by using a syslog implementation that provides the storage backends.
On Wed, May 1, 2013 at 5:00 PM, Cristian Rodríguez crrodriguez@opensuse.org wrote:
El 01/05/13 15:50, Claudio Freire escribió:
I wonder if it would be possible or desirable to write storage plug-ins (or modules) for journal. I imagine one based on a sane DB engine might be useful.
There is no API for storage plugins, if you need the journal data to be stored somewhere else you will be able to consume it via a webservice that will be provided by systemd-journal-gatewayd or simply by using a syslog implementation that provides the storage backends.
But that wouldn't apply to journalctl
On Wednesday 01 May 2013, Cristian Rodríguez wrote:
El 01/05/13 04:47, Stefan Seyfried escribió:
Then I still have not opted-out of journald and systemd, which was Rudi's subject. :-)
You can 't opt out from the journal or systemd, both are required components in the same sense the kernel is required or a shell is required.
I instructed you how to disable the journal storage. I think that is enough.
If you do not want those components, take a look at few distributions that do not currently use systemd ,the list gets shorter and shorter everyday, because systemd has become the de-facto init system by now.currently the exceptions are debian and slackware (but they wont be for much long I think)
At least they seem to wait until systemd gets stable but this will not happen soon I think.
cu, Rudi
Le mercredi 01 mai 2013 à 15:31 -0400, Cristian Rodríguez a écrit :
El 01/05/13 04:47, Stefan Seyfried escribió:
Then I still have not opted-out of journald and systemd, which was Rudi's subject. :-)
You can 't opt out from the journal or systemd, both are required components in the same sense the kernel is required or a shell is required.
I instructed you how to disable the journal storage. I think that is enough.
Even better, starting with 12.3, we didn't enforce journal storage on disk by default, since it is now pulled by the "systemd-logger" package (to allow people to not install any syslog implementation) which is NOT installed by default.
In 12.2, /var/log/journal was created by default (enabling on disk journal persistence) and it is kept when upgrading (because we can't detect if user want to keep it or not). If you don't want it, just remove the directory.
Frederic Crozat fcrozat@suse.com writes:
Even better, starting with 12.3, we didn't enforce journal storage on disk by default, since it is now pulled by the "systemd-logger" package (to allow people to not install any syslog implementation) which is NOT installed by default.
In 12.2, /var/log/journal was created by default (enabling on disk journal persistence) and it is kept when upgrading (because we can't detect if user want to keep it or not). If you don't want it, just remove the directory.
Those things would have deserved proper documentation (since you do not point to documentation, I assume that it does not exist). At least, a release notes entry is required.
I just created https://bugzilla.novell.com/show_bug.cgi?id=819707 --feel free to work on it :)
Le mardi 14 mai 2013 à 07:50 +0200, Karl Eichwalder a écrit :
Frederic Crozat fcrozat@suse.com writes:
Even better, starting with 12.3, we didn't enforce journal storage on disk by default, since it is now pulled by the "systemd-logger" package (to allow people to not install any syslog implementation) which is NOT installed by default.
In 12.2, /var/log/journal was created by default (enabling on disk journal persistence) and it is kept when upgrading (because we can't detect if user want to keep it or not). If you don't want it, just remove the directory.
Those things would have deserved proper documentation (since you do not point to documentation, I assume that it does not exist). At least, a release notes entry is required.
I just created https://bugzilla.novell.com/show_bug.cgi?id=819707 --feel free to work on it :)
Indeed, I'll try to draft some text there, feel free to improve it :)
Frederic Crozat wrote:
Le mercredi 01 mai 2013 à 15:31 -0400, Cristian Rodríguez a écrit :
El 01/05/13 04:47, Stefan Seyfried escribió:
Then I still have not opted-out of journald and systemd, which was Rudi's subject. :-)
You can 't opt out from the journal or systemd, both are required components in the same sense the kernel is required or a shell is required.
I instructed you how to disable the journal storage. I think that is enough.
Even better, starting with 12.3, we didn't enforce journal storage on disk by default, since it is now pulled by the "systemd-logger" package (to allow people to not install any syslog implementation) which is NOT installed by default.
I did notice this on my test-installs, thanks.
On Wednesday 19 September 2012, Claudio Freire wrote:
On Wed, Sep 19, 2012 at 7:26 AM, Ruediger Meier sweet_f_a@gmx.de
wrote:
Unfortunately you can do this only on machines where journalctl is installed/available. I assume that you can't read the journald logs on most existing systems.
Just a matter of building journalctl from source I'd imagine, as would be the case if you were missing grep.
grep is just one particular tool to read text files in a very special way. Compiling journalctl on arbitrary systems will be great fun I guess.
I happen to agree that the binary format is unnecessary, but it also happens to be a discretionary power of the author, and as soon as there's a working and ubiquitous "journalctl" to parse it... and its accompanying documentations... complaining will only start flame wars.
Still don't understand why this binary format should be used on production systems before these "ubiquitous" tools are existing.
cu, Rudi
El 19/09/12 12:59, Ruediger Meier escribió:
Still don't understand why this binary format should be used on production systems before these "ubiquitous" tools are existing.
No one has said it should be used, you still have syslog. however systemd requires the journal. it logs all its operations there.
you can simple remove /var/log/journal if you do not want persistent storage..systemd will still use the journal for runtime logging or internal operations in its own private /run/systemd/journal directory...
On Wed, Sep 19, 2012 at 12:59 PM, Ruediger Meier sweet_f_a@gmx.de wrote:
Just a matter of building journalctl from source I'd imagine, as would be the case if you were missing grep.
grep is just one particular tool to read text files in a very special way. Compiling journalctl on arbitrary systems will be great fun I guess.
I don't imagine journalctl's log parsing part to be anything other than fully portable. It's just a format parser.
Of course, there's lots of ways portability can go out the window. But those can be fixed as the need arises.
On 09/19/2012 11:53 AM, Per Jessen wrote:
Currently it is not a full replacement for syslog but I suggest you to check it out.
I tend to use ngsyslog for the filtering benefits. -- really has some powerful filtering in the 2.x line
Ditto - also much easier to configure than rsyslog.
As syslog-ng upstream, I can't agree more :-)
Journal: we consider it as a logging solution for stand alone desktops. You can read about it in a bit more details at http://czanik.blogs.balabit.com/2012/03/state-of-the-art-logging-syslog-ng-j...
And a bit of self promotion: if you are interested in logging and/or syslog-ng, be sure to come to the openSUSE conference in Prague, where I'll give a presentation Sunday, early in the afternoon: http://conference.opensuse.org/
Bye, Peter Czanik (CzP) BalaBit IT Security / syslog-ng upstream http://czanik.blogs.balabit.com/
El 19/09/12 06:29, Linda Walsh escribió:
I assume the full power of linux's text utilities can beused on them - like grep, sort, awk, perl... vim...
As long as you export them in either text, json, xml...
If I can't look at the whole stream as a text (messages, warnings, etc), I don't get a field for what is right or wrong behavior and certainly wouldn't be able to pick out an anomaly if I had to query each item separately -- that global view is a good way to look for 'warts'...
you can query items separately or view the whole log...
-
Andreas Jaeger -
Carlos E. R. -
Christian Boltz -
Claudio Freire -
Cristian Rodríguez -
Dominique Leuenberger a.k.a DimStar -
Duncan Mac-Vicar P. -
Frederic Crozat -
Guido Berhoerster -
Hans Witvliet -
Jan Engelhardt -
Joachim Schrod -
Karl Eichwalder -
Ken Schneider - openSUSE -
Lars Marowsky-Bree -
Linda Walsh -
Marcus Meissner -
Michal Kubecek -
Nelson Marques -
Per Jessen -
Peter Czanik -
Rajko -
root -
Ruediger Meier -
Stefan Seyfried -
Stephan Kulow -
Yamaban