[devel] Fwd: [cyber] I: Sisyphus-20190827 x86_64 beehive_status: +34 -5 (105)

[devel] Fwd: [cyber] I: Sisyphus-20190827 x86_64 beehive_status: +34 -5 (105)

[Levin Stanislav]

[-- 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 --]

Re: [devel] /dev/shm

[Dmitry V. Levin]

[-- 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 --]

Re: [devel] /dev/shm

[Dmitry V. Levin]

[-- 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 --]

Re: [devel] /dev/shm

[Anton Farygin]

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
>
Точно, я нарвался.

Re: [devel] /dev/shm

[Валерий Иноземцев]

[-- 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 --]

Re: [devel] /dev/shm

[Dmitry V. Levin]

[-- 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 --]

Re: [devel] /dev/shm

[Dmitry V. Levin]

[-- 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 --]

Re: [devel] /dev/shm

[Dmitry V. Levin]

[-- 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 --]

Re: [devel] /dev/shm

[Alexey Gladkov]

[-- 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 --]

Re: [devel] /dev/shm

[Dmitry V. Levin]

[-- 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 --]

Re: [devel] /dev/shm

[Alexey Gladkov]

[-- 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 --]

Re: [devel] /dev/shm

[Dmitry V. Levin]

[-- 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 --]

Re: [devel] /dev/shm

[Stanislav Levin]

[-- 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 --]

Re: [devel] /dev/shm

[Alexey Gladkov]

[-- 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 --]

Re: [devel] /dev/shm

[Anton Farygin]

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, не проблема же ;)

Re: [devel] /dev/shm

[Dmitry V. Levin]

[-- 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 --]

Re: [devel] /dev/shm

[Dmitry V. Levin]

[-- 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 --]

Re: [devel] /dev/shm

[Anton Farygin]

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, не проблема же ;)
> Интересно, как вы будете это тестировать. ;)
Жизнью. Выложишь, что-то сломается, ты починишь ;)

Re: [devel] /dev/shm

[Anton Farygin]

On 28.08.2019 21:45, Anton Farygin wrote:
> Могут сломаться другие пользователи hasher'а, поскольку полностью
> прекращается обмен файлами в hasher/chroot/dev между процессами
> снаружи и внутри чрута.
>
> Например, пришлось починить пакет mkve, потому что mkve-cache
> использовал hsh-fakedev, которого больше нет.
>
> Я не удивлюсь, если сломаются какие-то пользователи mkimage. 

Интересно, как станет себя вести hasher в системах виртуализации. В 
докере, в lxc.

Скорее всего основные поломки могут случиться там, где как-то 
ограничивают возможность создания устройств.

Re: [devel] /dev/shm

[Dmitry V. Levin]

[-- 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 --]

Re: [devel] /dev/shm

[Alexey Gladkov]

[-- 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 --]

Re: [devel] /dev/shm

[Dmitry V. Levin]

[-- 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 --]

Re: [devel] /dev/shm

[Alexey Gladkov]

[-- 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 --]

Re: [devel] /dev/shm

[Dmitry V. Levin]

[-- 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 --]

Re: [devel] /dev/shm

[Alexey Shabalin]

В Ср, 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

Re: [devel] /dev/shm

[Andrey Savchenko]

[-- 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 --]

Re: [devel] /dev/shm

[Dmitry V. Levin]

[-- 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 --]

Re: [devel] /dev/shm

[Anton Farygin]

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 прямо при 
ближайшей пересборке, просто записав в логи эту разницу.

Re: [devel] /dev/shm

[Dmitry V. Levin]

[-- 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 --]

Re: [devel] /dev/shm

[Leonid Krivoshein]

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.

Re: [devel] /dev/shm

[Dmitry V. Levin]

[-- 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 --]

Re: [devel] /dev/shm

[Leonid Krivoshein]

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.