Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[SOLVED] Migration to systemd: Flood from systemd-journald
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
lcj
Tux's lil' helper
Tux's lil' helper


Joined: 25 Apr 2004
Posts: 82
Location: Opole, Poland

PostPosted: Tue Dec 03, 2013 8:17 pm    Post subject: [SOLVED] Migration to systemd: Flood from systemd-journald Reply with quote

I'm using ~x86, latest updates form this week, latest kernel:

Using the Gentoo Wiki, I've migrated to systemd. OpenRC is still installed, I managed to recompile all with -consolekit systemd.

Configured kernel - prete much line-by-line what wiki says
Using lilo as boot manager I've added the init line, just as the wiki says.
Now after reboot, system boots but is on console immediately flooded with following message (the first might be slightly different I had to record hi-speed video of the console to get this):

Code:

[   OK    ] Started udev Kernel Device Manager
systemd-journald[1460]: /dev/kmsg buffer overrun, some messages lost
systemd-journald[1460]: /dev/kmsg buffer overrun, some messages lost
systemd-journald[1460]: /dev/kmsg buffer overrun, some messages lost
systemd-journald[1460]: /dev/kmsg buffer overrun, some messages lost
systemd-journald[1460]: /dev/kmsg buffer overrun, some messages lost


And this goes on with the flood...

After that there's not much happening - usually OpenRC started kde, but I don't get there after 5 minutes, I do have black screen just like right before nvidia module kicks in and activates the X.
I'm able to shut down safely with Power button or CTRL+ALT+DEL. Few times system stopped at the flood and I never got to console.

I did ask /etc/jorunald.conf NOT TO LOG anything to console nor syslog, uninstalled sysklod.

If I do not pass the systemd to kernel while booting - I'm getting running system with the exception of not being able to controll NetworkManager nor mount as user USB sticks... Of course systemd is not talking to dbus.
_________________
--
Lukasz C. Jokiel via web


Last edited by lcj on Thu Dec 05, 2013 5:36 pm; edited 1 time in total
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1480

PostPosted: Tue Dec 03, 2013 9:31 pm    Post subject: Reply with quote

You could add to your kernel cmdline (grub or lilo)
Code:
systemd.unit=multi-user.target blacklist=nvidia

or emergency.target and later on, when you solved some issues you add

systemd.unit=graphical.target
Don't forget to do before reboot enable kdm or gdm or lightdm
Code:
systemctl enable kdm.service
Back to top
View user's profile Send private message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Wed Dec 04, 2013 12:30 pm    Post subject: Reply with quote

Try increasing the kernel message log buffer length with the kernel parameter log_buf_len, for example: log_buf_len=262144
Back to top
View user's profile Send private message
lcj
Tux's lil' helper
Tux's lil' helper


Joined: 25 Apr 2004
Posts: 82
Location: Opole, Poland

PostPosted: Wed Dec 04, 2013 9:08 pm    Post subject: Reply with quote

Wow, the obvious thing of enabling kde helped, thanks ulenrich, my bad for not noticing that!

I see that NetworkManager is now talking to dbus, and I can controll it!
The VPN started to work too, bu it seems that passwords were not remembered in WiFi, but that's complety different thing.

TomWij - I still saw the messages...

I did recompile the kernel and changed the default 16=64k to 18...

system-journald is taking up to 95% of the CPU core, load is @ 1,53.
What I can see is that the cat /proc/kmsg shows repetetive power_supply BAT0: uevent

I'll investigate tomorrow and ask it to log something via syslog-ng and via the suggested lilo line, and remove the acpi debugs...

Big thanks - it's first time since 2004 that my problem was not already solved (using search) by the users of this forum.
_________________
--
Lukasz C. Jokiel via web


Last edited by lcj on Wed Dec 04, 2013 9:25 pm; edited 1 time in total
Back to top
View user's profile Send private message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Wed Dec 04, 2013 9:14 pm    Post subject: Reply with quote

lcj wrote:
What I can see is that the cat /proc/kmsg shows repetetive power_supply BAT0: uevent


Sounds like either some ACPI bug or a real problem with the power supply or battery. Best to investigate this. If you find no other way to fix the flooding, you can want to disable support for the ACPI Power Supply and/or the ACPI Battery (not ACPI itself) in the kernel.
Back to top
View user's profile Send private message
lcj
Tux's lil' helper
Tux's lil' helper


Joined: 25 Apr 2004
Posts: 82
Location: Opole, Poland

PostPosted: Wed Dec 04, 2013 9:27 pm    Post subject: Reply with quote

The battery just last month started to complain because it's around 3 years old, so Dell utility says after every boot: Battery may load normaly, but it's performance might be decreased over time.

So after removing the support from kernel: battery & AC power supply my kernel log is no longer overflooded. Thanks.
_________________
--
Lukasz C. Jokiel via web
Back to top
View user's profile Send private message
Barvinok
n00b
n00b


Joined: 29 Sep 2013
Posts: 34
Location: Ukraine

PostPosted: Fri Dec 06, 2013 1:26 pm    Post subject: Reply with quote

Having the same problem.
What if I need kernel support for the power supply and battery? How do I just stop journald flooding or redirect it elsewhere?
_________________
Unlike reality, stupidity is inescapable
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1480

PostPosted: Fri Dec 06, 2013 1:34 pm    Post subject: Reply with quote

Barvinok wrote:
Having the same problem.
What if I need kernel support for the power supply and battery? How do I just stop journald flooding or redirect it elsewhere?

If you know your hardware is rotten like @lcj it is hillarious to expect support from any software package. This thread solved.
Back to top
View user's profile Send private message
lcj
Tux's lil' helper
Tux's lil' helper


Joined: 25 Apr 2004
Posts: 82
Location: Opole, Poland

PostPosted: Fri Dec 06, 2013 1:35 pm    Post subject: Reply with quote

I can suggest:

#1 Try removing the battery and check the status
#2 Expand the kmsg log buffer in kernel beyond 256K
_________________
--
Lukasz C. Jokiel via web
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1480

PostPosted: Fri Dec 06, 2013 1:55 pm    Post subject: Reply with quote

lcj wrote:
#2 Expand the kmsg log buffer in kernel beyond 256K

@lcj, do you refer to:
Code:
$ zcat /proc/config.gz |grep -i log_buf
CONFIG_LOG_BUF_SHIFT=19
?
Back to top
View user's profile Send private message
lcj
Tux's lil' helper
Tux's lil' helper


Joined: 25 Apr 2004
Posts: 82
Location: Opole, Poland

PostPosted: Fri Dec 06, 2013 2:03 pm    Post subject: Reply with quote

Yes, I'm @
Code:
zcat /proc/config.gz |grep -i log_buf
CONFIG_LOG_BUF_SHIFT=18


so, there's still room to try.

Not trying to confuse, but with kernel 3.12.0-gentoo the flood seems to be *huge* while with previous (umh... 3.9.12 I guess) it was message every 5-6 minutes one from BAT followed by one from AC.
_________________
--
Lukasz C. Jokiel via web
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1480

PostPosted: Fri Dec 06, 2013 2:11 pm    Post subject: Reply with quote

lcj wrote:
with kernel 3.12.0-gentoo the flood seems to be *huge* while with previous (umh... 3.9.12 I guess) it was message every 5-6 minutes one from BAT followed by one from AC.

Such reduced time lapse of this service is surely meant as an improvement: Think of a use case when being mobile and having a heavy duty task run, which results in a battery with only one minute of power left !
Back to top
View user's profile Send private message
lcj
Tux's lil' helper
Tux's lil' helper


Joined: 25 Apr 2004
Posts: 82
Location: Opole, Poland

PostPosted: Fri Dec 06, 2013 2:53 pm    Post subject: Reply with quote

Well - not that I complain, but flood is probably not what we would like to get. Windows reports battery getting old once, maybe the interpretation of the ACPI event from this particular vendor (DELL) should be supressed after all.
I will investigate further but I think we should not continue this thread - the actual problem IS SOLVED.
_________________
--
Lukasz C. Jokiel via web
Back to top
View user's profile Send private message
Barvinok
n00b
n00b


Joined: 29 Sep 2013
Posts: 34
Location: Ukraine

PostPosted: Fri Dec 06, 2013 3:23 pm    Post subject: Reply with quote

ulenrich wrote:
Barvinok wrote:
Having the same problem.
What if I need kernel support for the power supply and battery? How do I just stop journald flooding or redirect it elsewhere?

If you know your hardware is rotten like @lcj it is hillarious to expect support from any software package. This thread solved.

I don't think so.
First off, my hardware is NOT rotten. It is the Dell Inspiron 1720 with replacement battery that works pretty well under either Windows and under my previous Gentoo setup (OpenRC + GNOME2 + same kernel 3.10.17).
That switching to systemd caused massive battery event flood in journal while OpenRC and Windows had no problems with it whatsoever means there's something wrong with systemd (misconfigure perhaps) and NOT with hardware.

lcj wrote:
Well - not that I complain, but flood is probably not what we would like to get. Windows reports battery getting old once, maybe the interpretation of the ACPI event from this particular vendor (DELL) should be supressed after all. I will investigate further but I think we should not continue this thread - the actual problem IS SOLVED.

I'm not having "old battery" messages from Windows so I presume it is not old, yet systemd still floods my journal with battery events on a large scale. Increasing kernel buffers did help in the sense that I now see that the flood is associated with battery.
Turning off kernel support for battery and power supply is not the way to go, because I'd like ALL of my hardware working as expected and supported by the OS.

So, the question lingers -- where do I find settings pertaining the verbosity of journald or suppression of specific kind of messages?
_________________
Unlike reality, stupidity is inescapable
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1480

PostPosted: Fri Dec 06, 2013 4:37 pm    Post subject: Reply with quote

Code:
$ zcat /proc/config.gz |grep LOGLEVEL
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=1

And specific journalctl options in conf files in /etc/systemd
But your more verbose output could be interesting for @lcj also. If there is a flood of messages there is a high chance you encountered a failure of your system!
Back to top
View user's profile Send private message
Barvinok
n00b
n00b


Joined: 29 Sep 2013
Posts: 34
Location: Ukraine

PostPosted: Sat Dec 07, 2013 10:10 am    Post subject: Reply with quote

Okay, now is the time for some ACPI mystery.
I was playing with journald config on this machine while ac and battery modules were turned off from the kernel. After that I re-enabled ac and battery modules only to see there's no more uevent flood. Worse still, the flood didn't reappear when I reverted journald settings back to previous. So now the issue on Dell Inspiron seem fixed but I still don't know how to fix it.

For next experiments, I took much newer laptop with stock battery, this time ASUS K52N, with exactly the same previous Gentoo setup and also in transition to systemd and GNOME3. It also flooded in the exactly same way as Inspiron did before, only this time I managed to take a peek at it:
1. modprobe ac results in the following flood which continues infinitely:
Code:

[  694.674997] systemd-journald[77]: /dev/kmsg buffer overrun, some messages lost.
[  694.675137] power_supply AC0: uevent
[  694.675139] power_supply AC0: POWER_SUPPLY_NAME=AC0
[  694.675157] power_supply AC0: prop ONLINE=1
[  694.675181] systemd-journald[77]: /dev/kmsg buffer overrun, some messages lost.
[  694.675323] power_supply AC0: uevent
[  694.675325] power_supply AC0: POWER_SUPPLY_NAME=AC0
[  694.675342] power_supply AC0: prop ONLINE=1
[  694.675366] systemd-journald[77]: /dev/kmsg buffer overrun, some messages lost.
[  694.675507] power_supply AC0: uevent
[  694.675509] power_supply AC0: POWER_SUPPLY_NAME=AC0
[  694.675526] power_supply AC0: prop ONLINE=1

2. modprobe battery results in the following flood, which also continues infinitely:
Code:

[ 1520.753770] systemd-journald[77]: /dev/kmsg buffer overrun, some messages lost.
[ 1520.753925] power_supply BAT0: uevent
[ 1520.753928] power_supply BAT0: POWER_SUPPLY_NAME=BAT0
[ 1520.753931] power_supply BAT0: prop STATUS=Unknown
[ 1520.753933] power_supply BAT0: prop PRESENT=1
[ 1520.753935] power_supply BAT0: prop TECHNOLOGY=Li-ion
[ 1520.753938] power_supply BAT0: prop CYCLE_COUNT=0
[ 1520.753940] power_supply BAT0: prop VOLTAGE_MIN_DESIGN=14400000
[ 1520.753942] power_supply BAT0: prop VOLTAGE_NOW=16616000
[ 1520.753945] power_supply BAT0: prop POWER_NOW=0
[ 1520.753947] power_supply BAT0: prop ENERGY_FULL_DESIGN=30100000
[ 1520.753949] power_supply BAT0: prop ENERGY_FULL=31332000
[ 1520.753952] power_supply BAT0: prop ENERGY_NOW=30800000
[ 1520.753954] power_supply BAT0: prop CAPACITY=98
[ 1520.753956] power_supply BAT0: prop MODEL_NAME=K52F-22
[ 1520.753959] power_supply BAT0: prop MANUFACTURER=ASUSTek
[ 1520.753961] power_supply BAT0: prop SERIAL_NUMBER=
[ 1520.753994] systemd-journald[77]: /dev/kmsg buffer overrun, some messages lost.
[ 1520.754135] power_supply BAT0: uevent
[ 1520.754137] power_supply BAT0: POWER_SUPPLY_NAME=BAT0
[ 1520.754140] power_supply BAT0: prop STATUS=Unknown
[ 1520.754142] power_supply BAT0: prop PRESENT=1
[ 1520.754145] power_supply BAT0: prop TECHNOLOGY=Li-ion
[ 1520.754147] power_supply BAT0: prop CYCLE_COUNT=0
[ 1520.754149] power_supply BAT0: prop VOLTAGE_MIN_DESIGN=14400000
[ 1520.754152] power_supply BAT0: prop VOLTAGE_NOW=16616000
[ 1520.754154] power_supply BAT0: prop POWER_NOW=0
[ 1520.754157] power_supply BAT0: prop ENERGY_FULL_DESIGN=30100000
[ 1520.754159] power_supply BAT0: prop ENERGY_FULL=31332000
[ 1520.754161] power_supply BAT0: prop ENERGY_NOW=30800000
[ 1520.754164] power_supply BAT0: prop CAPACITY=98
[ 1520.754166] power_supply BAT0: prop MODEL_NAME=K52F-22
[ 1520.754169] power_supply BAT0: prop MANUFACTURER=ASUSTek
[ 1520.754171] power_supply BAT0: prop SERIAL_NUMBER=


I don't see any hints of failures, the messages seem to be generic "i'm here and ok" kind.
And I can't turn off ac+battery modules for production because these laptops are often used off-AC and the users need to know the battery status.

Interesting is that if I reboot the system into OpenRC, these same modules do NOT produce flood. So the cause must be in the systemd.

Any ideas?
_________________
Unlike reality, stupidity is inescapable
Back to top
View user's profile Send private message
Barvinok
n00b
n00b


Joined: 29 Sep 2013
Posts: 34
Location: Ukraine

PostPosted: Sun Dec 08, 2013 6:27 am    Post subject: Reply with quote

Here's my latest discoveries on the issue.
I'm no longer blaming systemd, this seems to be some specific hardware issue unaccounted for in the kernel.
Stuffing dump_stack() in various places of kernel source, namely at power_supply and battery modules, I came to see that the uevent flood is reported by power_supply_uevent() function called by this:
Code:

гру 08 07:45:25 dolphin kernel:  [<ffffffff813ff5ab>] dev_attr_show+0x1b/0x60
гру 08 07:45:25 dolphin kernel:  [<ffffffff810a5fe2>] ? __get_free_pages+0x12/0x50
гру 08 07:45:25 dolphin kernel:  [<ffffffff81140094>] sysfs_read_file+0xa4/0x180
гру 08 07:45:25 dolphin kernel:  [<ffffffff810da173>] vfs_read+0xa3/0x170
гру 08 07:45:25 dolphin kernel:  [<ffffffff810da3dd>] SyS_read+0x4d/0x90
гру 08 07:45:25 dolphin kernel:  [<ffffffff81803a90>] system_call_fastpath+0x16/0x1b

Not being skilled kernel developer I don't know what the implications for this so as a temporary solution I wrote this dirty hack
Code:
*** power_supply_sysfs.c.bak    2013-12-08 08:00:33.505634432 +0200
--- power_supply_sysfs.c        2013-12-08 08:01:26.942007870 +0200
***************
*** 264,269 ****
--- 264,270 ----

  int power_supply_uevent(struct device *dev, struct kobj_uevent_env *env)
  {
+       return 0; // dirty hack to prevent ac/battery uevent flood on ASUS K52N
        struct power_supply *psy = dev_get_drvdata(dev);
        int ret = 0, j;
        char *prop_buf;

For now, ac and battery modules are working as expected. I hope nothing else was broken by this patch :lol:
_________________
Unlike reality, stupidity is inescapable
Back to top
View user's profile Send private message
lcj
Tux's lil' helper
Tux's lil' helper


Joined: 25 Apr 2004
Posts: 82
Location: Opole, Poland

PostPosted: Thu Dec 12, 2013 6:18 pm    Post subject: Reply with quote

@Barvinok:

So it's not related to actual hardware problems ? I do know that I had connected PSU for this Dell that wasn't enough (65W should be 90W) and the battery is not BAD yet.
But it seems this ACPI flood is unrelated to actual hardware issues.
_________________
--
Lukasz C. Jokiel via web
Back to top
View user's profile Send private message
Barvinok
n00b
n00b


Joined: 29 Sep 2013
Posts: 34
Location: Ukraine

PostPosted: Thu Dec 12, 2013 7:12 pm    Post subject: Reply with quote

lcj wrote:
So it's not related to actual hardware problems ?

I don't know for sure but this seems unlikely. The Asus laptop is quite new.

lcj wrote:
I do know that I had connected PSU for this Dell that wasn't enough (65W should be 90W) and the battery is not BAD yet. But it seems this ACPI flood is unrelated to actual hardware issues.

I'm thinking of elevating the issue to where kernel devs hang out.
_________________
Unlike reality, stupidity is inescapable
Back to top
View user's profile Send private message
lcj
Tux's lil' helper
Tux's lil' helper


Joined: 25 Apr 2004
Posts: 82
Location: Opole, Poland

PostPosted: Sun Dec 15, 2013 10:16 pm    Post subject: Reply with quote

I agree, elevate this!
_________________
--
Lukasz C. Jokiel via web
Back to top
View user's profile Send private message
Navar
Guru
Guru


Joined: 20 Aug 2012
Posts: 353

PostPosted: Mon Dec 16, 2013 4:40 am    Post subject: Reply with quote

ulenrich wrote:
If there is a flood of messages there is a high chance you encountered a failure of your system!

Proof? So far, the vector presented was with systemd-journald. Other vectors didn't exhibit, but you automatically leap to the assumption systemd is somehow errata free.

ulenrich wrote:
If you know your hardware is rotten like @lcj it is hillarious to expect support from any software package. This thread solved.

Proof? Give your definition of 'rotten hardware'. Exactly what do you think all the various code handling hardware 'quirks' in the kernel are for? So you think handling hardware exceptions via software is 'hillarious' and should not be supported? Have you removed all the various quirks, particularly ACPI oriented, within your kernel code? Who are these particular non-'rotten hardware' system vendors where no ACPI issues exist in linux?

These are community driven forums. The OP should decide if their thread is solved by merit of their own determination, not yours.

ulenrich wrote:
Such reduced time lapse of this service is surely meant as an improvement: Think of a use case when being mobile and having a heavy duty task run, which results in a battery with only one minute of power left !

... like systemd-journald? :roll:

lcj wrote:
system-journald is taking up to 95% of the CPU core, load is @ 1,53.

_________________
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1480

PostPosted: Mon Dec 16, 2013 11:52 am    Post subject: Reply with quote

@Navar,
my "solved" statement refered to this message just two above it:
lcj wrote:
The battery just last month started to complain because it's around 3 years old, so Dell utility says after every boot: Battery may load normaly, but it's performance might be decreased over time.

So after removing the support from kernel: battery & AC power supply my kernel log is no longer overflooded. Thanks.


Regarding a system log: Do you prefer hardware failure kept hidden from the logs? It is a fine balance yet to achieve between hiding a flood and - please not - hiding an issue. To not been hinted by syslog I would call an error. But with journald having such a high system load isn't favorable either. But it is less an error. Your argument: "The secure way having a car is without fuel."
Back to top
View user's profile Send private message
Navar
Guru
Guru


Joined: 20 Aug 2012
Posts: 353

PostPosted: Mon Dec 16, 2013 1:56 pm    Post subject: Reply with quote

@ulenrich,
Let's not presume what I may prefer. My argument was not against the importance of system logging, on the contrary. Instead, seemingly non-existent rate limiting on messages with a syslog function process acting, frankly, out of control on reporting duplicate events is the issue. It's hardly the first time a freedesktop.org 'invention' has shown race conditions and run away event handling (evolution, pulseaudio, nautilus, etc.). Hey, it's software development, stuff happens. But why it always has to be yet another not-ready-for-prime-time affair with multi-year userbase 'testing' is beyond me.

And if we're going there (systemd), which we're not--I'm clarifying my stance on this particular issue. I personally loathe the Redmond Way binary closed format of system and event logging rather than the simple de facto text output we're used to that many simple, non-proprietary, tools can easily process. When have obscure closed binary formats ever been a good idea for system logs?
  • When we care less about immediate performance and simplicity and more about large stores of metadata (now the metaphor on function is less a log and more a database with associated problems).
  • When there is money to be made off forcing your users to learn your particular proprietary tools for any access and recovery.
  • And apparently due to freedesktop documentation, when there is some burning need to store large chunks of binary data... what are we storing core file data now?
Have I utilized the systemd way of logging? Thankfully, no, but I've read enough frustrations of others it has been foist upon and screen shots displaying the situation to know I'm wary.

As convoluted and massive in scope as XML related technologies are, they're still far and away better in helping data exchange than dealing with binary formats. Efficiency is their main weak point. The only arguments for binary data have been efficiency and obscurity. If systemd were producing XML output (as an option) along with plain text like existing loggers do, I could see both sides. Hell, even if the option to opt out of binary journal use with their proprietary database scheme for simple text writes would be ok. But those options don't exist. In fact, the freekdesktop documentation strongly 'recommends' using their tools only rather than bothering to absorb their C API to produce your own parsing tools.
_________________
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.
Back to top
View user's profile Send private message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Tue Dec 17, 2013 12:41 am    Post subject: Reply with quote

Navar wrote:
ulenrich wrote:
If there is a flood of messages there is a high chance you encountered a failure of your system!

Proof? So far, the vector presented was with systemd-journald. Other vectors didn't exhibit, but you automatically leap to the assumption systemd is somehow errata free.


Don't shoot the messenger; I'm going to be that third dog that steals a bone when two dogs try to take it and mention that it could very well be a kernel bug too, which isn't errata free either.

Navar wrote:
ulenrich wrote:
If you know your hardware is rotten like @lcj it is hillarious to expect support from any software package. This thread solved.

Proof? Give your definition of 'rotten hardware'.


Yes, a definition would be nice; because until given, the following questions may or may not apply:

Navar wrote:
Exactly what do you think all the various code handling hardware 'quirks' in the kernel are for? So you think handling hardware exceptions via software is 'hillarious' and should not be supported? Have you removed all the various quirks, particularly ACPI oriented, within your kernel code? Who are these particular non-'rotten hardware' system vendors where no ACPI issues exist in linux?


A system failure may very well be the result of broken hardware; but there's a lot between that hardware and the screen before drawing that conclusion, 'rotten hardware' is a bit of a far-fetched expression given that the moment that was stated the hardware was not even known.

Navar wrote:
These are community driven forums. The OP should decide if their thread is solved by merit of their own determination, not yours.


+1

Navar wrote:
ulenrich wrote:
Such reduced time lapse of this service is surely meant as an improvement: Think of a use case when being mobile and having a heavy duty task run, which results in a battery with only one minute of power left !

... like systemd-journald? :roll:

lcj wrote:
system-journald is taking up to 95% of the CPU core, load is @ 1,53.


In the Harry Potter movie similar things happened when tons of letters arrived at their house, which made the house quite busy and loaded; ...
Back to top
View user's profile Send private message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Tue Dec 17, 2013 12:49 am    Post subject: Reply with quote

Navar wrote:
Instead, seemingly non-existent rate limiting on messages with a syslog function process acting, frankly, out of control on reporting duplicate events is the issue.


It brought attention to the issue and the events are readable; so, what's the issue?

Navar wrote:
And if we're going there (systemd), which we're not--I'm clarifying my stance on this particular issue. I personally loathe the Redmond Way binary closed format of system and event logging rather than the simple de facto text output we're used to that many simple, non-proprietary, tools can easily process. When have obscure closed binary formats ever been a good idea for system logs?
  • When we care less about immediate performance and simplicity and more about large stores of metadata (now the metaphor on function is less a log and more a database with associated problems).
  • When there is money to be made off forcing your users to learn your particular proprietary tools for any access and recovery.
  • And apparently due to freedesktop documentation, when there is some burning need to store large chunks of binary data... what are we storing core file data now?
Have I utilized the systemd way of logging? Thankfully, no, but I've read enough frustrations of others it has been foist upon and screen shots displaying the situation to know I'm wary.

As convoluted and massive in scope as XML related technologies are, they're still far and away better in helping data exchange than dealing with binary formats. Efficiency is their main weak point. The only arguments for binary data have been efficiency and obscurity. If systemd were producing XML output (as an option) along with plain text like existing loggers do, I could see both sides. Hell, even if the option to opt out of binary journal use with their proprietary database scheme for simple text writes would be ok. But those options don't exist. In fact, the freekdesktop documentation strongly 'recommends' using their tools only rather than bothering to absorb their C API to produce your own parsing tools.


Such options do exist:

Code:
  -o --output=STRING       Change journal output mode (short, short-iso,
                           short-precise, short-monotonic, verbose,
                           export, json, json-pretty, json-sse, cat)


From there on JSON to XML is only one step away.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum