Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Duplicate
-
25.10.3
-
None
Description
Summary
--------
maxctrl2 crashes with an unhandled C++ exception and aborts (core dump when
ulimit permits) whenever its current working directory is on a read-only
filesystem. The tool writes its log file to ./maxctrl2.log (relative to
CWD), and any failure to open that file for writing is fatal to the whole
process, even for commands like --help or --version that have no
functional need to write a log at all.
Environment
-----------
- MaxScale 25.10.3-2, maxctrl2 package (maxscale-maxctrl2)
- Reported OS: Rocky Linux (customer)
- Reproduced OS: Debian (internal)
- Reproduced as: root (permission bits are not sufficient to reproduce, see
Reproduction Notes)
Steps to Reproduce
-------------------
1. Create a directory on a filesystem mounted read-only:
mkdir -p /mnt/ro-test
mount -t tmpfs tmpfs /mnt/ro-test
mount -o remount,ro /mnt/ro-test
2. cd /mnt/ro-test
3. Run any maxctrl2 command, e.g.:
maxctrl2 --help
Actual Result
-------------
Failed to open file './maxctrl2.log': 30, Read-only file system
terminate called after throwing an instance of 'std::runtime_error'
what(): Failed to initialize the log.
Aborted (core dumped)
Process exits via abort(), not a clean CLI error path.
Expected Result
----------------
maxctrl2 should not crash due to an inability to write its own log file.
At minimum, the failure should be caught and reported as a normal CLI
error with a non-zero exit code, without a stack unwind abort or core
dump.
Reproduction Notes
-------------------
- Customer's original session was a non-root shell (bash-4.4$), consistent
with a read-only root filesystem or read-only bind-mounted working
directory, common in hardened or immutable OS images and some container
or cloud VM base images. Customer's deployment was tagged "Other Cloud
Provider."
Workaround
-----------
Run maxctrl2 from a directory on a writable filesystem (e.g. the user's
home directory or /tmp) instead of a read-only mounted CWD. This avoids
the crash entirely and lets the tool function normally. No config change
or flag is required, since maxctrl2 currently has no option to set the
log path directly.
Attachments
Issue Links
- duplicates
-
MXS-6616 maxctrl2 terminates if invoked in directory without write rights
-
- Closed
-