I had been trying to install Grocy in my Debian VPS1 for a week with no success. After several failed attempts, today I have finally made it.
In the beginning I followed the guide in the documentation and the guide pined in Reddit
(link), but
it did not work: some HTTP 500 Error or something like that. Then I made my own custom Nginx
server
configuration, it did not work neither. Then moved the files to different directories, changed their
ownership, installed php8.1
, etc., but nothing seemed to work.
The best result I achieved was being able to login, just to face a dashboard seeming not to recognize the CSS styling. A similar situation had been reported in Reddit a few days ago (link).
But then, out of nowhere…
Today I got the idea to be certain that the problem was in my VPS. So I installed php8.1 in my PC, downloaded
Grocy, and run the app with php -S 127.0.0.1:8000
from grocy/public
. It worked like a charm.
So I tried by first removing php
in my VPS and then installing php8.1
from scratch, and it worked! The
following are the exact steps I did:
Purge php7.4
and install php8.1
Remove the php
version currently installed, because mine was 7.4
|
|
Update and upgrade the system
|
|
Installed some other packages2 to add the php8.1
repository to the list
|
|
Then use this script to set up the php8.1
repository
|
|
Update and upgrade the system
|
|
Install php8.1
and other dependencies for Grocy
|
|
Start the php8.1
process
|
|
Download Grocy and set the Nginx server
Make the folder where Grocy is gonna live, and move to it
|
|
Download the last version of Grocy, and unpack it
|
|
Copy the config.php
file to the data
folder
|
|
Note: Normally you would edit the config.php
file as described in the documentation and in its internal
comments. In my case the Grocy instance is going to be on the subdomain grocy.website.org
of my
VPS. Therefore, I do not need to edit anything in config.php
.
Change the ownership of the files to the user and group www-data
(which should exist by default in your
system).
|
|
Edit/create the file /etc/nginx/conf.d/fastcgi_params
and fill it with the following information
|
|
Finally set the Nginx
server. In the file /etc/nginx/sites-available/grocy
write the following
|
|
Of course you must change the server_name
directives to your server.
Then create the link to the sites enabled folder
|
|
and restart Nginx
|
|
If you go to the server_name
address it should be there.
Conclusions
Following those exact steps it worked to me, and I did it twice from scratch to check it wasn’t just luck.
Finally, if you are using Certbot
to encrypt the traffic to your Nginx
server, do
|
|
Do not hesitate to contact me in case you find something wrong here, or have any question. Have in mind that I am not an expert on the subject, so anything too technical may be difficult to me.
Update to v4.0.2 and associated problems
I tried to update to the new release at the moment (4.0.2) with the script provided update.sh
, and something got broken. I had to do several things, revoking all the SSL Certificates and configurations of the Nginx previously generated (and re-do them), restarting the php-fpm
service with systemctl restart php8.1-fpm
, removing all the content from data
and letting the default. I do not really know what specific step worked.
However, whenever I was using it and make one or two clicks in the menus, it stopped the php8.1-fpm
service and the whole server went down. This should be related to an over-consumption of resources or something like that. I tied to fix it by making the following changes to the configuration file /etc/php/8.1/fpm/php.ini
, but it did not worked neither
max_input_time = -1
(it was 60)max_execution_time = 300
(it was 30)memory_limit = 512
(it was 128)post_max_size = 128M
(it was 8M)upload_max_filesize = 1024M
(it was 2M)
The last attempt was to make a fresh installation, and not to use my old database, because some issues were reported because of problems with new features of cascade units conversion. So far so good, although at the moment of writing this update I have only added my list of products to the database, not recipes, nor daily plans neither shopping lists. In case it breaks, then it means it is definitively related to the resources required by Grocy.
The problem with all this is that I had to manually rebuilding the database. It is something I have been doing gradually, and make sure everything is consistent. Luckily I had not that many data in it yet. However after I added the first recipe it started shutting down the system again. I looked at the result of ~$ top
at the moment the server went down, and indeed the memory resource went really up. No matter what the developers may say, there is something in this new releases that consumes much more RAM than in the 3.x.x versions, where I had no issues with this.
The final solution and identification of the problem
After a few days of rest, I was again searching what to do with Grocy, and realized I had no swap on my server, just the RAM (type free -h
to check your case). Then, I configured a swap partition of 3GB following step-by-step this excellent guide of Digital Ocean. Also, I modified/enabled the following options in the fpm
pool configuration file /etc/php/8.1/fpm/pool.d/www.conf
:
|
|
This solved my problem! Now I can see (with free -h
) that my RAM is a little bit free, and the swap partition is being used, around 800MB of it. Now I can use Grocy, but it is a little bit slow to response, even though my database is very small (around 30 ingredients and 2 recipes). Anyway, this is a great piece of software completely free as in freedom and as in money, maintained mostly by a single developer.
Footnotes
Thanks for reading the post! Do not hesitate to write me an email, and share your point of view 😉: contact@poview.org