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 is too fragile and capricious to work with actual daemons. That says a lot about the overal usefulness of systemd.
Nothing has been gained with systemd, at least not on servers.
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
Yep, Redhat must have gotten millions in support sales, thanks to systemd. What else would be better way to increase support sales than a constantly changing and spreading ameba, which nobody else than few developers know?
No, really, it happens. Especially when there are a lot of events being logged; some condition exists within journald's code that causes it to just drop messages if it can't keep up. It's like they've never heard of buffers or, at least, just learned of them and aren't quite sure how to properly implement them.
I'd fix it, but then I'd have my name on systemd and that would be worse than dealing with spotty logs.
Why does it throttle in the first place? I can see an argument for collapsing (e.g. "Some-logged-message [100]" to denote that "Some-logged-message" was logged 100 times), but if I have 100 unique messages, they need to all be in the log. Period.
It throttles for the same reason rsyslogd (for example) throttles -- to avoid overloading the system.
The throttling is done per service, so what did you lose when some process decided to log more than 1000 messages in a 30 second period (the default).
Personally I can see a couple of ways to fix things a bit -- it should be possible to set per service throttling parameters and throttling should take message priority into account.
(By the way -- the rsyslogd throttling might not even work -- syslog is usually
A lot of events? I'm talking about one or two lines only! When you run the process by hand, it clearly outputs an error message either to stdout or stderr, but when starting it with systemctl, there is no output and nothing is logged in the journal. That's a major problem for troubleshooting. Yes, you can revert to starting things by hand, but sometimes that's hard to figure-out all of the commandline options and environment needed to do so.
And this attitude is why things don't get fixed with systemd. I've seen multiple good reproduction steps that demonstrate this problem over the past few years, and it's still broken. It sucks when you can start something at the command line and see a few lines of output that show the exact problem, but when using "systemctl start [service-name]" nothing is saved in the journal.
I've seen multiple good reproduction steps that demonstrate this problem over the past few years, and it's still broken.
I've seen them too. And in every case they are fixed by fixing the broken scripts or configuration files that cause them. I've never seen one that was caused by a bug in systemd.
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.
So you didn't RTFM or your distro maintainer didn't set the option in the unit file correctly?
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.
So you didn't RTFM or your distro maintainer didn't set the option in the unit file correctly?
The distro maintainer is the company that created systemd. Thanks for playing.
I'm inclined to agree, BUT... I actually quite like system unit (files). It's a great way to daemonise a very simple program (perhaps one you got handed by your devs who know nothing about sysadmin, or perhaps some crap downloaded from the Internet because someone thought it would be useful). Getting simple stuff to work with systemd is actually super-easy. All those symlinks are really just enable/disable, although I'd love to see the actual files in some obvious directory - I'm not sure how much of that i
Whatever form of logging there is, systemd makes debugging really hard. It doesn't seem to suck up STDOUT/STDERR when you really need it to, it doesn't seem to tell you the command it ran that it thought had failed when you want it to, it doesn't give you the response code, it doesn't tell you why it considered it failed,
Crap.
Every single one of these assertions is purest bollocks.
although I'd love to see the actual files in some obvious directory
> man systemd.unit
In the section titled "Unit File Load Path": Table 1. Load path when running in system mode (--system). Path Description/etc/systemd/system Local configuration/run/systemd/system Runtime units/usr/lib/systemd/system Units of installed packages
Trying to have half a dozen 'linked' systemd units to fire up a half dozen daemons in the right order is really really horrible.
This is because you are applying SysVInit thinking to systemd and expecting them to work equivalently. With systemd, you don't specify an "order" to start services. You declare dependencies and let systemd handle the ordering.
Trying to make an old init.d script work in systemd is a world of pain.
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.
If you don't write your systemd unit files correctly, you can't blame systemd.
systemd makes it much more likely that nearly everyone will do it wrong.
You won't do it wrong if you know how systemd works. You'll know how systemd works if you read the documentation. If you treat a systemd unit file as another kind of init script, it won't work correctly. If you recognize, from reading the documentation, that a unit file is NOT an init script and has a different way of managing the boot process, you won't have any problems with it. It's that simple.
The problem is there are a lot of old init scripts that have to be properly migrated and distro maintainers are
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,
Then there is a problem with the service unit file. A common one is not setting the correct Type= value
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.
Then the service unit file should have a suitable TimeoutStartSec= [freedesktop.org] specified.
Of course, I have seen this in sysvinit scripts, and there if you had a service that would never start, you had to reboot and disable services to try and boot far enough to find out what was wrong with that service, and if you wanted to add timeouts, you had to make lots of changes to the init script, only to risk having it overwr
The "improved" boot time is lost to me on every reboot, as it takes up to several minutes, once at a login: prompt, to, you know, login. Like it just sits there waiting a random amount of time before completing and giving me a shell prompt.
SystemD generates Windows style "faster booting". You get to a boot prompt faster but the system is still sorting itself out. So it's all an illusion. They system isn't really ready yet. It's not useful. It's basically a sham.
You are also very likely to get things out of order so things will be broken with fairly trivial setups.
Again, if your system is more likely to get broken either by the vendors or the end users then your design failed.
Yes extra complexity for no real benefit... Debugging becomes more difficult, other things become impractical (in emergencies i've mounted a complete system drive on another host, gone into it with chroot and started services to recover data or run as a temporary measure etc).
Boot time isn't important on a server, servers are typically stable and with reliable power sources so they don't reboot except at scheduled maintenance times, and there are even ways to live patch servers to avoid reboots while keepin
I don't find faster boot time to be terribly useful for a media appliance. Although SystemD seems to make automatically starting a Linux machine as an appliance a much less reliable thing.
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: Ah yes the secret to simplicity (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 is too fragile and capricious to work with actual daemons. That says a lot about the overal usefulness of systemd.
Nothing has been gained with systemd, at least not on servers.
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
Re: (Score:1)
Yep, Redhat must have gotten millions in support sales, thanks to systemd. What else would be better way to increase support sales than a constantly changing and spreading ameba, which nobody else than few developers know?
Re: (Score:1)
> Troubleshooting is really a bitch with systemd
And also because of dropped log messages. Not everything ends-up in the journal.
Re: (Score:2)
I'd fix it, but then I'd have my name on systemd and that would be worse than dealing with spotty logs.
Re: (Score:1)
Especially when there are a lot of events being logged;
So what do you have your journald throttling options set at?
Re: (Score:2)
Re: (Score:1)
It throttles for the same reason rsyslogd (for example) throttles -- to avoid overloading the system.
The throttling is done per service, so what did you lose when some process decided to log more than 1000 messages in a 30 second period (the default).
Personally I can see a couple of ways to fix things a bit -- it should be possible to set per service throttling parameters and throttling should take message priority into account.
(By the way -- the rsyslogd throttling might not even work -- syslog is usually
Re: (Score:1)
A lot of events? I'm talking about one or two lines only! When you run the process by hand, it clearly outputs an error message either to stdout or stderr, but when starting it with systemctl, there is no output and nothing is logged in the journal. That's a major problem for troubleshooting. Yes, you can revert to starting things by hand, but sometimes that's hard to figure-out all of the commandline options and environment needed to do so.
Re: (Score:1)
And this attitude is why things don't get fixed with systemd. I've seen multiple good reproduction steps that demonstrate this problem over the past few years, and it's still broken. It sucks when you can start something at the command line and see a few lines of output that show the exact problem, but when using "systemctl start [service-name]" nothing is saved in the journal.
Re: (Score:1)
I've seen multiple good reproduction steps that demonstrate this problem over the past few years, and it's still broken.
I've seen them too. And in every case they are fixed by fixing the broken scripts or configuration files that cause them. I've never seen one that was caused by a bug in systemd.
Re: (Score:2)
Re: (Score:2)
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.
So you didn't RTFM or your distro maintainer didn't set the option in the unit file correctly?
Re: (Score:2)
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.
So you didn't RTFM or your distro maintainer didn't set the option in the unit file correctly?
The distro maintainer is the company that created systemd. Thanks for playing.
Re: (Score:3)
I'm inclined to agree, BUT... I actually quite like system unit (files). It's a great way to daemonise a very simple program (perhaps one you got handed by your devs who know nothing about sysadmin, or perhaps some crap downloaded from the Internet because someone thought it would be useful). Getting simple stuff to work with systemd is actually super-easy. All those symlinks are really just enable/disable, although I'd love to see the actual files in some obvious directory - I'm not sure how much of that i
Re: (Score:1)
Whatever form of logging there is, systemd makes debugging really hard. It doesn't seem to suck up STDOUT/STDERR when you really need it to, it doesn't seem to tell you the command it ran that it thought had failed when you want it to, it doesn't give you the response code, it doesn't tell you why it considered it failed,
Crap.
Every single one of these assertions is purest bollocks.
Re: (Score:2)
although I'd love to see the actual files in some obvious directory
> man systemd.unit
In the section titled "Unit File Load Path": /etc/systemd/system Local configuration /run/systemd/system Runtime units /usr/lib/systemd/system Units of installed packages
Table 1. Load path when running in system mode (--system).
Path Description
Trying to have half a dozen 'linked' systemd units to fire up a half dozen daemons in the right order is really really horrible.
This is because you are applying SysVInit thinking to systemd and expecting them to work equivalently. With systemd, you don't specify an "order" to start services. You declare dependencies and let systemd handle the ordering.
Trying to make an old init.d script work in systemd is a world of pain.
That rea
Re: (Score:2)
It does all of those things. You just need to learn how to use the tools. For starters try,
> journalctl -b -u -o verbose
Please point out the improvement over "cat".
Re: (Score:2)
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.
If you don't write your systemd unit files correctly, you can't blame systemd.
Re: (Score:2)
> If you don't write your systemd unit files correctly, you can't blame systemd.
Sure you can.
systemd makes it much more likely that nearly everyone will do it wrong.
That's an artifact of piss poor system design.
Re: (Score:2)
systemd makes it much more likely that nearly everyone will do it wrong.
You won't do it wrong if you know how systemd works. You'll know how systemd works if you read the documentation. If you treat a systemd unit file as another kind of init script, it won't work correctly. If you recognize, from reading the documentation, that a unit file is NOT an init script and has a different way of managing the boot process, you won't have any problems with it. It's that simple.
The problem is there are a lot of old init scripts that have to be properly migrated and distro maintainers are
make-work (Score:2)
The problem is there are a lot of old init scripts that have to be properly migrated
Why? They were not broken. They worked perfectly well since before the idiot who created systemd was born.
Re: (Score:2)
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,
Then there is a problem with the service unit file. A common one is not setting the correct Type= value
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.
Then the service unit file should have a suitable TimeoutStartSec= [freedesktop.org] specified.
Of course, I have seen this in sysvinit scripts, and there if you had a service that would never start, you had to reboot and disable services to try and boot far enough to find out what was wrong with that service, and if you wanted to add timeouts, you had to make lots of changes to the init script, only to risk having it overwr
Re: (Score:2)
The "improved" boot time is lost to me on every reboot, as it takes up to several minutes, once at a login: prompt, to, you know, login. Like it just sits there waiting a random amount of time before completing and giving me a shell prompt.
Re: (Score:2)
Re: (Score:2)
SystemD generates Windows style "faster booting". You get to a boot prompt faster but the system is still sorting itself out. So it's all an illusion. They system isn't really ready yet. It's not useful. It's basically a sham.
You are also very likely to get things out of order so things will be broken with fairly trivial setups.
Again, if your system is more likely to get broken either by the vendors or the end users then your design failed.
Re: (Score:2)
Re: (Score:2)
Yes extra complexity for no real benefit... Debugging becomes more difficult, other things become impractical (in emergencies i've mounted a complete system drive on another host, gone into it with chroot and started services to recover data or run as a temporary measure etc).
Boot time isn't important on a server, servers are typically stable and with reliable power sources so they don't reboot except at scheduled maintenance times, and there are even ways to live patch servers to avoid reboots while keepin
Re: (Score:2)
I don't find faster boot time to be terribly useful for a media appliance. Although SystemD seems to make automatically starting a Linux machine as an appliance a much less reliable thing.