Closed ottok closed 2 years ago
No responses in 3 months. Anyway, rebased on latest 4.x.
No responses in in a year. Anyway, rebased on latest 4.x.
I am considering putting this fix in Debian since it seems correct and upstream inclusion so far is just due to lack of review. https://salsa.debian.org/mariadb-team/galera-4/-/merge_requests/7
The test suite needs some kind of adaptation to not use the absolute path in base_dir but instead a relative one for the duration of the test run. Can you please advice what would be the best way to do it?
Test failure (test only, a real system installation will work correctly):
Running tests...
/usr/bin/ctest --force-new-ctest-process --output-on-failure
Test project /builds/mariadb-team/galera-4/debian/output/source_dir/obj-x86_64-linux-gnu
Start 1: gu_tests
1/7 Test #1: gu_tests ......................... Passed 3.32 sec
Start 2: gu_tests++
2/7 Test #2: gu_tests++ ....................... Passed 1.37 sec
Start 3: check_gcomm
3/7 Test #3: check_gcomm ......................***Failed 0.70 sec
Running suite(s): fair_send_queue
util
types
gcomm::evs
gcomm::pc
98%: Checks: 88, Failures: 1, Errors: 0
./gcomm/test/check_util.cpp:177:F:test_view_state:test_view_state:0: Assertion 'vst == vst3' failed
Start 4: gcache_tests
4/7 Test #4: gcache_tests ..................... Passed 0.01 sec
Start 5: gcs_tests
5/7 Test #5: gcs_tests ........................ Passed 8.95 sec
Start 6: galera_check
6/7 Test #6: galera_check .....................***Failed 2.87 sec
Running suite(s): DataSet
100%: Checks: 2, Failures: 0, Errors: 0
Running suite(s): KeySet
100%: Checks: 4, Failures: 0, Errors: 0
Running suite(s): WriteSet
100%: Checks: 5, Failures: 0, Errors: 0
Running suite(s): certification
100%: Checks: 6, Failures: 0, Errors: 0
Running suite(s): trx_handle
100%: Checks: 4, Failures: 0, Errors: 0
Running suite(s): service_thd
100%: Checks: 3, Failures: 0, Errors: 0
Running suite(s): ist
100%: Checks: 14, Failures: 0, Errors: 0
Running suite(s): saved_state
100%: Checks: 3, Failures: 0, Errors: 0
Running suite(s): Defaults
Could not open state file for writing: '/var/lib/galera/grastate.dat'. Check permissions and/or disk space.: 2 (No such file or directory)
at ./galera/src/saved_state.cpp:SavedState():51
0%: Checks: 1, Failures: 1, Errors: 0
./galera/tests/defaults_check.cpp:276:F:defaults:defaults:0: Assertion 'WSREP_OK == ret' failed
Running suite(s): progress_suite
100%: Checks: 1, Failures: 0, Errors: 0
Total tests failed: 1
Start 7: wsrep_test
7/7 Test #7: wsrep_test ....................... Passed 0.01 sec
71% tests passed, 2 tests failed out of 7
Total Test time (real) = 17.24 sec
The following tests FAILED:
3 - check_gcomm (Failed)
6 - galera_check (Failed)
Errors while running CTest
Hi,
Modifying COMMON_BASE_DIR_DEFAULT
will affect both garbd and Galera library, so it is not likely the best solution.
Would this be solvable by changing the working directory in systemd service file: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#WorkingDirectory=.
Makes sense. Feel free to close this PR as rejected. Somebody should make a new attempt at it via the systemd and init.d default path method.
The old default value '.' often translate simply to system root '/' when garbd (most often) is run from a system init/service file that has no path or is just '/' to begin with. This is a bad default, garbd should not imply that it wants to write to file system root.
Many users seem to set this manually to /var/lib/galera or /var/lib/garb. On Debian/Ubuntu systems I've seen users set in /etc/default/garbd: GALERA_OPTIONS="base_dir=/var/lib/galera/"
This change in the global default will render such hacks unnecessary.