Outcome: The doubtlessly 'optimized' journald-code at 100% CPU usage, my absolutely unoptimized Perl code sending the data at about 30% and the writing process which also needs to do base64 decoding (written in C)
doesn't even show up.
Colour me unsurprised :-)))
Rainer Weikusat <rweikusat@talktalk.net> wrote:
<snip>
Outcome: The doubtlessly 'optimized' journald-code at 100% CPU usage, my
absolutely unoptimized Perl code sending the data at about 30% and the
writing process which also needs to do base64 decoding (written in C)
doesn't even show up.
Colour me unsurprised :-)))
Curious, did you try that on a syslog system ?
Also how long did each process run (systend vs your perl) ?
Since everything goes through syslogd(8) I wonder if the
same would happen. If you can describe how you did this
or post the script I would like to try it uder OpenBSD.
Ever since Lennart the Poettering start 'improving' syslog support for
Linux, I've been wondering how his 'improved' code would fare when
coming somewhat under actual load, as his 'improvement ideas' sounded
like the exact kind of lemon all his other ideas sounded like.
Now I know: In order to test some output queueing code, I'm writing 8K
blocks of base64 data to a socketpair. Another process on the other end
of the pair receives them and writes them to disk. I'm sending four of
these in a loop and then reschedule the send function through the
top-level I/O loop so that the (single-threaded) sending program also
gets some other stuff done. This causes a couple of lines of text to be >logged for each data block.
Outcome: The doubtlessly 'optimized' journald-code at 100% CPU usage, my >absolutely unoptimized Perl code sending the data at about 30% and the >writing process which also needs to do base64 decoding (written in C)
doesn't even show up.
Colour me unsurprised :-)))
John McCue <jmccue@fuzzball.mhome.org> wrote:
Rainer Weikusat <rweikusat@talktalk.net> wrote:
<snip>
Outcome: The doubtlessly 'optimized' journald-code at 100% CPU usage, my >>> absolutely unoptimized Perl code sending the data at about 30% and the
writing process which also needs to do base64 decoding (written in C)
doesn't even show up.
Colour me unsurprised :-)))
Curious, did you try that on a syslog system ?
Also how long did each process run (systend vs your perl) ?
Since everything goes through syslogd(8) I wonder if the
same would happen. If you can describe how you did this
or post the script I would like to try it uder OpenBSD.
For several years now there is no separate syslogd daemon for inbound logs. >systemd handles that directly:
On Tue, 01 Feb 2022 20:00:40 +0000
Rainer Weikusat <rweikusat@talktalk.net> wrote:
Ever since Lennart the Poettering start 'improving' syslog support for >>Linux, I've been wondering how his 'improved' code would fare when
coming somewhat under actual load, as his 'improvement ideas' sounded
like the exact kind of lemon all his other ideas sounded like.
Outcome: The doubtlessly 'optimized' journald-code at 100% CPU usage,
Colour me unsurprised :-)))
Unfortunately the herd (or if you want to be cruel - sheep) mentality
is alive and well in the Linux distro community and where Red Hat goes
the rest of them follow.
At least Devuan is trying to remain with old style init and
Slackware (if he ever bothers to release 15.0 it might be worth a look).
Muttley@dastardlyhq.com writes:
I'm running Devuan at home but support systemd professionally (system >integration only). If it actually improved anything, instead of just
changing everything, I've yet to find it. Even service start scripts are >still with us because the systemd-provided facilities are too primitive
to replace them completely.
Rainer Weikusat <rweikusat@talktalk.net> wrote:
<snip>
Outcome: The doubtlessly 'optimized' journald-code at 100% CPU usage, my
absolutely unoptimized Perl code sending the data at about 30% and the
writing process which also needs to do base64 decoding (written in C)
doesn't even show up.
Colour me unsurprised :-)))
Curious, did you try that on a syslog system ?
Since everything goes through syslogd(8) I wonder if the
same would happen.
If you can describe how you did this
or post the script I would like to try it uder OpenBSD.
William Ahern <william@25thandClement.com> writes:
John McCue <jmccue@fuzzball.mhome.org> wrote:
Rainer Weikusat <rweikusat@talktalk.net> wrote:
<snip>
Outcome: The doubtlessly 'optimized' journald-code at 100% CPU usage, my >>>> absolutely unoptimized Perl code sending the data at about 30% and the >>>> writing process which also needs to do base64 decoding (written in C)
doesn't even show up.
Colour me unsurprised :-)))
Curious, did you try that on a syslog system ?
Also how long did each process run (systend vs your perl) ?
Since everything goes through syslogd(8) I wonder if the
same would happen. If you can describe how you did this
or post the script I would like to try it uder OpenBSD.
For several years now there is no separate syslogd daemon for inbound logs. >>systemd handles that directly:
That depends entirely on which distribution you are using. There
are many distributions (including most BSDs) that eschew the steaming
pile of dog turds called systemd.
John McCue <jmccue@fuzzball.mhome.org> writes:<snip>
Rainer Weikusat <rweikusat@talktalk.net> wrote:
That's part of a >7000 LOC set of programs for enabling cloud-based management of network threat detection appliances (and obviously, all proprietary stuff).
Muttley@dastardlyhq.com writes:
On Tue, 01 Feb 2022 20:00:40 +0000
Rainer Weikusat <rweikusat@talktalk.net> wrote:
Ever since Lennart the Poettering start 'improving' syslog support for >>Linux, I've been wondering how his 'improved' code would fare when
coming somewhat under actual load, as his 'improvement ideas' sounded >>like the exact kind of lemon all his other ideas sounded like.
[...]
Outcome: The doubtlessly 'optimized' journald-code at 100% CPU usage,
[...]
Colour me unsurprised :-)))
Unfortunately the herd (or if you want to be cruel - sheep) mentality
is alive and well in the Linux distro community and where Red Hat goes
the rest of them follow.
I think this is more a case of "what RedHat pays for, the others will
use".
At least Devuan is trying to remain with old style init and
Slackware (if he ever bothers to release 15.0 it might be worth a look).
I'm running Devuan at home but support systemd professionally (system integration only). If it actually improved anything, instead of just
changing everything, I've yet to find it. Even service start scripts are still with us because the systemd-provided facilities are too primitive
to replace them completely.
On Wed, 02 Feb 2022 15:45:13 +0000
Rainer Weikusat <rweikusat@talktalk.net> wrote:
Muttley@dastardlyhq.com writes:
On Tue, 01 Feb 2022 20:00:40 +0000
Rainer Weikusat <rweikusat@talktalk.net> wrote:
Ever since Lennart the Poettering start 'improving' syslog support for
Linux, I've been wondering how his 'improved' code would fare when
coming somewhat under actual load, as his 'improvement ideas' sounded
like the exact kind of lemon all his other ideas sounded like.
[...]
Outcome: The doubtlessly 'optimized' journald-code at 100% CPU usage,
[...]
Colour me unsurprised :-)))
Unfortunately the herd (or if you want to be cruel - sheep) mentality
is alive and well in the Linux distro community and where Red Hat goes
the rest of them follow.
I think this is more a case of "what RedHat pays for, the others will
use".
At least Devuan is trying to remain with old style init andI'm running Devuan at home but support systemd professionally (system
Slackware (if he ever bothers to release 15.0 it might be worth a look). >>
integration only). If it actually improved anything, instead of just
changing everything, I've yet to find it. Even service start scripts are
still with us because the systemd-provided facilities are too primitive
to replace them completely.
And then, to try and replicate what a shell script does, you look at the
Unit file man pages to see that there are _hundreads_ of options and knobs >available.
A few times in Linux's history a large subsystem has been thrown out because it became too unwieldy. dbus comes to mind as the most recent. One can hope that eventually enough people will get so sick of systemd that Red Hat supported or not, it'll get removed from most distros.
I do indeed use OpenBSD for the stuff that matters most =) But I figured the context here was mainline Linux distributions using systemd (e.g. Debian, Fedora), not alternative Linux distributions (e.g. Alpine) or different Unix operating systems altogether.
On 2022-02-02, William Ahern <william@25thandClement.com> wrote:
I do indeed use OpenBSD for the stuff that matters most =) But I figured the >> context here was mainline Linux distributions using systemd (e.g. Debian,
Fedora), not alternative Linux distributions (e.g. Alpine) or different Unix >> operating systems altogether.
Debian, and I would guess most GNU/Linux distributions, also distribute >good-old SysV init and can be configured to use that. So it's really on
you, if you decide to stick with systemd. Removing systemd is the first
thing I do on any new GNU/Linux installation.
On 26 May 2022 21:36:35 GMT
John Tsiombikas <nuclear@member.fsf.org> wrote:
On 2022-02-02, William Ahern <william@25thandClement.com> wrote:
I do indeed use OpenBSD for the stuff that matters most =) But I figured the
context here was mainline Linux distributions using systemd (e.g. Debian, >>> Fedora), not alternative Linux distributions (e.g. Alpine) or different Unix
operating systems altogether.
Debian, and I would guess most GNU/Linux distributions, also distribute >>good-old SysV init and can be configured to use that. So it's really on >>you, if you decide to stick with systemd. Removing systemd is the first >>thing I do on any new GNU/Linux installation.
Just install Slackware, it uses SysV by default.
Speaking of which, I recently installed Slackware 15 into a VM.
Very refreshing experience.
But, I must say, Slackware is quite harmed by the insane piece of
vandalism that some dastardly knaves perpetrated against the kernel
source sometime in the past couple of years. I'm talking about the
vicious removal of the Shift-PgUp scrollback history available in the >console.
When you are doing a text-only install using only the console,
in a distro such as Slackware, it's very annoying not to be able to
scroll back. I needed to see something that scrolled off the screen
while doing partitioning with fdisk. This was so vexing, I did the >unthinkable and finished the job with cfdisk.
Burn in hell, scrollback-removing cretins!
In article <20220527223044.307@kylheku.com>,
Kaz Kylheku <480-992-1380@kylheku.com> wrote:
...
Speaking of which, I recently installed Slackware 15 into a VM.
Very refreshing experience.
But, I must say, Slackware is quite harmed by the insane piece of
vandalism that some dastardly knaves perpetrated against the kernel
source sometime in the past couple of years. I'm talking about the
vicious removal of the Shift-PgUp scrollback history available in the >>console.
When you are doing a text-only install using only the console,
in a distro such as Slackware, it's very annoying not to be able to
scroll back. I needed to see something that scrolled off the screen
while doing partitioning with fdisk. This was so vexing, I did the >>unthinkable and finished the job with cfdisk.
Burn in hell, scrollback-removing cretins!
+1 (!)
Two comments:
1) I heard about this on some Raspberry Pi forum. Apparently, what
happened was that somebody discovered a bug (presumably, a non-trivial one) in the code for this, but there was no one around (i.e., no one left) who could fix it.
On 2022-05-28, Kenny McCormack <gazelle@shell.xmission.com> wrote:
In article <20220527223044.307@kylheku.com>,
Kaz Kylheku <480-992-1380@kylheku.com> wrote:
...
Speaking of which, I recently installed Slackware 15 into a VM.
Very refreshing experience.
But, I must say, Slackware is quite harmed by the insane piece of >>>vandalism that some dastardly knaves perpetrated against the kernel >>>source sometime in the past couple of years. I'm talking about the >>>vicious removal of the Shift-PgUp scrollback history available in the >>>console.
When you are doing a text-only install using only the console,
in a distro such as Slackware, it's very annoying not to be able to >>>scroll back. I needed to see something that scrolled off the screen
while doing partitioning with fdisk. This was so vexing, I did the >>>unthinkable and finished the job with cfdisk.
Burn in hell, scrollback-removing cretins!
+1 (!)
Two comments:
1) I heard about this on some Raspberry Pi forum. Apparently, what
happened was that somebody discovered a bug (presumably, a non-trivial one) >> in the code for this, but there was no one around (i.e., no one left) who
could fix it.
This is the part that is idiotic, because unless those bugs are so
severe that they make possible a *remote* exploit, they should
just stay.
I enjoyed "years of trouble-free operation" with the console, and now
some fuckfaces who can't deal with a few corner cases think it's fine to
deal a blow to the user-friendliness of Linux?
Make it a command line option, you know?
linux root=whatever ... console_scroll=1 ,,,
The source is available for download. Feel free to fix it and
submit the patch to the kernel mailing list.
Speaking of which, I recently installed Slackware 15 into a VM.
Very refreshing experience.
But, I must say, Slackware is quite harmed by the insane piece of
vandalism that some dastardly knaves perpetrated against the kernel
source sometime in the past couple of years. I'm talking about the
vicious removal of the Shift-PgUp scrollback history available in the console.
When you are doing a text-only install using only the console,
in a distro such as Slackware, it's very annoying not to be able to
scroll back. I needed to see something that scrolled off the screen
while doing partitioning with fdisk. This was so vexing, I did the unthinkable and finished the job with cfdisk.
Burn in hell, scrollback-removing cretins!
On 26 May 2022 21:36:35 GMT John Tsiombikas <nuclear@member.fsf.org>
wrote:
Removing systemd is the first thing I do on any new GNU/Linux
installation.
Just install Slackware, it uses SysV by default.
On 2022-05-27, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
On 26 May 2022 21:36:35 GMT John Tsiombikas <nuclear@member.fsf.org>
wrote:
Removing systemd is the first thing I do on any new GNU/Linux >>>installation.
Just install Slackware, it uses SysV by default.
Slackware is a perfectly good system, and I have used it in the past,
but Debian is more convenient day to day, and as I said, the option to
use SysV init is there. It not being the default doesn't make much >difference. Default installation options are meaningless when you
install a system once and keep using it for the next 12 years :)
I think my current Debian installation dates from 2010.
I wasn't familiar with this functionality. Does it offer any advantages over >using GNU screen or script ?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 497 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 03:22:05 |
| Calls: | 9,773 |
| Calls today: | 14 |
| Files: | 13,748 |
| Messages: | 6,186,529 |