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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Sep 19, 2012 at 7:26 AM, Ruediger Meier 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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Sep 19, 2012 at 12:49 PM, Cristian Rodríguez 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? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Sep 19, 2012 at 1:09 PM, Cristian Rodríguez 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... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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 :

* Cristian Rodríguez [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

-- --- Artigo 21 - Direito à Resistência Todos têm o direito de resistir a qualquer ordem que ofensa os seus direitos, liberdades e garantias e de repelir pela força qualquer agressão, quando não seja possível recorrer à autoridade pública. Constituição da Républica Portuguesa -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday 26 September 2012, Dominique Leuenberger a.k.a DimStar wrote:

Quoting Ruediger Meier :

...

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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday 26 September 2012, Dominique Leuenberger a.k.a DimStar wrote:

Quoting Ruediger Meier :

...

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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Nelson Marques [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. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Le mercredi 19 septembre 2012 à 23:44 +0100, Nelson Marques a écrit :

2012/9/19 Guido Berhoerster :

...

* Nelson Marques [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 SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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. -- Frederic Crozat SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Sep 20, 2012 at 2:40 PM, Cristian Rodríguez 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). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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

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: 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/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Claudio Freire wrote:

On Thu, Sep 20, 2012 at 4:51 PM, Peter Czanik 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). -- Per Jessen, Zürich (19.9°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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/ -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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 -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Rather side by side, so be sure to disable logging to /var/log/journal or it'll take twice the space.

Awesome; space isn't important :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Sep 19, 2012 at 12:49 PM, Cristian Rodríguez 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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Stefan Seyfried [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 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. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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

Am 30.04.2013 12:21, schrieb Lars Marowsky-Bree:

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.

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 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 -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod, Roedermark, Germany Email: jschrod@acm.org -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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 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; -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod, Roedermark, Germany Email: jschrod@acm.org -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, 30 Apr 2013 22:30:26 -0400 Cristian Rodríguez 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.) -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, 01 May 2013 11:10:32 +0200 Stefan Seyfried 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. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Rajko wrote:

On Wed, 01 May 2013 11:10:32 +0200 Stefan Seyfried 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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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. -- 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:57 PM, Ken Schneider - openSUSE 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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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 :-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, May 2, 2013 at 2:03 AM, Yamaban wrote:

On Thu, 2 May 2013 06:26, Jan Engelhardt 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... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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

-- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Cristian Rodríguez [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. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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

Am 01.05.2013 03:04, schrieb Joachim Schrod:

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.

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

-----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) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlGCK3MACgkQtTMYHG2NR9VmegCfZaGjQCU9XUWBU7/VyRUQZShg rPAAn13ftKhZ5+QvNkmG/uYFU1tPZ87B =KAl4 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----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) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlGBaFgACgkQtTMYHG2NR9WnzwCbBcEJ4HpJY57o185YwAA400fF 7fQAnAhhMw15kZKcQEwjr4VE4zdla/48 =Rdq2 -----END PGP SIGNATURE----- -- 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 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. ;-| -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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

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.. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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

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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

From: Ruediger Meier 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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----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) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlGBbF4ACgkQtTMYHG2NR9VH4wCaA8xPpJYZ/uFX/1ue51idAIm2 /+EAn0THqBpB1w6nBwa10A4jugCdgZ+f =lJHe -----END PGP SIGNATURE-----

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) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Frederic Crozat 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 :) -- Karl Eichwalder SUSE LINUX Products GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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. -- Per Jessen, Zürich (14.0°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org