Re: Debian 8 how to install and run init.d scripts?

2019-10-28 Thread Greg Wooledge
On Sat, Oct 26, 2019 at 08:59:16AM +0200, to...@tuxteam.de wrote:
> On Fri, Oct 25, 2019 at 11:14:22PM +0200, Steffen Dettmer wrote:
> > Not sure if on topic, but I what is needed to guess, it should run the
> > scripts in order of their rcX/Snn number? I though the difficulty
> > would be to use a suited nn number (and in fact, if my init.d script
> > would get started at all it won't work because of a missing user as
> > it is started before pam ldap - this are places where I expect problems,
> > not at the attempt to run or not at all).
> 
> Even simpler than that: if you keep to the LSB init script spec [1] [2],
> the dependencies are stated explicitly: that should be exactly what
> systemd needs to calculate its dependencies.

In other words: no, systemd does not respect the Snn ordering of
the symlinks in /etc/rc*.d/.  It recalculates the dependencies on its
own, based on whatever information it is able to gather.

That information includes the parseable "comments" at the top of the
"simple shell script", which is really, really not just a "simple shell
script" at all.

Once you take into account that you're really writing an init.d script
in no less than *two* languages (one procedural language, sh, plus one
declarative language, the embedded comments at the top of the file),
*plus* incorporating knowledge of OS-specific tools like start-stop-daemon,
it should be clear why I claimed that a sysv-rc script is much more
complicated than a systemd unit.



Re: Debian 8 how to install and run init.d scripts?

2019-10-26 Thread tomas
On Fri, Oct 25, 2019 at 11:14:22PM +0200, Steffen Dettmer wrote:

[...]

> Not sure if on topic, but I what is needed to guess, it should run the
> scripts in order of their rcX/Snn number? I though the difficulty
> would be to use a suited nn number (and in fact, if my init.d script
> would get started at all it won't work because of a missing user as
> it is started before pam ldap - this are places where I expect problems,
> not at the attempt to run or not at all).

Even simpler than that: if you keep to the LSB init script spec [1] [2],
the dependencies are stated explicitly: that should be exactly what
systemd needs to calculate its dependencies.

Cheers

[1] https://wiki.debian.org/LSBInitScripts/
[2] https://wiki.debian.org/LSBInitScripts/DependencyBasedBoot
-- t


signature.asc
Description: Digital signature


Re: Debian 8 how to install and run init.d scripts?

2019-10-25 Thread Steffen Dettmer
Hi,

thanks for your reply.

On Tue, Oct 22, 2019 at 5:45 AM Peter Wiersig  wrote:

> Steffen Dettmer  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.
>


> Like Greg says, systemd units are really much simpler.
>

Thank you for your opinion. I'm sure it is fully true in your context.


> 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.
>

Not sure if on topic, but I what is needed to guess, it should run the
scripts in order of their rcX/Snn number? I though the difficulty
would be to use a suited nn number (and in fact, if my init.d script
would get started at all it won't work because of a missing user as
it is started before pam ldap - this are places where I expect problems,
not at the attempt to run or not at all).
 it's documentation with Debian 9 (stretch) is in


> "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."
>

In my case, the script does exist and I can call it manually. The problem
is that it sources lsb functions that source "hooks" which includes
some s40systemd-wrapper (or such) which calls "exit 0" instead of
letting the sourcing script continue.
Unless DPKG_MAINTSCRIPT_PACKAGE is set.


> 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.
>

Technically it is clear, because some sourced systemd script calls some
exit 0, since sourced, it does not terminate the sourced script, but also
the calling script.

Maybe it is a bug that it exits. Maybe it is a bug that it exits in my
situation.
I noticed that it does not exits when DPKG_MAINTSCRIPT_PACKAGE is
set. This suggests me that there must be some trick (even if fragile).
(Since its not most recent and systemd I think it makes no sense to
file a bug report, I just tried to understand and get it working).

>> 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.
>

(These places were mentioned as points where to read, I just told that
I read them but still did not understand whats happening and especially
if it is a bug, or what kind of bug I'm facing)
So although systemd is assumed to be simple, my issue
"just start a script" still isn't solved, even with all the help from this
list,
so I think under the hood things are more complex than they seem to be.

 > 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".
>

Yes, it was. I patched the gitlab-runner script to set
DPKG_MAINTSCRIPT_PACKAGE,
and installed a gitlab-runner2 without that.


> > 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.


systemd is from 2010, so in Debian 8 it should be somewhat
stable already I think.


> 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)
>   (...)
>

I think in Debian 8 / Jessie it looks the same, IF it works.
Here my problem is, that it does NOT work :(

But as already said, maybe with systemd its impossible
to get init.d script running correclty so that I need to
write such a unit file (using Devuan is no option here).

> 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.
>

This sounds like a way where I possibly should dig in deeper?


> Did you install gitlab as whole from packages or from source?


well... it's complicated...
Let's take 

Re: Debian 8 how to install and run init.d scripts?

2019-10-25 Thread Steffen Dettmer
On Mon, Oct 21, 2019 at 9:32 PM Greg Wooledge  wrote:

> On Mon, Oct 21, 2019 at 09:26:57PM +0200, Steffen Dettmer wrote:
> > On Mon, Oct 21, 2019 at 3:27 PM Greg Wooledge 
> wrote:
> > > This is not correct.  Debian's systemd will use init.d scripts in
> > > compatibility mode.
> >
> > Ahh, this sounds good! But how to do that correctly?
>
> wooledg:~$ systemctl status exim4
>

as I already explained in detail, this does not work.

Steffen


Re: Debian 8 how to install and run init.d scripts?

2019-10-21 Thread Peter Wiersig
Steffen Dettmer  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



Re: Debian 8 how to install and run init.d scripts?

2019-10-21 Thread Greg Wooledge
On Mon, Oct 21, 2019 at 09:26:57PM +0200, Steffen Dettmer wrote:
> On Mon, Oct 21, 2019 at 3:27 PM Greg Wooledge  wrote:
> > This is not correct.  Debian's systemd will use init.d scripts in
> > compatibility mode.
> 
> Ahh, this sounds good! But how to do that correctly?

wooledg:~$ systemctl status exim4
● exim4.service - LSB: exim Mail Transport Agent
   Loaded: loaded (/etc/init.d/exim4; generated)
   Active: active (exited) since Thu 2019-09-05 08:45:26 EDT; 1 months 15 days a
 Docs: man:systemd-sysv-generator(8)
Tasks: 0 (limit: 4915)
   Memory: 0B
   CGroup: /system.slice/exim4.service

See "man systemd-sysv-generator" for further details.



Re: Debian 8 how to install and run init.d scripts?

2019-10-21 Thread Steffen Dettmer
Hi,

thanks for your reply.

On Mon, Oct 21, 2019 at 3:27 PM Greg Wooledge  wrote:

> > 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.
>
> This is not correct.  Debian's systemd will use init.d scripts in
> compatibility mode.


Ahh, this sounds good! But how to do that correctly?

Installing the script and calling insserv does not work; by reading the
wrapper scripts I accidentally found that it works with I set
DPKG_MAINTSCRIPT_PACKAGE, otherwise it does not work.
I found no hint in the documentation and no helpful error messages
in the places pointed by it.
What am I missing?

Steffen


Re: Debian 8 how to install and run init.d scripts?

2019-10-21 Thread Greg Wooledge
On Mon, Oct 21, 2019 at 12:20:10PM +0200, Steffen Dettmer wrote:
> 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.

An init.d script is approximately 5 to 10 times as complicated as
a systemd unit.  Rough estimate, here.

> 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.

This is not correct.  Debian's systemd will use init.d scripts in
compatibility mode.  However, writing a brand new init.d script in 2019
is just pointless masochism, unless you're distributing a product that
has to run on a variety of init-systems.



Re: Debian 8 how to install and run init.d scripts?

2019-10-21 Thread Steffen Dettmer
Hi,

thanks for your reply.

On Sun, Oct 20, 2019 at 10:26 PM Peter Wiersig 
wrote:

> 5.)
> Instead of init.d scripts create systemd units.
> https://wiki.debian.org/systemd#Creating_or_altering_services

https://freedesktop.org/wiki/Software/systemd/


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.

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.
I just see that I'm supposed to reboot (!) with special parameters to debug
a shell script.

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)

funny that it does not even tell WHICH file was not found and why it was
loaded anyway.
I tried "journalctl -b > journal.txt" and found in journal.txt several
blocks like that:

  09:40:09 node17-0 systemd[1]: Started LSB: gitlab-runner.
  09:40:09 node17-0 gitlab-runner[17967]: Starting multi-runner from
/local/users/sdettmer/work/_gitlab/config.tom   l ...  builds=0
...
  09:44:08 node17-0 systemd[1]: Stopping LSB: gitlab-runner...
  09:44:08 node17-0 gitlab-runner[17967]: WARNING: Requested service stop:
terminated builds=0
  09:44:08 node17-0 gitlab-runner[17967]: All workers stopped. Can exit now
  builds=0
  09:44:08 node17-0 gitlab-runner[10318]: Stopping GitLab Runner:.
  09:44:08 node17-0 systemd[1]: Stopped LSB: gitlab-runner.

which does not give any hint (except that it works with
DPKG_MAINTSCRIPT_PACKAGE set).

The string "gitlab-runner2" does not appear anywhere in the whole file at
all.

Any other places where I could look?

What is in gitlab-runner.service on that one server anyways?
>

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.


> Somewhen in 2016-2018 someone on debian planet posted multiple blogs of
> a great systemd introduction series, I can't find my bookmark right now
> :(
>

What a pitty, I though init.d scripts would be in support of systemd, but
apparently they are not anymore :(
So in future portable packages won't be that easy.

Steffen


Re: Debian 8 how to install and run init.d scripts?

2019-10-21 Thread Steffen Dettmer
Hi,

thank you for your reply.

On Fri, Oct 18, 2019 at 3:34 PM Jonas Smedegaard  wrote:

> Quoting Steffen Dettmer (2019-10-18 15:17:10)
> > in short: how to use "init.d" scripts on Debian?
>
> In short:
>
>   service $SERVICE stop
>

Thanks for the tip. man insserv does not tell about service, and neither
man init.

Anyway, it does not work.

I created a new file and:

  root@node17-0:/etc/init.d# service gitlab-runner2 start
  Failed to start gitlab-runner2.service: Unit gitlab-runner2.service
failed to load: No such file or directory.

(It is a 230 line wrapper to call a shell script with a single parameter,
which calls a binary with more than 100 command line options - to call a
shell script. Unfortunately, no --debug or --verbose. Using strace showed,
that this binary seems to send socket commands only, so it seems it
communicates with some complex server. To start a shell script with a
single parameter. And it does not work.)


> > in detail:
> >
> > On one server a init.d script with LSB header does not work, at least
> > when started by command line.
>
> Diving into the rabbit hole of messing directly with those files,


Unfortunately I don't understand what you mean.
Do you mean, I shall not have any own software on Debian?


> I suggest to start here:

  man service


Obviously, the man page is outdated. Tracing the service script (bash -x)
shows 83 lines of output ending with:

  exec systemctl start gitlab-runner2.service

so actually the script delegates to "systemctl", which is something from
systemd, which is not described in the man page at all.

I still think systemd makes some magic when called with
DPKG_MAINTSCRIPT_PACKAGE set...

Steffen


Re: Debian 8 how to install and run init.d scripts?

2019-10-20 Thread Peter Wiersig
5.) 
Instead of init.d scripts create systemd units.
https://wiki.debian.org/systemd#Creating_or_altering_services

https://freedesktop.org/wiki/Software/systemd/

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/

What is in gitlab-runner.service on that one server anyways?

Somewhen in 2016-2018 someone on debian planet posted multiple blogs of
a great systemd introduction series, I can't find my bookmark right now
:(

Peter



Re: Debian 8 how to install and run init.d scripts?

2019-10-18 Thread Jonas Smedegaard
Quoting Steffen Dettmer (2019-10-18 15:17:10)
> in short: how to use "init.d" scripts on Debian?

In short:

  service $SERVICE stop
  service $SERVICE start
  service $SERVICE reload
  service $SERVICE force-reload
  service $SERVICE restart

> in detail:
> 
> On one server a init.d script with LSB header does not work, at least 
> when started by command line.

Diving into the rabbit hole of messing directly with those files, I 
suggest to start here:

  man service

Enjoy!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature