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

systemd startup logic suggestions

    XMLWordPrintable

Details

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

    Description

      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.

      mariadb-columnstore

      /usr/bin/mariadb-columnstore-start.sh

      #!/bin/bash
       
      # 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.

      clearShm

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

      Is redirecting the output to null the best idea?

      Description

      The description of these services is a bit brief.

      good bits

      Good use of PartOf

      Feature enhancements

      mcs-workernode.service

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

      mariadb.service

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

      Attachments

        Issue Links

          Activity

            People

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

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

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