I am having some problems with this, I have a script that is supposed to start airodump-ng on boot but it usually only runs the first part of the script and thats it.

I have tried creating a systemd service file and enabling it but the script does not run as root.

I tried this in both arch linux and debian but in debian i went the init script route but still the script would not run as root.

My script:

ifconfig wlan0 down
sleep 5
airmon-ng start wlan0
sleep 5
airodump-ng mon0

exit 0

Service file:

Description=auto start airmon



Edit* This is the output from systemctl status:

ap.service - auto start airmon
Loaded: error (Reason: Invalid argument)
Active: inactive (dead)

Jan 13 13:03:44 alarmpi systemd[1]: [/etc/systemd/system/cap.service:5] Executable   path is not absolute, ignoring: ~/scripts/cap.sh
Jan 13 13:03:44 alarmpi systemd[1]: cap.service lacks ExecStart setting. Refusing.
Jan 13 13:47:08 alarmpi systemd[1]: [/etc/systemd/system/cap.service:5] Executable path is not absolute, ignoring: ~/scripts/cap.sh
Jan 13 13:47:08 alarmpi systemd[1]: cap.service lacks ExecStart setting. Refusing.
  • 2
    I think your issue is that you are running commands that may not necessarily end, so you may need to fork them to the background with adding & at the end of the line (not on the sleep ones, of course). – nerdwaller Jan 13 '14 at 20:41
  • But when i run the script as root in the terminal everything works fine. – Skilo Skilo Jan 13 '14 at 20:43
  • 2
    For best results, put the service file and the output of systemctl status $YOURSERVICE (whatever that service is) in your question. And double check that you typed that script in correctly. People are going to immediately jump on one fairly obvious error that might only be your typing error here. – JdeBP Jan 13 '14 at 20:44
  • So i changed the location of the script and now it seems to be working, I guess systemd does not like the home directory. – Skilo Skilo Jan 13 '14 at 21:53
  • What are you using, Debian or Arch? Are you using systemd? – Braiam Jan 13 '14 at 22:41

The journal is actually telling you why your service won't start.

What it's saying is that service units are not shell scripts. You don't get, apart from some very specialized items, things like ~ expansions or environment variables in service units. The name that you pass to ExecStart must be the ordinary, absolute, path of the program to run. Your name is ~/system/cap.sh, which is (of course) a relative path not an absolute one. This is not the shell. ~ is not a metacharacter. It's an ordinary character, denoting some purported subdirectory of the current directory named ~.

systemd refuses to accept an ExecStart with a relative pathname. And it refuses, obviously enough, to start a service that doesn't have a valid ExecStart that describes how the service is started.

After fixing that, you then need to fix your script so that it's actually a properly executable script. It needs to have execute permission and to have #! spelled properly on the first line. Also note that there's nothing about it that requires the Bourne Again shell, and it's a good idea to follow Debian's lead of using the Almquist rather than the Bourne Again shell in scripts run as part of the system bootstrap.

You'll probably want to tweak your service file so that it doesn't fiddle with the network interfaces in parallel with the system initializing them in the first place. What that means is specific to your system, so you'll have to work out what to put as an After= in your unit file.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.