"service {FOO} start" vs. "/etc/init.d/{FOO} start"? [closed]

Question

I use CrashPlan on my Debian 8 desktop. I have a script where I must stop the CrashPlan service at the beginning and then start it before exiting. I was using

/etc/init.d/crashplan start

for the restart but the new CrashPlan process was exiting at the termination of my script. I switched to

service crashplan start

and all is well!

Oddly, under Ubuntu 16.04 on another box, the init.d script/command behaves as desired. When my script exits, CrashPlan continues to run. Welp, now Ubuntu is giving me the same issues.

My Debian script is now functional. But I was under the impression that the service command was on the way to deprecation, so I am puzzled by the differences, both between init.d and service, and between the current releases of Debian and Ubuntu.

Answer 1

On any system using systemd, running an init.d script directly won't be the best way to start a service, since it will bypass all settings and bookkeeping usually done by systemd itself. Also, you might not even have an init script, the service might be described only in a unit file.

With "old-style" sysvinit there was not much bookkeeping to do: starting a service was about the same as just running a script. That doesn't mean it was a good idea to the init script directly, the description in the man page of service tells you why:

service runs a System V init script or upstart job in as predictable an environment as possible, removing most environment variables and with the current working directory set to /.

A random shell is not a very predictable environment, you could have e.g. file or process limits active.

As for deprecation, perhaps you should use systemctl, but on Debian service actually tries to do the right thing and runs systemctl for you. (Let's just say that if service is deprecated, then running an init script directly is even more so.)

(I'm not enough of a systemd expert to tell you what exactly kills the service if you run the init script directly. That also depends on what runs the script you are running: from cron, from the command line, from something else...)