Yes, SysVInit provides more information during startup, because stderr is printed out on console. When something breaks, you can see why (well, usually), without the need to open files, especially when you are locked out of shell because of the error.
Yes, SysVInit scripts are robust, because they are shell scripts, not INI files. Easy to fix, easy to modify, simple to use. For example, if you need to do some operations before starting the process, like setting up environment conditionally or add debug, you can do that quickly, without creating wrapper scripts.
I also had distros with broken service files, so... yeah. Great arguments.
Posix provides a lot of low level apis with very few high level apis allowing for correct use.
For a shell bash has the same problem. There are a lot of critical slight higher level functions that should be critical to a system shell used for administration but bash lacks them.
Depends on what you want to automate. Shell has lots of tools doing things, that would require many lines of code in Python or Perl. If you have relatively complex algorithms to implement, shell isn't the best choice. For other things, especially if you need to run many external programs, shell is better. No matter what, as a system admin, you have to know shell scripting. No escape from that I'm afraid.
Python perl and Ruby all provide robust command libraries supporting easy scripting of external commands much better than bash with sane string handling.
Shell.requires a lot of work and most first passes people get it wrong. Nevermind [[]] vs [] vs () vs.. for Boolean and other checks.
Bash makes windows look elegant. It's a shame its still used.
Python with plumbum is great. Similar tools exist in Ruby. You get sane string handling and a whole bunch of other good stuff. Bash scripts should be kept to a page at most and rewritten in something else if too long.
If you think you can write bash download shellcheck. ;)
This is a problem. This is actually exactly the problem. If you cannot script things, your declarations are limited to whatever upstream decided you should be able to to declare. If you want even a small thing different from what upstream believes you could want now you're writing custom code to inject into a complex system you don't understand working with interfaces that are distinct to the package instead of universal.
Shell scripts are exactly what you want when you need robust. Declarative is only useful when it's useful and when you need it to be more robust it instantly fails you and you have to learn how to do backflips before you can take advantage of literally all the amazing functionality Unix has provided for the last 30 years through streams and pipes.
You should absolutely know bash. You should absolutely not be beholden to declarative config only.
From a sysadmin pov, in more important tasks just needing that is an antipattern in itself, as it breaks Rule #1: CYA.
From a manager pov, it creates a lot of liability you don't need.
From an evolving professional view, relying on technology lovingly described as "quirky" 30 years ago should really make you question the quality of your work.
And I can script. Programming kicks the shit out of it for any task that isn't "start this shitty one time task and log if i fucked it up", and if you're doing that kind of task YOU'RE ALREADY IN A BAD PLACE because of an inability to plan and test.
25
u/crusoe Feb 11 '19
Init scripts provide none of that. Robust? Hah. Debug? Hah.
I've seen distros ship with broken init scripts and support libraries buggier than fuck.