Anton Aylward wrote:
On 09/29/2014 06:33 PM, Dirk Gently wrote:
Anton Aylward wrote:
On 09/28/2014 11:20 PM, Carlos E. R. wrote:
You told us so many times how easy it is to understand what script under /etc/init.d does by just looking at it and now you ask this question? What prevents you from just looking at script and answer yourself?
I was intrigued enough to have a look. Then I found out and laughed :-) Took me some time, though. Maybe five minutes in all. I'm not a script junkie, after all :-)
Indeed, the script seems superfluous!
So. how is the script getting interecepted and replaced with a systemctl command, when there is NO mention of systemctl anywhere in the cron start/stop script?
Indeed, but Carlos is right when he says he's not a script junkie. Its not the script that's starting the cron daemon. In fact the cron daemon could be started without the script and without making use of systemctl.
Yes, I know that. That's not the point. \The point is... why is starting cron being hijacked into systemctl?
This item demonstrates quite nicely what a con-job the idea of wonderful sysvinit scripts are. The shell and shell script has noting to do with starting cron any more than a hand typed command line or a systemd unit.
Oh joy Oh wonder Oh ROTHFLMAO
let seem how man use-cases are like that?
autofs cups dovecot fetchmail gpm mcelog nfs ntp pcscd powerd proftpd rsyncd spamd spampd sshd xdm ypbind
Oh Wonderful!
OBTW: there's no 'intercepted' about it. Its the way they were designed to start with. Before systemd came along. The idea that sysvinit is about shell scripts is a fundamentally flawed notion. Its just about entry levels and run levels.
So fundamentally flawed that it worked perfectly for 40 years.... That's like saying that round tires are fundamentally flawed because there's no guarantee that they can't hang from a ceiling.
If it wasn't that systemd maintained backwards comparability with being able to do what's expected when a sysadmin types "init 3", "init 6", or "init s" at the prompt there would be no need to keep these things around. It never was the scripts that were doing the work. They were just a means to an end.
Actually, yes, the scripts DO do the work... they are there to make sure that deamons are started and stoped in a consistent manner... the manner (flags & arguments) listed in the script, as debugged by the admin (or software distgributor), rather than in whatever manner the admin-at-the-moment thinks it should be started ro stopped.
Part of the reason systemd is so large is dealing with this kind of backward compatibility. If you really were to strip out all the backward compatibility like the above the code would be a lot smaller and lot cleaner. There would be no need to recognise special cases and have all those run-level comparability hooks. A lot of the basis for criticism of systemd would go away because the code on which it based would not be there.
It would also be a hell of a lot smaller if it wasn't also being a cron deamon, an http server, a socket listener, etc. and whatever deamons Sievert & Poettering have decided must be added to the ever growing list of deamons that they've hijacked and hard-coded into systemd. Q?uit justifying this monolithic pile of crap. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org