gdraheim
ERROR:systemctl:Unknown operation set-environment.
Hello all,
would it by possible to implement systemctl set-environment interface too? I have a problem with NetApp management software installation which uses this interface to upgrade mysql database but it fails exactly on this step:
Transaction test succeeded
Running transaction
Installing : ocie-serverbase-9.6.0-2019.11.J5066.x86_64
Installing : unzip-6.0-20.el7.x86_64
Installing : netapp-application-server-9.6.0-2019.11.J5066.x86_64
Installing : p7zip-16.02-10.el7.x86_64
Installing : 1:java-11-openjdk-headless-11.0.5.10-0.el7_7.x86_64
Installing : 1:java-11-openjdk-11.0.5.10-0.el7_7.x86_64
Installing : netapp-platform-base-9.6.0-2019.11.J5066.x86_64
ERROR:systemctl:Unknown operation set-environment.
Setting skip-grant-tables failed. Exiting installer
warning: %post(netapp-platform-base-9.6.0-2019.11.J5066.x86_64) scriptlet failed, exit status 255
Non-fatal POSTIN scriptlet failure in rpm package netapp-platform-base-9.6.0-2019.11.J5066.x86_64
Thanks a lot. Pavol
Please check the function "def get_env" which is used during start-unit. I guess that "set-environment" needs to write to a file which is then being read during get_env.
The tricky bits are about (a) use "truncate_old(filename)" to have the values from earlier set-environment to not servive a boot/reboot and (b) figuring out how these variable are subject to value expansion as the systemd documentation is often lacking about those details.
I guess that I will not have the time to implement it until summer. But I take patches.
I can provide you with a set of dummy functions on the develop branch if you want to go for it, so that the skeleton is in place.
This ticket is still open and I would like to ask if there is a workaround that you use? I don't have access to "netapp" packages in the general distros that are the base of the testing scenarios in this project, so a sufficient implementation can not be specified.
Mariadb version 10.5 will not start because it uses unset-environment and set-environment I had to comment the lines ExecStartPre and ExecStartPost to make it work
So you say that the ExecStartPre command contains some kind of "set-environment" ?
I have tested a few mariadb versions but I did not see such. Can you show the systemd descriptor?
Hi, check the source for mariadb.service: https://github.com/MariaDB/server/blob/10.6/support-files/mariadb.service.in I copy here lines 79-95 Though this code is for version 10.6, similar code appears in version 10.1 in the repo
ExecStartPre=/bin/sh -c "systemctl unset-environment _WSREP_START_POSITION"
ExecStartPre=/bin/sh -c "[ ! -e @bindir@/galera_recovery ] && VAR= || \
VAR=`cd @bindir@/..; @bindir@/galera_recovery`; [ $? -eq 0 ] \
&& systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1"
# Needed to create system tables etc.
# ExecStartPre=@scriptdir@/mysql_install_db -u mysql
# Start main service
# MYSQLD_OPTS here is for users to set in /etc/systemd/system/mariadb.service.d/MY_SPECIAL.conf
# Use the [Service] section and Environment="MYSQLD_OPTS=...".
# This isn't a replacement for my.cnf.
# _WSREP_NEW_CLUSTER is for the exclusive use of the script galera_new_cluster
ExecStart=@sbindir@/mariadbd $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION
# Unset _WSREP_START_POSITION environment variable.
ExecStartPost=/bin/sh -c "systemctl unset-environment _WSREP_START_POSITION"
Oh, this is really awful, I hate it just from seeing it.
Nethertheless I see your point that it seems easier to extend systemctl.py instead of fixing the mess in MariaDB.
After checking the systemd documentation, it seems that set-environment does NOT alter the environment space of the unit but it does alter the environment space of the central [Manager] process. There seems to be the expectation at MariaDB that the altered manager environment is inherited immediatly to all subprocesses.
This can not work with the replacement tool as each "systemctl" call is separate and there is no central manager or daemon running. While I can image a set-environment to write some global conf file it would NOT do what MariaDB seems to expect. Supporting the MariaDB logic would require add quite a number of hacks to systemctl.py.
Even when not considering the technical difficulty, it is a bad idea to modify a global variable of the system for usage in a single service. And the global variable does not even have a prefix related to MariaDB. I see the point of checking /galery_recovery to switch MariaDB into another mode but this is a bad design. Writing to a unit local space like the RuntimeDirectory of a service would have been better.
With all due respect but I will not invest my personal time into this. Please continue to add hacks to cleanup the mess from MariaDB.
Hi, I understand and agree with your analysis of the problem. Thanks for checking that.
What I did to get mariadb start was to simply comment the lines. To do that in the Dockerfile I used sed -i to modify in place the problematic lines of /usr/lib/systemd/system/mariadb.service I think that code is not needed if mariadb is not part of a cluster.
I also had to uncomment the line "# ExecStartPre=@scriptdir@/mysql_install_db -u mysql" to get the tables created when mounting an external volume to /var/lib/mysql
MariaDB is working with https://github.com/feo-cz/docker-systemctl-replacement
