iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
Short answer: mysqld_safe is being given two mutually exclusive logging destinations: --log-error selects a file, while --syslog selects the system logger. Remove one. For a file, keep log-error=/path/to/error.log (or the default host_name.err) and add --skip-syslog if you want the choice to be explicit. For journald or syslog, remove the file destination and configure MySQL’s native system-log support. Then restart with the same service manager that normally starts MySQL and verify the destination you selected.
What the conflict message means
The message Can’t log to error log and syslog at the same time.
is a destination collision, not an indication that the error-log file is corrupted. mysqld_safe must send its own notices and errors, together with messages it receives from mysqld, to one destination. The two switches below select different destinations:
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problems
| Setting | Destination selected | Effect |
|---|---|---|
--log-error=file_name |
An error-log file | Messages are written to the specified path. If no path is supplied, MySQL can use the default host_name.err file in the data directory. |
--syslog |
The operating system’s syslog facility | Messages are handed to the system logger rather than a mysqld_safe error-log file. |
--skip-syslog |
File logging | Suppresses syslog and writes to the default error-log file or to the file named by --log-error. |
MySQL Bug #72598 records this exact startup failure. The fix is to leave only one destination in the complete startup configuration. A setting in an included option file, a systemd drop-in, or a service command line can conflict with a setting you edited elsewhere.
First determine how MySQL is started
Do this before changing an option file. The correct fix depends on whether a wrapper called mysqld_safe launches the server or whether a service manager launches mysqld directly.
#1 Best Overall
Check the service unit
On a systemd host, inspect the service and its drop-in files. The service may be named mysql.service or mysqld.service, depending on the package.
- Run
systemctl status mysql. If that unit does not exist, trysystemctl status mysqld. - Display the complete unit, including drop-ins, with
systemctl cat mysql.service(or the actual unit name). - Read the
ExecStartline. If it launchesmysqlddirectly, mysqld_safe is not the component choosing the destination.
Confirm the running command line as well, for example with ps -ef | grep '[m]ysqld'. A package can install mysqld_safe even when the enabled service never uses it.
Free tools Windows power users keep installed
One-click scans. No signup required.
Why the distinction matters
With systemd packaging, mysqld_safe may be unnecessary, absent, or bypassed. The MySQL 8.4 documentation warns that [mysqld_safe] and [safe_mysqld] option-file sections are unsupported or can behave unexpectedly when systemd starts the server. In that arrangement, configure the systemd unit and mysqld’s own logging settings instead of trying to repair a mysqld_safe command that is not running.
Find every setting that chooses a destination
Search all option files, included directories, service overrides, and manually supplied arguments for the three relevant names: syslog, skip-syslog, and log-error. Do not stop after finding the first occurrence; an included file can override the file you normally edit.
Option files
Review the files used by your installation, such as /etc/my.cnf, /etc/mysql/my.cnf, and files in an included conf.d or my.cnf.d directory. A read-only search can help locate all occurrences:
grep -RniE '(^|[[:space:]])(syslog|skip-syslog|log-error)' /etc/my.cnf /etc/mysql /etc/my.cnf.d 2>/dev/null
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Also inspect the service’s ExecStart arguments and any systemd drop-in under /etc/systemd/system. A command-line --syslog can override an apparently correct file configuration.
Keep one destination
- For file logging, remove
--syslogand retain a singlelog-errorvalue, or rely on the default error file. Add--skip-syslogwhen you want to make suppression of syslog explicit. - For system logging, remove the file destination that causes the collision and use MySQL’s native system-log support. Do not leave a second
log-errorsetting in another option group or service argument. - Do not treat
--skip-syslogand--syslogas complementary switches. They express opposite choices; the effective configuration must select one destination.
Fix the configuration for an error-log file
Choose this path when administrators need a conventional file for tailing, application-specific collection, or a file-rotation policy.
- In the option group used by the process that actually starts MySQL, remove
--syslog. - Set
log-error=/path/to/error.login the appropriate server option group if you need a fixed path. If you omit it, MySQL can use the defaulthost_name.errfile in the data directory. - Use
--skip-syslogas an explicit mysqld_safe switch when mysqld_safe is genuinely being used. The current MySQL 8.4 manual states that this switch suppresses syslog and selects the default error file or the file named by--log-error. - Check that the directory exists and that the account running mysqld can create and write the file. A syntactically correct path still fails if its parent directory or permissions are wrong.
- Restart through the normal manager: for example,
systemctl restart mysqlorsystemctl restart mysqld, using the unit that was active in the first step. - Verify the result by opening the configured file or running
tail -n 50 /path/to/error.log. Confirm that a new startup timestamp appears after the restart.
When mysqld_safe is used, it arranges for its own error and notice messages and mysqld’s messages to go to the same selected destination. File rotation, retention, permissions, and disk-space monitoring are therefore part of the file-logging administration work.
Fix the configuration for syslog or journald
Choose system logging when your operating system already centralizes service messages, applies a standard retention policy, or exposes them through a journal. The exact storage location is controlled by the system logger, not by a universal MySQL filename.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →- Remove the file destination that conflicts with syslog, including a
log-errorargument supplied by the mysqld_safe command or service unit. - Use MySQL’s native system-log support in the server configuration. This is the forward-looking method in current MySQL documentation; the mysqld_safe
--syslogand--skip-syslogcontrols are deprecated. - Reload or restart using the same service manager that normally starts the server. If you changed a systemd unit or drop-in, run
systemctl daemon-reloadbefore the restart. - Check the system destination. For a systemd unit, start with
journalctl -u mysql.service -bor the actual unit name. On systems using a traditional syslog daemon, consult that daemon’s configured facility and destination files.
A journal entry does not prove that file logging is enabled. Services can send errors to stderr, and a service manager may capture that stream in the journal even when the selected MySQL destination is a file. Verify the configured destination directly.
File logging versus system logging
The choice is operational as well as syntactic. The following comparison uses the configuration ownership and maintenance responsibilities that matter when removing the conflict.
| Consideration | Error-log file | Syslog or journald |
|---|---|---|
| Destination | A path set by log-error, or the default host_name.err in the data directory |
The operating system’s logger, such as a journal or traditional syslog daemon |
| Configuration owner | mysqld_safe when it is the launcher, plus mysqld’s log-error setting |
Prefer MySQL’s native server system-log support; mysqld_safe controls are legacy and deprecated |
| Operational visibility | Direct file tools such as tail, file collectors, and editors |
Journal or syslog tools, filters, facilities, and service-unit views |
| Rotation and retention | Must be planned for the selected file, its owner, disk usage, and rotation process | Handled by the system logger’s rules and retention policy |
| Compatibility with systemd packaging | Works when the active service starts a process configured for file logging; mysqld_safe sections may be ignored when systemd starts mysqld directly | Fits a systemd-managed service when native server logging and the unit’s journal capture are configured consistently |
Where the error log is when syslog is enabled
There may be no MySQL error-log file at all. With syslog selected, messages go to the system logger, whose final location depends on the operating system and its logging rules. On a systemd installation, query the MySQL unit’s journal, for example:
journalctl -u mysql.service --since today
If the service is named differently, substitute that unit name. On a host using rsyslog, syslog-ng, or another traditional daemon, inspect the daemon’s configured rules for the facility and destination used by MySQL. Do not assume that a familiar path such as a particular file under /var/log applies to every distribution.
The MySQL 8.4 behavior is also important when diagnosing startup output: notices go to the selected destination and stdout, while errors go to the selected destination and stderr. A systemd journal can therefore contain stderr or stdout from a startup attempt even when the configured persistent destination is a file.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Troubleshoot the common failure branches
The same conflict appears after editing one file
The process is probably reading another option file or receiving a command-line override. Recheck every included directory, the complete output of systemctl cat, and any wrapper script. Search specifically for both spellings, syslog and skip-syslog, as well as every log-error entry. Restart only after removing the unwanted destination from the configuration path that actually launches MySQL.
The service starts, but no expected file is created
First confirm that the active process uses file logging rather than native syslog. Then check the exact log-error path, the data directory’s default host_name.err location, parent-directory permissions, and available disk space. If systemd starts mysqld directly, a [mysqld_safe] setting will not select the file.
The journal contains messages although file logging was selected
This can be normal for startup diagnostics because errors are also written to stderr and notices to stdout. Determine whether the configured error file is receiving new entries; do not infer the active destination from a journal line alone.
The file and syslog both appear to receive messages
Inspect whether one stream is merely captured by the service manager while the selected destination is elsewhere. Also look for two separate processes or two startup attempts. mysqld_safe’s rule is one destination for its managed messages; remove duplicate launchers and conflicting arguments before deciding that simultaneous persistent logging is configured.
A systemd service ignores mysqld_safe options
That indicates a startup-path mismatch rather than a malformed switch. Move the setting to the systemd unit or mysqld’s native logging configuration, then reload the unit and restart it. Do not rely on unsupported or unexpected [mysqld_safe] or [safe_mysqld] sections in a systemd-managed installation.
What changes in MySQL 8.4 and later administration
The current MySQL 8.4 manual makes three points that guide a durable fix:
- If none of the destination options is supplied to mysqld_safe, the default is
--skip-syslog, so file logging is the default behavior for that wrapper. --syslogand--skip-syslogare deprecated mysqld_safe controls.- Controlling mysqld logging from mysqld_safe is deprecated; native server syslog support is the recommended direction.
For a legacy installation that still invokes mysqld_safe, selecting exactly one destination resolves the immediate startup error. For a systemd-managed or newly maintained installation, configure logging at the server and service-manager layers instead of building new dependencies on mysqld_safe.
Quick Recap
Final verification checklist
- Identify whether mysqld_safe is actually running or whether systemd launches mysqld directly.
- Search all option files, include directories, service units, drop-ins, and command-line overrides.
- Choose one destination: a file or the system logger.
- For a file, remove
--syslog, setlog-errorif needed, and use--skip-syslogexplicitly when mysqld_safe is in use. - For syslog, remove the conflicting file destination and configure native server system logging.
- Restart through the normal service manager and reload systemd configuration when a unit changed.
- Verify the selected destination directly: inspect the error file, or query the journal/syslog facility.
- Check ownership, permissions, rotation, retention, and disk space for whichever destination remains.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
