Your script is a typical use of a service. Usually a service is started once and then it is running in background until it is stopped by the service manager. The service manager can restart a script but it isn't made to be used for loops because it is working on system level with logging and dependency checking and all to manage services.
So first you ...
Hit shift when starting up.
Hit "e" to edit config
tab over to cmdline.txt
add to the end of the line
hit ok, then Esc to boot...... it will boot you in to a command line
(this will do something)
# mount -n -o remount,rw /
(this will remount / so you can make changes)
now you should be able to edit the init.d config.....
Raspian is basically Debian.
Debian until and including Wheezy/7 used SysV, since Jessie/8 systemd.
Upstart is not relevant anymore, since even RHEL and Ubuntu (the Upstart developers) have moved to systemd.
systemd is very different from sysv. However, there is a compatibility layer in systemd that will transparently create units for properly annotated ...
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 ...
It's still systemd that handles the old-style init scripts, using systemd-sysv-generator:
systemd-sysv-generator is a generator that creates wrapper .service units for SysV init scripts in /etc/init.d/* at boot and when configuration of the system manager is reloaded. This will allow systemd(1) to support them similarly to native units.
LSB headers in ...
I ended up getting around this problem by doing the following:
Running a DHCP server on the laptop
Connecting the RPi to the ethernet port directly
Granting the RPi an IP through the DHCP server
SSHing into it
Manually running the raspi-config program from the terminal
Selecting "Finish" (otherwise it keeps popping up).
Init services run as root. Do not include sudo in service files run by init, regardless of whether it is SysV or systemd.
I would try [but please see comments, this is a bit personal preference]:
Then in /home/pi/...
If you are running Jessie this should be started with a systemd service. I copied from https://www.raspberrypi.org/forums/viewtopic.php?t=123457&p=830506
Create a new file /etc/systemd/system/vncserver@.service with the following contents:
Description=Remote desktop service (VNC)
If I remember correctly, the operating system will not move beyond an init.d script until it has finished running. Essentially, your system is trying to launch its init.d script, but since this script never exists, your system never moves past it.
At this point you won't be able to log in via SSH or through the desktop. If you don't want to do a clean ...
to avoid the error feh ERROR: Can't open X display. just execute this line of code in a terminal:
after this your code will work fine.
to execute commands "at boot", if autologin is enabled (since what it really does it execute them when the pi user logs in), i'd suggest editing the autostart file wich is in the ~/.config/lxsession/LXDE-...
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 ...
I used crontab instead, which worked fine for me.
sudo crontab -e
Select editor for yourself i used nano editor which i felt easy myself.
@reboot su - pi -c '/usr/bin/tightvncserver :1'
or if you use VNC server instead of tightvncserver.
@reboot su - pi -c '/usr/bin/vncserver :1'
Explanation of the command:
"su" is a user to select, "pi" is a name ...
Several of the other answers here are now incorrect:
The GPIO jumper pin method was removed from the upstream OS, so it only works now if you're using a NOOBS image
Raspbian Jessie's move to systemd breaks the init=/bin/sh hack. When you do this, it complains, can't access tty: job control turned off
Fortunately, there is a solution that works, which ...
deluged init script
sudo wget https://gist.github.com/earthmeLon/a4bf68d385f8f840d2b5/raw/ -O /etc/init.d/deluged
This downloads the script and places it in the correct directory
sudo chmod +x /etc/init.d/deluged
This allows execution of the new file, which is essential for it to be run at startup
sudo update-rc.d deluged defaults
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 ...
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 ...
Nope, deluge does not have init scripts in current debian, as well as in ubuntu and a bunch of other Linuxes. They have guides on creating such scripts though: http://dev.deluge-torrent.org/wiki/UserGuide/InitScript (and one especially for debian&ubuntu). It should not be that hard, but I switched to transmission because of this extra work.
I found the problem as soon as I started writing my question. The solution is simple -- there was a mistake in my cmdline.txt file. The original content was:
dwc_otg.lpm_enable=0 rpitestmode=1 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait
I added second console=tty1. Thus, all output from init script ...
The only change that should be necessary is to drop the sudo from the ExecStart line:
As goldilocks noted, you can determine your run level from /etc/inittab.
Assuming it's run level 2, and assuming nothing was changed in /etc/rc2.d, S03ssh gets called before S05rc.local. Presumably something is going wrong well before rc.local is called.
Can you share the contents of /etc/rc2.d (again, assuming that's your default run level)? I'd expect ...
The only reason I can think of for not being able to save the file is that the file system has been mounted read only as it is corrupt.
You need a PC with a SD card reader.
That PC must be another Linux machine or booted from a live Linux CD.
That would allow you to check and fix the SD card file system.
This prioritizes this script to run ahead of pretty much everything else; on default Raspbian, the only things with S01 in rcS.d are fake-hwclock, hostname, and mountkernfs. Hence:
echo "this script is called on boot" >> /cca-debug
Will likely fail, because the root filesystem has not been remounted read-write. If you ...
I installed the program Paragon extfs on my PC.
I could then open the rc.local file and delete the code.
I opened the cmdline.txt and deleted the init=/bin/sh
The Raspberry Pi is now starting up normally again.
init.d may still work - systemd tries to make a .service from init.d scripts, but you would be better to write a systemd service.
Services should all specify full paths to executables.
You appear to have a more fundamental problem. $INSTALL_DIR/WateringSystem.exe does not look like an ARM executable.
The first step before automating any script is to run ...
Raspbian Jessie uses systemd which reads the /etc/hostname and sets the hostname directly with a system call. See: https://www.freedesktop.org/software/systemd/man/hostname.html
systemd does not use /bin/hostname to set the hostname.
We were able to use Supervisor to successfully have a Python script run in the background on boot.
Tutorial I Used to set it up: Monitoring Processes with Supervisord
Supervisor runs as a service, and you have a configuration file where you set up your scripts that you want it to run:
As you are told by systemd:
zfs-import.service is not a native service, redirecting to systemd-sysv-install.
Old style SysV init system is deprecated and not used anymore. For compatibility it is only emulated by systemd but there are limitations. Look at Compatibility with SysV.
If you encounter problems with SysV emulation then the first step should ...
A simple solution.
Append your commands to rc.local
execute this command in the console
sudo nano /etc/rc.local
and add your command to the file.
further reading here
Note: Usage of /etc/rc.local has been depreciated due to compatibIlity with SysV as pointed out by Ingo.