* [devel] Fwd: [cyber] I: Sisyphus-20190827 x86_64 beehive_status: +34 -5 (105) @ 2019-08-28 8:27 ` Levin Stanislav 2019-08-28 9:04 ` [devel] /dev/shm Dmitry V. Levin 0 siblings, 1 reply; 32+ messages in thread From: Levin Stanislav @ 2019-08-28 8:27 UTC (permalink / raw) To: ALT Linux Team development discussions [-- Attachment #1.1: Type: text/plain, Size: 23370 bytes --] Здравствуйте! Вчерашняя пересборка показала вероятное изменение на сборочных машинах x86_64 и i586, а именно возможность обращения "на запись" пользователю "builder" к "/dev/shm" ( без указания в сборочных зависимостях "/dev/shm" ). Для x86_64 и i586: + id uid=523(builder) gid=523(builder) groups=523(builder) + ls -ld /dev/shm drwxr-xr-x 2 root root 40 Aug 27 19:02 /dev/shm Для ppc64le и aarch64: + id uid=523(builder) gid=523(builder) groups=523(builder) + ls -ld /dev/shm drwxrwxrwt 2 caller rooter 40 Aug 27 19:01 /dev/shm При добавлении к BR "/dev/shm" ожидания оправдываются: + id uid=517(builder) gid=517(builder) groups=517(builder) + ls -ld /dev/shm drwxrwxrwt 2 root root 40 Aug 28 07:00 /dev/shm Но, к сожалению, на aarch64 "/dev/shm" (пока что?) не разрешена: Building target platforms: aarch64 Building for target aarch64 Wrote: /usr/src/in/nosrpm/py-1.8.0-alt5.nosrc.rpm hasher-priv: mount: /dev/shm: mount point not allowed hsh-rebuild: rebuild of `pkg.tar' failed. Возникло несколько вопросов: 1) Как именно достигнуто указанное ниже состояние и для чего. Будет ли теперь это попадать под категорию "так задумано"? без BR: /dev/shm + ls -ld /dev/shm drwxr-xr-x 2 root root 40 Aug 27 19:02 /dev/shm /Примечание: интересуюсь для настройки локальной сборочницы в соответствии с главной./ 2) Нельзя ли применить одинаковые настройки (насколько это возможно и целесообразно) на всех платформах для сборки. 3) Ну и, конечно, в идеале ( как уже многие просили ) опубликовать настройки сборочного окружения, которые могут вызывать отличающиеся (относительно локального) результаты сборки. Спасибо! -------- Перенаправленное сообщение -------- Тема: [cyber] I: Sisyphus-20190827 x86_64 beehive_status: +34 -5 (105) Дата: Tue, 27 Aug 2019 06:23:39 +0000 От: ALT beekeeper <hiver@altlinux.org> Отвечать: devel@lists.altlinux.org Кому: sisyphus-cybertalk@lists.altlinux.org 34 NEW error logs Perlbal-1.80-alt1 Result: FAIL Failed 1/25 test programs. 0/533 subtests failed. make: *** [Makefile:852: test_dynamic] Error 255 Uranium-3.6.0-alt3 > unlink_now) E PermissionError: [Errno 13] Permission denied /usr/lib64/python3.7/multiprocessing/synchronize.py:59: PermissionError cjdns-20.3-alt1 if (err) { throw err; } Error: gcc -Wl,-z,relro,-z,now,-z,noexecstack -pie -flto -O0 -o build_linux/contrib_c_privatetopublic_c build_linux/util_Assert_c.o,build_linux/util_Bits_c.o,build_linux/crypto_AddressCalc_c.o,build_linux/memory_Allocator_c.o,build_linux/util_CString_c.o,build_linux/benc_String_c.o,build_linux/exception_Except_c.o,build_linux/util_log_Log_c.o,build_linux/crypto_random_seed_RandomSeed_c.o,build_linux/crypto_random_seed_DevUrandomRandomSeed_c.o,build_linux/util_Hex_c.o,build_linux/crypto_random_seed_LinuxRandomUuidSysctlRandomSeed_c.o,build_linux/crypto_random_seed_ProcSysKernelRandomUuidRandomSeed_c.o,build_linux/crypto_random_seed_GetEntropyRandomSeed_c.o,build_linux/crypto_random_seed_SystemRandomSeed_c.o,build_linux/crypto_random_Random_c.o,build_linux/crypto_Key_c.o,build_linux/util_Base10_c.o,build_linux/util_platform_Sockaddr_c.o,build_linux/util_AddrTools_c.o,build_linux/dht_Address_c.o,build_linux/contrib_c_privatetopublic_c.o build_linux/dependencies/cnacl/jsbuild/libnacl.a,build_linux/dependencies/libuv/out/Release/libuv.a,-lpthread,-lrt x86_64-alt-linux-gcc: error: build_linux/dependencies/libuv/out/Release/libuv.a: No such file or directory at error (/usr/src/RPM/BUILD/cjdns-20.3/node_build/builder.js:53:15) firefox-68.0.1-alt1 0:20.20 sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) 0:20.20 OSError: [Errno 13] Permission denied 0:20.28 *** Fix above errors and then restart with\ firefox-esr-68.0.2-alt1 1:30.13 sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) 1:30.13 OSError: [Errno 13] Permission denied 1:30.50 *** Fix above errors and then restart with\ glibc-6:2.27-alt10 XPASS: elf/tst-protected1b FAIL: io/tst-copy_file_range FAIL: io/tst-copy_file_range-compat UNSUPPORTED: io/tst-getcwd-abspath FAIL: io/tst-open-tmpfile UNSUPPORTED: math/test-double-libmvec-alias-avx512 -- UNSUPPORTED: resolv/tst-resolv-threads FAIL: rt/tst-shm UNSUPPORTED: rt/tst-shm-cancel -- + rc=2 + grep '^FAIL:' build-x86_64-linux/tests.sum + cut '-d ' -f2- -- ==> build-x86_64-linux/io/tst-copy_file_range.test-result <== FAIL: io/tst-copy_file_range original exit status 1 -- info: using alternate temporary files directory: /dev/shm error: tst-copy_file_range.c:778: mkstemp ("/dev/shm/tst-copy_file_range-xdev-Wut34a"): Permission denied error: 1 test failures ==> build-x86_64-linux/io/tst-copy_file_range-compat.test-result <== FAIL: io/tst-copy_file_range-compat original exit status 1 -- info: using alternate temporary files directory: /dev/shm error: tst-copy_file_range.c:778: mkstemp ("/dev/shm/tst-copy_file_range-xdev-5jVDDn"): Permission denied error: 1 test failures libabigail-1.2-alt1 mkdir(name, mode) OSError: [Errno 17] File exists: '/usr/src/RPM/BUILD/libabigail-1.2/doc/manuals/doctrees' The full traceback has been saved in /usr/src/tmp/sphinx-err-Ma3Wkq.log, if you want to report the issue to the developers. libmozjs60-60.1.0-alt1 sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) OSError: [Errno 13] Permission denied librabbitmq-c-0.9.0-alt1 [ 15%] Building C object librabbitmq/CMakeFiles/rabbitmq-static.dir/amqp_framing.c.o /usr/src/RPM/BUILD/librabbitmq-c-0.9.0/BUILD/librabbitmq/amqp_framing.c:1981:1: error: unterminated comment make[2]: *** [librabbitmq/CMakeFiles/rabbitmq-static.dir/build.make:83: librabbitmq/CMakeFiles/rabbitmq-static.dir/amqp_framing.c.o] Error 1 perl-Net-Server-Mail-0.28-alt1 t/smtp.t ...... ok # Error: Can't call method "peerhost" on an undefined value at t/starttls.t line 131. # kill 9, 79903 (server) -- Result: FAIL Failed 1/4 test programs. 0/33 subtests failed. make: *** [Makefile:783: test_dynamic] Error 255 pki-core-10.7.0-alt2 unlink_now) PermissionError: [Errno 13] Permission denied ERROR: InvocationError for command /usr/src/RPM/BUILD/pki-core-10.7.0/.tox/pep8py3/bin/flake8 (exited with code 1) ERROR: invocation failed (exit code 1) ✖ FAIL pep8py3 in 11.02 seconds -- lint3: commands succeeded ERROR: pep8py3: parallel child exit code 1 py37: commands succeeded py-1.8.0-alt4 reason: svn-1.7 has buggy 'status --xml' output FAILED testing/path/test_local.py::TestLocalPath::test_make_numbered_dir_multiprocess_safe == 1 failed, 799 passed, 41 skipped, 16 xfailed, 7 warnings in 35.91 seconds === ..ERROR: InvocationError for command /usr/src/RPM/BUILD/py-1.8.0/.tox/py27/bin/py.test --confcutdir=. --junitxml=/usr/src/RPM/BUILD/py-1.8.0/.tox/py27/log/junit-py27.xml (exited with code 1) ERROR: invocation failed (exit code 1) ✖ FAIL py27 in 60.246 seconds -- > unlink_now) E PermissionError: [Errno 13] Permission denied /usr/lib64/python3.7/multiprocessing/synchronize.py:59: PermissionError -- reason: svn-1.7 has buggy 'status --xml' output FAILED testing/path/test_local.py::TestLocalPath::test_make_numbered_dir_multiprocess_safe ====== 1 failed, 798 passed, 43 skipped, 16 xfailed, 5 warnings in 35.25s ====== ERROR: InvocationError for command /usr/src/RPM/BUILD/py-1.8.0/.tox/py37/bin/py.test --confcutdir=. --junitxml=/usr/src/RPM/BUILD/py-1.8.0/.tox/py37/log/junit-py37.xml (exited with code 1) ERROR: invocation failed (exit code 1) ✖ FAIL py37 in 1 minute, 7.833 seconds ___________________________________ summary ____________________________________ ERROR: py27: parallel child exit code 1 ERROR: py37: parallel child exit code 1 python-module-affine-2.0.0.post1-alt2.1 affine/tests/test_pickle.py::test_pickle PASSED [ 1%] affine/tests/test_pickle.py::test_with_multiprocessing FAILED [ 3%] affine/tests/test_rotation.py::test_rotation_angle PASSED [ 5%] -- > sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) E OSError: [Errno 13] Permission denied /usr/lib64/python2.7/multiprocessing/synchronize.py:75: OSError python-module-billiard-3.6.0-alt1 > kind, value, maxvalue, self._make_name(), unlink_now, E OSError: [Errno 13] Permission denied billiard/synchronize.py:72: OSError -- > kind, value, maxvalue, self._make_name(), unlink_now, E OSError: [Errno 13] Permission denied billiard/synchronize.py:72: OSError -- > kind, value, maxvalue, self._make_name(), unlink_now, E OSError: [Errno 13] Permission denied billiard/synchronize.py:72: OSError -- > kind, value, maxvalue, self._make_name(), unlink_now, E OSError: [Errno 13] Permission denied billiard/synchronize.py:72: OSError -- > kind, value, maxvalue, self._make_name(), unlink_now, E OSError: [Errno 13] Permission denied billiard/synchronize.py:72: OSError python-module-coverage-4.5.4-alt2 unlink_now) PermissionError: [Errno 13] Permission denied ----------------------------- Captured stdout call ----------------------------- -- unlink_now) PermissionError: [Errno 13] Permission denied ----------------------------- Captured stdout call ----------------------------- -- unlink_now) PermissionError: [Errno 13] Permission denied ----------------------------- Captured stdout call ----------------------------- -- unlink_now) PermissionError: [Errno 13] Permission denied ----------------------------- Captured stdout call ----------------------------- -- unlink_now) PermissionError: [Errno 13] Permission denied ----------------------------- Captured stdout call ----------------------------- -- unlink_now) PermissionError: [Errno 13] Permission denied ----------------------------- Captured stdout call ----------------------------- -- unlink_now) PermissionError: [Errno 13] Permission denied ----------------------------- Captured stdout call ----------------------------- -- unlink_now) PermissionError: [Errno 13] Permission denied =========================== short test summary info ============================ FAILED tests/test_concurrency.py::MultiprocessingTest::test_multiprocessing_with_branching FAILED tests/test_concurrency.py::MultiprocessingTest::test_multiprocessing 2 failed, 756 passed, 39 skipped in 153.30s (0:02:33) python-module-etcd-0.4.5-alt3.S1 > sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) E OSError: [Errno 13] Permission denied /usr/lib64/python2.7/multiprocessing/synchronize.py:75: OSError -- > sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) E OSError: [Errno 13] Permission denied /usr/lib64/python2.7/multiprocessing/synchronize.py:75: OSError -- > sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) E OSError: [Errno 13] Permission denied /usr/lib64/python2.7/multiprocessing/synchronize.py:75: OSError python-module-fs-2.2.1-alt1 test_writetext (tests.test_zipfs.TestWriteZipFS) ... ok ERROR: test_raise_in_multiprocessing (tests.test_errors.TestErrors) Traceback (most recent call last): -- pool.close() UnboundLocalError: local variable 'pool' referenced before assignment ERROR: test suite for <class 'tests.test_ftpfs.TestFTPFS'> Traceback (most recent call last): -- ls.append(pyftpdlib.servers.MultiprocessFTPServer) AttributeError: 'module' object has no attribute 'MultiprocessFTPServer' -------------------- >> begin captured logging << -------------------- -- --------------------- >> end captured logging << --------------------- ERROR: test suite for <class 'tests.test_ftpfs.TestFTPFSNoMLSD'> Traceback (most recent call last): -- ls.append(pyftpdlib.servers.MultiprocessFTPServer) AttributeError: 'module' object has no attribute 'MultiprocessFTPServer' -------------------- >> begin captured logging << -------------------- -- Ran 1636 tests in 38.858s FAILED (SKIP=100, errors=3) ERROR: InvocationError for command /usr/src/RPM/BUILD/python-module-fs-2.2.1/.tox/py27/bin/nosetests --with-coverage --cover-package=fs --cover-package=fs.opener tests -v (exited with code 1) ___________________________________ summary ____________________________________ ERROR: py27: commands failed python-module-matplotlib-2.2.3-alt3 unlink_now) PermissionError: [Errno 13] Permission denied During handling of the above exception, another exception occurred: -- from PyQt4 import QtCore ValueError: PyCapsule_GetPointer called with incorrect name error: Bad exit status from /usr/src/tmp/rpm-tmp.82446 (%build) python-module-oauth2client-4.1.3-alt1 > sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) E OSError: [Errno 13] Permission denied /usr/lib64/python2.7/multiprocessing/synchronize.py:75: OSError -- > sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) E OSError: [Errno 13] Permission denied /usr/lib64/python2.7/multiprocessing/synchronize.py:75: OSError python-module-parallel-collections-0.2.3-alt1.git20141027.1 sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) OSError: [Errno 13] Permission denied python-module-pebble-4.3.7-alt1.git20180228 E OSError: [Errno 13] Permission denied /usr/lib64/python2.7/multiprocessing/synchronize.py:75: OSError -- > sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) E OSError: [Errno 13] Permission denied /usr/lib64/python2.7/multiprocessing/synchronize.py:75: OSError -- > sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) E OSError: [Errno 13] Permission denied /usr/lib64/python2.7/multiprocessing/synchronize.py:75: OSError -- > sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) E OSError: [Errno 13] Permission denied /usr/lib64/python2.7/multiprocessing/synchronize.py:75: OSError -- > sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) E OSError: [Errno 13] Permission denied /usr/lib64/python2.7/multiprocessing/synchronize.py:75: OSError -- > sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) E OSError: [Errno 13] Permission denied /usr/lib64/python2.7/multiprocessing/synchronize.py:75: OSError python-module-pexpect-4.6-alt3 > sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) E OSError: [Errno 13] Permission denied /usr/lib64/python2.7/multiprocessing/synchronize.py:75: OSError -- > sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) E OSError: [Errno 13] Permission denied /usr/lib64/python2.7/multiprocessing/synchronize.py:75: OSError -- > sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) E OSError: [Errno 13] Permission denied /usr/lib64/python2.7/multiprocessing/synchronize.py:75: OSError python-module-pycrypto-2.7-alt3.a1.git20140620.1.1.1.1 ..E..................................................... ERROR: runTest (Crypto.SelfTest.Random.test__UserFriendlyRNG.RNGMultiprocessingForkTest) Traceback (most recent call last): -- sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) OSError: [Errno 13] Permission denied Ran 1891 tests in 38.175s FAILED (errors=1) Traceback (most recent call last): -- raise SelfTestError("Self-test failed", result) Crypto.SelfTest.SelfTestError: ('Self-test failed', <unittest.runner.TextTestResult run=1891 errors=1 failures=0>) python-module-pygame-1.9.4-alt1 sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) OSError: [Errno 13] Permission denied python-module-setuptools-1:41.2.0-alt1 > sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) E OSError: [Errno 13] Permission denied /usr/lib64/python2.7/multiprocessing/synchronize.py:75: OSError -- > sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) E OSError: [Errno 13] Permission denied /usr/lib64/python2.7/multiprocessing/synchronize.py:75: OSError -- > sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) E OSError: [Errno 13] Permission denied /usr/lib64/python2.7/multiprocessing/synchronize.py:75: OSError -- = 56 failed, 517 passed, 39 skipped, 8 xfailed, 1 xpassed, 1 warnings, 64 error in 282.96 seconds = ERROR: InvocationError for command /usr/src/RPM/BUILD/python-module-setuptools-41.2.0/.tox/py27/bin/pytest --cov-config=/usr/src/RPM/BUILD/python-module-setuptools-41.2.0/tox.ini --cov-report= (exited with code 1) ERROR: invocation failed (exit code 1) ✖ FAIL py27 in 5 minutes, 6.812 seconds ___________________________________ summary ____________________________________ ERROR: py27: parallel child exit code 1 ERROR: py37: parallel child exit code 1 python-module-tlslite-ng-0.7.5-alt1 sock.connect(sa) ConnectionRefusedError: [Errno 111] Connection refused error: Bad exit status from /usr/src/tmp/rpm-tmp.26737 (%check) python-module-waitress-1.2.1-alt2 unlink_now) PermissionError: [Errno 13] Permission denied ERROR: test_request_body_too_large_with_wrong_cl_http10 (waitress.tests.test_functional.UnixTooLargeTests) Traceback (most recent call last): -- unlink_now) PermissionError: [Errno 13] Permission denied ERROR: test_request_body_too_large_with_wrong_cl_http10_keepalive (waitress.tests.test_functional.UnixTooLargeTests) Traceback (most recent call last): -- unlink_now) PermissionError: [Errno 13] Permission denied ERROR: test_request_body_too_large_with_wrong_cl_http11 (waitress.tests.test_functional.UnixTooLargeTests) Traceback (most recent call last): -- unlink_now) PermissionError: [Errno 13] Permission denied ERROR: test_request_body_too_large_with_wrong_cl_http11_connclose (waitress.tests.test_functional.UnixTooLargeTests) Traceback (most recent call last): -- unlink_now) PermissionError: [Errno 13] Permission denied ERROR: test_equal_body (waitress.tests.test_functional.UnixWriteCallbackTests) Traceback (most recent call last): python-module-zc.thread-0.1.0-alt1.znanja1.git20120922.1.1.1 test_Process_w_mock (zc.thread.tests.TestThread) ... ok test_Process_wo_mock (zc.thread.tests.TestThread) ... ERROR test_Thread_wo_mock (zc.thread.tests.TestThread) ... ok -- test_undecorated_and_exception_return (zc.thread.tests.TestThread) ... ok ERROR: test_Process_wo_mock (zc.thread.tests.TestThread) Traceback (most recent call last): -- sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) OSError: [Errno 13] Permission denied Ran 6 tests in 0.048s FAILED (errors=1) Test failed: <unittest.runner.TextTestResult run=6 errors=1 failures=0> foo called foo3 called error: Test failed: <unittest.runner.TextTestResult run=6 errors=1 failures=0> python3-3.7.4-alt1 id2obj(a_id) except KeyError: print('OK') python3-module-Quamash-0.6.1-alt1 + xvfb-run py.test3 -v _XSERVTransmkdir: ERROR: euid != 0,directory /tmp/.X11-unix will not be created. The XKEYBOARD keymap compiler (xkbcomp) reports: -- tests/test_qeventloop.py::TestCanRunTasksInExecutor::test_can_run_tasks_in_executor[ThreadPoolExecutor] PASSED [ 11%] tests/test_qeventloop.py::TestCanRunTasksInExecutor::test_can_run_tasks_in_executor[ProcessPoolExecutor] ERROR [ 13%] tests/test_qeventloop.py::TestCanRunTasksInExecutor::test_can_handle_exception_in_executor[None] PASSED [ 15%] -- tests/test_qeventloop.py::TestCanRunTasksInExecutor::test_can_handle_exception_in_executor[ThreadPoolExecutor] PASSED [ 20%] tests/test_qeventloop.py::TestCanRunTasksInExecutor::test_can_handle_exception_in_executor[ProcessPoolExecutor] ERROR [ 22%] tests/test_qeventloop.py::test_can_execute_subprocess PASSED [ 24%] -- ==================================== ERRORS ==================================== _ ERROR at setup of TestCanRunTasksInExecutor.test_can_run_tasks_in_executor[ProcessPoolExecutor] _ request = <SubRequest 'executor' for <Function test_can_run_tasks_in_executor[ProcessPoolExecutor]>> -- > unlink_now) E PermissionError: [Errno 13] Permission denied /usr/lib64/python3.7/multiprocessing/synchronize.py:59: PermissionError -- DEBUG asyncio:selector_events.py:53 Using selector: _Selector _ ERROR at setup of TestCanRunTasksInExecutor.test_can_handle_exception_in_executor[ProcessPoolExecutor] _ request = <SubRequest 'executor' for <Function test_can_handle_exception_in_executor[ProcessPoolExecutor]>> -- > unlink_now) E PermissionError: [Errno 13] Permission denied /usr/lib64/python3.7/multiprocessing/synchronize.py:59: PermissionError python3-module-pytest-5.1.1-alt1 E and: '> unlink_now)' E and: 'E PermissionError: [Errno 13] Permission denied' E and: '' -- > unlink_now) E PermissionError: [Errno 13] Permission denied /usr/lib64/python3.7/multiprocessing/synchronize.py:59: PermissionError -- is this important to support?? FAILED testing/test_assertion.py::test_exception_handling_no_traceback - Fail... = 1 failed, 2486 passed, 33 skipped, 10 xfailed, 1 warnings in 768.47s (0:12:48) = ERROR: InvocationError for command /usr/src/RPM/BUILD/python3-module-pytest-5.1.1/.tox/py37/bin/pytest (exited with code 1) ___________________________________ summary ____________________________________ ERROR: py37: commands failed error: Bad exit status from /usr/src/tmp/rpm-tmp.9838 (%check) squid-4.8-alt1 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 See src/test-suite.log sssd-2.2.0-alt3 FAIL sysdb-tests (exit status: 1) FAIL: krb5-utils-tests Could not create empty directory [tp_krb5_utils_tests-krb5_utils-tests]. [13][Permission denied]. FAIL krb5-utils-tests (exit status: 1) FAIL: check_and_open-tests Running suite(s): check_and_open -- FAIL check_and_open-tests (exit status: 1) FAIL: files-tests Running suite(s): files_suite -- FAIL files-tests (exit status: 1) FAIL: auth-tests Running suite(s): auth -- FAIL auth-tests (exit status: 1) FAIL: util-tests Running suite(s): util -- FAIL util-tests (exit status: 1) FAIL: debug-tests Running suite(s): debug -- FAIL debug-tests (exit status: 1) FAIL: sysdb_ssh-tests Running suite(s): sysdb_ssh -- # SKIP: 2 # XFAIL: 0 # FAIL: 42 # XPASS: 0 # ERROR: 0 See ./test-suite.log thunderbird-60.8.0-alt1 2:12.01 sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) 2:12.01 OSError: [Errno 13] Permission denied 2:12.43 *** Fix above errors and then restart with\ 5 error logs REMOVED from the list erlang-meck-0.8.13-alt1 jed-2:0.99.19-alt2.qa2.1 python-module-argcomplete-1.9.4-alt2 python-module-pycobertura-0.10.5-alt2 vzmigrate-7.0.124-alt1 Total 105 error logs. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-28 8:27 ` [devel] Fwd: [cyber] I: Sisyphus-20190827 x86_64 beehive_status: +34 -5 (105) Levin Stanislav @ 2019-08-28 9:04 ` Dmitry V. Levin 2019-08-28 9:55 ` Dmitry V. Levin 2019-08-28 13:54 ` Dmitry V. Levin 0 siblings, 2 replies; 32+ messages in thread From: Dmitry V. Levin @ 2019-08-28 9:04 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 1827 bytes --] On Wed, Aug 28, 2019 at 11:27:39AM +0300, Levin Stanislav wrote: > Здравствуйте! > > Вчерашняя пересборка показала вероятное изменение на сборочных машинах > x86_64 и i586, > > а именно возможность обращения "на запись" пользователю "builder" к > "/dev/shm" > > ( без указания в сборочных зависимостях "/dev/shm" ). > > > Для x86_64 и i586: > > + id > uid=523(builder) gid=523(builder) groups=523(builder) > + ls -ld /dev/shm > drwxr-xr-x 2 root root 40 Aug 27 19:02 /dev/shm > > > Для ppc64le и aarch64: > > + id > uid=523(builder) gid=523(builder) groups=523(builder) > + ls -ld /dev/shm > drwxrwxrwt 2 caller rooter 40 Aug 27 19:01 /dev/shm > > > > При добавлении к BR "/dev/shm" ожидания оправдываются: > > + id > uid=517(builder) gid=517(builder) groups=517(builder) > + ls -ld /dev/shm > drwxrwxrwt 2 root root 40 Aug 28 07:00 /dev/shm Да, всё это так. > Но, к сожалению, на aarch64 "/dev/shm" (пока что?) не разрешена: > > Building target platforms: aarch64 > Building for target aarch64 > Wrote: /usr/src/in/nosrpm/py-1.8.0-alt5.nosrc.rpm > hasher-priv: mount: /dev/shm: mount point not allowed > hsh-rebuild: rebuild of `pkg.tar' failed. Fixed. > Возникло несколько вопросов: > > 1) Как именно достигнуто указанное ниже состояние и для чего. Будет ли > теперь это попадать под категорию "так задумано"? Я тестирую новые hasher/hasher-priv из задания #236645, в том числе на масштаб последствий. > без BR: /dev/shm > > + ls -ld /dev/shm > drwxr-xr-x 2 root root 40 Aug 27 19:02 /dev/shm > > /Примечание: интересуюсь для настройки локальной сборочницы в > соответствии с главной./ > > 2) Нельзя ли применить одинаковые настройки (насколько это возможно и > целесообразно) > на всех платформах для сборки. Можно. -- ldv [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-28 9:04 ` [devel] /dev/shm Dmitry V. Levin @ 2019-08-28 9:55 ` Dmitry V. Levin 2019-08-28 9:58 ` Anton Farygin 2019-08-28 10:03 ` Валерий Иноземцев 2019-08-28 13:54 ` Dmitry V. Levin 1 sibling, 2 replies; 32+ messages in thread From: Dmitry V. Levin @ 2019-08-28 9:55 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 512 bytes --] On Wed, Aug 28, 2019 at 12:04:28PM +0300, Dmitry V. Levin wrote: > On Wed, Aug 28, 2019 at 11:27:39AM +0300, Levin Stanislav wrote: [...] > > 2) Нельзя ли применить одинаковые настройки (насколько это возможно и > > целесообразно) > > на всех платформах для сборки. > > Можно. Попытка установить одинаковый hasher на всех платформах привела к тому, что на aarch64 больше ничего не собирается вот с такой диагностикой: hasher-priv: chrootuid: mknod: console: Operation not permitted -- ldv [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-28 9:55 ` Dmitry V. Levin @ 2019-08-28 9:58 ` Anton Farygin 2019-08-28 10:03 ` Валерий Иноземцев 1 sibling, 0 replies; 32+ messages in thread From: Anton Farygin @ 2019-08-28 9:58 UTC (permalink / raw) To: devel On 28.08.2019 12:55, Dmitry V. Levin wrote: > On Wed, Aug 28, 2019 at 12:04:28PM +0300, Dmitry V. Levin wrote: >> On Wed, Aug 28, 2019 at 11:27:39AM +0300, Levin Stanislav wrote: > [...] >>> 2) Нельзя ли применить одинаковые настройки (насколько это возможно и >>> целесообразно) >>> на всех платформах для сборки. >> Можно. > Попытка установить одинаковый hasher на всех платформах привела к тому, > что на aarch64 больше ничего не собирается вот с такой диагностикой: > > hasher-priv: chrootuid: mknod: console: Operation not permitted > Точно, я нарвался. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-28 9:55 ` Dmitry V. Levin 2019-08-28 9:58 ` Anton Farygin @ 2019-08-28 10:03 ` Валерий Иноземцев 2019-08-28 10:13 ` Dmitry V. Levin 1 sibling, 1 reply; 32+ messages in thread From: Валерий Иноземцев @ 2019-08-28 10:03 UTC (permalink / raw) To: devel [-- Attachment #1.1: Type: text/plain, Size: 850 bytes --] 28.08.2019 12:55, Dmitry V. Levin пишет: > On Wed, Aug 28, 2019 at 12:04:28PM +0300, Dmitry V. Levin wrote: >> On Wed, Aug 28, 2019 at 11:27:39AM +0300, Levin Stanislav wrote: > [...] >>> 2) Нельзя ли применить одинаковые настройки (насколько это возможно и >>> целесообразно) >>> на всех платформах для сборки. >> >> Можно. > > Попытка установить одинаковый hasher на всех платформах привела к тому, > что на aarch64 больше ничего не собирается вот с такой диагностикой: > > hasher-priv: chrootuid: mknod: console: Operation not permitted когда ожидать исправления? -- Valery V. Inozemtsev [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-28 10:03 ` Валерий Иноземцев @ 2019-08-28 10:13 ` Dmitry V. Levin 2019-08-28 10:57 ` Dmitry V. Levin 0 siblings, 1 reply; 32+ messages in thread From: Dmitry V. Levin @ 2019-08-28 10:13 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 759 bytes --] On Wed, Aug 28, 2019 at 01:03:38PM +0300, Валерий Иноземцев wrote: > 28.08.2019 12:55, Dmitry V. Levin пишет: > > On Wed, Aug 28, 2019 at 12:04:28PM +0300, Dmitry V. Levin wrote: > >> On Wed, Aug 28, 2019 at 11:27:39AM +0300, Levin Stanislav wrote: > > [...] > >>> 2) Нельзя ли применить одинаковые настройки (насколько это возможно и > >>> целесообразно) > >>> на всех платформах для сборки. > >> > >> Можно. > > > > Попытка установить одинаковый hasher на всех платформах привела к тому, > > что на aarch64 больше ничего не собирается вот с такой диагностикой: > > > > hasher-priv: chrootuid: mknod: console: Operation not permitted > > когда ожидать исправления? Сейчас мы в процессе выяснения, что следует исправлять. -- ldv [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-28 10:13 ` Dmitry V. Levin @ 2019-08-28 10:57 ` Dmitry V. Levin 2019-08-29 0:56 ` Alexey Shabalin 0 siblings, 1 reply; 32+ messages in thread From: Dmitry V. Levin @ 2019-08-28 10:57 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 1122 bytes --] On Wed, Aug 28, 2019 at 01:13:04PM +0300, Dmitry V. Levin wrote: > On Wed, Aug 28, 2019 at 01:03:38PM +0300, Валерий Иноземцев wrote: > > 28.08.2019 12:55, Dmitry V. Levin пишет: > > > On Wed, Aug 28, 2019 at 12:04:28PM +0300, Dmitry V. Levin wrote: > > >> On Wed, Aug 28, 2019 at 11:27:39AM +0300, Levin Stanislav wrote: > > > [...] > > >>> 2) Нельзя ли применить одинаковые настройки (насколько это возможно и > > >>> целесообразно) > > >>> на всех платформах для сборки. > > >> > > >> Можно. К сожалению, нельзя. > > > Попытка установить одинаковый hasher на всех платформах привела к тому, > > > что на aarch64 больше ничего не собирается вот с такой диагностикой: > > > > > > hasher-priv: chrootuid: mknod: console: Operation not permitted > > > > когда ожидать исправления? > > Сейчас мы в процессе выяснения, что следует исправлять. Оказывается, что systemd-nspawn, под управлением которого находятся сборочные узлы aarch64, не позволяет создавать /dev/console с правами 0600. Чтобы разблокировать разработку, я откатил обновление hasher на сборочных узлах aarch64. -- ldv [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-28 10:57 ` Dmitry V. Levin @ 2019-08-29 0:56 ` Alexey Shabalin 0 siblings, 0 replies; 32+ messages in thread From: Alexey Shabalin @ 2019-08-29 0:56 UTC (permalink / raw) To: devel В Ср, 28/08/2019 в 13:57 +0300, Dmitry V. Levin пишет: > On Wed, Aug 28, 2019 at 01:13:04PM +0300, Dmitry V. Levin wrote: > > On Wed, Aug 28, 2019 at 01:03:38PM +0300, Валерий Иноземцев wrote: > > > 28.08.2019 12:55, Dmitry V. Levin пишет: > > > > On Wed, Aug 28, 2019 at 12:04:28PM +0300, Dmitry V. Levin > > > > wrote: > > > > > On Wed, Aug 28, 2019 at 11:27:39AM +0300, Levin Stanislav > > > > > wrote: > > > > [...] > > > > > > 2) Нельзя ли применить одинаковые настройки (насколько это > > > > > > возможно и > > > > > > целесообразно) > > > > > > на всех платформах для сборки. > > > > > > > > > > Можно. > > К сожалению, нельзя. > > > > > Попытка установить одинаковый hasher на всех платформах привела > > > > к тому, > > > > что на aarch64 больше ничего не собирается вот с такой > > > > диагностикой: > > > > > > > > hasher-priv: chrootuid: mknod: console: Operation not permitted > > > > > > когда ожидать исправления? > > > > Сейчас мы в процессе выяснения, что следует исправлять. > > Оказывается, что systemd-nspawn, под управлением которого находятся > сборочные > узлы aarch64, не позволяет создавать /dev/console с правами 0600. Это systemd-nspawn в принципе не позволяет, или на узлах такие настройки? И зачем на сборочном узле systemd-nspawn? На других архитектурах ведь этого нет? > Чтобы разблокировать разработку, я откатил обновление hasher на > сборочных > узлах aarch64. > > > _______________________________________________ > Devel mailing list > Devel@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/devel ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-28 9:04 ` [devel] /dev/shm Dmitry V. Levin 2019-08-28 9:55 ` Dmitry V. Levin @ 2019-08-28 13:54 ` Dmitry V. Levin 2019-08-28 14:33 ` Alexey Gladkov 1 sibling, 1 reply; 32+ messages in thread From: Dmitry V. Levin @ 2019-08-28 13:54 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 1288 bytes --] On Wed, Aug 28, 2019 at 12:04:28PM +0300, Dmitry V. Levin wrote: > On Wed, Aug 28, 2019 at 11:27:39AM +0300, Levin Stanislav wrote: > > Здравствуйте! > > > > Вчерашняя пересборка показала вероятное изменение на сборочных машинах > > x86_64 и i586, > > > > а именно возможность обращения "на запись" пользователю "builder" к > > "/dev/shm" > > > > ( без указания в сборочных зависимостях "/dev/shm" ). > > > > Для x86_64 и i586: > > > > + id > > uid=523(builder) gid=523(builder) groups=523(builder) > > + ls -ld /dev/shm > > drwxr-xr-x 2 root root 40 Aug 27 19:02 /dev/shm > > > > Для ppc64le и aarch64: > > > > + id > > uid=523(builder) gid=523(builder) groups=523(builder) > > + ls -ld /dev/shm > > drwxrwxrwt 2 caller rooter 40 Aug 27 19:01 /dev/shm > > > > При добавлении к BR "/dev/shm" ожидания оправдываются: > > > > + id > > uid=517(builder) gid=517(builder) groups=517(builder) > > + ls -ld /dev/shm > > drwxrwxrwt 2 root root 40 Aug 28 07:00 /dev/shm > > Да, всё это так. С другой стороны, /dev/shm до сих пор был фактически доступен по умолчанию, поскольку создавался hasher'ом автоматически с правами 01777, начиная с версии 1.3.23 (т.е.уже более 7 лет). Видимо, убирать /dev/shm сейчас будет уже неправильно. -- ldv [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-28 13:54 ` Dmitry V. Levin @ 2019-08-28 14:33 ` Alexey Gladkov 2019-08-28 15:02 ` Dmitry V. Levin 2019-08-28 16:31 ` Stanislav Levin 0 siblings, 2 replies; 32+ messages in thread From: Alexey Gladkov @ 2019-08-28 14:33 UTC (permalink / raw) To: Dmitry V. Levin; +Cc: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 700 bytes --] On Wed, Aug 28, 2019 at 04:54:43PM +0300, Dmitry V. Levin wrote: > С другой стороны, /dev/shm до сих пор был фактически доступен по > умолчанию, поскольку создавался hasher'ом автоматически с правами 01777, > начиная с версии 1.3.23 (т.е.уже более 7 лет). > > Видимо, убирать /dev/shm сейчас будет уже неправильно. Да, это изменение ломает пакеты, но с другой стороны лучше явно иметь BR: /dev/shm и явно знать кому он нужен. -- Rgrds, legion [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 163 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-28 14:33 ` Alexey Gladkov @ 2019-08-28 15:02 ` Dmitry V. Levin 2019-08-28 15:11 ` Alexey Gladkov 2019-08-28 16:31 ` Stanislav Levin 1 sibling, 1 reply; 32+ messages in thread From: Dmitry V. Levin @ 2019-08-28 15:02 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 746 bytes --] On Wed, Aug 28, 2019 at 04:33:26PM +0200, Alexey Gladkov wrote: > On Wed, Aug 28, 2019 at 04:54:43PM +0300, Dmitry V. Levin wrote: > > С другой стороны, /dev/shm до сих пор был фактически доступен по > > умолчанию, поскольку создавался hasher'ом автоматически с правами 01777, > > начиная с версии 1.3.23 (т.е.уже более 7 лет). > > > > Видимо, убирать /dev/shm сейчас будет уже неправильно. > > Да, это изменение ломает пакеты, но с другой стороны лучше явно иметь > BR: /dev/shm и явно знать кому он нужен. Целью новой версии является всё-таки не создание несовместимости с предыдущей версией, а новая фича allowed_devices. Ради этой фичи пришлось переделать монтирование файловых систем и создание устройств. -- ldv [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-28 15:02 ` Dmitry V. Levin @ 2019-08-28 15:11 ` Alexey Gladkov 2019-08-28 15:23 ` Dmitry V. Levin 0 siblings, 1 reply; 32+ messages in thread From: Alexey Gladkov @ 2019-08-28 15:11 UTC (permalink / raw) To: Dmitry V. Levin; +Cc: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 729 bytes --] On Wed, Aug 28, 2019 at 06:02:20PM +0300, Dmitry V. Levin wrote: > > Да, это изменение ломает пакеты, но с другой стороны лучше явно иметь > > BR: /dev/shm и явно знать кому он нужен. > > Целью новой версии является всё-таки не создание несовместимости > с предыдущей версией, а новая фича allowed_devices. > > Ради этой фичи пришлось переделать монтирование файловых систем > и создание устройств. Ну тогда это явная регрессия )) -- Rgrds, legion [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 163 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-28 15:11 ` Alexey Gladkov @ 2019-08-28 15:23 ` Dmitry V. Levin 2019-08-28 18:08 ` Alexey Gladkov 0 siblings, 1 reply; 32+ messages in thread From: Dmitry V. Levin @ 2019-08-28 15:23 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 664 bytes --] On Wed, Aug 28, 2019 at 05:11:45PM +0200, Alexey Gladkov wrote: > On Wed, Aug 28, 2019 at 06:02:20PM +0300, Dmitry V. Levin wrote: > > > Да, это изменение ломает пакеты, но с другой стороны лучше явно иметь > > > BR: /dev/shm и явно знать кому он нужен. > > > > Целью новой версии является всё-таки не создание несовместимости > > с предыдущей версией, а новая фича allowed_devices. > > > > Ради этой фичи пришлось переделать монтирование файловых систем > > и создание устройств. > > Ну тогда это явная регрессия )) Да, я тоже так думаю. :) Что ещё может сломаться из-за изменений в http://git.altlinux.org/tasks/236645/ ? -- ldv [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-28 15:23 ` Dmitry V. Levin @ 2019-08-28 18:08 ` Alexey Gladkov 2019-08-28 18:11 ` Anton Farygin 2019-08-28 18:15 ` Dmitry V. Levin 0 siblings, 2 replies; 32+ messages in thread From: Alexey Gladkov @ 2019-08-28 18:08 UTC (permalink / raw) To: Dmitry V. Levin; +Cc: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 435 bytes --] On Wed, Aug 28, 2019 at 06:23:42PM +0300, Dmitry V. Levin wrote: > Да, я тоже так думаю. :) > > Что ещё может сломаться из-за изменений в > http://git.altlinux.org/tasks/236645/ > > ? Ну ты спросишь. Это же вычитывать нужно т.к. изменения серьёзные. Я не специалист в hasher-priv :) -- Rgrds, legion [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 163 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-28 18:08 ` Alexey Gladkov @ 2019-08-28 18:11 ` Anton Farygin 2019-08-28 18:24 ` Dmitry V. Levin 2019-08-28 18:15 ` Dmitry V. Levin 1 sibling, 1 reply; 32+ messages in thread From: Anton Farygin @ 2019-08-28 18:11 UTC (permalink / raw) To: devel On 28.08.2019 21:08, Alexey Gladkov wrote: > On Wed, Aug 28, 2019 at 06:23:42PM +0300, Dmitry V. Levin wrote: >> Да, я тоже так думаю. :) >> >> Что ещё может сломаться из-за изменений в >> http://git.altlinux.org/tasks/236645/ >> >> ? > Ну ты спросишь. Это же вычитывать нужно т.к. изменения серьёзные. > Я не специалист в hasher-priv :) > Судя по тому, что Дима не знает что может сломаться - сломаться может что угодно. Ответ очевиден. Да протестируем на Sisyphus, не проблема же ;) ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-28 18:11 ` Anton Farygin @ 2019-08-28 18:24 ` Dmitry V. Levin 2019-08-28 18:45 ` Anton Farygin 0 siblings, 1 reply; 32+ messages in thread From: Dmitry V. Levin @ 2019-08-28 18:24 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 1037 bytes --] On Wed, Aug 28, 2019 at 09:11:57PM +0300, Anton Farygin wrote: > On 28.08.2019 21:08, Alexey Gladkov wrote: > > On Wed, Aug 28, 2019 at 06:23:42PM +0300, Dmitry V. Levin wrote: > >> Да, я тоже так думаю. :) > >> > >> Что ещё может сломаться из-за изменений в > >> http://git.altlinux.org/tasks/236645/ > >> > >> ? > > Ну ты спросишь. Это же вычитывать нужно т.к. изменения серьёзные. > > Я не специалист в hasher-priv :) > > > Судя по тому, что Дима не знает что может сломаться - сломаться может > что угодно. Ответ очевиден. Обычная сборка пакетов сломаться не может. Могут сломаться другие пользователи hasher'а, поскольку полностью прекращается обмен файлами в hasher/chroot/dev между процессами снаружи и внутри чрута. Например, пришлось починить пакет mkve, потому что mkve-cache использовал hsh-fakedev, которого больше нет. Я не удивлюсь, если сломаются какие-то пользователи mkimage. > Да протестируем на Sisyphus, не проблема же ;) Интересно, как вы будете это тестировать. ;) -- ldv [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-28 18:24 ` Dmitry V. Levin @ 2019-08-28 18:45 ` Anton Farygin 2019-08-28 18:50 ` Anton Farygin 0 siblings, 1 reply; 32+ messages in thread From: Anton Farygin @ 2019-08-28 18:45 UTC (permalink / raw) To: devel On 28.08.2019 21:24, Dmitry V. Levin wrote: > On Wed, Aug 28, 2019 at 09:11:57PM +0300, Anton Farygin wrote: >> On 28.08.2019 21:08, Alexey Gladkov wrote: >>> On Wed, Aug 28, 2019 at 06:23:42PM +0300, Dmitry V. Levin wrote: >>>> Да, я тоже так думаю. :) >>>> >>>> Что ещё может сломаться из-за изменений в >>>> http://git.altlinux.org/tasks/236645/ >>>> >>>> ? >>> Ну ты спросишь. Это же вычитывать нужно т.к. изменения серьёзные. >>> Я не специалист в hasher-priv :) >>> >> Судя по тому, что Дима не знает что может сломаться - сломаться может >> что угодно. Ответ очевиден. > Обычная сборка пакетов сломаться не может. > > Могут сломаться другие пользователи hasher'а, поскольку полностью > прекращается обмен файлами в hasher/chroot/dev между процессами > снаружи и внутри чрута. > > Например, пришлось починить пакет mkve, потому что mkve-cache > использовал hsh-fakedev, которого больше нет. > > Я не удивлюсь, если сломаются какие-то пользователи mkimage. > >> Да протестируем на Sisyphus, не проблема же ;) > Интересно, как вы будете это тестировать. ;) Жизнью. Выложишь, что-то сломается, ты починишь ;) ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-28 18:45 ` Anton Farygin @ 2019-08-28 18:50 ` Anton Farygin 2019-08-28 18:59 ` Dmitry V. Levin 0 siblings, 1 reply; 32+ messages in thread From: Anton Farygin @ 2019-08-28 18:50 UTC (permalink / raw) To: devel On 28.08.2019 21:45, Anton Farygin wrote: > Могут сломаться другие пользователи hasher'а, поскольку полностью > прекращается обмен файлами в hasher/chroot/dev между процессами > снаружи и внутри чрута. > > Например, пришлось починить пакет mkve, потому что mkve-cache > использовал hsh-fakedev, которого больше нет. > > Я не удивлюсь, если сломаются какие-то пользователи mkimage. Интересно, как станет себя вести hasher в системах виртуализации. В докере, в lxc. Скорее всего основные поломки могут случиться там, где как-то ограничивают возможность создания устройств. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-28 18:50 ` Anton Farygin @ 2019-08-28 18:59 ` Dmitry V. Levin 2019-08-29 21:08 ` Dmitry V. Levin 0 siblings, 1 reply; 32+ messages in thread From: Dmitry V. Levin @ 2019-08-28 18:59 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 1320 bytes --] On Wed, Aug 28, 2019 at 09:50:06PM +0300, Anton Farygin wrote: > On 28.08.2019 21:45, Anton Farygin wrote: > > Могут сломаться другие пользователи hasher'а, поскольку полностью > > прекращается обмен файлами в hasher/chroot/dev между процессами > > снаружи и внутри чрута. > > > > Например, пришлось починить пакет mkve, потому что mkve-cache > > использовал hsh-fakedev, которого больше нет. > > > > Я не удивлюсь, если сломаются какие-то пользователи mkimage. > > Интересно, как станет себя вести hasher в системах виртуализации. В > докере, в lxc. Везде, где можно создавать новые tmpfs, поведение будет таким же, как и прежде. Везде, где нельзя создавать новые tmpfs, hasher не будет работать совсем. > Скорее всего основные поломки могут случиться там, где как-то > ограничивают возможность создания устройств. Устройства создавались и раньше. Изменяется то, на какой файловой системе они создаются. Раньше это было непосредственно в hasher/chroot/dev, теперь это отдельно созданная tmpfs: $ hsh-run --mount=/proc -- cat /proc/mounts dev /dev tmpfs rw,nosuid,noexec,relatime,size=4k,nr_inodes=256,mode=755 0 0 shmfs /dev/shm tmpfs rw,nosuid,nodev,noexec,relatime,size=1024k,nr_inodes=256 0 0 proc /proc proc ro,nosuid,nodev,noexec,relatime,gid=19,hidepid=1 0 0 -- ldv [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-28 18:59 ` Dmitry V. Levin @ 2019-08-29 21:08 ` Dmitry V. Levin 0 siblings, 0 replies; 32+ messages in thread From: Dmitry V. Levin @ 2019-08-29 21:08 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 1707 bytes --] On Wed, Aug 28, 2019 at 09:59:38PM +0300, Dmitry V. Levin wrote: > On Wed, Aug 28, 2019 at 09:50:06PM +0300, Anton Farygin wrote: > > On 28.08.2019 21:45, Anton Farygin wrote: > > > Могут сломаться другие пользователи hasher'а, поскольку полностью > > > прекращается обмен файлами в hasher/chroot/dev между процессами > > > снаружи и внутри чрута. > > > > > > Например, пришлось починить пакет mkve, потому что mkve-cache > > > использовал hsh-fakedev, которого больше нет. > > > > > > Я не удивлюсь, если сломаются какие-то пользователи mkimage. > > > > Интересно, как станет себя вести hasher в системах виртуализации. В > > докере, в lxc. > > Везде, где можно создавать новые tmpfs, поведение будет таким же, > как и прежде. Везде, где нельзя создавать новые tmpfs, hasher > не будет работать совсем. > > > Скорее всего основные поломки могут случиться там, где как-то > > ограничивают возможность создания устройств. > > Устройства создавались и раньше. Изменяется то, на какой файловой системе > они создаются. Раньше это было непосредственно в hasher/chroot/dev, > теперь это отдельно созданная tmpfs: > > $ hsh-run --mount=/proc -- cat /proc/mounts > dev /dev tmpfs rw,nosuid,noexec,relatime,size=4k,nr_inodes=256,mode=755 0 0 > shmfs /dev/shm tmpfs rw,nosuid,nodev,noexec,relatime,size=1024k,nr_inodes=256 0 0 > proc /proc proc ro,nosuid,nodev,noexec,relatime,gid=19,hidepid=1 0 0 Я склоняюсь к мысли, что сломаются только пользователи hsh-fakedev, которого больше нет. Это mkve-cache, который я уже исправил, и mkimage. Я отправлю в Сизиф новый hasher только после того, как все известные пользователи hsh-fakedev будут адаптированы. -- ldv [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-28 18:08 ` Alexey Gladkov 2019-08-28 18:11 ` Anton Farygin @ 2019-08-28 18:15 ` Dmitry V. Levin 2019-08-28 19:50 ` Alexey Gladkov 1 sibling, 1 reply; 32+ messages in thread From: Dmitry V. Levin @ 2019-08-28 18:15 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 729 bytes --] On Wed, Aug 28, 2019 at 08:08:27PM +0200, Alexey Gladkov wrote: > On Wed, Aug 28, 2019 at 06:23:42PM +0300, Dmitry V. Levin wrote: > > Да, я тоже так думаю. :) > > > > Что ещё может сломаться из-за изменений в > > http://git.altlinux.org/tasks/236645/ > > > > ? > > Ну ты спросишь. Это же вычитывать нужно т.к. изменения серьёзные. > Я не специалист в hasher-priv :) Изменение по сути одно и оно точечное. Содержимое hasher/chroot/dev будет недоступно процессам в чруте, поскольку у них будет свой /dev на tmpfs, создаваемый каждый раз при запуске этих процессов в их mount namespace и, соответственно, недоступный процессам снаружи. > Я не специалист в hasher-priv :) Тогда я тоже. :) -- ldv [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-28 18:15 ` Dmitry V. Levin @ 2019-08-28 19:50 ` Alexey Gladkov 2019-08-28 20:53 ` Dmitry V. Levin 0 siblings, 1 reply; 32+ messages in thread From: Alexey Gladkov @ 2019-08-28 19:50 UTC (permalink / raw) To: Dmitry V. Levin; +Cc: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 2111 bytes --] On Wed, Aug 28, 2019 at 09:15:52PM +0300, Dmitry V. Levin wrote: > Изменение по сути одно и оно точечное. > > Содержимое hasher/chroot/dev будет недоступно процессам в чруте, > поскольку у них будет свой /dev на tmpfs, создаваемый каждый раз > при запуске этих процессов в их mount namespace и, соответственно, > недоступный процессам снаружи. Ну setns всё-таки есть :) > > Я не специалист в hasher-priv :) > > Тогда я тоже. :) А почему теперь /dev/shm обязателен и не отключаем ? Раньше же без него обходились. http://git.altlinux.org/tasks/236645/gears/340/git?p=git;a=blob;f=hasher-priv/mount.c;h=5b99354f6c64ba440980fe27a9f3738130a9be6e;hb=1a2f923ab0ca822de9406198ed409c79eb000ce7#l284 В requested_mountpoints ты проверяешь и игнорируешь /dev/shm, но не сам /dev. Хотя даже комментарий намекает :) http://git.altlinux.org/tasks/236645/gears/340/git?p=git;a=blob;f=hasher-priv/mount.c;h=5b99354f6c64ba440980fe27a9f3738130a9be6e;hb=1a2f923ab0ca822de9406198ed409c79eb000ce7#l304 Дим, зачем ты отдельно проходишь по всему mount_vec, который заполняешь чуть выше ? Разве не проще сделать: --- a/hasher-priv/mount.c +++ b/hasher-priv/mount.c @@ -301,6 +301,8 @@ setup_mountpoints(void) mpoint_vec = xgrowarray(mpoint_vec, &mpoint_allocated, sizeof(*mpoint_vec)); + if (!strcmp("/dev/pts", item)) + dev_pts_mounted = 1; mpoint_vec[mpoint_size++] = item; } else { error(EXIT_FAILURE, 0, -- Rgrds, legion [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 163 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-28 19:50 ` Alexey Gladkov @ 2019-08-28 20:53 ` Dmitry V. Levin 2019-08-28 21:46 ` Alexey Gladkov 0 siblings, 1 reply; 32+ messages in thread From: Dmitry V. Levin @ 2019-08-28 20:53 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 2194 bytes --] On Wed, Aug 28, 2019 at 09:50:18PM +0200, Alexey Gladkov wrote: > On Wed, Aug 28, 2019 at 09:15:52PM +0300, Dmitry V. Levin wrote: > > Изменение по сути одно и оно точечное. > > > > Содержимое hasher/chroot/dev будет недоступно процессам в чруте, > > поскольку у них будет свой /dev на tmpfs, создаваемый каждый раз > > при запуске этих процессов в их mount namespace и, соответственно, > > недоступный процессам снаружи. > > Ну setns всё-таки есть :) Это процессы разных пользователей, и setns не сработает с hidepid=1. > > > Я не специалист в hasher-priv :) > > > > Тогда я тоже. :) > > А почему теперь /dev/shm обязателен и не отключаем ? Раньше же без него > обходились. Раньше его неотключаемо создавал hasher, теперь hasher-priv. В принципе, его можно отключить через /etc/hasher-priv/fstab, написав какой-нибудь mode=755, но зачем? > http://git.altlinux.org/tasks/236645/gears/340/git?p=git;a=blob;f=hasher-priv/mount.c;h=5b99354f6c64ba440980fe27a9f3738130a9be6e;hb=1a2f923ab0ca822de9406198ed409c79eb000ce7#l284 > > В requested_mountpoints ты проверяешь и игнорируешь /dev/shm, но не сам > /dev. Хотя даже комментарий намекает :) На тот случай, если нерадивый админ добавит /dev в allowed_mountpoints? OK, харденинга много не бывает. > http://git.altlinux.org/tasks/236645/gears/340/git?p=git;a=blob;f=hasher-priv/mount.c;h=5b99354f6c64ba440980fe27a9f3738130a9be6e;hb=1a2f923ab0ca822de9406198ed409c79eb000ce7#l304 > > Дим, зачем ты отдельно проходишь по всему mount_vec, который заполняешь > чуть выше ? Разве не проще сделать: > > --- a/hasher-priv/mount.c > +++ b/hasher-priv/mount.c > @@ -301,6 +301,8 @@ setup_mountpoints(void) > mpoint_vec = > xgrowarray(mpoint_vec, &mpoint_allocated, > sizeof(*mpoint_vec)); > + if (!strcmp("/dev/pts", item)) > + dev_pts_mounted = 1; > mpoint_vec[mpoint_size++] = item; > } else { > error(EXIT_FAILURE, 0, Это же оптимизация! :) -- ldv [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-28 20:53 ` Dmitry V. Levin @ 2019-08-28 21:46 ` Alexey Gladkov 2019-08-28 22:52 ` Dmitry V. Levin 2019-08-29 23:39 ` Leonid Krivoshein 0 siblings, 2 replies; 32+ messages in thread From: Alexey Gladkov @ 2019-08-28 21:46 UTC (permalink / raw) To: Dmitry V. Levin; +Cc: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 3357 bytes --] On Wed, Aug 28, 2019 at 11:53:15PM +0300, Dmitry V. Levin wrote: > On Wed, Aug 28, 2019 at 09:50:18PM +0200, Alexey Gladkov wrote: > > On Wed, Aug 28, 2019 at 09:15:52PM +0300, Dmitry V. Levin wrote: > > > Изменение по сути одно и оно точечное. > > > > > > Содержимое hasher/chroot/dev будет недоступно процессам в чруте, > > > поскольку у них будет свой /dev на tmpfs, создаваемый каждый раз > > > при запуске этих процессов в их mount namespace и, соответственно, > > > недоступный процессам снаружи. > > > > Ну setns всё-таки есть :) > > Это процессы разных пользователей, и setns не сработает с hidepid=1. Да, но это нужно делать в хост-системе и он будет глобален для всего pid namespace ... нужно всё-таки возродить тот патч. > > А почему теперь /dev/shm обязателен и не отключаем ? Раньше же без него > > обходились. > > Раньше его неотключаемо создавал hasher, теперь hasher-priv. > В принципе, его можно отключить через /etc/hasher-priv/fstab, > написав какой-нибудь mode=755, но зачем? Ну просто это ещё одна tmpfs. Она конечно ограничена по размеру, но всё-таки. Я бы и /sys без нужды не давал ибо нефиг читать информацию про хост-систему и модули. > На тот случай, если нерадивый админ добавит /dev в allowed_mountpoints? Вдруг он перестал принимать свои таблетки. > > http://git.altlinux.org/tasks/236645/gears/340/git?p=git;a=blob;f=hasher-priv/mount.c;h=5b99354f6c64ba440980fe27a9f3738130a9be6e;hb=1a2f923ab0ca822de9406198ed409c79eb000ce7#l304 > > > > Дим, зачем ты отдельно проходишь по всему mount_vec, который заполняешь > > чуть выше ? Разве не проще сделать: > > > > --- a/hasher-priv/mount.c > > +++ b/hasher-priv/mount.c > > @@ -301,6 +301,8 @@ setup_mountpoints(void) > > mpoint_vec = > > xgrowarray(mpoint_vec, &mpoint_allocated, > > sizeof(*mpoint_vec)); > > + if (!strcmp("/dev/pts", item)) > > + dev_pts_mounted = 1; > > mpoint_vec[mpoint_size++] = item; > > } else { > > error(EXIT_FAILURE, 0, > > Это же оптимизация! :) Ты же знаешь, что в моей конторе любят всё "оптимизировать" ! :) Мне как-то не понравились специальные кейсы про /dev, /dev/pts, /dev/shm, но сходу не смог придумать как от них избавиться. -- Rgrds, legion [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 163 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-28 21:46 ` Alexey Gladkov @ 2019-08-28 22:52 ` Dmitry V. Levin 2019-08-29 13:58 ` Andrey Savchenko 2019-08-29 23:39 ` Leonid Krivoshein 1 sibling, 1 reply; 32+ messages in thread From: Dmitry V. Levin @ 2019-08-28 22:52 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 1802 bytes --] On Wed, Aug 28, 2019 at 11:46:50PM +0200, Alexey Gladkov wrote: > On Wed, Aug 28, 2019 at 11:53:15PM +0300, Dmitry V. Levin wrote: > > On Wed, Aug 28, 2019 at 09:50:18PM +0200, Alexey Gladkov wrote: > > > On Wed, Aug 28, 2019 at 09:15:52PM +0300, Dmitry V. Levin wrote: > > > > Изменение по сути одно и оно точечное. > > > > > > > > Содержимое hasher/chroot/dev будет недоступно процессам в чруте, > > > > поскольку у них будет свой /dev на tmpfs, создаваемый каждый раз > > > > при запуске этих процессов в их mount namespace и, соответственно, > > > > недоступный процессам снаружи. > > > > > > Ну setns всё-таки есть :) > > > > Это процессы разных пользователей, и setns не сработает с hidepid=1. > > Да, но это нужно делать в хост-системе и он будет глобален для всего pid > namespace ... нужно всё-таки возродить тот патч. Сейчас без hidepid=1 возможна утечка доступа к /dev из чрута к вызывающему пользователю. Этого, наверное, можно было бы избежать, установив права доступа 0700 к /dev в чруте, но это, вероятно, сломает какие-нибудь генераторы образов. Пожалуй, лучше оставить 0755. > > > А почему теперь /dev/shm обязателен и не отключаем ? Раньше же без него > > > обходились. > > > > Раньше его неотключаемо создавал hasher, теперь hasher-priv. > > В принципе, его можно отключить через /etc/hasher-priv/fstab, > > написав какой-нибудь mode=755, но зачем? > > Ну просто это ещё одна tmpfs. Она конечно ограничена по размеру, но > всё-таки. Я бы и /sys без нужды не давал ибо нефиг читать информацию про > хост-систему и модули. Можно объявить, что /dev/shm мы монтируем временно для обеспечения обратной совместимости, и скоро уберём. Ну а /sys по умолчанию не входит в allowed_mountpoints, который по умолчанию вообще пуст. -- ldv [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-28 22:52 ` Dmitry V. Levin @ 2019-08-29 13:58 ` Andrey Savchenko 2019-08-29 19:24 ` Dmitry V. Levin 0 siblings, 1 reply; 32+ messages in thread From: Andrey Savchenko @ 2019-08-29 13:58 UTC (permalink / raw) To: ALT Linux Team development discussions [-- Attachment #1: Type: text/plain, Size: 1922 bytes --] On Thu, 29 Aug 2019 01:52:44 +0300 Dmitry V. Levin wrote: > > > > А почему теперь /dev/shm обязателен и не отключаем ? Раньше же без него > > > > обходились. > > > > > > Раньше его неотключаемо создавал hasher, теперь hasher-priv. > > > В принципе, его можно отключить через /etc/hasher-priv/fstab, > > > написав какой-нибудь mode=755, но зачем? > > > > Ну просто это ещё одна tmpfs. Она конечно ограничена по размеру, но > > всё-таки. Я бы и /sys без нужды не давал ибо нефиг читать информацию про > > хост-систему и модули. > > Можно объявить, что /dev/shm мы монтируем временно > для обеспечения обратной совместимости, и скоро уберём. /dev/shm — это часть стандарта POSIX и должен быть всегда. Понятно, что не все приложения его используют, но сидеть и разбирать дополнительные баги из-за того, что кому-то понадобилось /dev/shm, а его нет и вылезла неочевидная ошибка — лично у меня желания нет, работы и так больше, чем людей. P.S. Я говорю не просто так. В HPC окружении при желании убрать "лишнее" именно на это и напоролся. А у нас есть HPC пакеты, у них есть тесты, ну вы поняли. И это вылезти может не только на HPC, а где угодно. Best regards, Andrew Savchenko [-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-29 13:58 ` Andrey Savchenko @ 2019-08-29 19:24 ` Dmitry V. Levin 2019-08-29 19:36 ` Anton Farygin 0 siblings, 1 reply; 32+ messages in thread From: Dmitry V. Levin @ 2019-08-29 19:24 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 2324 bytes --] On Thu, Aug 29, 2019 at 04:58:43PM +0300, Andrey Savchenko wrote: > On Thu, 29 Aug 2019 01:52:44 +0300 Dmitry V. Levin wrote: > > > > > А почему теперь /dev/shm обязателен и не отключаем ? Раньше же без него > > > > > обходились. > > > > > > > > Раньше его неотключаемо создавал hasher, теперь hasher-priv. > > > > В принципе, его можно отключить через /etc/hasher-priv/fstab, > > > > написав какой-нибудь mode=755, но зачем? > > > > > > Ну просто это ещё одна tmpfs. Она конечно ограничена по размеру, но > > > всё-таки. Я бы и /sys без нужды не давал ибо нефиг читать информацию про > > > хост-систему и модули. > > > > Можно объявить, что /dev/shm мы монтируем временно > > для обеспечения обратной совместимости, и скоро уберём. > > /dev/shm — это часть стандарта POSIX и должен быть всегда. Понятно, Не всё, что является частью стандарта POSIX, должно быть всегда. Что-то может быть по требованию. Так что это слабый аргумент. > что не все приложения его используют, но сидеть и разбирать > дополнительные баги из-за того, что кому-то понадобилось /dev/shm, > а его нет и вылезла неочевидная ошибка — лично у меня желания нет, > работы и так больше, чем людей. А вот это аргумент посильнее. На самом деле выяснить, используется ли /dev/shm для сборки конкретного пакета, теперь будет очень легко: для этого достаточно сравнить время модификации /dev и /dev/shm, и если /dev/shm новее /dev, значит, /dev/shm использовался. -- ldv [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-29 19:24 ` Dmitry V. Levin @ 2019-08-29 19:36 ` Anton Farygin 0 siblings, 0 replies; 32+ messages in thread From: Anton Farygin @ 2019-08-29 19:36 UTC (permalink / raw) To: devel On 29.08.2019 22:24, Dmitry V. Levin wrote: > On Thu, Aug 29, 2019 at 04:58:43PM +0300, Andrey Savchenko wrote: >> On Thu, 29 Aug 2019 01:52:44 +0300 Dmitry V. Levin wrote: >> >> что не все приложения его используют, но сидеть и разбирать >> дополнительные баги из-за того, что кому-то понадобилось /dev/shm, >> а его нет и вылезла неочевидная ошибка — лично у меня желания нет, >> работы и так больше, чем людей. > А вот это аргумент посильнее. > > На самом деле выяснить, используется ли /dev/shm для сборки конкретного > пакета, теперь будет очень легко: для этого достаточно сравнить время > модификации /dev и /dev/shm, и если /dev/shm новее /dev, значит, /dev/shm > использовался. > Так ты можешь выяснить все пакеты, использующие /dev/shm прямо при ближайшей пересборке, просто записав в логи эту разницу. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-28 21:46 ` Alexey Gladkov 2019-08-28 22:52 ` Dmitry V. Levin @ 2019-08-29 23:39 ` Leonid Krivoshein 2019-08-30 0:27 ` Dmitry V. Levin 1 sibling, 1 reply; 32+ messages in thread From: Leonid Krivoshein @ 2019-08-29 23:39 UTC (permalink / raw) To: devel 29.08.2019 00:46, Alexey Gladkov пишет: > [...] >>> А почему теперь /dev/shm обязателен и не отключаем ? Раньше же без него >>> обходились. >> Раньше его неотключаемо создавал hasher, теперь hasher-priv. >> В принципе, его можно отключить через /etc/hasher-priv/fstab, >> написав какой-нибудь mode=755, но зачем? > Ну просто это ещё одна tmpfs. Она конечно ограничена по размеру, но > всё-таки. Я бы и /sys без нужды не давал ибо нефиг читать информацию про > хост-систему и модули. Ещё одна tmpfs... А как это всё соотносится с повсеместной тенденцией иметь всё-таки ОДНУ tmpfs на каждую систему? Ведь при её создании с параметрами по умолчанию ей выставляется лимит в 50% RAM. Понятно, что hasher здесь накладывает ещё и свои ограничения, к тому же всё делается на tmpfs хостовой системы. Раз пошли вслед за остальными в этом вопросе (имеются ввиду симлинки /var/run -> /run и /var/lock -> /run/lock), логичнее было бы довести это до ума с остальными каталогами, которые также всегда были tmpfs. Чтобы на каждую систему была только одна tmpfs: /dev/.* -> /run/* (к примеру /dev/.udev -> /run/udev) /dev/shm -> /run/shm /dev/shm/* -> /run/* /tmp -> /run/tmp В частности /dev/shm должен быть симлинком на /run/shm. Или сборочницы (хэшера) это вообще не должно касаться? -- Best regards, Leonid Krivoshein. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-29 23:39 ` Leonid Krivoshein @ 2019-08-30 0:27 ` Dmitry V. Levin 2019-08-30 4:30 ` Leonid Krivoshein 0 siblings, 1 reply; 32+ messages in thread From: Dmitry V. Levin @ 2019-08-30 0:27 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 2138 bytes --] On Fri, Aug 30, 2019 at 02:39:34AM +0300, Leonid Krivoshein wrote: > > 29.08.2019 00:46, Alexey Gladkov пишет: > > [...] > >>> А почему теперь /dev/shm обязателен и не отключаем ? Раньше же без него > >>> обходились. > >> Раньше его неотключаемо создавал hasher, теперь hasher-priv. > >> В принципе, его можно отключить через /etc/hasher-priv/fstab, > >> написав какой-нибудь mode=755, но зачем? > > Ну просто это ещё одна tmpfs. Она конечно ограничена по размеру, но > > всё-таки. Я бы и /sys без нужды не давал ибо нефиг читать информацию про > > хост-систему и модули. > > Ещё одна tmpfs... Ещё и с существенно отличающимися параметрами монтирования. > А как это всё соотносится с повсеместной тенденцией иметь всё-таки ОДНУ > tmpfs на каждую систему? Интересно, где наблюдается такая тенденция? > Ведь при её создании с параметрами по умолчанию > ей выставляется лимит в 50% RAM. Понятно, что hasher здесь накладывает > ещё и свои ограничения, Ограничения? /dev вообще монтируется с nr_blocks=0,nr_inodes=256,nosuid,noexec, /dev/shm монтируется с nr_blocks=256,nr_inodes=256,nosuid,noexec,nodev. > к тому же всё делается на tmpfs хостовой системы. Хостовая файловая система, вообще говоря, не обязана быть tmpfs. > Раз пошли вслед за остальными в этом вопросе (имеются ввиду симлинки > /var/run -> /run и /var/lock -> /run/lock), логичнее было бы довести это > до ума с остальными каталогами, которые также всегда были tmpfs. Чтобы > на каждую систему была только одна tmpfs: > > /dev/.* -> /run/* (к примеру /dev/.udev -> /run/udev) > /dev/shm -> /run/shm Интересно, а что такое /run/shm? > /dev/shm/* -> /run/* Прямо в run? > /tmp -> /run/tmp Интересно, а что такое /run/tmp? Раньше размер /tmp на порядки превышал размер /run; с тех пор что-то изменилось? У разных tmpfs разные задачи и, как следствие, разные параметры монтирования. > В частности /dev/shm должен быть симлинком на /run/shm. > Или сборочницы (хэшера) это вообще не должно касаться? hasher/chroot/run обычно не заполняется и не используется, насколько я понимаю. -- ldv [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-30 0:27 ` Dmitry V. Levin @ 2019-08-30 4:30 ` Leonid Krivoshein 0 siblings, 0 replies; 32+ messages in thread From: Leonid Krivoshein @ 2019-08-30 4:30 UTC (permalink / raw) To: devel 30.08.2019 03:27, Dmitry V. Levin пишет: > On Fri, Aug 30, 2019 at 02:39:34AM +0300, Leonid Krivoshein wrote: >> [...] >> Ещё одна tmpfs... > Ещё и с существенно отличающимися параметрами монтирования. Если это имеет существенное значение для хэшера, тогда понятно. Но так ли нужные отличающиеся параметры монтирования (несколько экземпляров tmpfs) в обычной системе *по умолчанию*? >> А как это всё соотносится с повсеместной тенденцией иметь всё-таки ОДНУ >> tmpfs на каждую систему? > Интересно, где наблюдается такая тенденция? Похоже, насчёт повсеместности я несколько перегнул. Посмотрел скелеты базовых систем разных дистрибутивов, тенденция не прослеживается. Кто во что горазд, даже чаще встречается отказ от /bin -> /usr/bin, от /sbin -> /usr/sbin и от /lib64 -> /usr/lib64. В Debian на такую схему перешли в 2013 для упрощения перехода из stage1 в stage2 (один mount --move /run вместо дюжины). FHS явно описывает разное назначение для этих каталогов: /tmp может быть tmpfs, но может быть и частью корневой системы, /run должна быть tmpfs, но преемственность с /var/run подразумевает и её чистку при загрузке, /dev/shm вообще не затрагивается FHS, но это всегда только tmpfs и отказаться от неё практически невозможно. То есть, FHS здесь можно трактовать по-разному, в том числе, в пользу объединения. Контроль над параметрами монтирования различных tmpfs или пересоздания каталогов при запуске, помимо статических записей в /etc/fstab, предусмотрен только для /tmp (в каких-нибудь /etc/default/tmpfs или /etc/tmpfiles.d/*.conf), да и логика подталкивает к тому, что /run и /tmp очень схожи по сути. Для многопользовательских систем systemd отделяет /run/user/$UID, хотя у нас есть свой /tmp/.private/$USER, но на общем разделе /tmp. Для типичной однопользовательской системы нет особой нужды иметь столько TMPDIR'ов. Если корневая система только для чтения, вполне логично, что у нас могут быть проблемы и с /root/tmp, и с /etc/udev/hwdb.bin (rpm -V udev, по-хорошему надо тоже линковать в /run/udev, поскольку создаётся при каждой загрузке). По FHS опять же /root необязателен, на практике без него встречал только некоторые busybox-образы, а тот факт, что для рута могут использоваться и /root/tmp, и /tmp немного вводит в замешательство. Короче, клоню к тому, что проще администрировать одну tmpfs. > >> к тому же всё делается на tmpfs хостовой системы. > Хостовая файловая система, вообще говоря, не обязана быть tmpfs. Да, но так ведь практика... >> Раз пошли вслед за остальными в этом вопросе (имеются ввиду симлинки >> /var/run -> /run и /var/lock -> /run/lock), логичнее было бы довести это >> до ума с остальными каталогами, которые также всегда были tmpfs. Чтобы >> на каждую систему была только одна tmpfs: >> >> /dev/.* -> /run/* (к примеру /dev/.udev -> /run/udev) >> /dev/shm -> /run/shm > Интересно, а что такое /run/shm? Подкаталог, создаваемый при каждом запуске после монтирования tmpfs в /run (в Debian и основанных на нём). >> /dev/shm/* -> /run/* > Прямо в run? Да. Наверное, имеются ввиду всякие X-овые в первую очередь программы, всякие СУБД, которые раньше использовали для тех же целей /dev/shm -- теперь они могут использовать непосредственно /run, та же tmpfs. >> /tmp -> /run/tmp > Интересно, а что такое /run/tmp? Тоже подкаталог, как и /run/shm. Но я проверил, это далеко не везде так. > Раньше размер /tmp на порядки превышал размер /run; > с тех пор что-то изменилось? Поскольку речь идёт о делёжке RAM+SWAP, придумывать жёсткие лимиты на каждый случай для схожих задач незачем. Ничто не мешает закрутить гайки на конкретной системе, если цели оправданы. Сейчас же мне это видится скорее вредным, раз всё так перемешалось и программы могут использовать разные пути для своих задач. > У разных tmpfs разные задачи и, как следствие, разные параметры > монтирования. Разные только в плане ограничения по размеру (айнодам). Так-то задача tmpfs иметь быстрый доступ к данным и не захламлять диск. Большая часть других ограничений решается дискретной моделью доступа к подкаталогам в /run и общим для всего tmpfs (/run) "nosuid,noexec". Тем, кто собирает на tmpfs хэшером или mkimage это, понятно, не подходит. Но ведь не все пользователи альта занимаются сборкой, скорее меньшинство, а дефолт /tmp сейчас для сборщиков в ущерб безопасности. Вот для них (для нас то есть) /tmp можно отделить причём даже не весь /tmp, а только $TMPDIR. -- Best regards, Leonid Krivoshein. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] /dev/shm 2019-08-28 14:33 ` Alexey Gladkov 2019-08-28 15:02 ` Dmitry V. Levin @ 2019-08-28 16:31 ` Stanislav Levin 1 sibling, 0 replies; 32+ messages in thread From: Stanislav Levin @ 2019-08-28 16:31 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1.1: Type: text/plain, Size: 679 bytes --] 28.08.2019 17:33, Alexey Gladkov пишет: > On Wed, Aug 28, 2019 at 04:54:43PM +0300, Dmitry V. Levin wrote: >> С другой стороны, /dev/shm до сих пор был фактически доступен по >> умолчанию, поскольку создавался hasher'ом автоматически с правами 01777, >> начиная с версии 1.3.23 (т.е.уже более 7 лет). >> >> Видимо, убирать /dev/shm сейчас будет уже неправильно. > Да, это изменение ломает пакеты, но с другой стороны лучше явно иметь > BR: /dev/shm и явно знать кому он нужен. Согласен - добавить теперь точно придется. Правда, большинство "неправильных" пакетов оказалось у меня :-) Насчет автосоздания - а что гласит POSIX (если, конечно, это авторитетный источник) ? [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2019-08-30 4:30 UTC | newest] Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-08-28 8:27 ` [devel] Fwd: [cyber] I: Sisyphus-20190827 x86_64 beehive_status: +34 -5 (105) Levin Stanislav 2019-08-28 9:04 ` [devel] /dev/shm Dmitry V. Levin 2019-08-28 9:55 ` Dmitry V. Levin 2019-08-28 9:58 ` Anton Farygin 2019-08-28 10:03 ` Валерий Иноземцев 2019-08-28 10:13 ` Dmitry V. Levin 2019-08-28 10:57 ` Dmitry V. Levin 2019-08-29 0:56 ` Alexey Shabalin 2019-08-28 13:54 ` Dmitry V. Levin 2019-08-28 14:33 ` Alexey Gladkov 2019-08-28 15:02 ` Dmitry V. Levin 2019-08-28 15:11 ` Alexey Gladkov 2019-08-28 15:23 ` Dmitry V. Levin 2019-08-28 18:08 ` Alexey Gladkov 2019-08-28 18:11 ` Anton Farygin 2019-08-28 18:24 ` Dmitry V. Levin 2019-08-28 18:45 ` Anton Farygin 2019-08-28 18:50 ` Anton Farygin 2019-08-28 18:59 ` Dmitry V. Levin 2019-08-29 21:08 ` Dmitry V. Levin 2019-08-28 18:15 ` Dmitry V. Levin 2019-08-28 19:50 ` Alexey Gladkov 2019-08-28 20:53 ` Dmitry V. Levin 2019-08-28 21:46 ` Alexey Gladkov 2019-08-28 22:52 ` Dmitry V. Levin 2019-08-29 13:58 ` Andrey Savchenko 2019-08-29 19:24 ` Dmitry V. Levin 2019-08-29 19:36 ` Anton Farygin 2019-08-29 23:39 ` Leonid Krivoshein 2019-08-30 0:27 ` Dmitry V. Levin 2019-08-30 4:30 ` Leonid Krivoshein 2019-08-28 16:31 ` Stanislav Levin
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git