Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Uselessd

uselessd.darknedgy.net

Post reply on HN
Print view View original

1–10 of 60 posts

Re: Uselessd

#2

Post by silon3 »

"like" (it happened to me)

No journald. Consequently, this also means no libqrencode and libmicrohttpd integration, nor hooking coredumps to the journal. The default log target for auxiliaries is now LOG_TARGET_SYSLOG_OR_KMSG.

The main case against binary logs is their corruptibility. This happens more often than you’d think, due to not having any transaction consistency, as an RDBMS would. The advice of the systemd developers on handling this? Ignore it.

Re: Uselessd

#3

Post by Uberphallus »

silon3 wrote: post #2

"like" (it happened to me) No journald. Consequently, this also means no libqrencode and libmicrohttpd integration, nor hooking coredumps to the journal. The default log target for auxiliaries is now LOG_TARGET_SYSLOG_OR_KMSG. The main case against binary logs is their corruptibility. This happens more often than you’d think, due to not having any transaction consistency, as an RDBMS would. The advice of the systemd…

Not related to all binary logging, but journalctl is incredibly sluggish.

Some combinations of slow (rotating) media, certain filesystems, and underpowered CPUs (ARM in my experience) and you get a barely usable logging system that makes you want to punch your box.

Re: Uselessd

#4

Post by taeric »

Ok, this has to have been one of the more interesting reads on what the complaints against systemd are. Ridiculously entertaining, to boot.

Re: Uselessd

#6

Post by pgl »

Uberphallus wrote: post #3
silon3 wrote: post #2

"like" (it happened to me) No journald. Consequently, this also means no libqrencode and libmicrohttpd integration, nor hooking coredumps to the journal. The default log target for auxiliaries is now LOG_TARGET_SYSLOG_OR_KMSG. The main case against binary logs is their corruptibility. This happens more often than you’d think, due to not having any transaction consistency, as an RDBMS would. The advice of the systemd…

Not related to all binary logging, but journalctl is incredibly sluggish. Some combinations of slow (rotating) media, certain filesystems, and underpowered CPUs (ARM in my experience) and you get a barely usable logging system that makes you want to punch your box.

I found this to be the case as well. Especially on a busy system where there are a lot of events, when you're trying to find the cause of an issue and constantly opening and closing logs, the lag is definitely noticeable.

Re: Uselessd

#7

Post by rakoo »

Uberphallus wrote: post #3
silon3 wrote: post #2

"like" (it happened to me) No journald. Consequently, this also means no libqrencode and libmicrohttpd integration, nor hooking coredumps to the journal. The default log target for auxiliaries is now LOG_TARGET_SYSLOG_OR_KMSG. The main case against binary logs is their corruptibility. This happens more often than you’d think, due to not having any transaction consistency, as an RDBMS would. The advice of the systemd…

Not related to all binary logging, but journalctl is incredibly sluggish. Some combinations of slow (rotating) media, certain filesystems, and underpowered CPUs (ARM in my experience) and you get a barely usable logging system that makes you want to punch your box.

I don't even have an esoteric setup and every time I want to read logs I'll have to wait 30 secs. Even though there is absolutely no activity.

Re: Uselessd

#8

Post by pgl »

This is such an excellent example of how to actually approach what you don't like about another project. It also has the potential of actually being really useful (despite the name): there are lots of _good_ bits in systemd which are out of reach for people who disagree with so much else in it.

I really hope this takes off.

Re: Uselessd

#9

Post by mrweasel »

Uberphallus wrote: post #3
silon3 wrote: post #2

"like" (it happened to me) No journald. Consequently, this also means no libqrencode and libmicrohttpd integration, nor hooking coredumps to the journal. The default log target for auxiliaries is now LOG_TARGET_SYSLOG_OR_KMSG. The main case against binary logs is their corruptibility. This happens more often than you’d think, due to not having any transaction consistency, as an RDBMS would. The advice of the systemd…

Not related to all binary logging, but journalctl is incredibly sluggish. Some combinations of slow (rotating) media, certain filesystems, and underpowered CPUs (ARM in my experience) and you get a barely usable logging system that makes you want to punch your box.

I'm not currently using Linux, so I might be wrong, or misunderstanding what you're trying to do, but could you just have journald write to syslog?

ForwardToSyslog=yes in /etc/systemd/journald.conf.

Post reply on HN