Uploaded image for project: 'MariaDB ColumnStore'
  1. MariaDB ColumnStore
  2. MCOL-4132

systemd startup logic suggestions



    • Task
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • None
    • 5.4.1
    • installation
    • None


      MCOL-3618 - the entire install should be runable as non-root and as such systemd service files should have a `User=`

      paths in scripts need to be at least configurable.



      # This script allows to gracefully start MCS
      /bin/systemctl start mcs-storagemanager
      /bin/systemctl start mcs-loadbrm
      /bin/systemctl start mcs-workernode
      /bin/systemctl start mcs-controllernode
      /bin/systemctl start mcs-primproc
      /bin/systemctl start mcs-writeengineserver
      /bin/systemctl start mcs-exemgr
      /bin/systemctl start mcs-dmlproc
      /bin/systemctl start mcs-ddlproc
      exit 0

      This is horrible. Use Requires or similar. Maybe the `Partof` in other services forms the heirarcy ok.

      What I've generally found with systemd is to specify something if required. patching both ends of the service just gets messy.

      Don't sleep

      Use of sleep like:

      ExecStart=/usr/bin/env bash -c "/bin/sleep 2 && /usr/bin/DDLProc"

      is an ugly fragile hack. Use of Type=simple isn't robust way to handle the dependencies to other services.

      Ways to fix this in preferred order are:

      a) Use `Type=notify`

      When using this the server will be linked against a systemd server component and use sd_notify to communicate when it is ready.

      The mariadb server uses this since 10.1.8 so see how it does it. READY is sent in sql/mysqld.cc just before the loop that accepts connections.

      b) Type=dbus

      If you are consider moving all communication to dbus rather than focusing development effort on client/server protocols.

      c) Use `Type=forking`.

      When the main process is ready it should fork.

      d) Use ExecStartPost

      To have some sort of wait condition (e.g. file created, socket exists etc).

      LD_PRELOAD jemalloc

      ExecStart=/usr/bin/env bash -c "LD_PRELOAD=$(ldconfig -p | grep -m1 libjemalloc | awk '{print $1}') exec /usr/bin/ExeMgr"

      So if the libjemalloc is in the loader cache it should be used? This isn't a good idea because:

      • What the service is running depends rather indirectly on the system
      • jemalloc may be build with a prefix and not immediately replace the malloc functions
      • the use can force jemalloc use if they want to by doing a service override (examples https://mariadb.com/kb/en/mariadb/systemd/).

      ExecStop kill

      ExecStop=/usr/bin/env bash -c "kill -15 $MAINPID"

      Don't do this. This is close to the default anyway so can be omitted.


      ExecStopPost=/usr/bin/env bash -c "clearShm > /dev/null 2>&1"

      Is redirecting the output to null the best idea?


      The description of these services is a bit brief.

      good bits

      Good use of PartOf

      Feature enhancements


      this is a good case for Service Template where the instance name is the worker identifier.


      Think how you want the dependency with the mariadb.service to show up as. `PartOf` again?


        Issue Links



              drrtuy Roman
              danblack Daniel Black
              0 Vote for this issue
              4 Start watching this issue



                Git Integration

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