And the whole thing came up because someone (and not a systemd developer) decided that rlimits for setuid processes should be copied from pid 1, because that seemed a good default. Linus didn't like the patch, making his joking reference to systemd, but he was right whatever pid 1 was, shell, init(1), upstart or whatever -- copying rlimits from pid1 to all setuid processes makes no fucking sense whatever.
Also, systemd defaults to "no logging", you have to explicitly send to a systemd log.
Nope, not the case:
man systemd.exec [...]
StandardOutput=
Controls where file descriptor 1 (STDOUT) of the executed processes
is connected to. Takes one of inherit, null, tty, journal, syslog,
kmsg, journal+console, syslog+console, kmsg+console, socket or fd. [...]
This setting defaults to the value set with DefaultStandardOutput=
in systemd-system.conf(5), which defaults to journal. [...]
StandardError=
Controls where file descriptor 2 (STDERR) of the executed processes
is connected to. The available options are identical to those of
StandardOutput=, with some exceptions: if set to inherit the file
descriptor used for standard output is duplicated for standard
error, [...]
This setting defaults to the value set with DefaultStandardError=
in systemd-system.conf(5), which defaults to inherit.
So if you, or your distro, don't change the default it goes to the journal.
Like logging. Logging is critical for both troubleshooting and security. With sys V init scripts, even if the error wasn't logged to syslog, you'd at least see it on the console instead of so often seeing nothing with systemd.
Hahaha! Someone was dumb enough to upvote the troll! Well done little troll!
The bigger problem is that messages that used to show on the console with SysV init scripts are now no longer showed on the console, and they are not logged in the journal. That makes troubleshooting a pain in the neck. Simple problems, like a/var/lib/mongodb/mongod.lock hanging around after a power problem which prevents MongoDB from restarting, can take a while to trackdown since nothing logs that error
Not Enuch swear -- Eunuchs ware (i.e. when I made this account I was a UnixWare (svr4.2) user -- "UNIX" == "UNiplexed Information and Computing Service" -- a castrated version of Multics).
A bit more tricky to see than a database field as the developers will be of the mindset that the integer is 64bits, as it will be on the devices they develop on.
Yeah, that sounds possible. A good reason to hire older guys like me!
I built an application with a 32 bit message counter. When I noticed we were approaching 1 billion messages I reformatted the database and modified the application to use a 64 bit counter. Been there, done that.
That's the thing that they are obsessed with, the terrorists, the idea of knocking down an airplane in flight, particularly if it's a U.S. carrier, particularly if it's full of U.S. people.
So this restriction will apply to domestic flights?
Slashdot Mirror
(Yes, snatching STDERR from a daemon is genius. Definitely. But what was wrong with then handing the output to the syslog daemon?)
Uh, nothing is wrong with that. That's why you can configure systemd to do that, as, for example, Debian does.
And the whole thing came up because someone (and not a systemd developer) decided that rlimits for setuid processes should be copied from pid 1, because that seemed a good default. Linus didn't like the patch, making his joking reference to systemd, but he was right whatever pid 1 was, shell, init(1), upstart or whatever -- copying rlimits from pid1 to all setuid processes makes no fucking sense whatever.
https://lkml.org/lkml/2017/7/6...
Also, systemd defaults to "no logging", you have to explicitly send to a systemd log.
Nope, not the case:
man systemd.exec
[...]
StandardOutput=
Controls where file descriptor 1 (STDOUT) of the executed processes
is connected to. Takes one of inherit, null, tty, journal, syslog,
kmsg, journal+console, syslog+console, kmsg+console, socket or fd.
[...]
This setting defaults to the value set with DefaultStandardOutput=
in systemd-system.conf(5), which defaults to journal.
[...]
StandardError=
Controls where file descriptor 2 (STDERR) of the executed processes
is connected to. The available options are identical to those of
StandardOutput=, with some exceptions: if set to inherit the file
descriptor used for standard output is duplicated for standard
error,
[...]
This setting defaults to the value set with DefaultStandardError=
in systemd-system.conf(5), which defaults to inherit.
So if you, or your distro, don't change the default it goes to the journal.
> doing it half-assed.
Like logging. Logging is critical for both troubleshooting and security. With sys V init scripts, even if the error wasn't logged to syslog, you'd at least see it on the console instead of so often seeing nothing with systemd.
Hahaha! Someone was dumb enough to upvote the troll! Well done little troll!
ObScanners
The bigger problem is that messages that used to show on the console with SysV init scripts are now no longer showed on the console, and they are not logged in the journal. That makes troubleshooting a pain in the neck. Simple problems, like a /var/lib/mongodb/mongod.lock hanging around after a power problem which prevents MongoDB from restarting, can take a while to trackdown since nothing logs that error
Repost of trolling from over a year ago.
the fact that the lead dev gave someone a tongue lashing over expecting his logs to be at-least partially usable after a system crash
Amusing anecdote. Pity it's not true.
What, never? Never worked that way? Are you sure?
Well, yes. :-)
Fucking HTML, I meant <= 32
Nope, the vast majority of "machines" in use are = 32 bit. More phones than PC's by orders of magnitude.
Not Enuch swear -- Eunuchs ware (i.e. when I made this account I was a UnixWare (svr4.2) user -- "UNIX" == "UNiplexed Information and Computing Service" -- a castrated version of Multics).
A bit more tricky to see than a database field as the developers will be of the mindset that the integer is 64bits, as it will be on the devices they develop on.
Yeah, that sounds possible. A good reason to hire older guys like me!
Not hindsight, foresight.
(see reply to anonymous cow herd above).
I built an application with a 32 bit message counter. When I noticed we were approaching 1 billion messages I reformatted the database and modified the application to use a 64 bit counter. Been there, done that.
This was obviously an unforeseen bug that was nearly impossible to anticipate
Only if you're an idiot.
Off your meds again?
Maybe.
Looked a lot less civilised in November 1938.
I run the original f4 version, ported to an ICL 1900 mainframe. The C version is for wimps.
The monthly terror attacks in the Western world are being perpetrated by people from the same few countries.
The most recent attack in the UK was committed by someone born in Manchester. Which "same few countries" are you thinking of?
That's the thing that they are obsessed with, the terrorists, the idea of knocking down an airplane in flight, particularly if it's a U.S. carrier, particularly if it's full of U.S. people.
So this restriction will apply to domestic flights?
What "8% social tax"? You mean the CSG? If you're going to count that then why not count all the social security payments?
Anyway, if you can't see the difference between "over 50% of your income" and "45% on income over 150,000 EUR"...
... when someone steals them?
Germany. Google Bagger 293.
That's very probably true but I very much doubt it will be to France where at least ~15 years ago you used to pay over 50% of your income in tax,
The top income tax rate (on income over EUR 151,261) is 45%.