Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-23321

debian upgrade shouldn't start previously stopped services

Details

    Description

      When doing a debian/ubuntu upgrade, if you have mariadb installed and stopped as a service, the process of doing an `apt-get upgrade` shouldn't start the mariadb service.

      This applies both to systemd and sysv.

      Additionally for systemd, systemd multiinstances e.g.`mariadb@xyz`, those that are started before the upgrade, should be stopped, and restarted after the upgrade.

      Attachments

        Issue Links

          Activity

            danblack Daniel Black added a comment -

            Based on looking so far:

            preinst install - needs to note fresh install in a state

            prerm upgrade - needs to account for multi-instances. Its at this stage that a recording of active services needs to occur. Q: where can this state be saved?

            postinst abort-upgrade - should restart the services. Why don't we do this already? (note same isn't true for preinst abort-upgrade as server executable has been overwritten)

            postinst configure - is where we should restarted only services previously stopped, or default service if fresh install

            danblack Daniel Black added a comment - Based on looking so far: preinst install - needs to note fresh install in a state prerm upgrade - needs to account for multi-instances. Its at this stage that a recording of active services needs to occur. Q: where can this state be saved? postinst abort-upgrade - should restart the services. Why don't we do this already? (note same isn't true for preinst abort-upgrade as server executable has been overwritten) postinst configure - is where we should restarted only services previously stopped, or default service if fresh install

            Note that when you research this, note both the maintainer script sources and the rules file contents:

            debian/rules:
             
            override_dh_systemd_enable:
            	dh_systemd_enable --name=mariadb
            	dh_systemd_enable --no-enable --name=mariadb@
             
            # Start mysql at sequence number 19 before 20 where apache, proftpd etc gets
            # started which might depend on a running database server.
            override_dh_installinit-arch:
            	dh_installinit --name=mariadb --no-start -- defaults 19 21
            	dh_systemd_start --restart-after-upgrade
            

            debian/mariadb-server-10.5.postinst
            debian/mariadb-server-10.5.postrm
            debian/mariadb-server-10.5.preinst
            debian/mariadb-server-10.5.prerm
            debian/mariadb-server-10.5.triggers
            

            Please don't invent anything new, but instead just make sure that dh_systemd and dh_installinit man pages and policies are followed correctly.

            If those docs don't say anything about multi-instances, then ask for guidance on the debian-devel mailing list or use Debian codesearch to find how other packages have already solved this instead of re-inventing the wheel.

            otto Otto Kekäläinen added a comment - Note that when you research this, note both the maintainer script sources and the rules file contents: debian/rules:   override_dh_systemd_enable: dh_systemd_enable --name=mariadb dh_systemd_enable --no-enable --name=mariadb@   # Start mysql at sequence number 19 before 20 where apache, proftpd etc gets # started which might depend on a running database server. override_dh_installinit-arch: dh_installinit --name=mariadb --no-start -- defaults 19 21 dh_systemd_start --restart-after-upgrade debian/mariadb-server-10.5.postinst debian/mariadb-server-10.5.postrm debian/mariadb-server-10.5.preinst debian/mariadb-server-10.5.prerm debian/mariadb-server-10.5.triggers Please don't invent anything new, but instead just make sure that dh_systemd and dh_installinit man pages and policies are followed correctly. If those docs don't say anything about multi-instances, then ask for guidance on the debian-devel mailing list or use Debian codesearch to find how other packages have already solved this instead of re-inventing the wheel.

            We could also just simply solve this by instructing those who run multi-instances or for other reasons want to control the services in details themselves to roll their own systemd service files etc and use the mariadb-server-core-10.5 package and skip using the mariadb-servero-10.5 package that comes with the service files (and makes assumptions that the sysadmin wants to run a mariadbd service).

            otto Otto Kekäläinen added a comment - We could also just simply solve this by instructing those who run multi-instances or for other reasons want to control the services in details themselves to roll their own systemd service files etc and use the mariadb-server-core-10.5 package and skip using the mariadb-servero-10.5 package that comes with the service files (and makes assumptions that the sysadmin wants to run a mariadbd service).
            danblack Daniel Black added a comment - - edited

            Ok. pkg-systemd-maintainers help requested.

            mariadb-server-10.5 includes the system multi services and you want instructions not to install it? That won't work.

            I must stay I'm rather confused by the contradictions:

            the override_dh_installinit-arch has a '--restart-after-upgrade' indicating that do no restart service until upgrade.

            https://github.com/MariaDB/server/blob/10.5/debian/mariadb-server-10.5.prerm#L8 has a stop service

            preinst has https://github.com/MariaDB/server/blob/10.5/debian/mariadb-server-10.5.preinst#L141-L142 "to be sure". Was there a bug this was preventing?

            and post service has an explict start https://github.com/MariaDB/server/blob/10.5/debian/mariadb-server-10.5.postinst#L242

            If so what's the debian/rules on service starting for?

            At the very least I'd like the preinst more considered in which process it kills. Checking these process are related to the executable being overwritten would be a good first step. Better may be examining if its got a file lock on the default datadir.

            danblack Daniel Black added a comment - - edited Ok. pkg-systemd-maintainers help requested. mariadb-server-10.5 includes the system multi services and you want instructions not to install it? That won't work. I must stay I'm rather confused by the contradictions: the override_dh_installinit-arch has a '--restart-after-upgrade' indicating that do no restart service until upgrade. https://github.com/MariaDB/server/blob/10.5/debian/mariadb-server-10.5.prerm#L8 has a stop service preinst has https://github.com/MariaDB/server/blob/10.5/debian/mariadb-server-10.5.preinst#L141-L142 "to be sure". Was there a bug this was preventing? and post service has an explict start https://github.com/MariaDB/server/blob/10.5/debian/mariadb-server-10.5.postinst#L242 If so what's the debian/rules on service starting for? At the very least I'd like the preinst more considered in which process it kills. Checking these process are related to the executable being overwritten would be a good first step. Better may be examining if its got a file lock on the default datadir.

            I am unassigning myself from this. I don't have such a good understanding of the systemd service files as they've become so complex, and now with also socket activation in place I grasp them even less.

            otto Otto Kekäläinen added a comment - I am unassigning myself from this. I don't have such a good understanding of the systemd service files as they've become so complex, and now with also socket activation in place I grasp them even less.

            danblack
            > If so what's the debian/rules on service starting for?

            If the inline comments in the scripts don't explain enough, then please dig in with `git blame` on both the mariadb.org and debian.org repos.

            E.g.:

            The line you are asking from is inherited from https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/9f49e4b494f3dad8c403972996f7a1ebceb4b34f

            Unfortunately the commit message is of low quality and does not explain what actually was "messed up" and the reference to http://bugs.debian.org/865870 does not help at all. It has been working for several years without bugs filed..

            otto Otto Kekäläinen added a comment - danblack > If so what's the debian/rules on service starting for? If the inline comments in the scripts don't explain enough, then please dig in with `git blame` on both the mariadb.org and debian.org repos . E.g.: https://github.com/MariaDB/server/blame/10.5/debian/mariadb-server-10.5.prerm#L8 https://salsa.debian.org/mariadb-team/mariadb-10.5/-/blame/master/debian/mariadb-server-10.5.prerm#L8 The line you are asking from is inherited from https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/9f49e4b494f3dad8c403972996f7a1ebceb4b34f Unfortunately the commit message is of low quality and does not explain what actually was "messed up" and the reference to http://bugs.debian.org/865870 does not help at all. It has been working for several years without bugs filed..
            danblack Daniel Black added a comment -

            Need to so some work in dh_installsystemd to get templated instances into the start

            danblack Daniel Black added a comment - Need to so some work in dh_installsystemd to get templated instances into the start
            ralf.gebhardt Ralf Gebhardt added a comment -

            I have removed the fixVersion for this task as it is one of 5.5, 10.1, 10.2, 10.3, which are EOLed.

            Please add a new fixVersion if you plan to work on this task for a not EOLed versions.

            ralf.gebhardt Ralf Gebhardt added a comment - I have removed the fixVersion for this task as it is one of 5.5, 10.1, 10.2, 10.3, which are EOLed. Please add a new fixVersion if you plan to work on this task for a not EOLed versions.

            People

              Unassigned Unassigned
              danblack Daniel Black
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.