Hello! I am about to upload MariaDB 10.3.29 to Debian in the near future.
If you have a suggestion on how to fix this issue, I'd appreciate if you submit your suggestion as a Merge Request at https://salsa.debian.org/mariadb-team/mariadb-10.3 (or for 10.5 at https://salsa.debian.org/mariadb-team/mariadb-10.5). Since we inherit the systemd file from upstream, you could also in addition (or instead) file an issue upstream or even submit a PR to fix it at https://github.com/mariadb/server On Sun, 31 Jan 2021 at 05:24, Jörg Delker <jo...@delker.de> wrote: > > Am 30.01.2021 um 23:57 schrieb Otto Kekäläinen: > > Hello! > > > > We are using the same mariadb@.service as upstream ships. It has not > > been customized for Debian, so maybe you want to file this upstream? > > Hmm... Debian's bug guidelines deprecate that explicitly, saying that an > issue shall not be posted here and upstream. > From the README.Debian I understood, that the packages provided by > mariadb.org and Debian differ quite significantly and shall not be > mixed. Maybe the instance-service works just fine in their environment...? > > > The directory /etc/mysql/conf.d/*.cnf has and always will be included > > when parsing configuration for every server. If there is a server > > instance that needs its own config, it should reside at some other > > location, where other instances will not read it. > > I would generally agree to that. I'm not saying, that an instance must not > include /etc/mysql/conf.d/*.cnf, > but if the instance service definition has it's "own config" hard-coded to > that directory, it becomes part of any other service instance by default. > From my understanding this renders the provided mariadb@.service competely > unusable. > > In fact, there are several more glitches in that service, which do not work > properly with a dedicated instance. > That begins with a colliding /run dir and goes on with the invocation of the > debian-start script, which operates on the main server, rather than the > instance. > -- - Otto
