I guess that the sysv script run pre start tests like checking that lock file and where the ones producting the logs while the systemd unit file for mongodb is just starting mongodb straight up and thus is not getting these particular logs because mongodb does not log about them. Either mongodb should be changed to start logging these things or the systemd unit file should be changed to include those pre start tests that the old sysv script had.
So the problem is not with systemd itself but with the sysv to systemd transition.
"systemctl start" schedules the service to start, it does not start it there and then. You might still not like it but systemd is an event driven system and not a "execute this particular bash shell" type of system, so one cannot use systemctl as a straight drop in replacement for how sysv worked, it works differently.
Note that you had this kind of behaviour in some sysv scripts as well so it was more of a hit and miss in sysv. I.e daemons that could take a very long time to start like say MySQL had init scripts that forked and then sysv would return OK when the actual daemon could very well fail a few second later. So with systemd we actually now have a consistent handling and not the old hit and miss but you have to adopt to the new way for the daemons where sysv happened to be "hit"
Because it's a proven lie? systemd does not swallow log messages, it presents and stores far more logs than sysv did. And the complaint about exit codes are due to either pure lies or people trying to use "systemctl start " as a drop in replacement for "/etc/init.d/ start" which it's not.
I see no critiquing, almost every single anti systemd post on Slashdot for the last years have been crybullying. And the GP in particular was crybullying, nothing more.
I think that it's for users who don't know all those packages to feed to apt and who want to simply install a single meta-package, say "Virtual Observatory" and thus get all the packages included there installed automatically. As I understand it these pure blends is not special versions of Debian either but more working groups that create and maintain these meta-packages that you can install from a vanilla Debian 9.
So go use Devuan? Or is the anti systemd crowd now joining the SWJ, Vegan, Crossfitter crowds where they cannot stand silent for 5 minutes before announcing their special needs and wants to the world?
CMake to me is way more horrible than automake, i.e tried to add a --pkgconfig-dir option to a CMake build for hours until I found out that CMake caches the initial value and always uses the cached value regardless of what you supply to the "cmake." step. And trying to make cmake work in say an initial mingw32 install is always fun.
Of course it's because I'm way more familiar with automake so it's syntax comes naturally to me. Don't really know why my post was modded as troll though. Must be people who have never tried to make a portable JNI or endian build...
Everyone thinks that automake+autoconf+libtool are horrible so they create their new build tool. Then once their new build tool gets close to having similar functionality that automakte+autoconf+libtool has they often tend to be far more ugly and horrible.
And it does not help that we have braindead things like i.e Java JNI where there is a jni.h file in a well hidden non-standards location with a jni_md.h in a system dependent subfolder (so you might have.../freebsd/jni_md.h or../win32/jni_md.h and so on).
Or why there might be __BYTE_ORDER__, __BYTE_ORDER or plain BYTEORDER (or due to the infinite wisdom of Microsoft, no such thing at all). Or the good ol boys from OpenSSL that thought that instead of having a define for the presence of an algorithm there should be a define for if the algorithm is supported by the version of OpenSSL but disabled by the configuration. Or why not the flameretarded OpenBSD that decided to hardcoded the OpenSSL version as 2.0 in LibreSSL when they forked the 1.0 API from OpenSSL when OpenSSL then changed some of their API in v1.1 so now you cannot check if version
Not exactly, due to historical reasons some file systems still have 32-bit time stamps even on 64-bit machines. It will of course be fixed long before 2038 but there are still some work left to do.
Microsoft managed to change time_t to 64-bit due to time_t not being widely used in Windows and because shared libraries on Windows rarely exchange time_t values (since that would break if you linked with an old dll that used the 32-bit time_t as you might imagine).
Stance in Linux land regarding the issue is not to go 64-bit or be abandoned, there are plans in motion, it's just that there are a lot of code to go over and change since time_t is a central piece in Unix vs Windows where it's practically not used anywhere.
Much easier to do there since the OpenBSD project contains all the supported applications so they can simply rebuild it all. Far worse for something like Linux where it's popularity have put it into a situation where it have to support all those third party binaries.
Well since he is both a pragmatist and smart then I suppose that he have nothing at all against systemd, and for those that don't like systemd there are i.e Devuan, Gentoo, Alpine and so on.
Sorry for not being more clear but I meant that as a reply to what you wrote about what to do after first login. Using password on SSH should be something that you do at maximum once per system. Myself I always transfer my public rsa key to a flash drive and put it into any machine that I installs and thus never use a insecure ssh session but I do understand that this is seen as an inconvenience for the majority of users, but using keys instead of passwords after first login will not only make the connection secure, it will also greatly enhance the usability (i.e no more need to input a password on the device).
no the password should be outright disabled and the user should add his public key to.ssh/authorized_keys instead. Using passwords over SSH is just plain stupid.
Travel to the UK and partake in actual terrorist activities and I guarantee you that you will be deported today. What May are after are ways to deport you if they think that you are doing something that they have absolutely no proof of you doing.
So please inform me where I now can purchase all these new shiny SSDs to replace all the 8TB disks that we have in our array cabinets. And that without having to pay more for a single of those new drives than 100 or so of the old ones...
Linux have a far higher market share than 2% on "servers, routers and firewalls" that TFS mentions. And still 2% of the worlds desktop users are still a significant number of people considering just how many desktop users there are out there.
Still an attacker needs access to a account on your samba share with write access because he needs to first upload a library with his payload and then tell samba to execute it.
I've heard that sarcasm on the Internet was impossible and now I have proof that it is so. I really thought that my last line about the retired folks should be the "reveal" but alas no:(
Slashdot Mirror
I guess that the sysv script run pre start tests like checking that lock file and where the ones producting the logs while the systemd unit file for mongodb is just starting mongodb straight up and thus is not getting these particular logs because mongodb does not log about them. Either mongodb should be changed to start logging these things or the systemd unit file should be changed to include those pre start tests that the old sysv script had.
So the problem is not with systemd itself but with the sysv to systemd transition.
"systemctl start" schedules the service to start, it does not start it there and then. You might still not like it but systemd is an event driven system and not a "execute this particular bash shell" type of system, so one cannot use systemctl as a straight drop in replacement for how sysv worked, it works differently.
Note that you had this kind of behaviour in some sysv scripts as well so it was more of a hit and miss in sysv. I.e daemons that could take a very long time to start like say MySQL had init scripts that forked and then sysv would return OK when the actual daemon could very well fail a few second later. So with systemd we actually now have a consistent handling and not the old hit and miss but you have to adopt to the new way for the daemons where sysv happened to be "hit"
Because it's a proven lie? systemd does not swallow log messages, it presents and stores far more logs than sysv did. And the complaint about exit codes are due to either pure lies or people trying to use "systemctl start " as a drop in replacement for "/etc/init.d/ start" which it's not.
That's why I gave up on food. Too much variety to choose from.
I see no critiquing, almost every single anti systemd post on Slashdot for the last years have been crybullying. And the GP in particular was crybullying, nothing more.
I think that it's for users who don't know all those packages to feed to apt and who want to simply install a single meta-package, say "Virtual Observatory" and thus get all the packages included there installed automatically. As I understand it these pure blends is not special versions of Debian either but more working groups that create and maintain these meta-packages that you can install from a vanilla Debian 9.
So go use Devuan? Or is the anti systemd crowd now joining the SWJ, Vegan, Crossfitter crowds where they cannot stand silent for 5 minutes before announcing their special needs and wants to the world?
CMake to me is way more horrible than automake, i.e tried to add a --pkgconfig-dir option to a CMake build for hours until I found out that CMake caches the initial value and always uses the cached value regardless of what you supply to the "cmake ." step. And trying to make cmake work in say an initial mingw32 install is always fun.
Of course it's because I'm way more familiar with automake so it's syntax comes naturally to me. Don't really know why my post was modded as troll though. Must be people who have never tried to make a portable JNI or endian build...
Everyone thinks that automake+autoconf+libtool are horrible so they create their new build tool. Then once their new build tool gets close to having similar functionality that automakte+autoconf+libtool has they often tend to be far more ugly and horrible.
And it does not help that we have braindead things like i.e Java JNI where there is a jni.h file in a well hidden non-standards location with a jni_md.h in a system dependent subfolder (so you might have .../freebsd/jni_md.h or ../win32/jni_md.h and so on).
Or why there might be __BYTE_ORDER__, __BYTE_ORDER or plain BYTEORDER (or due to the infinite wisdom of Microsoft, no such thing at all). Or the good ol boys from OpenSSL that thought that instead of having a define for the presence of an algorithm there should be a define for if the algorithm is supported by the version of OpenSSL but disabled by the configuration. Or why not the flameretarded OpenBSD that decided to hardcoded the OpenSSL version as 2.0 in LibreSSL when they forked the 1.0 API from OpenSSL when OpenSSL then changed some of their API in v1.1 so now you cannot check if version
Not exactly, due to historical reasons some file systems still have 32-bit time stamps even on 64-bit machines. It will of course be fixed long before 2038 but there are still some work left to do.
Microsoft managed to change time_t to 64-bit due to time_t not being widely used in Windows and because shared libraries on Windows rarely exchange time_t values (since that would break if you linked with an old dll that used the 32-bit time_t as you might imagine).
Stance in Linux land regarding the issue is not to go 64-bit or be abandoned, there are plans in motion, it's just that there are a lot of code to go over and change since time_t is a central piece in Unix vs Windows where it's practically not used anywhere.
GNU libc has this plan: https://sourceware.org/glibc/w...
And the plans for the Linux kernel: https://lwn.net/Articles/64323... . Latest update: https://lwn.net/Articles/71707...
Until he found the journalctl command ;)
Good thing it's signed or dates 1970 would be difficult to represent.
Much easier to do there since the OpenBSD project contains all the supported applications so they can simply rebuild it all. Far worse for something like Linux where it's popularity have put it into a situation where it have to support all those third party binaries.
Well since he is both a pragmatist and smart then I suppose that he have nothing at all against systemd, and for those that don't like systemd there are i.e Devuan, Gentoo, Alpine and so on.
Sorry for not being more clear but I meant that as a reply to what you wrote about what to do after first login. Using password on SSH should be something that you do at maximum once per system. Myself I always transfer my public rsa key to a flash drive and put it into any machine that I installs and thus never use a insecure ssh session but I do understand that this is seen as an inconvenience for the majority of users, but using keys instead of passwords after first login will not only make the connection secure, it will also greatly enhance the usability (i.e no more need to input a password on the device).
You do realise that systemd is not part of the Linux kernel where Linus decides what should go in or not?
no the password should be outright disabled and the user should add his public key to .ssh/authorized_keys instead. Using passwords over SSH is just plain stupid.
Travel to the UK and partake in actual terrorist activities and I guarantee you that you will be deported today. What May are after are ways to deport you if they think that you are doing something that they have absolutely no proof of you doing.
If so then you download the executable via SMB to your RAM.
So please inform me where I now can purchase all these new shiny SSDs to replace all the 8TB disks that we have in our array cabinets. And that without having to pay more for a single of those new drives than 100 or so of the old ones...
Found the millenial!
Linux have a far higher market share than 2% on "servers, routers and firewalls" that TFS mentions. And still 2% of the worlds desktop users are still a significant number of people considering just how many desktop users there are out there.
Still an attacker needs access to a account on your samba share with write access because he needs to first upload a library with his payload and then tell samba to execute it.
I've heard that sarcasm on the Internet was impossible and now I have proof that it is so. I really thought that my last line about the retired folks should be the "reveal" but alas no :(