| 1 |
On Fri, Dec 28, 2012 at 12:53 PM, Kevin Chadwick <ma1l1ists@××××××××.uk> wrote: |
| 2 |
> On Thu, 27 Dec 2012 17:38:15 -0600 |
| 3 |
> Canek Peláez Valdés <caneko@×××××.com> wrote: |
| 4 |
> |
| 5 |
>> In SysV, I can *write* the daemon in the init script. |
| 6 |
>> In *that* sense, the init system tells the daemon how to do things, |
| 7 |
> |
| 8 |
> Please explain, sure there is the environment that tells a daemon what |
| 9 |
> to do. No shell can tell a c daemon like sshd how to drop priviledges |
| 10 |
> or use systrace but it could do these things for it in a more fine |
| 11 |
> grained manner before it tries and fails itself or if the daemon |
| 12 |
> wishes it to like monit. It's still not telling how but duplicating or |
| 13 |
> removing the need. That's just a bonus that applies to all init |
| 14 |
> systems because shell is so powerful on unix. |
| 15 |
|
| 16 |
Stop thinking in sshd. I can write the *whole* daemon in shell, not in |
| 17 |
another script file, but inside /etc/init.d/mystupiddaemon (or |
| 18 |
/etc/rc.whatever); shell is Turing-complete, I can write in it |
| 19 |
anything I can write in C (or in assembler, or machine code). In that |
| 20 |
sense, the init system (which uses shell for launching daemons) can be |
| 21 |
used to determine *how* the daemon behaves (because it uses shell for |
| 22 |
launching daemons). |
| 23 |
|
| 24 |
You can't do that with systemd; there is a clear and unavoidable |
| 25 |
separation between the starting/stoping/monitoring of daemons, and the |
| 26 |
daemons themselves. Such distinction doesn't really exists in SysV nor |
| 27 |
OpenRC (since they use shell, a Turing-complete language, for |
| 28 |
launching daemons), and therefore you can mixup everything. I agree, |
| 29 |
it doesn't necessarily means that it *will* happen; but even the |
| 30 |
possibility is frigthning for a system administrator in a production |
| 31 |
server. With systemd, that possibility *doesn't exist* (because it |
| 32 |
doesn't uses a Turing-complete language to start/stop/monitor |
| 33 |
daemons). |
| 34 |
|
| 35 |
Like the clear separation between content and presentation in webapps, |
| 36 |
or between the model and the view in the MVC design patter, having a |
| 37 |
clear separation between how you start/stop/monitor your daemon, and |
| 38 |
what the daemon does, is a good thing. If you don't agree with that, |
| 39 |
well, we must agree to disagree. |
| 40 |
|
| 41 |
Regards. |
| 42 |
-- |
| 43 |
Canek Peláez Valdés |
| 44 |
Posgrado en Ciencia e Ingeniería de la Computación |
| 45 |
Universidad Nacional Autónoma de México |
Archives