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

[Daniel Black]

On Fri, Mar 12, 2021 at 6:51 AM Otto Kekäläinen <otto at debian.org> wrote:

> Hello!
>
> Thanks for reviewing the systemd scripts in MariaDB. I added a couple
> of MariaDB devs as the systemd service files are not maintained in
> Debian but inherited from upstream MariaDB.
>
> On Thu, 11 Mar 2021 at 19:42, Marc Lehmann <debian-reportbug at plan9.de>
> wrote:
> >
> > Package: mariadb-server-core-10.5
> > Version: 1:10.5.9-1
> > Severity: normal
> >
> > Dear Maintainer,
> >
> >    * What led up to the situation?
> >
> > various scripts (e.g. galera_new_cluster) and the systemd.unit modify the
> > global/systemwide environment, e.g. with variables _WSREP_START_POSITION.
> >
> > 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.

> 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


> where starting/stopping one server or bootstrapping one cluster
> > will interfere with the other instance,s which could easily lead to
> > database corruption.
>

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?


>    * What exactly did you do (or not do) that was effective (or
> >      ineffective)?
> >
> > I didn't try to solve the problem, it seems to be too fundamental to
> > easily work around. The mechanism (systemd environment block) is wholly
> > unsuitable to solve this problem.
>

I know it's unclean.

Suggestions welcome as to how to communicate state between two separate
ExecStart* states in systemd welcome.

note:
* Filesystem ways need to prevent using the datadir which could be a place
for a SST to be rsynced
* You can't export environment between ExecStart scripts
* Codership are quite unaccepting of contributions (e.g:
https://github.com/codership/galera/pull/109).

https://jira.mariadb.org/browse/MDEV-14707 has never come up with concrete
improvements.

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

>
> >    * 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?

critical environment variables of other services
> > erased/modified.
>

Nothing else is modified or erased as you've already seen

>    * What outcome did you expect instead?
> >
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-mysql-maint/attachments/20210319/2b644cdf/attachment.htm>