A big ol ball? My init.d was about 13 scripts big which were readable and editable. Ever tried to edit systemd files? Depending on systemd version you have to create overrides, modify symlinks or edit systemd files straight up which can be in about 5 different locations and on top of that, systemd can have overrides on any changes either with an update or just inherited.
Systemd makes every system into a dependency mess.
Remove/fail a hard drive and your system will boot into single user mode, not even remote
So the short answer is: Yes, systemd makes things unnecessarily complex with little benefit.
That matches my experience - losing a lot of time trying to figure out why things don't work. The improved boot time is lost several times over.
I completely agree. Troubleshooting is really a bitch with systemd, much more time-consuming. For instance, often systemctl reports a daemon as failed while it's not, or suddenly decides that it didn't start because of some mysterious arbitrary timeout while the daemon just needs some time to run a maintenance tasks at startup time. And getting anything of value out of the log is a pain in the ass.
Quite often I end up writing control shell scripts specifically to be called by systemd, because this junkware
Troubleshooting is really a bitch with systemd, much more time-consuming. For instance, often systemctl reports a daemon as failed while it's not, or suddenly decides that it didn't start because of some mysterious arbitrary timeout while the daemon just needs some time to run a maintenance tasks at startup time.
Not to mention that the damn logs are not plain text, which in itself complicates things before you even have the chance to start troubleshooting.
Maybe his point is that it's better if you can choose any of 1000+ text editors and tools that suit you best instead of being forced to use on buggy tool? Makes perfect sense to me.
The point being that text format is more universally readable, and also should it get corrupted, it has a better shot of still being readable.
On the other hand, pure binary logging was not necessary to achieve what they wanted. In fact, strictly speaking a split format of fixed-size, well aligned binary metadata alongside a text record of the variable length data would have been even *better* performance and still be readable.
Granted, I have never needed any kind of tampering or corruption mitigation in my log files over the last 20 years of Linux administration. So the value for at least my usage of journalctl has been sum negative because I don't see the value in a command that by default truncates log output.
So the answer for systemd is to workaround it by using a "legacy" service to restore decades of functionality.
SMF was the death knell for Solaris (along with the Oracle purchase), and it feels like systemd is going to be the anchor which drags Linux into the abyss.
I'd say it is worse having to type something different for one log on the system, when the other 100+ are plain text and so accessible with the old tools we've all learned backwards. It means you don't have the necessary switches or key presses to hand because you don't do it often enough.
"journalctl" might be the best thing since sliced bread, but making it a hard requirement of systemd makes adoption of systemd that much harder. IMHO, systemd should "pick it's battles" and concentrate on managing system p
This is one of the things that frustrates me, they didn't need to make it a binary format to acheive those ends. It's not like text records cannot accommodate such feats. It's also not as if you must embed the binary and text data in the same file to acheive performance gains (I maintain that segregating the data would have made for even faster indexing).
Remind me again how useful journalctl and binary logs are when you can't remember the exact name of the unit? "tail -f/var/log/messages | grep dhcp" is a lot easier to remember than "journactl -f -u isc-dhcp-server" - and hopefully you ARE running isc-dhcp-server, because if it's a different server you're SOL.
Remind me again how useful journalctl and binary logs are when the only things that run on a system are "echo" and maybe "/bin/cat" if you're lucky?
And yes, I've had that happen. Problems with the i
I suggest if you're struggling to remember a command (you are an administrator right?) that you simply make an alias. Or do the other things I suggested. Make systemd dump out a text file if you are absolutely incapable of learning a new command.
Remind me again how useful journalctl and binary logs are when you can't remember the exact name of the unit? "tail -f/var/log/messages | grep dhcp" is a lot easier to remember than "journactl -f -u isc-dhcp-server" - and hopefully you ARE running isc-dhcp-server, because if it's a different server you're SOL.
'systemctl status dhcpd' shows me the logs I need to see 95% of the time.
If you don't know what the service name is, or just want to see recent logs or failures, try journalctl -b|tail or journalctl -x.
It really isn't that hard to run journaltcl --help, but these days it seems no-one on slashdot is able to do that, they are only able to use commands that existed in the previous century...
Wrong. The journal is easier to search since you can pass time ranges and other filters to journalctl and get back only those events
It's been possible to do that with insanely sophisticated tools such as "grep" for 30+ years.
And anyways, we pay a shitload of moneys to Splunk so we can a lot more than that on basic log files (pie charts, trends, etc); the systemd journal just makes it more difficult to have the same splunk rules.
One more instance of systemd trying to do everything and doing it wrong.
Using text processing skills to process a generic text file isn't any harder than using journalctl. The difference is that the former is generically applicable to just about any other software on the planet, and the latter is for journald. It's not that complex to confer the journalctl benefits without ditching *native* text log capability, but they refuse to do so.
Using ForwardToSyslog just means there's an unnecessary middle-man, meaning both services must be functional to complete logging. The problem is the time when you actually want logs is the time when there's something going wrong. A few weeks ago was trying to support someone who did something pretty catastrophic to his system. One of the side effects was that it broke the syslog forwarding (syslog would still work, but nothing from journald would get to it). The other thing that happened would be for the system to lock out all access. I thought 'ok, I'll reboot and use jornalctl', but wait, on CentOS 7, journald defaults to not persisting journald across boot, because you have syslog to do that.
Of course the other problem (not entirely systemd project fault) was the quest to 'simplify' console output so he just saw 'fail' instead of the much more useful error messages that would formerly spam the console on experiencing the sort of problem he hit (because it would be terrible to have an 'ugly' console...). This hints about another source of the systemd controversy, that it's also symbolic of a lot of other design choices that have come out of the distros.
On your last point, that's REALLY BAD! When there is a catastrophic failure of some part of one of my systems, I want lights and sirens and a flashing sign pointing at the problem, not just "fail" printed out on a screen I might not even be looking at!
But, of course, we're handing the world over to a generation that believe that only the things they want to matter actually matter and, if they can minimize their interaction with things they don't like, those things cease to exist. By that logic, hiding the
The road to ruin is always in good repair, and the travellers pay the
expense of it.
-- Josh Billings
Ah yes the secret to simplicity (Score:0, Flamebait)
Ah yes, a big ol' ball of gaffer tape and bash scripts. The cure to complexity.
I'm still yet to have someone give me a legitimately non hysterical reason why "systemd bad" other than "its different"
Re: Ah yes the secret to simplicity (Score:5, Insightful)
A big ol ball? My init.d was about 13 scripts big which were readable and editable. Ever tried to edit systemd files? Depending on systemd version you have to create overrides, modify symlinks or edit systemd files straight up which can be in about 5 different locations and on top of that, systemd can have overrides on any changes either with an update or just inherited.
Systemd makes every system into a dependency mess.
Remove/fail a hard drive and your system will boot into single user mode, not even remote
Re: Ah yes the secret to simplicity (Score:5, Insightful)
So the short answer is: Yes, systemd makes things unnecessarily complex with little benefit.
That matches my experience - losing a lot of time trying to figure out why things don't work. The improved boot time is lost several times over.
Re: (Score:5, Informative)
So the short answer is: Yes, systemd makes things unnecessarily complex with little benefit.
That matches my experience - losing a lot of time trying to figure out why things don't work. The improved boot time is lost several times over.
I completely agree. Troubleshooting is really a bitch with systemd, much more time-consuming. For instance, often systemctl reports a daemon as failed while it's not, or suddenly decides that it didn't start because of some mysterious arbitrary timeout while the daemon just needs some time to run a maintenance tasks at startup time. And getting anything of value out of the log is a pain in the ass.
Quite often I end up writing control shell scripts specifically to be called by systemd, because this junkware
Re: Ah yes the secret to simplicity (Score:5, Informative)
Troubleshooting is really a bitch with systemd, much more time-consuming. For instance, often systemctl reports a daemon as failed while it's not, or suddenly decides that it didn't start because of some mysterious arbitrary timeout while the daemon just needs some time to run a maintenance tasks at startup time.
Not to mention that the damn logs are not plain text, which in itself complicates things before you even have the chance to start troubleshooting.
Re: (Score:1)
Maybe his point is that it's better if you can choose any of 1000+ text editors and tools that suit you best instead of being forced to use on buggy tool? Makes perfect sense to me.
Re: (Score:3)
The point being that text format is more universally readable, and also should it get corrupted, it has a better shot of still being readable.
On the other hand, pure binary logging was not necessary to achieve what they wanted. In fact, strictly speaking a split format of fixed-size, well aligned binary metadata alongside a text record of the variable length data would have been even *better* performance and still be readable.
Re: Ah yes the secret to simplicity (Score:5, Insightful)
Granted, I have never needed any kind of tampering or corruption mitigation in my log files over the last 20 years of Linux administration. So the value for at least my usage of journalctl has been sum negative because I don't see the value in a command that by default truncates log output.
So the answer for systemd is to workaround it by using a "legacy" service to restore decades of functionality.
SMF was the death knell for Solaris (along with the Oracle purchase), and it feels like systemd is going to be the anchor which drags Linux into the abyss.
Re: (Score:2)
Granted, I have never needed any kind of tampering or corruption mitigation in my log files over the last 20 years of Linux administration.
You *think* so, but how can you know for sure?
Re: (Score:3)
I'd say it is worse having to type something different for one log on the system, when the other 100+ are plain text and so accessible with the old tools we've all learned backwards. It means you don't have the necessary switches or key presses to hand because you don't do it often enough.
"journalctl" might be the best thing since sliced bread, but making it a hard requirement of systemd makes adoption of systemd that much harder. IMHO, systemd should "pick it's battles" and concentrate on managing system p
Re: (Score:2)
Re: (Score:2)
This is one of the things that frustrates me, they didn't need to make it a binary format to acheive those ends. It's not like text records cannot accommodate such feats. It's also not as if you must embed the binary and text data in the same file to acheive performance gains (I maintain that segregating the data would have made for even faster indexing).
Re: (Score:2, Insightful)
Remind me again how useful journalctl and binary logs are when you can't remember the exact name of the unit? "tail -f /var/log/messages | grep dhcp" is a lot easier to remember than "journactl -f -u isc-dhcp-server" - and hopefully you ARE running isc-dhcp-server, because if it's a different server you're SOL.
Remind me again how useful journalctl and binary logs are when the only things that run on a system are "echo" and maybe "/bin/cat" if you're lucky?
And yes, I've had that happen. Problems with the i
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Is this even supposed to be a serious argument?
Considering that the flags were "-f -u", I'm thinking you're the only one who needs that question answered. No, it was not.
Re: (Score:2)
Re: (Score:2)
Remind me again how useful journalctl and binary logs are when you can't remember the exact name of the unit? "tail -f /var/log/messages | grep dhcp" is a lot easier to remember than "journactl -f -u isc-dhcp-server" - and hopefully you ARE running isc-dhcp-server, because if it's a different server you're SOL.
'systemctl status dhcpd' shows me the logs I need to see 95% of the time.
If you don't know what the service name is, or just want to see recent logs or failures, try journalctl -b|tail or journalctl -x.
It really isn't that hard to run journaltcl --help, but these days it seems no-one on slashdot is able to do that, they are only able to use commands that existed in the previous century ...
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Wrong. The journal is easier to search since you can pass time ranges and other filters to journalctl and get back only those events
It's been possible to do that with insanely sophisticated tools such as "grep" for 30+ years.
And anyways, we pay a shitload of moneys to Splunk so we can a lot more than that on basic log files (pie charts, trends, etc); the systemd journal just makes it more difficult to have the same splunk rules.
One more instance of systemd trying to do everything and doing it wrong.
Re: Ah yes the secret to simplicity (Score:5, Insightful)
Using text processing skills to process a generic text file isn't any harder than using journalctl. The difference is that the former is generically applicable to just about any other software on the planet, and the latter is for journald. It's not that complex to confer the journalctl benefits without ditching *native* text log capability, but they refuse to do so.
Using ForwardToSyslog just means there's an unnecessary middle-man, meaning both services must be functional to complete logging. The problem is the time when you actually want logs is the time when there's something going wrong. A few weeks ago was trying to support someone who did something pretty catastrophic to his system. One of the side effects was that it broke the syslog forwarding (syslog would still work, but nothing from journald would get to it). The other thing that happened would be for the system to lock out all access. I thought 'ok, I'll reboot and use jornalctl', but wait, on CentOS 7, journald defaults to not persisting journald across boot, because you have syslog to do that.
Of course the other problem (not entirely systemd project fault) was the quest to 'simplify' console output so he just saw 'fail' instead of the much more useful error messages that would formerly spam the console on experiencing the sort of problem he hit (because it would be terrible to have an 'ugly' console...). This hints about another source of the systemd controversy, that it's also symbolic of a lot of other design choices that have come out of the distros.
Re: (Score:2)
But, of course, we're handing the world over to a generation that believe that only the things they want to matter actually matter and, if they can minimize their interaction with things they don't like, those things cease to exist. By that logic, hiding the