FAQ

Composer runs into auth issues on my Mac OS X machine.

Question

As Solution Partner or Customer, you received a ext12345 username together with a token. This gives you access via composer to the necessary libraries. These credentials have to be added in your auth.json, which can, for example, be in the source directory of your project like src/auth.json.

Example:

{
   "http-basic": {
      "gitlab.met.tdintern.de": {
         "username": "ext00000",
         "password": "asaZIjkUIollKSADnrlm"
      }
   }
}

Whenever composer will be invoked, these credentials will be used for the HTTP download, composer will do. In some cases, you’ll receive a message from composer that you’ll not have the necessary access rights to install pacemaker or one of its packages.

Answer

macOS saves the credentials in the keychain on the host level (https://gitlab.met.tdintern.de). When invoking composer the first time, and it doesn’t matter from which project, the first host entry from the keychain will be used and not the one from the auth.json anymore. This may lead to the problem that the Pacemaker libraries can not be loaded anymore because of missing access.

As generally, you’ll access the GIT repositories over SSH, in case of pacemaker it will be necessary to disable the caching of the credentials of the system for HTTPS calls. Therefore execute the following commands to remove the credential helper from the GIT configuration

git config --local --unset-all credential.helper \
  && git config --global --unset-all credential.helper \
  && git config --system --unset-all credential.helper

After that, the credential helper has to re-initialized empty (because of any other tool like xCode for example may also use it) with the following command

git config --global --add credential.helper "" && composer clear-cache

Finally, search in the keychain tool for met and delete the entry gitlab.met.tdintern.de. If the keychain has been deactivated, in the future GIT should ALWAYS use the credentials from the auth.json from your project or the global one.

The performance on the production/stating system is worse than on my local machine!

Question

The performance between your local and any other system differs significantly. What can be the reason?

Answer

Probably the MySQL transaction log has different settings. The option innodb_flush_log_at_trx_commit by default has the value 1. This means, that the transaction log will be written by MySQL after each commit. This option controls the balance between strict ACID compliance for commit operations and higher performance that is possible when commit-related I/O operations are rearranged and done in batches. Setting this value to 2, you can achieve better performance, but then you can lose transactions in a crash.

Possible values are

0

write and flush once per second

1

write and flush at each commit

2

write at commit, flush once per second

For example, switching this value from 1 to 2 the import performance improves from 02:06:10 to 00:03:29 h which is for sure significant

ID Pipeline Created Finished Duration

219

xxx_import_catalog

Oct 24, 2019 2:47:04 PM

Oct 24, 2019 4:53:14 PM

02:06:10 h

221

xxx_import_catalog

Oct 24, 2019 5:02:02 PM

Oct 24, 2019 5:05:31 PM

00:03:29 h

Supervisor does not restarts the runners any more

Problem

After working for a while as a charm the supervisor stops restarting the runner consumers. The supervisor log displays an error like FATAL Exited too quickly (process log may have details).

Answer

Even if a process exits with an “expected” exit code, supervisor will consider the start as a failure if the process exits quicker than startsecs. Which is default 1 second. You need to set the option startsecs=0 to the supervisor configuration in order to avoid this behaviour.

Please refer to How to configure the runners.