咨询:Google Compute Engine中Flask应用关闭SSH后如何持续运行及目录影响?
Hey there! I’ve run into this exact issue before with GCE VMs and Flask apps—let’s fix this step by step.
Why Your App Stops When You Close SSH
When you start your Flask app in the SSH terminal, it’s running as a foreground process tied directly to your SSH session. When you close the connection, the system sends a SIGHUP (hangup) signal to all processes in that session, which kills your Flask app. The fix is to run the app in a way that detaches it from the SSH session entirely.
3 Reliable Ways to Keep Your App Running
1. Quick Fix: Use nohup to Run in the Background
This is the simplest method for testing or short-term use:
- Launch your app with this command:
nohup python3 your_flask_app.py &nohupignores theSIGHUPsignal that would terminate the app when SSH closes&sends the process to the background so you can keep using the terminal
- By default, logs are saved to
nohup.outin your current directory. You can redirect logs to a specific file for easier management:nohup python3 your_flask_app.py > /var/log/flask_app.log 2>&1 &
2. Terminal Multiplexer: screen or tmux
Perfect if you need to occasionally reattach to the app’s terminal (e.g., for debugging or updating):
- Install
screen(Debian/Ubuntu):sudo apt update && sudo apt install screen - Start a named screen session for your app:
screen -S flask_app_session - Launch your Flask app normally inside the screen session
- Detach from the session without closing it: press
Ctrl + A, thenD - When you reconnect via SSH, reattach to the session to resume interacting with the app:
screen -r flask_app_session
3. Production-Grade: Use systemd (Recommended)
This is the best method for long-term, stable deployment—it ensures your app starts automatically on VM boot and restarts if it crashes unexpectedly.
- Create a systemd service file:
sudo nano /etc/systemd/system/flask-app.service - Paste this configuration (adjust paths and user to match your setup):
[Unit] Description=My Flask Web Application After=network.target # Wait for network connectivity before starting the app [Service] User=your_gce_username # Replace with your VM's username (e.g., ubuntu) WorkingDirectory=/path/to/your/app/folder # e.g., /home/ubuntu/my_flask_app ExecStart=/usr/bin/python3 /path/to/your/app/folder/app.py # Full path to your Flask app Restart=always # Automatically restart the app if it crashes Environment="FLASK_APP=app.py" Environment="FLASK_ENV=production" # Use "development" only for testing purposes [Install] WantedBy=multi-user.target # Start the service when the system reaches multi-user mode - Save and exit the editor (for nano:
Ctrl + O, pressEnter, thenCtrl + X) - Reload systemd to recognize the new service:
sudo systemctl daemon-reload - Start the app service:
sudo systemctl start flask-app - Enable it to start automatically on VM boot:
sudo systemctl enable flask-app - Check the app’s status or logs anytime:
# Verify if the app is running sudo systemctl status flask-app # View real-time logs journalctl -u flask-app -f
Does the Storage Directory Matter?
Short answer: No, the directory itself doesn’t affect whether the app runs continuously. However, there are a few directory-related issues that could cause problems:
- Permissions: If your app needs to write files (e.g., uploads, logs) to its directory, make sure the user running the app has read/write permissions there. Fix this with:
sudo chown -R your_gce_username:your_gce_username /path/to/your/app/folder - Relative Paths: If your Flask app uses relative paths to load templates, static files, or configs, starting the app from a different directory might break those paths. Always use absolute paths in your code, or set the
WorkingDirectoryin your systemd service to the app’s folder (as shown above) to avoid this. - Temporary Directories: Avoid storing critical app files in
/tmp—the system cleans this directory periodically, which could break your app if it relies on files stored there.
内容的提问来源于Stack Exchange,提问作者doedotdev

