I/O failure is a common cause of this; processes suffering from such are
stuck in an uninterruptible sleep.
If this is widespread and includes critical processes, the entire system will stutter and stall -- although from a GUI perspective this may be exaggerated in that it is mostly the GUI that is stalling.
Such processes can be identified with diagnostic ...
As I understand your question:
You have a cron job to reboot your RPi every night at 01:00; e.g.
0 1 * * * sudo reboot (#or something similar; e.g. shutdown -r now)
You have a 2nd cron job to restart your app using the @reboot facility in cron; e.g.
If you're certain that your 01:00 reboot is being executed successfully, ...
If it has hung because you dropped something conductive on it (something that conducts electricity) which has bridged some tracks on the board, then one reason for not pulling the plug, the risk of file system damage, does not apply. If that was going to happen, it happened when the Pi froze. The other reason given in the answers you linked to, which is the ...
You've not explained or shown how you have your batteries arranged, nor provided any specs on them. But it seems likely they are in series - thereby providing ~ 9V output.
Batteries in series can provide no more current that a single battery, and even a good quality AA cell isn't capable of much more than 1 amp. And so your battery pack will be unable to ...
A charger isn't a PSU. Also the cable quality can make a big difference.
In this case with a RPI3+ I would say the power supply is the most plausible cause of the reboots.
Also check after some time over ssh
If the ouptput is different from:
iIt means the cpu has throttled.
This can be caused by bad power supply or ...
I assume you are using an operating system like Raspbian since version Jessie. Then you can use a simple systemd Unit file to run a script at shutdown. Just create a new service with:
rpi ~$ sudo systemctl --force --full edit log-shutdown.service
In the empty editor insert these statements, save them and quit the editor:
Description=Execute script ...
You are using the old style SysV init system, but that is deprecated since years and not really installed. For compatibility it is only emulated by the new systemd init system. If you really want to use SysV you should have a look at man systemd-sysv-generator why your scripts are not running.
I would use direct a simple systemd service to do what you want. ...
Try CtrlAltF1-6. At least one of this should take you to a plain text login. From there you should be able to get the PID of the Kodi process -- presuming it's called kodi, which I don't know:
ps -C kodi
This will respond with a number, or nothing it it is not actually called kodi, in which case you could try ps -A | grep kodi to see if it is something ...
If you had SSH, you could go back and rewrite it back to the original.
If you can access your files, back them up on a USB, and reinstall your version of Raspbian.
I would like it for you to provide picture so I can give more to this answer.
it just reboots sometimes even 3 or 4 times.
That certainly isn't because of Chrome. If it rebooted once when you opened Chrome, it might be, but it could not cause it to repeat the process unless you opened it again.
There's also this lightning symbol on the corner of the screen, do you think it's a probable cause?
That's not the cause, that's a ...
I ended up solving this by soldering in diodes in the usb cable.
I wanted to run a dual HDD USB RAID NAS but the boot failure (back powering issue) got me flummuxed for a bit. Didn't want to use try usb hub (party for speed reasons - hdd would be connected through two usb hub chips inc onboard one). I used the split power cables from ebay - feeding the non-...
You can repair most such problems on the Pi by rebooting to a root shell.
Append init=/bin/sh at the end of cmdline.txt and reboot. (This needs to be performed by mounting the SD Card on another computer.)
After booting you will be at the prompt in a root shell.
Your root file system is mounted as readonly now, so remount it as
read/write mount -n -o ...
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.
The answer is in the error message. DISPLAY is not set. Cron is not a part of your desktop environment, so it does not know where to display the xterm.
If you open an xterm normally, and ask echo $DISPLAY, it will tell you soemthing like
That is the display identifier where windows would be displayed. Unfortunately, you cannot just put
Your service file looks good, except for the Before=multi-user.target line. That should be After=multi-user.target, because services get stopped in the inverted order they got started.
There's no need for ExecStart= or Type= as you can find the following in the manual pages:
Type=oneshot is the implied default if neither Type= nor ExecStart= are ...
Maybe your power supply is failing. The power supply in your link appears to have an inline power switch on the 5V side. These are a bad idea and can cause voltage drop.
I suggest you buy the official power supply.
From experience I bet the problem is a not-powerful-enough converter (I remember a question asked earlier, where an even smaller converter was put to test and failed miserably, killing the Pi in the process). Look for a converter featuring a ring inductor with thick copper wire around it: those can typically handle enough current to start a Pi.
End your script with a line which deletes it. For a bash script which is run from the directory where it resides, the self-delete command is simply
Most autorun systems will ignore a non-existent script which they are supposed to run, or can be instructed to ignore it. For instance, in /etc/rc.local you could write:
test -f /path/to/script && /...
Try setting force_turbo=1 in config.txt. This will disable dynamic frequency scaling of the CPU. I have had four devices (all my three Zero W devices and one Raspi 4) which used to freeze, the Zeros when the Pi Cam was connected (and used to create timelapses), then they froze randomly after a couple of hours or after a couple of days and the Raspi 4 under ...
Not sure exactly what's causing the issue, but a couple of things to try:
the cron environment uses sh instead of bash AFAIR. Add SHELL=/bin/bash to crontab just before invoking your script.
I think you may have a disconnect wrt where your script output is going. You redirect the date output in your script, but the echo output will go to stdout (aka /dev/...
Sounds like an undervoltage situation. Keep in mind that phone chargers aren't the best when used as a PSU. Get a better charger or buy the raspberry pi official PSU.
I used to have this problem as well.
To automount your USB drives to a directory of your choosing:
In accordance w/ man fstab:
The second field (fs_file).
This field describes the mount point (target) for the filesystem. For swap partitions, this field should
be specified as none. If the name of the mount point contains spaces these can be escaped as \...
To mount the hard drive on boot up you can just add an entry into /etc/fstab, something like:
LABEL=hard-drive /media/hard-drive ext4 defaults 0 0
Instead of ext4 you may have to use the filesystem on your hard-drive.
To execute the clear command on startup just create a systemd Unit with:
rpi ~$ sudo systemctl --force --full edit clear-screen....
A quick observation: Are you sure using /dev/sda works? It is much more likely to be /dev/sda1, which I'll use here. If you are positive the stick was formatted without partitions, then it would be /dev/sda, but this is a very unusual thing to do, particularly since it's implicit this was formatted on Windows.
You can use /etc/fstab for this; see also man ...
The problem, as indicated by the comments, could be that Raspian is specific for Raspberry Pis. Although you might get it running on a different system, it is likely that you run into problems, especially at boot time or with IO.
We do not know a lot about your system. It may not even support rebooting. The A83T is "based on" the A7, so you would probably ...
If you specify now to shutdown or call for reboot, then the command take immediate effect. Among other things it stops the ssh services and you can / will get cold-dropped like that. If you want to get a warning, then you need to specify a future time for the command to execute.
this script is monitoring files in a folder. If 2 minutes have passed and there are no new files being generated then reboot the system
To debug this you would need to print flagTime and currentTime to a log when they are initialized. If you had done this, I think you would notice that delta is indeed > 120 seconds even though much less time elapsed ...
You should use the command sudo crontab -e and make cron start a bash file that contains your fm_transmitter -f 104.0 -r song.wav.
So make a bash file like /home/pi/fm_transmitter -f 104.0 -r song.wav and let crontab run that.