Re: [Buildroot] [PATCH 1/2] package/docker-engine: rewrite dockerd init script

From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: Fiona Klute <fiona.klute@gmx.de>
Cc: Christian Stewart <christian@aperture.us>,
	Fiona Klute via buildroot <buildroot@buildroot.org>
Subject: Re: [Buildroot] [PATCH 1/2] package/docker-engine: rewrite dockerd init script
Date: Tue, 30 Jul 2024 17:50:36 +0200	[thread overview]
Message-ID: <20240730175036.2d4bd34f@windsurf> (raw)
In-Reply-To: <1f90c2c6-ef59-47d8-b547-527879f9d8fc@gmx.de>

Hello Fiona,

On Tue, 30 Jul 2024 17:33:07 +0200
Fiona Klute <fiona.klute@gmx.de> wrote:

> > While would need the while loop waiting for the daemon to actually be
> > started in the docker-engine init script and not the other services?  
> 
> There isn't a fundamental difference, I might have over-engineered a bit
> while thinking about experiments with the Docker config and how it'd be
> annoying if I change the config and restart, see "OK", and then the
> service isn't running. Effectively the loop only confirms that the
> service reaches the point where it writes its PID file (that's something
> those other services don't do, note the absence of --make-pidfile), but
> it might still crash after.
> 
> It should be fine to drop the loop and accept the same limitation as in
> those other scripts (if the binary can be executed and then crashes,
> output still says "OK").

To me, the whole goal of the effort you have started (and which is
super nice!) is to have consistency among the init scripts, so I would
really prefer that a given situation is handled in exactly the same way
in all init scripts.

BTW, in another e-mail, I had suggested to improve a bit our
documentation to describe the different situations, and how we intend
to handle each situation in our init script.

> I can respin, I'm just hoping to get an opinion on the second patch
> first (the log capture one), so I know whether to modify or drop that in v2.

I don't have a super super strong opinion PATCH 2/2. Wrapper scripts
always tend to make things a bit more "obscure". My initial thought
was: but if all what's missing is --no-close support in Busybox, why
don't we implement it? On the other hand, your wrapper script allows
the logging to go into syslog (which is configurable), while with
--no-close, it simply gets redirected to a file, and that's it (which I
suppose we can say is less configurable than having logs going through
syslog).

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot