BeagleBone Debian/jessie开机自启动脚本systemctl配置异常排查

Hey there, let's walk through the most common issues that cause systemd service failures on BeagleBone—this stuff can be finicky, but we'll get it sorted.

1. First, Fix That Service File Path (Probably a Typo!) #

You mentioned putting the service file in /lib/systemctl/system/—that's a typo, right? Systemd looks for service files in /lib/systemd/system/ or /etc/systemd/system/ (the latter takes priority if you want a custom override). Double-check your file is in one of those valid directories, and that it's named exactly autostart-scripts.service (the .service suffix is mandatory).

2. Validate Your Service File Syntax (Systemd Is Picky!) #

Most failures come from a misconfigured service file. Here's a solid template to compare yours against—adjust the values to match your setup:

[Unit]
Description=Autostart Custom Scripts
After=multi-user.target  # Wait until the system is in multi-user mode before running

[Service]
Type=oneshot  # Use this if your script runs once and exits; use "simple" if it runs continuously
ExecStart=/home/your-actual-username/your-script.sh  # MUST use absolute path—no ~ allowed!
User=your-actual-username  # Run as your user, not root (avoids permission messes)
WorkingDirectory=/home/your-actual-username/  # Set the script's working directory
RemainAfterExit=yes  # Required if using Type=oneshot (tells systemd the service is "active" after exit)
Restart=no  # No need to restart if it's a one-time script

[Install]
WantedBy=multi-user.target

Key checks here:

• No relative paths anywhere: Systemd doesn't recognize ~/script.sh—use full paths for everything.
• Match Type to your script: If it's a one-and-done script, oneshot + RemainAfterExit=yes is non-negotiable. If it's a daemon that runs forever, use simple.
• Add dependencies if needed: If your script needs network access, add After=network.target to the [Unit] section.

3. Make Sure Your Script Actually Works Manually #

Before blaming systemd, test the script directly:

/home/your-actual-username/your-script.sh

If this throws errors, fix those first:

• Does the script start with a shebang line? Like #!/bin/bash at the top (tells the system what interpreter to use).
• Does it have execute permissions? Run chmod +x /home/your-actual-username/your-script.sh to fix that.
• Are any file paths in the script using relative paths? Swap those for absolute paths too.

4. Dig Into Systemd Logs for the Real Error #

The systemctl status output only shows a snippet—use journalctl to get the full story:

journalctl -u autostart-scripts.service -b

The -b flag limits logs to the current boot. You'll see exactly why it failed—whether it's a permission denied, missing file, or a script runtime error. This is the fastest way to pinpoint the issue.

5. Reload Systemd & Re-Enable the Service #

If you tweak the service file, you have to tell systemd to pick up the changes:

sudo systemctl daemon-reload
sudo systemctl reenable autostart-scripts.service

Then reboot and test:

sudo reboot

Quick Bonus Tips #

• Avoid using environment variables in the service file (like $HOME)—systemd's environment doesn't match your user's login environment. Stick to absolute paths.
• If your script needs the graphical desktop, change WantedBy to graphical.target and After=graphical.target in the [Unit] section.
• Don't let your script block the boot process—if it's a long-running task, consider running it in the background or using Type=forking (but only if your script forks properly).

内容的提问来源于stack exchange，提问作者Jefferson Alexis