Uploaded image for project: 'MariaDB MaxScale'
  1. MariaDB MaxScale
  2. MXS-6923

maxctrl2 aborts with unhandled exception when CWD is on a read-only filesystem

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Duplicate
    • 25.10.3
    • 25.10.4
    • maxctrl
    • 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

          Activity

            People

              johan.wikman Johan Wikman
              Emilio.Alvarez Emilio Alvarez Rosendo
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0d
                  0d
                  Logged:
                  Time Spent - 1h
                  1h

                  Git Integration

                    Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.