On Fri, Mar 12, 2021 at 6:51 AM Otto Kekäläinen <o...@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-report...@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/mari...@.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.
