基于Google Cloud定时获取网站数据的持久运行方案咨询

Hey there! Let's get your crypto data getter running non-stop on GCE, even after you close your SSH session, and make sure those CSV files are saved properly. Here are a few reliable methods to solve this:

1. Quick Fix: Use nohup #

This is the simplest way to run your script in the background without being tied to your SSH session.

• SSH into your GCE instance as usual.
• Navigate to the directory where your code.py is stored.
• Run this command:

  nohup python3 code.py &
  

  • nohup stands for "no hangup"—it keeps the process running even after you log out.
  • The & sends the process to the background so you can keep using the terminal.
• By default, output from the script will be saved to nohup.out in the same directory. If you want to specify a custom log file:

  nohup python3 code.py > crypto_script.log 2>&1 &
  

• To check if the script is still running:

  ps aux | grep code.py
  

• To stop the process later, use kill followed by the process ID you get from the command above:

  kill <process-id>
  

2. Reattachable Sessions: Use screen or tmux #

If you want to be able to reconnect to your script's terminal session later (to check output or make changes), screen or tmux are perfect. Let's use screen as an example:

• First, install screen if it's not already on your instance:

  sudo apt update && sudo apt install screen
  

• Start a new screen session with a descriptive name:

  screen -S crypto_data_session
  

• Now run your script like normal:

  python3 code.py
  

• To detach from the session (leaving it running in the background), press Ctrl + A then D. You can now close your SSH session—your script will keep running.
• To reattach to the session later (when you SSH back in):

  screen -r crypto_data_session
  

• To close the session entirely, just type exit inside the screen session.

3. Most Reliable: Create a systemd Service #

For long-term, production-like running (including auto-restart if the script crashes or the instance reboots), setting up a systemd service is the way to go.

Step 1: Create the service file #

Open a new service file with nano:

sudo nano /etc/systemd/system/crypto-data-getter.service

Step 2: Paste this configuration (update placeholders!) #

[Unit]
Description=Crypto Currency Data Getter Service
After=network.target  # Wait for network to be ready before starting

[Service]
User=your-username  # Replace with your GCE instance username (e.g., ubuntu)
WorkingDirectory=/path/to/your/script/folder  # Replace with the directory containing code.py
ExecStart=/usr/bin/python3 code.py  # Path to your Python interpreter and script
Restart=always  # Auto-restart if the script crashes
RestartSec=10  # Wait 10 seconds before restarting
StandardOutput=append:/var/log/crypto-data.log  # Optional: Log output to a file
StandardError=append:/var/log/crypto-data.log

[Install]
WantedBy=multi-user.target  # Start the service when the instance boots

Step 3: Enable and start the service #

• Save the file by pressing Ctrl + O, hit Enter, then Ctrl + X to exit.
• Reload systemd to recognize the new service:

  sudo systemctl daemon-reload
  

• Start the service:

  sudo systemctl start crypto-data-getter
  

• Set it to start automatically when the instance boots:

  sudo systemctl enable crypto-data-getter
  

Step 4: Manage the service #

• Check the service status:

  sudo systemctl status crypto-data-getter
  

• View real-time logs:

  journalctl -u crypto-data-getter -f
  

• Stop the service if needed:

  sudo systemctl stop crypto-data-getter
  

Important Note About CSV File Saving #

Make sure your script saves the CSV file to a stable, absolute path (instead of a relative path) to avoid confusion. For example, instead of:

with open('crypto_data.csv', 'a') as f:

Use something like:

with open('/home/your-username/crypto_data.csv', 'a') as f:

This ensures the CSV is saved to a consistent location, no matter how you run the script.

Why Your Startup Script Might Have Failed #

If your initial startup script didn't work, it's likely because:

• The script ran as the root user, but your Python dependencies or file permissions are set for your regular user.
• You used a relative path to code.py instead of an absolute path.
  Fix this by updating your startup script to run the command as your regular user, e.g.:

su - your-username -c "nohup python3 /home/your-username/code.py &"

内容的提问来源于stack exchange，提问作者Ahmet Burkay Kınık