I have been running a fedora server for many years running NextCloud for internal use. I have gone through many upgrades of Fedora without any issues. Now, after upgrading to f41, all of a sudden the web server gives me internal server error without giving me a real error in the log files. What could’ve changed to cause this error?
Have a look on the change log … check the server specific apps you could have had installed or software changes where you have to reinstall or substitute:
Releases/41/ChangeSet - Fedora Project Wiki
There have been some ssl changes you might have to check.
This is when you access the web site to manage NextCloud?
You might also give a bit more information which web-server you are using etc.
I am using apache. I don’t remember the exact version of python I was running it under, but if it was under 2.7 and the forced upgrade was for 2.8, how am I supposed to handle that.
On the server you can still log in right?
How do you manage your server? With cockpit?
Yes, I can. I manage it through ssh.
Do you get more information when you check
sudo systemctl status httpd.service
sudo systemctl restart httpd.service # or restart and see what error it gives
Then you can do research in the journalctl with the programs failing etc.
I did as you suggested. With the restart, I’m receiving no error. That’s the whole issue with this problem. I have no idea what to try, because I’m receiving no errors anywhere. Including the messages log or any of the httpd logs.
According to the php-fpm logs
[26-Nov-2024 13:19:18] NOTICE: Terminating …
[26-Nov-2024 13:19:18] NOTICE: exiting, bye-bye!
[26-Nov-2024 13:20:11] NOTICE: fpm is running, pid 931
[26-Nov-2024 13:20:11] NOTICE: ready to handle connections
[26-Nov-2024 13:20:11] NOTICE: systemd monitor interval set to 10000ms
[26-Nov-2024 14:10:03] NOTICE: Terminating …
[26-Nov-2024 14:10:03] NOTICE: exiting, bye-bye!
[26-Nov-2024 14:10:03] NOTICE: fpm is running, pid 2146
[26-Nov-2024 14:10:03] NOTICE: ready to handle connections
[26-Nov-2024 14:10:03] NOTICE: systemd monitor interval set to 10000ms
It’s continuously restarting. Is that normal?
I don’t think bare nextcloud requires python, but many web-server ad-ons use python.
DoubleBastion Red Scarf Suite is a new effort to provide an open-source business suite (using debian, currently pre-release) and has Linux Server Guide. After
you may want to consider whether some components are no longer being maintained and will be problematic on current linux.
So isn’t there anything interesting in journalctl or even dmesg? Some OOM killer message?
No there was still no message because it wasn’t httpd that was failing. It turns out it was because valkey (redis) wasn’t running because the valkey user wasn’t in the redis group and the log directory redis didn’t have the correct permissions to write log files into /var/logs/redis. I also had to set valkey to run on reboot for everything to come up after reboot. Very frustrating. It was all set by the upgrade process.
1 Like
I do believe, especially if you not have some keywords to search after. But in the end could you solve your issue?
Did the Topic below help you to solve your issue?
1 Like
Yeah, I ran into this as well on my Nextcloud host going from 40 to 41. The redis->valkey transition wasn’t flawless. I basically needed to create and set perms on the locations that were no longer there.
I created /var/run/redis and /var/log/redis and set ownership to valkey:valkey to both and then it started. Alternatively, you could updated your valkey configs to point to valkey locations but they didn’t all exist for me either.
sudo mkdir -p /var/run/redis /var/log/redis && sudo chown -R valkey:valkey /var/run/redis /var/log/redis && sudo systemctl restart valkey should fix it.
(I had to set the SELinux context for the re-used redis locations, so it might be better to point your conf to valkey locations instead.)
2 Likes
Did you have to setup valkey to autostart on bootup? I found out the problem by doing a ton of googling that finally got me to a support page on nextcloud’s website.
1 Like
I used sudo systemctl enable --now when I started it the first time just to be sure.