[debian-mysql] Bug#984996: Bug#984996: mariadb-server-core-10.5: modifies globalö environment, causing race conditions

[Marc Lehmann]

On Fri, Mar 19, 2021 at 03:41:06PM +1100, Daniel Black <daniel at mariadb.org> wrote:
> > > This has the effect of polluting the environment of other sservices with
> > > these variables, which is usually pretty harmless.
> 
> The intent was for minimal effects.

That has clearly failed, as it pollutes the environment blocvks for all
services on the system-

> > However, if there are multiple server instances then this creates a race
> > > condition
> 
> Multiinstance services use _WSREP_START_POSITION%I as the environment name
> 
> ref:
> https://salsa.debian.org/mariadb-team/mariadb-10.3/-/blob/master/support-files/mariadb@.service.in#L88

That might indeed work around the problem, but of course increases the
pollution for unrelated services and user sessions.

> I'm not convinced about it easily. There are aria and innodb locks on
> filesystem preventing a second process
> modifying an already running process.
> 
> Also the state only exists within the startup process of the
> mariadb.service. There are systemd blocks that prevent
> two copies of the same service starting at the same time.
> 
> Maybe you mean something I haven't thought of. Can you explain the scenario?

The environment variables are _global_, not per-service. They will leak
into every other service started concurrently, including other mariadb
services.

> I know it's unclean.
> 
> Suggestions welcome as to how to communicate state between two separate
> ExecStart* states in systemd welcome.

Files would be an obvious better solution, either using instanced
filenames or maybe a private fs namespace (e.g. in /tmp). I am not a
systemd expert, so can't comment on what the best working solution would
be, but files are obviously already better without any systemd features,
as they don't interfere with the suer environment or other services.

> * Codership are quite unaccepting of contributions (e.g:
> https://github.com/codership/galera/pull/109).

Can't force them to fix bugs or have a high-quality product, of
course. They do their thing, and hopefully get happy. But debian could,
and probably should, if at all possible.

> And there's been no bugs that I've found reported against the operation of
> the functionality.

Luck is not a good argument :) It is, after all, a race condition.

> > >    * What was the outcome of this action?
> > >
> > > Environment polluted,
> 
> One environment variable of a constrained name. Pollution? That appears for
> the microscopic time between a couple service script starts and is gone by
> the time the service start? Pollution, really?

Slippery slope much? :)

The "microscopic" time can be many minutes or longer under normal
operating conditions, and I don't think I need to seriously defend leaving
the global environment alone.

> critical environment variables of other services
> > > erased/modified.
> >
> 
> Nothing else is modified or erased as you've already seen

Other than variables of other services, no, I agree.

> > > A systemd service should _never_ _ever_ modify the global environment.
> 
>  I agree. But an exaggerated purist argument to fix a problem that doesn't
> have a concrete real or theoretical failure isn't going to get a high
> priority.

That's why I explaiend concrete and theoretical failures in my report.

In any case, I think the problem is well understood, and I don't think more
explanations will be needed. If nobody cares about fixing this, thats fine
with me.

Good luck, and thanks for your efforts!

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\