首页 > Sysadmin > 正文

MySQL Autostart: Check mysql vs mysqld Before systemctl enable

2026-10-26 Sysadmin

Autostart is just a symlink: enable only links the unit into the target’s wants directory, it never starts the service on the side, and the service name is easy to get wrong. Commands tested on WSL Ubuntu 24.04; a real reboot was not done.

Get the service name right first: mysql, mysqld, mariadb

systemctl list-unit-files | grep -iE "mysql|maria"
systemctl is-active mariadb
systemctl status mariadb --no-pager

The MySQL docs say: if the service name is not mysqld, use the name that applies, and on Debian-family systems (Ubuntu included) and SLES you should use mysql rather than mysqld [1]. Verified against package files (unpacked and inspected only, nothing installed): Ubuntu noble’s mysql-server-8.0 package ships usr/lib/systemd/system/mysql.service and no mysqld.service; the mariadb-server package ships mariadb.service and additionally makes mysql.service and mysqld.service symlinks to it — so on a MariaDB machine systemctl status mysql works too, but the unit actually running is mariadb.service.

One more common trap: default-mysql-server in apt is only a metapackage — which engine you get depends on the distribution, and on Ubuntu noble its dependency is mysql-server-8.0 [2]. This was checked with apt-cache in WSL (the Debian target was not verified locally).

enable only creates a symlink; starting the service is separate

The man page is explicit: enable creates a set of symlinks according to the Install section of the unit file, and it does not start any of the enabled units as a result — to start the service at the same time you need --now, or a start afterwards [3] [4].

systemctl enable mariadb
systemctl is-active mariadb        # tested: still inactive at this point
systemctl enable --now mariadb
ls -l /etc/systemd/system/multi-user.target.wants/

The test matched the manual: after enable alone, is-active was still inactive; only with --now did it become active, and the symlink did land under multi-user.target.wants. Note that a unit with no Install section is static, and systemctl enable on it is meaningless (tested: “The unit files have no installation config”) [3].

Worth clearing up a common misunderstanding: get-default on this machine is graphical.target, while the package’s Install section says WantedBy=multi-user.target, and the link still goes under multi-user — because graphical.target pulls in multi-user.target [5]. Tested: systemctl show graphical.target -p Requires returns multi-user.target, so a desktop default target does not affect database autostart.

Scripts should not rely on the exit code alone

systemctl is-enabled mariadb
test -L /etc/systemd/system/multi-user.target.wants/mariadb.service && echo "will start at boot"
journalctl -u mariadb -b --no-pager | head -10

The manual’s is-enabled status table says disabled returns an exit code greater than 0 [3], but on this WSL Ubuntu 24.04 box (systemd 255) three runs — directly, redirected to /dev/null, and after masking — all returned 0. So checking $? in a script is not reliable here; reading the output string or the symlink in the wants directory is safer.

A real reboot cannot be tested in WSL: WSL needs systemd enabled in the boot section of wsl.conf (it is true on this machine), but re-entering after wsl --shutdown is not a full boot, so “autostart after reboot” can only be checked with restart + journalctl, and the real reboot stays on the pre-publish to-do list.

Any config change requires daemon-reload

The MySQL docs give the drop-in approach: create an override file under /etc/systemd/system/mysqld.service.d (on Debian-family systems the equivalent is mysql.service.d), run daemon-reload after editing, then restart [1].

systemctl edit mariadb              # interactive edit, produces override.conf on save
systemctl daemon-reload
systemctl restart mariadb
systemctl cat mariadb | tail -5

An easy-to-miss difference showed up in testing: after writing a file into service.d by hand, systemctl cat reads the new content from disk immediately, but the loaded state shown by systemctl show still has the old ExecStart until daemon-reload runs; only after reload does it show the new value, and only restart actually applies it. Also, systemctl edit on this box’s systemd 255 has no --stdin option (unrecognized option), so a script has to write the file itself and then reload.

Troubleshooting quick reference

| Symptom | Cause | Fix | |—|—|—| | status shows active but nothing started after reboot | only start, no enable, or the unit is static | systemctl is-enabled + check the symlink in the wants directory | | start reports “Unit is masked” | it was masked earlier (mask points the unit at /dev/null, stronger than disable) [4] | systemctl unmask, then start | | mask reports “File already exists” | the unit file is already in /etc/systemd/system, and mask only works on units packaged under /usr/lib | the manual states this; reproduced in testing [4] | | service name errors, unit not found | used mysqld but the real name is mysql or mariadb | see section 1; both extra names are symlinks in the MariaDB package | | config change did not take effect | forgot daemon-reload, or no restart | systemctl daemon-reload && systemctl restart |

Rollback, limits and FAQ

Rollback: systemctl disable --now mariadb (tested — it removes the wants symlink and stops the service), delete the override file under service.d then daemon-reload, and use unmask to restore a masked unit.

FAQ:

  • enable vs start? enable only governs the boot-time linkage, start only governs the current run — they are orthogonal [4].
  • service or systemctl? The official docs list service as an alternative to systemctl; for new deployments use systemctl directly [1].
  • Can autostart be set in the config file? my.cnf has no autostart option — autostart is a unit-layer concern, so keep config and autostart separate.
  • Multiple instances? The official docs use the mysqld@.service / mysql@.service templates, and enable must name the specific instance [1].
  • Limits: real reboot, RPM platforms, SELinux and systemd inside containers were not tested; the package-file conclusions come from dpkg-deb unpacking inspection. Test environment: WSL Ubuntu 24.04.4 (systemd 255.4), date 2026-10-26; the temporary unit and downloaded package files used for testing were cleaned up. Draft pending review; all commands except the real-reboot items were executed in WSL, and the topic skeleton came from the source site’s list-page summary (the source article body was blocked by the site WAF and not fetched).

References

The main commands in this article were tested on WSL Ubuntu (24.04); some items (tools not installed / install-type commands) were only checked against official docs, not executed.