On Sat, Dec 29, 2012 at 4:17 AM, Pandu Poluan <pa...@poluan.info> wrote: > An example: A dev needs a newer version of a package. We upgrade it. It > refuses to startup properly, but going back is out of the question because > the dev *needs* the features only available in the new version. We check the > (extremely) detailed logs. We find out what made the package balked. We do > some changes, and all is well. > > Another example: After a security audit, we are required to upgrade a > certain daemon to a new version, despite the current version running well. > As we feared, the new version can't start. We use the detailed log to find > out what happened. We made changes. It works again. > > In the two examples I give, having a C program doing all the starting will > certainly mean that complex things have to be done, not to mention the > headache of compiling them -- and possibly fail.
You obviously haven't the slightest _clue_ what the hell you're talking about. 1) systemd does not prevent you from checking logs. If anything the systemd journal gives you more fine-grained tools for ensuring that some logs came from some daemon, not so easy to ensure when your log file is being peppered with auth attempts and whatnot. 2) the "make some changes" part you mentioned has little, if anything, to do with the init script that started it. "Any Enterprise SysAdmin worth his salt", to use your term, knows it's 99% something he overlooked in the config settings that are independent of the startup system. 3) "Having a C program doing all the starting" doesn't imply complex things have to be done, because in most cases your startup script - whatever it's written in - simply calls the program with the right arguments. Ironically, shell scripts only appear simpler because _someone has already done the complex things for you_. -- This email is: [ ] actionable [ ] fyi [x] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate [ ] soon [x] none
