| 1 |
On Dec 29, 2012 2:18 AM, "Canek Peláez Valdés" <caneko@×××××.com> wrote: |
| 2 |
> |
| 3 |
> Stop thinking in sshd. I can write the *whole* daemon in shell, not in |
| 4 |
> another script file, but inside /etc/init.d/mystupiddaemon (or |
| 5 |
> /etc/rc.whatever); shell is Turing-complete, I can write in it |
| 6 |
> anything I can write in C (or in assembler, or machine code). In that |
| 7 |
> sense, the init system (which uses shell for launching daemons) can be |
| 8 |
> used to determine *how* the daemon behaves (because it uses shell for |
| 9 |
> launching daemons). |
| 10 |
> |
| 11 |
> You can't do that with systemd; there is a clear and unavoidable |
| 12 |
> separation between the starting/stoping/monitoring of daemons, and the |
| 13 |
> daemons themselves. Such distinction doesn't really exists in SysV nor |
| 14 |
> OpenRC (since they use shell, a Turing-complete language, for |
| 15 |
> launching daemons), and therefore you can mixup everything. I agree, |
| 16 |
> it doesn't necessarily means that it *will* happen; but even the |
| 17 |
> possibility is frigthning for a system administrator in a production |
| 18 |
> server. |
| 19 |
|
| 20 |
You got it wrong. |
| 21 |
|
| 22 |
SysAdmins, especially Enterprise SysAdmins, will prefer total control of |
| 23 |
the startup process. If a daemon is extremely important for enterprise |
| 24 |
operation, any SysAdmin worth his/her salary will fire up vi (or emacs) and |
| 25 |
pepper the code with asserts and instrumentation. |
| 26 |
|
| 27 |
Having a Turing-complete language for starting a script is one of our (= |
| 28 |
Enterprise SysAdmins) weapon for fixing up glitches due to some changes |
| 29 |
introduced by the package maintainer. |
| 30 |
|
| 31 |
An example: A dev needs a newer version of a package. We upgrade it. It |
| 32 |
refuses to startup properly, but going back is out of the question because |
| 33 |
the dev *needs* the features only available in the new version. We check |
| 34 |
the (extremely) detailed logs. We find out what made the package balked. We |
| 35 |
do some changes, and all is well. |
| 36 |
|
| 37 |
Another example: After a security audit, we are required to upgrade a |
| 38 |
certain daemon to a new version, despite the current version running well. |
| 39 |
As we feared, the new version can't start. We use the detailed log to find |
| 40 |
out what happened. We made changes. It works again. |
| 41 |
|
| 42 |
In the two examples I give, having a C program doing all the starting will |
| 43 |
certainly mean that complex things have to be done, not to mention the |
| 44 |
headache of compiling them -- and possibly fail. |
| 45 |
|
| 46 |
sh scripts are much easier to modify. |
| 47 |
|
| 48 |
> Like the clear separation between content and presentation in webapps, |
| 49 |
> or between the model and the view in the MVC design patter, having a |
| 50 |
> clear separation between how you start/stop/monitor your daemon, and |
| 51 |
> what the daemon does, is a good thing. |
| 52 |
|
| 53 |
That is the Theory. In Practice, things don't work that way. Murphy's Law |
| 54 |
reigns supreme. |
| 55 |
|
| 56 |
Rgds, |
| 57 |
-- |
Archives