Hi there!
From what you described, it doesn’t sound like the issue stems from any specific coding errors—looking over app.py, nothing seems overtly “wrong”—but rather from the way the Flask application is being run. In other words, it might be that the app times out or is terminated after a while. On a Raspberry Pi, if you launch the app manually (for example, with python app.py) in an interactive terminal, it only takes a closed session or a system event to terminate the app.
Here are a few tips to help solve the problem:
1. Use a process manager or systemd
Instead of launching app.py in the foreground, consider configuring a systemd service (or a process manager like supervisor, pm2, etc.) that keeps the app running continually. That way, even if the app “crashes” or if you close the SSH/terminal session, the service will restart automatically.
For example, you can create a systemd service file (/etc/systemd/system/magazzino.service) with something like:
Then enable and start it with:
2. Remove debug=True in production
In a production environment, the debug=True setting in Flask isn’t recommended because it can lead to unexpected behavior (the Flask development server isn’t designed for long-term use). It’s better to use a WSGI server like Gunicorn or uWSGI behind a reverse proxy (Nginx or Apache) for a more robust setup.
However, if your goal is simply to use it on a LAN for private purposes, systemd plus the built-in Flask server might be sufficient.
3. Check your logs
Your code already logs database operations, which is great. Check /var/log/syslog (or wherever you’ve configured logs, if you’re using systemd) to see if there are error messages or Python interpreter crashes, or if you see out-of-memory (OOM) errors.
If the Raspberry Pi is struggling for some reason (too little RAM, too many processes), you might see OOM errors in the system logs.
4. Make sure Apache/MariaDB are stable
If you’re also running Apache on another port, ensure there are no networking conflicts, especially if you’re running Flask on 0.0.0.0:80. It’s often simpler to have Flask on a different port (like 5000 or 8080) and leave Apache on 80.
MariaDB usually doesn’t cause trouble, but if you have a lot of writes, verify that there are no disk errors or related issues.
5. Consider a hosting service or external support
If you’d prefer to delegate setting up and maintaining the application to professional developers, you might find it helpful to check out this article on Python Development Outsourcing http://limeup.io/blog/python-development-outsourcing/ for insights on how to outsource Python projects if you don’t want to manage everything yourself.
In summary, there are no obvious mistakes in your app.py; the main issue is likely that your Flask application isn’t run as a persistent service, so it shuts down after some time or a system event. Try configuring it as a systemd service or using a process manager to ensure it stays up 24/7.
Hope these suggestions help you keep your virtual warehouse up and running without interruption. Let us know if it resolves your issue!
From what you described, it doesn’t sound like the issue stems from any specific coding errors—looking over app.py, nothing seems overtly “wrong”—but rather from the way the Flask application is being run. In other words, it might be that the app times out or is terminated after a while. On a Raspberry Pi, if you launch the app manually (for example, with python app.py) in an interactive terminal, it only takes a closed session or a system event to terminate the app.
Here are a few tips to help solve the problem:
1. Use a process manager or systemd
Instead of launching app.py in the foreground, consider configuring a systemd service (or a process manager like supervisor, pm2, etc.) that keeps the app running continually. That way, even if the app “crashes” or if you close the SSH/terminal session, the service will restart automatically.
For example, you can create a systemd service file (/etc/systemd/system/magazzino.service) with something like:
Code:
[Unit]Description=Flask Magazzino ServiceAfter=network.target[Service]ExecStart=/usr/bin/python /path/to/your/app.pyWorkingDirectory=/path/to/your/Restart=always[Install]WantedBy=multi-user.targetCode:
sudo systemctl enable magazzino.servicesudo systemctl start magazzino.serviceIn a production environment, the debug=True setting in Flask isn’t recommended because it can lead to unexpected behavior (the Flask development server isn’t designed for long-term use). It’s better to use a WSGI server like Gunicorn or uWSGI behind a reverse proxy (Nginx or Apache) for a more robust setup.
However, if your goal is simply to use it on a LAN for private purposes, systemd plus the built-in Flask server might be sufficient.
3. Check your logs
Your code already logs database operations, which is great. Check /var/log/syslog (or wherever you’ve configured logs, if you’re using systemd) to see if there are error messages or Python interpreter crashes, or if you see out-of-memory (OOM) errors.
If the Raspberry Pi is struggling for some reason (too little RAM, too many processes), you might see OOM errors in the system logs.
4. Make sure Apache/MariaDB are stable
If you’re also running Apache on another port, ensure there are no networking conflicts, especially if you’re running Flask on 0.0.0.0:80. It’s often simpler to have Flask on a different port (like 5000 or 8080) and leave Apache on 80.
MariaDB usually doesn’t cause trouble, but if you have a lot of writes, verify that there are no disk errors or related issues.
5. Consider a hosting service or external support
If you’d prefer to delegate setting up and maintaining the application to professional developers, you might find it helpful to check out this article on Python Development Outsourcing http://limeup.io/blog/python-development-outsourcing/ for insights on how to outsource Python projects if you don’t want to manage everything yourself.
In summary, there are no obvious mistakes in your app.py; the main issue is likely that your Flask application isn’t run as a persistent service, so it shuts down after some time or a system event. Try configuring it as a systemd service or using a process manager to ensure it stays up 24/7.
Hope these suggestions help you keep your virtual warehouse up and running without interruption. Let us know if it resolves your issue!
Statistics: Posted by LimeUp — Fri Mar 28, 2025 3:31 pm