<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 12, 2021 at 6:51 AM Otto Kekäläinen <<a href="mailto:otto@debian.org">otto@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
<br>
Thanks for reviewing the systemd scripts in MariaDB. I added a couple<br>
of MariaDB devs as the systemd service files are not maintained in<br>
Debian but inherited from upstream MariaDB.<br>
<br>
On Thu, 11 Mar 2021 at 19:42, Marc Lehmann <<a href="mailto:debian-reportbug@plan9.de" target="_blank">debian-reportbug@plan9.de</a>> wrote:<br>
><br>
> Package: mariadb-server-core-10.5<br>
> Version: 1:10.5.9-1<br>
> Severity: normal<br>
><br>
> Dear Maintainer,<br>
><br>
>    * What led up to the situation?<br>
><br>
> various scripts (e.g. galera_new_cluster) and the systemd.unit modify the<br>
> global/systemwide environment, e.g. with variables _WSREP_START_POSITION.<br>
><br>
> This has the effect of polluting the environment of other sservices with<br>
> these variables, which is usually pretty harmless.<br></blockquote><div><br></div><div>The intent was for minimal effects.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> However, if there are multiple server instances then this creates a race<br>
> condition</blockquote><div><br></div><div><div>Multiinstance services use <code> _WSREP_START_POSITION%I as the environment name<br></code></div><div><br></div><div>ref: <a href="https://salsa.debian.org/mariadb-team/mariadb-10.3/-/blob/master/support-files/mariadb@.service.in#L88">https://salsa.debian.org/mariadb-team/mariadb-10.3/-/blob/master/support-files/mariadb@.service.in#L88</a></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> where starting/stopping one server or bootstrapping one cluster<br>
> will interfere with the other instance,s which could easily lead to<br>
> database corruption.<br></blockquote><div><br></div><div>I'm not convinced about it easily. There are aria and innodb locks on filesystem preventing a second process</div><div>modifying an already running process.</div><div><br></div><div>Also the state only exists within the startup process of the mariadb.service. There are systemd blocks that prevent</div><div>two copies of the same service starting at the same time.<br></div><div><br></div><div>Maybe you mean something I haven't thought of. Can you explain the scenario?</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>    * What exactly did you do (or not do) that was effective (or<br>
>      ineffective)?<br>
><br>
> I didn't try to solve the problem, it seems to be too fundamental to<br>
> easily work around. The mechanism (systemd environment block) is wholly<br>
> unsuitable to solve this problem.<br></blockquote><div><br></div><div>I know it's unclean.</div><div><br></div><div>Suggestions welcome as to how to communicate state between two separate ExecStart* states in systemd welcome.</div><div><br></div><div>note:<br></div><div>* Filesystem ways need to prevent using the datadir which could be a place for a SST to be rsynced</div><div>* You can't export environment between ExecStart scripts</div><div>* Codership are quite unaccepting of contributions (e.g: <a href="https://github.com/codership/galera/pull/109">https://github.com/codership/galera/pull/109</a>).</div><div><br></div><div><a href="https://jira.mariadb.org/browse/MDEV-14707">https://jira.mariadb.org/browse/MDEV-14707</a> has never come up with concrete improvements.</div><div><br></div><div>And there's been no bugs that I've found reported against the operation of the functionality.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
><br>
>    * What was the outcome of this action?<br>
><br>
> Environment polluted,</blockquote><div><br></div><div>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?<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">critical environment variables of other services<br>
> erased/modified.<br></blockquote><div><br></div><div>Nothing else is modified or erased as you've already seen<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>    * What outcome did you expect instead?<br>
><br>
> A systemd service should _never_ _ever_ modify the global environment.</blockquote><div><br></div><div> 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.</div><div><br></div><div><br></div></div></div>