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

[Otto Kekäläinen]

Hello!

If this was fixed in some Galera release, please let me know.

I did not see any Forwarded: line in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984996

On Fri, 19 Mar 2021 at 09:34, Marc Lehmann <schmorp at schmorp.de> wrote:
>
> 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
>       -=====/_/_//_/\_,_/ /_/\_\



-- 
- Otto