Re: Debian 8 how to install and run init.d scripts?
Steffen Dettmer <steffen.dettmer@gmail.com> writes:
> So you propose not to use init.d scripts. I usually prefer a simple shell
> script that is easy to test, systemd is just way to complex. But probably
> for Debian you are right, if I understood correctly, newer versions do not
> even support init.d / LSB anymore, so using systemd units seems to be
> required there.
Like Greg says, systemd units are really much simpler.
The thing with the compatibility mode is that that part has do *guess*
what the init.d tries to call and adapt that to its inner working and
can fail.
it's documentation with Debian 9 (stretch) is in
man:systemd-sysv-generator(8), but it's also so short that it would
probably not help.
furthermore quoting from "man systemd.service":
NOTES
1. Incompatibilities with SysV
http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities
and from the referenced doc:
"If your distribution removes SysV init scripts in favor of systemd unit
files typing "/etc/init.d/foobar start" to start a service will not
work, since the script will not be available. Use the more correct
"/sbin/service foobar start" instead, and your command will be forwarded
to systemd."
There are many more details on that page and maybe buried in there is a
hint why the init.d you have does not work.
> About your gitlab-runner.service failure:
>>
>> https://wiki.debian.org/systemd#Failed_units
>> HINT: Extensive debugging information about systemd is on this
>> FreeDesktop page. https://freedesktop.org/wiki/Software/systemd/Debugging/
>
>
> I didn't find anything about init.d or DPKG_MAINTSCRIPT_PACKAGE in these
> pages.
Correct, as they are about systemd units/services/timers etc.
> Only I found using "status", but this does not help either:
>
> root@node17-0:/etc/init.d# systemctl status gitlab-runner2.service
> - gitlab-runner2.service
> Loaded: not-found (Reason: No such file or directory)
> Active: inactive (dead)
Was the ...-runner2 intentional? Your other quoted error showed
"gitlab-runner.service".
> funny that it does not even tell WHICH file was not found and why it was
> loaded anyway.
Yeah, that's probably jessies ancient systemd at fault. Newer output
is more detailed and looks like that:
server:/etc/apt/sources.list.d# systemctl status atd.service
● atd.service - Deferred execution scheduler
Loaded: loaded (/lib/systemd/system/atd.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2019-07-24 04:48:30 CEST; 2 months 29 days ago
Docs: man:atd(8)
Main PID: 570 (atd)
(...)
> There is no such file "gitlab-runner.service" (I tried "find /etc" and
> "locate").
> It seem that some systemd magic applies here. Maybe, if its content is
> needed for technical reasons, systemd creates some "virtual unit" on the
> fly, who knows.
There is also a possible gitlab-runner@.service file to check, for the
indeed rather magic stuff from systemd.
Did you install gitlab as whole from packages or from source? Is the
gitlab-runner version compatible to the other parts?
Did you use the gitlab runner packages from the gitlab repo?
https://docs.gitlab.com/runner/install/linux-repository.html
Debian 8 should be jessie, so supported until summer if i get that page
correctly, and remember the codename to version number correct.
Where did you get the init.d file from? Can you put it in a gist or pastebin?
Hmm, strange apparently there is a correct runner service in play when
the installer parts find systemd:
https://docs.gitlab.com/runner/configuration/init.html
" The system services of GitLab Runner
GitLab Runner uses the Go service library to detect the underlying OS
and eventually install the service file based on the init system.
Note: service will install / un-install, start / stop, and run a program
as a service (daemon). Currently supports Windows XP+, Linux/(systemd |
Upstart | SysV), and macOS/Launchd.
Once GitLab Runner is installed, the service file will be automatically be created:
systemd: /etc/systemd/system/gitlab-runner.service
upstart: /etc/init/gitlab-runner"
Annoying that those are generated and not packaged. Try to share them
with us also, so we may to look for errors in there
Peter
Reply to: