| 1 |
On Fri, Dec 28, 2012 at 2:17 PM, Pandu Poluan <pandu@××××××.info> wrote: |
| 2 |
> |
| 3 |
> On Dec 29, 2012 2:18 AM, "Canek Peláez Valdés" <caneko@×××××.com> wrote: |
| 4 |
>> |
| 5 |
>> Stop thinking in sshd. I can write the *whole* daemon in shell, not in |
| 6 |
>> another script file, but inside /etc/init.d/mystupiddaemon (or |
| 7 |
>> /etc/rc.whatever); shell is Turing-complete, I can write in it |
| 8 |
>> anything I can write in C (or in assembler, or machine code). In that |
| 9 |
>> sense, the init system (which uses shell for launching daemons) can be |
| 10 |
>> used to determine *how* the daemon behaves (because it uses shell for |
| 11 |
>> launching daemons). |
| 12 |
>> |
| 13 |
>> You can't do that with systemd; there is a clear and unavoidable |
| 14 |
>> separation between the starting/stoping/monitoring of daemons, and the |
| 15 |
>> daemons themselves. Such distinction doesn't really exists in SysV nor |
| 16 |
>> OpenRC (since they use shell, a Turing-complete language, for |
| 17 |
>> launching daemons), and therefore you can mixup everything. I agree, |
| 18 |
>> it doesn't necessarily means that it *will* happen; but even the |
| 19 |
>> possibility is frigthning for a system administrator in a production |
| 20 |
>> server. |
| 21 |
> |
| 22 |
> You got it wrong. |
| 23 |
|
| 24 |
I don't believe so. |
| 25 |
|
| 26 |
> SysAdmins, especially Enterprise SysAdmins, will prefer total control of the |
| 27 |
> startup process. If a daemon is extremely important for enterprise |
| 28 |
> operation, any SysAdmin worth his/her salary will fire up vi (or emacs) and |
| 29 |
> pepper the code with asserts and instrumentation. |
| 30 |
|
| 31 |
Pandou, I have worked as SysAdmin. Several years. "Total control" has |
| 32 |
degrees; if you program in assembly language, you have even more |
| 33 |
control. And with systemd you can still fire up vi or Emacs (or, if |
| 34 |
you prefer "total control", ed), and fix *your* daemon. If systemd has |
| 35 |
a bug, you can still look at the code, and fix *that* code. What you |
| 36 |
say doesn't make any sense: "any SysAdmin worth his/her salary will |
| 37 |
fire up vi (or emacs) and pepper the code with asserts and |
| 38 |
instrumentation" works in SysV, OpenRC, systemd, and anything else as |
| 39 |
long as you have the source code. The only problem resides in |
| 40 |
proprietary code. |
| 41 |
|
| 42 |
> Having a Turing-complete language for starting a script is one of our (= |
| 43 |
> Enterprise SysAdmins) weapon for fixing up glitches due to some changes |
| 44 |
> introduced by the package maintainer. |
| 45 |
|
| 46 |
Again, you make no sense: you can fix "glitches" as long as you have |
| 47 |
the source code. You can roll your own packages (I maintain my overlay |
| 48 |
to get rid of OpenRC on my systems). That some SysAdmins can *only* |
| 49 |
code properly (if at all) in shell is a problem of *those* SysAdmins. |
| 50 |
A worthy SysAdmin, if encountering a bug with systemd, can easily |
| 51 |
check out the C code and fix it (it's relatively simple, not |
| 52 |
kernel-level). |
| 53 |
|
| 54 |
And having a separation between the starting/stoping of daemons and |
| 55 |
the daemons themselves makes it easier to check where the bug lies, |
| 56 |
and fixing accordingly, instead of patching blindly to workaround the |
| 57 |
real problem. |
| 58 |
|
| 59 |
> An example: A dev needs a newer version of a package. We upgrade it. It |
| 60 |
> refuses to startup properly, but going back is out of the question because |
| 61 |
> the dev *needs* the features only available in the new version. We check the |
| 62 |
> (extremely) detailed logs. We find out what made the package balked. We do |
| 63 |
> some changes, and all is well. |
| 64 |
|
| 65 |
How that is not possible in systemd? |
| 66 |
|
| 67 |
> Another example: After a security audit, we are required to upgrade a |
| 68 |
> certain daemon to a new version, despite the current version running well. |
| 69 |
> As we feared, the new version can't start. We use the detailed log to find |
| 70 |
> out what happened. We made changes. It works again. |
| 71 |
|
| 72 |
How that is not possible in systemd? Have you ever used it? |
| 73 |
|
| 74 |
> In the two examples I give, having a C program doing all the starting will |
| 75 |
> certainly mean that complex things have to be done, not to mention the |
| 76 |
> headache of compiling them -- and possibly fail. |
| 77 |
|
| 78 |
You are assuming the problem is going to be in systemd's side. First |
| 79 |
of all, that will not always be the case. Second, if it is the case, |
| 80 |
you go and fix it. You still have the code. |
| 81 |
|
| 82 |
SysAdmin's laziness is not an excuse to do things wrong. It's also |
| 83 |
"more complex" to add comments to the code, it's "more complex" to |
| 84 |
take notes of the procedures rolling servers, it's "more complex" to |
| 85 |
keep a database of the versions running in each machine, and what |
| 86 |
hardware has and when it was installed. It's always "more complex" to |
| 87 |
properly do the job. |
| 88 |
|
| 89 |
> sh scripts are much easier to modify. |
| 90 |
|
| 91 |
Read above. |
| 92 |
|
| 93 |
>> Like the clear separation between content and presentation in webapps, |
| 94 |
>> or between the model and the view in the MVC design patter, having a |
| 95 |
>> clear separation between how you start/stop/monitor your daemon, and |
| 96 |
>> what the daemon does, is a good thing. |
| 97 |
> |
| 98 |
> That is the Theory. In Practice, things don't work that way. Murphy's Law |
| 99 |
> reigns supreme. |
| 100 |
|
| 101 |
Then we should agree to disagree in this particular issue. |
| 102 |
|
| 103 |
Regards. |
| 104 |
-- |
| 105 |
Canek Peláez Valdés |
| 106 |
Posgrado en Ciencia e Ingeniería de la Computación |
| 107 |
Universidad Nacional Autónoma de México |
Archives