Other Notes

1. Code quality check

dbbot’s YAML recommendation is to perform a lint before committing:

sh lint_all_yml_files.sh

If .ansible-lint exists in the repository, please follow the ignore rules in this file.

2. Common troubleshooting

2.1 The MySQL service has been restarted too many times and cannot be started again.

If a dbbot-deployed mysql3306.service keeps failing during testing, it will eventually stop in the following state:

systemctl status mysql3306.service --no-pager -l

× mysql3306.service - MySQL Server
     Loaded: loaded (/usr/lib/systemd/system/mysql3306.service; enabled; preset: disabled)
     Active: failed (Result: exit-code)
...
Mar 20 02:27:30 systemd[1]: mysql3306.service: Main process exited, code=exited, status=1/FAILURE
Mar 20 02:27:32 systemd[1]: mysql3306.service: Start request repeated too quickly.
Mar 20 02:27:32 systemd[1]: Failed to start MySQL Server.

This is not a new root cause. It means the systemd protection rule has taken effect. By default, dbbot configures the MySQL service to restart on failure, but only allows two abnormal starts within five minutes. After that, systemd stops trying so mysqld does not loop forever, bury the first real error, and delay alert confirmation and manual intervention.

You can inspect the deployed service settings directly:

systemctl show mysql3306.service -p Restart -p StartLimitIntervalUSec -p StartLimitBurst

Restart=on-failure
StartLimitIntervalUSec=5min
StartLimitBurst=2

The startup log stream usually looks like this:

journalctl -u mysql3306.service -n 20 --no-pager

Mar 20 02:27:22 systemd[1]: Started MySQL Server.
Mar 20 02:27:25 systemd[1]: mysql3306.service: Main process exited, code=exited, status=1/FAILURE
Mar 20 02:27:27 systemd[1]: Started MySQL Server.
Mar 20 02:27:30 systemd[1]: mysql3306.service: Main process exited, code=exited, status=1/FAILURE
Mar 20 02:27:32 systemd[1]: mysql3306.service: Start request repeated too quickly.
Mar 20 02:27:32 systemd[1]: Failed to start MySQL Server.

When this happens, look for the first real failure instead of focusing only on start-limit-hit:

journalctl -u mysql3306.service -n 50 --no-pager

Common root causes include a bad my.cnf, a busy port, wrong directory permissions, a missing dependency, or an incorrect package path.

If this only happened during testing and the root cause has already been fixed, clear the counter and start the service again:

systemctl reset-failed mysql3306.service
systemctl start mysql3306.service
systemctl status mysql3306.service --no-pager -l

If you changed the unit file, reload systemd first:

systemctl daemon-reload
systemctl reset-failed mysql3306.service
systemctl start mysql3306.service

2.2 SSL certificate time error when downloading dbbot or MySQL package

Typical errors include certificate is not yet valid, certificate has expired, and CERTIFICATE_VERIFY_FAILED.

When you see this kind of error, check the system time first instead of disabling SSL verification.

How to quickly confirm whether this is a time problem

Check the local time and NTP state:

date -R
timedatectl status
chronyc tracking

Observed output excerpt:

Fri, 20 Mar 2026 02:04:09 +0800
System clock synchronized: yes
NTP service: active
System time     : 0.004828646 seconds slow of NTP time

Then check the certificate validity window of the target site:

echo | openssl s_client -connect github.com:443 -servername github.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Observed output:

subject=CN=github.com
issuer=C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication CA DV E36
notBefore=Mar  6 00:00:00 2026 GMT
notAfter=Jun  3 23:59:59 2026 GMT

If the local system time is earlier than notBefore or later than notAfter, HTTPS downloads from wget, curl, and playbooks will fail with certificate time errors.

When the time is correct, curl -I should return normal headers, for example:

curl -I https://github.com

HTTP/2 200
date: Thu, 19 Mar 2026 18:05:47 GMT
strict-transport-security: max-age=31536000; includeSubdomains; preload

On Rocky 9 / RHEL 9, prefer chronyd:

timedatectl set-ntp true
systemctl restart chronyd
chronyc -a makestep
date -R
chronyc tracking

On older systems that still use ntpdate, run:

ntpdate pool.ntp.org

After the time is corrected, rerun the download or playbook.

Do not hide the problem with wget --no-check-certificate or curl -k. Fix the system clock first.

3. Suggestions

  • Do time synchronization and network connectivity check before deployment.
  • In the production environment, be careful to directly modify the systemd current limiting parameters and confirm the root cause first.
  • It is recommended to take a snapshot or backup before high-risk operations.