Проблема в отсутствии на
$ uname -a
Linux pbf64.office.etersoft.ru 2.6.32-ovz-el-alt147 #1 SMP Fri Oct 28 17:45:13 UTC 2016 x86_64 GNU/Linux

системного вызова:
getrandom(0x8e05f0, 24, 0)              = -1 ENOSYS (Function not implemented)
write(2, "Fatal Python error: getentropy()"..., 40Fatal Python error: getentropy() failed
) = 40

Ошибка должна воспроизводится с
$ strace -e fault=getrandom python3

У меня подозрение, что новый glibc предоставил обёртку для getrandom приложению,
а приложение не может корректно обработать ошибку вызова этой функции.

$ uname -r
4.9.18-std-def-alt1
$ rpm -q glibc 
glibc-2.25-alt2.x86_64
$ python3
Python 3.5.1 (default, Apr  7 2017, 11:25:29)
[GCC 6.3.1 20170118 (ALT 6.3.1-alt2)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D
$ strace -o /dev/null -e fault=getrandom python3
Fatal Python error: getentropy() failed
zsh: segmentation fault  strace -o /dev/null -e fault=getrandom python3

(In reply to comment #1)
> Проблема в отсутствии на
> $ uname -a
> Linux pbf64.office.etersoft.ru 2.6.32-ovz-el-alt147 #1 SMP Fri Oct 28 17:45:13
> UTC 2016 x86_64 GNU/Linux
> 
> системного вызова:
> getrandom(0x8e05f0, 24, 0)              = -1 ENOSYS (Function not implemented)
> write(2, "Fatal Python error: getentropy()"..., 40Fatal Python error:
> getentropy() failed
> ) = 40
> 
> Ошибка должна воспроизводится с
> $ strace -e fault=getrandom python3
> 
> У меня подозрение, что новый glibc предоставил обёртку для getrandom
> приложению,
> а приложение не может корректно обработать ошибку вызова этой функции.

По-моему, python3 даже в некотором смысле обработал эту ошибку (ведь кто-то написал: Fatal Python error), но он написан так, что считает, что эта функция в нормальной ситуации не возвращает ошибку.

Если верно предположение о том, что вызывается обёртка над системным вызовом из glibc, получается, что glibc считает нормальным вернуть ошибку (и пусть приложение разбирается), а приложение считает, что ненормально (и glibc должна была сама разобраться, раз уж предоставило такое API). Какое поведение функции из glibc более правильное?

(Интересно: а тесты же python3 проходили в сборочнице. Там какое-то другое ядро?)

Просто в Сизифе старый глючный питон, не рассчитанный на современные ядра и glibc.

(In reply to comment #2)
> $ uname -r
> 4.9.18-std-def-alt1
> $ rpm -q glibc 
> glibc-2.25-alt2.x86_64
> $ python3
> Python 3.5.1 (default, Apr  7 2017, 11:25:29)
> [GCC 6.3.1 20170118 (ALT 6.3.1-alt2)] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> ^D
> $ strace -o /dev/null -e fault=getrandom python3
> Fatal Python error: getentropy() failed
> zsh: segmentation fault  strace -o /dev/null -e fault=getrandom python3

Я, наоборот, понял, что на более современных ядрах питон не падает, как видно здесь. (Возможно, он и на ядре в сборочнице не падает.) А этот системный вызов он в итоге делает всегда при просто запуске, раз если его явно зафейлить с помощью strace, то он падает.

Я подумал, что функция в glibc стала возвращать ошибку на более старых ядрах (дело не в неадаптированности python3 к новым ядрам), либо python3 после пересборки стал вызывать другую функцию из glibc, которая возвращает ошибку на более старых ядрах (недоделка в python3).

(In reply to comment #4)
> Просто в Сизифе старый глючный питон, не рассчитанный на современные ядра и
> glibc.

В Сизифе как раз достаточно свежие питоны (и я не знаю версии питонов, которые будучи собранными в окружении с современными ядрами и glibc, не работали с ними). Проблема проявляется, как я понял, на openvz-ядрах с glibc-2.25. Похоже, что-то поменялось в поведении glibc.

python3-3.5.1-alt8 -> sisyphus:

* Tue Apr 11 2017 Gleb F-Malinovskiy <glebfm@altlinux> 3.5.1-alt8
- Fixed interpreter breakage caused by rebuild with glibc >= 2.25
  (closes: #33356).