The easiest way to do this for a headless setup is to create a file named ssh on the boot partition of the SD card. This will enable the SSH daemon immediately after first boot and will be deleted.
Official SSH guide: https://www.raspberrypi.org/documentation/remote-access/ssh/README.md#3-enable-ssh-on-a-headless-raspberry-pi-add-file-to-sd-card-on-another-...
Ensure terminal over serial is disabled in raspi-config
and in "Advanced" choose "Serial" (Enable/Disable shell and kernel messages on the serial connection) and disable it.
Steps 2 and 3 should not be necessary if you do this step first, but in case it didn't work - check them also.
Ensure /boot/cmdline.txt has no ttyAMA0
Now, I can start my script as a service with systemctl start test.service and stop it the same way. But for a clean script, I want to execute GPIO.cleanup() before the script is closed by systemctl stop test.service. How can I achieve that? The finally doesn't seem to work in this case...
By default, systemd sends a SIGTERM, then SIGKILL to your service ...
Same issue with both stretch and jessie. Until you enable the service with:
systemctl enable ssh
you cannot refer to the service as "sshd". Once the service is enabled, no problem, you can even disable the service with:
systemctl disable sshd
Really stupid in my opinion but that's the way it is.
I have done this on several projects. https://bitbucket.org/dnetman99/raspberrypiprojects if you look at the gpsdpiTracker, the trackerServer.py uses the daemon class to daemonize the script. I then just use restartd to watch if it stops and restarts it, which also means it will start it after boot as well. I also have used the skeleton file for start, ...
Create an init.d script to run your application
you can run the mono service in linux OS by using the command
mono-service [options] program.exe call this from an init.d sript
Check this man page for more details about running mono service on linux
Took me a while to figure out what is going on but after installing tcpdump, monitoring the network traffic and more carefully reading the fine print of NTPd docs, I realized that NTPd requires unrestricted access to UDP port 123 for both outgoing and incoming traffic.
Since this is not something I'm willing to do on my network, I uninstalled the ntp ...
With most Linux distros I've used, it's simply sudo service <name> restart...
This is because many or most linux distros are descended from Debian, which traditionally has used a "UNIX System 5" (aka. SysV) style init system. In fact, if you go back far enough all linux distros used this kind of system.
I am not sure whether the service command was ...
The simplest method I've found for starting a persistent background service via systemd, which may be handy since you can then get it to report on subprocesses currently running as children via systemctl status ..., etc., is via a service file like this:
You can use the watch utility to continuously update the status without using a loop.
watch --interval 1 'date; /etc/init.d/homebridge status'
which will update every second (the default is two seconds).
network-online.target is a static unit. You can check it with:
rpi ~$ systemctl list-unit-files network-online.target
UNIT FILE STATE
1 unit files listed.
means it has no [Install] section and starts only if it is Wants or Requires by another unit. It cannot be started and stopped and does not run on bootup. But if ...
These are for SysV compatibility, which traditionally has been the most widespread init system used on GNU/Linux since its inception. I believe SysV scripts also have a degree of compatibility with BSD init, used on other contemporary POSIX operating systems. While none of that is actually part of the POSIX specification, some commonplace cross-platform ...
Systemd services aren't executed by a shell, and although man systemd.service notes the syntax for the various Exec___ directives is "inspired by shell syntax", it also notes:
redirection using "<", "<<", ">", and ">>", pipes using "|",
running programs in the background using "&", and other elements of shell syntax are not supported....
To disable a service means do not start it automatically on startup. It does not mean to disable its functionality. You always can start and stop it and it can be started by other services. That seems to be the case here. You can show dependencies with:
rpi ~$ systemctl list-dependencies xrdp
To disable a service completely you have to mask it:
rpi ~$ ...
On Linux systems, there's a special file at /sys/class/net/$interface/carrier (where $interface is your interface name, e.g., eth0, wlan0). You can read from it like you would any other file in Python. If you read a 1, the interface is connected, and if you read a 0, it is not connected.
Here's some untested example code to illustrate:
supervisord is such a monitoring daemon. It can launch processes when it starts (though this can be disabled, so processes are manually started). If a process crashes, it will be restarted.
As a bonus, it has a nice web interface:
You can disable all services you don't use using the command
update-rc.d -f the-service remove
Most of the services do not do anything when they are not used. For example, Apache (webserver) is sleeping when no client request a page. However, some services could do some background tasks and consume CPU cycles, in addition to the memory footprint of the ...
If you don't want to write a debian style sysv init script (see /etc/init.d/README), you can just append a line to /etc/rc.local, eg:
The full path is necessary as $PATH may not be properly set for rc.local when it is run at boot (but it will be for "myprogram").
The & just backgrounds the process, allowing rc.local to ...
The command to restart networking entirely, including wpa_supplicant, is this:
sudo systemctl restart networking.service
As a side note, you should be able to hit the <tab> key after you start typing the name of a service and your shell will autocomplete the name of the service, assuming you've typed in enough to make it unique. That saves you from ...
You didn't state which OS you are running on your Pi.
I've been messing around with motion (the camera capture program) on the Raspberry Pi running Arch Linux. I have several Pi's, several webcams, several power supplies, several SD cards...and one thing remains the same. All of them will completely lock up (as in you can't even ping the Pi and the video ...
Unfortunately there isn't any easy answer to get it working straight away, however here are a few things I would try in your case;
First off I would try lowering your resolution to something like 320x240 and see if it's any more stable, basically that should lower any load on the Pi.
You could actually go one step further and change "webcam_port" to zero ...
I think that your problem may be that you are connecting to the Pi through ssh and expecting it to restart, the problem is when restarting the ssh process your ssh connection to that very same process is broken. If this is not the case and you are actually physically connected to the Pi with a monitor and keyboard then please elaborate on what you see when ...
If you are using jessie, check:
systemctl list-units | grep vpn
You should be able to find the name of the service this way (wild guess: openvpn), then:
sudo systemctl disable openvpn
That won't stop it right now, but it should prevent it from starting next boot. You will still be able to start it manually via sudo systemctl start openvpn (and stop it ...
The simple answer is No.
If you want to try stuff out then, for a long time you could not install background services or applications. Things are slowly changing though but still very slowly tricking in.
You can have a look at this merge in GitHub on how to get service running on the Windows PIoT. I am sorry but it does not look like a simple command yet, ...
To show how it works I have made a stripped down test script that simply sends an email every minute. Here is the script:
rpi ~$ cat >/home/pi/mySendMail.py <<EOF
server = smtplib.SMTP('smtp.gmail.com', 587)
You are using old style SysV init scripts but since Raspbian Jessie SysV init isn't used anymore. It is replaced by systemd. Only for compatibility systemd emulates SysV so your init.d/script in practice is a systemd unit and any systemd unit can be restarted by default. You can verify it with:
rpi ~$ systemctl status tomcat.service
This should give you in ...