[Bug]: Synology DSM 6.2.4 - Could not initialize random number generator Found /var/run/php/php-fpm.sock!

[olituks]

Issue description

Hello, after a successful setup from Flarum on my Synology the logs show recurrently this error:
[Mon May 29 08:48:45.815751 2023] [:crit] [pid 303] (38)Function not implemented: AH00141: Could not initialize random number generator
Flarum is not accessible but the container is running.

Environment

• Operating System Version: DSM 6.2.4 last version (not upgradable anymore)
• Docker Version: 20.10.3-0554
• kernel version on my NAS:

sysadmin@iHome:/$ uname -a
Linux iHome 3.10.105 #25556 SMP Tue Mar 21 22:22:21 CST 2023 x86_64 GNU/Linux synology_cedarview_1812+

Steps to reproduce the issue

1.Install Flarum on a Synology DSM 6.2.4 or higher (confirmed in the nextcloud github with DSM 7.x)
2.
3.

What is expected?

I know the issue is not directly related with your container, but have you any idea how to solve this?

Additional details / screenshots

You can see the similar issue for phpmyadmin: phpmyadmin/docker#373
The same with nextcloud: nextcloud/docker#1574

[gingerbeardman]

I've had this with other docker containers, if you google the error message you'll find lots. I've had this in the past with RSS-Bridge and this month with Huginn.

nextcloud/docker#1574 (comment)

The issue is with the way the docker container is packaged, what the developer has included that assumes /dev/urandom is available...when it isn't on every version of Linux kernel.

The easiest solution is to go back to an older version of the docker container before this breaking change.

The more difficult solution is to try to persuade the owner of the container to look into and fix the problem.

[shinsenter]

Hi @olituks, @gingerbeardman!

Thank you for providing comprehensive information about this issue. As you mentioned, this is not directly related to my Docker image building process, and currently, I haven't found any effective solution to this problem. Therefore, I would appreciate it if you could let me know if there are any possible solutions.

Best regards.

[gingerbeardman]

Usually the problem is Apache or OpenSSL. There's a recent recommendation/patch for OpenSSL to avoid use of /dev/urandom/ which is the first thing I'd recommend checking.

Ruby 3.2 suffers the same problem and they have a pull request to remove their use of urandom in their OpenSSL calls.

But really all contents of the container will need to be checked for calls to urandom. It sucks to be stuck on old hardware (I'm Synology 6 too) I think there are many of us.

[olituks]

@shinsenter The only thing I wish is firsty, warning you about the issue and impact on the DSM community, second if it's doable indeed, checking if OpenSSL or another component can be fixed. Nothing more. =) If not, I have a fall back solution with a Raspberry PI 4. Many thanks in advance, whatever the result :)

@gingerbeardman Yes it sucks to not have possibility to upgrade old expensive hardware from Synology to the 7.x DSM. But it provide me a good reason to wait a decent price to buy on a new SSD NAS like the Asustor Flashstor.

[gingerbeardman]

OpenSSL or another component can be fixed

Historically OpenSSL recommended developers use urandom during integration of OpenSSL into their projects. But internally /dev/urandom is only used by OpenSSL if it's available. But many developers don't understand that /dev/urandom isn't always available.

Since recently (v3) OpenSSL no longer recommend that. Maybe because of this issue, I'm not sure. The problem is, many open source projects missed the memo.

ruby/ruby#7705

[shinsenter]

I am saving this document as a reference link for the issue.

If anybody is running with old kernel or disables getrandom I would say they are on their own - also other stuff will break, not only apache2.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978045

[gingerbeardman]

Also worth mentioning from the same thread

I think a perfectly valid fix would be to document (in the changelog or
elsewhere) that this hard requirement was added, in particular because
(IIUC) using getrandom() instead of one of the other codepaths is the
choice of the package maintainer. (I.e. this isn't just the result of
upstream.) Tracking down what broke and why was mostly tricky because it
wasn't documented

For me, I do plan to upgrade "soon", but in order to do that I need to physically be at my server which happens rarely.

In the handful of years I've had it running, this breakage has happened with 3 packages total, two were changed to workaround the getrandom issue, which is easy enough in most situations if the maintainer wants to do it, and one package is still thinking about how to deal with it. And then there is your package.

[gingerbeardman]

one solution is to use php:8.2-apache-buster

from: nextcloud/docker#1574 (comment)

[shinsenter]

@olituks @gingerbeardman

I have pushed the newly built docker images from the official php docker images, I hope they can solve your problem.
https://hub.docker.com/r/shinsenter/php/tags

I am updating the documentation, you can also refer to it here.
https://github.com/shinsenter/php/blob/5.x/README.md