There're three forms about running a script on the boot of the Raspberry, that are modifying /etc/rc.local, modifying the cron daemon and making a script that automatically run on boot in /etc/init.d
I want to know which of the methods listed about executed first.
The point of the question is that I'm trying to run wvdial with an Alcatel X600D at boot, that is as simple as modify the /etc/network/interfaces with these lines:
auto ppp0
iface ppp0 inet wvdial
But the problem is that the modem needs to receive the PIN before the wvdial is called. For that, I need to pass the PIN to the modem before the system raises the ppp0 connection.
Regards.
Script in /etc/init.d
Whatever is in /etc/rc.local
Your cron daemon command
Proof:
Scripts in /etc/init.d are ran according to their priority and dependencies (look within the files in /etc/init.d and in the runlevel directories /etc/rc*.d)
cat /etc/rc.local
get
# This script is executed at the end of each multiuser runlevel.
Cron scripts are executed whenever the timing pattern specified in them is reached which is independent from the boot order. So a script in cron probably would not make much sense.
Also have a look at https://wiki.debian.org/Modem/3G, it might be possible to do what you're trying to achieve without coding your own script.
Related
The GPS hardware I'm using with my Raspberry Pi, if sent the command $CDCMD,33,1*7C, will report the status of the antenna connection.
I'd like this command to be issued whenever my GPS daemon starts. My current config file at /etc/default/gpsd looks like this:
# Devices gpsd should collect to at boot time.
# They need to be read/writeable, either by user gpsd or the group dialout.
DEVICES="/dev/serial0 /dev/pps0"
# Other options you want to pass to gpsd
GPSD_OPTIONS="-n"
# Automatically hot add/remove USB GPS devices via gpsdctl
USBAUTO="false"
# Start the gpsd daemon automatically at boot time
START_DAEMON="true"
Is there anything I can add to this config file to insert either the antenna command, or the path of a file containing the command?
I've searched all over for documentation for the config file, yet all I can find is example file, nothing that fully documents what options are available for configuration.
Alternatively, if the gpsd daemon is already up and running, and already has control of the serial port used to communicate with the GPS hardware, is there a way to send an NMEA command that gpsd will pass along to the hardware?
The only way I've been able to test this command was to shut down gpsd, then run minicom to issue the command to the hardware directly.
When I deployed my play application I built the package using:
dist
This created a file that I can run on my server like:
sudo ./bin/app-name -Dhttp.port=9090
This works fine for testing but how can I run this process in the background?
I will eventually have to use upstart or some sort of process monitoring tool to make sure this process is running after server reboots etc.
Using play 2.3.x
Since you are on ubuntu
sudo ./bin/app-name -Dhttp.port=9090 &
should do the trick.
Ceating the upstart script is also fairly easy https://askubuntu.com/questions/18802/how-to-correctly-add-a-custom-daemon-to-init-d
In your case it would be in /etc/init/app-name.conf and look like
# app-name
#
start on stopped rc RUNLEVEL=[2345]
stop on runlevel [!2345]
respawn
exec $PATH_TO_APP/bin/app-name -Dhttp.port=9090
Of course you will want to change the RUNLEVEL and the PATH_TO_APP
That of course depends on the system at which you're deploying the app, anyway in general you need to run it as a deamon.
Refer to your system's documentations, I'm pretty sure that you will find tutorial very soon.
I've setup a systemd service file to perform some pactl operations at system startup for a test process. While the commands work fine when performed from a terminal I always get "pa_context_connect() failed connection refused" when running the same script from the systemd service by starting the service. I'm also using the 'User=' directive in the service file to ensure that the auto-login user matches the user used to run the service commands.
I've read that this is somehow related to the pulseaudio session not being valid in the environmentless context of the systemd service but I haven't been able to figure that out further.
Although it might be a bit late for whatever project you might have been be working on, here's what I found out.
The regular systemctl, the PID 1, indeed cannot access the environement variables of the current user when launching a service. Since pactl relies on those variables to find what instance of pulseaudio it needs to connect to, it is unable to do so when launched though a service. I'm sure there's a fairly dirty workaround for this, but I found something better.
Most systems have a second instance of systemd running in userspace (accessible through systemctl --user while not connected as root). This instance indeed can access all the userspace environment variables and I found that pactl doesn't return any errors when being called either directly or through a script.
All you need to do is put your services in either /usr/lib/systemd/user/, /etc/systemd/user/, or ~/.config/systemd/user/, remove the User= directive from your service file and run systemctl --user daemon-reload as a regular user to make sure they've been detected.
I have program that I need to run at startup in the background, so far I have it in rc.local like so:
sudo ./simple_program &
However this does not take into consideration if the program crashes. I need it so that whenever the program crashes, it is restarted again.
I think the approach is to write a bash script and run that instead in rc.local, where the bash script calls the simple_program and reruns it if needed. However, I'm not quite sure exactly what to do here. Could someone provide me a template?
Try with monit or daemontools, they are specifically designed to supervise other processes
I'm working with an embedded computer that has a Debian on it. I already manage to run a command just before it has booted and play the "bell" to tell that is ready to work, and for example try to connect to a service.
The problem is that I need to play the bell (or run any command/program) when the system is halted so is safe to un-plug the power. Is there any runscript that run just after halt?
If you have a look in /etc/init.d, you'll see a script called halt. I'm pretty certain that when /sbin/halt is called in a runlevel other than 0 or 6, it calls /sbin/shutdown, which runs this script (unless called with an -n flag). So maybe you could add your own hook into that script? Obviously, it would be before the final halt was called, but nothing runs after that, so maybe that's ok.
Another option would be to use the fact that all running processes get sent a SIGTERM followed (a second or so later) by a SIGKILL. So you could write a simple daemon that just sat there until given a SIGTERM, at which point it went "ping" and died.