I read plenty of Q&A about cron but I was not able to understand an anomaly which I am facing.
I have a Raspberry Pi running 3 cronjobs:
* * * * * /home/pi/heartbeatgenerator.sh 2>&1
*/5 * * * * /home/pi/extase2influx/extase2influx.sh 2>&1
*/5 * * * * /home/pi/ows2influx/ows2influx.sh 2>&1
The first one is a simple script which write every minute 0 or 1 alternatively to a database (InfluxDB) via a curl call. The idea is to check if the RPi has a regular connection to the DB and function properly.
It looks like this:
value=$(($( date +"%M")%2))
curl -i -XPOST "https://[REDACTED].influxcloud.net:8086/write?db=[REDACTED]&u=[REDACTED]&p=[REDACTED]&precision=s" \
--data "heartbeat $HOSTNAME=$value"
The second script is query some sensors and posting the values to the same DB.
The third script is bascially the same of the second one, but the first line has a 'sleep 10s' command (to avoid a spike in CPU/network usage).
Now, everything is working nicely EXCEPT that the first script (the heartbeat) fails regularly every hour at minute 08 and 09. It fails meaning no data are posted into the DB. This is a piece of the DB dump:
1/7/2019 1:05:06.000000000 PM,1
1/7/2019 1:06:01.000000000 PM,0
1/7/2019 1:07:01.000000000 PM,1
1/7/2019 1:10:01.000000000 PM,0
1/7/2019 1:11:01.000000000 PM,1
1/7/2019 1:12:02.000000000 PM,0
This is how looks like visually
Here is a piece of the logfile:
Jan 7 13:05:01 RPi CRON[6346]: (pi) CMD (/home/pi/ows2influx/ows2influx.sh 2>&1)
Jan 7 13:05:01 RPi CRON[6347]: (pi) CMD (/home/pi/extase2influx/extase2influx.sh 2>&1)
Jan 7 13:05:01 RPi CRON[6348]: (pi) CMD (/home/pi/heartbeatgenerator.sh 2>&1)
Jan 7 13:05:01 RPi CRON[6334]: (CRON) info (No MTA installed, discarding output)
Jan 7 13:05:11 RPi pi: /home/pi/extase2influx/extase2influx.sh INFO: Database entry successfull. Written 1520 bytes
Jan 7 13:05:11 RPi CRON[6333]: (CRON) info (No MTA installed, discarding output)
Jan 7 13:05:12 RPi pi: /home/pi/ows2influx/ows2influx.sh INFO-OWS: Database entry successfull. Written 1456 bytes
Jan 7 13:05:12 RPi CRON[6332]: (CRON) info (No MTA installed, discarding output)
Jan 7 13:05:16 RPi dhcpcd[520]: wlan0: Router Advertisement from fe80::21d:aaff:feb0:8f20
Jan 7 13:05:20 RPi dhcpcd[520]: wlan0: Router Advertisement from fe80::21d:aaff:feb0:8f20
Jan 7 13:05:24 RPi dhcpcd[520]: wlan0: Router Advertisement from fe80::21d:aaff:feb0:8f20
Jan 7 13:06:01 RPi CRON[6566]: (pi) CMD (/home/pi/heartbeatgenerator.sh 2>&1)
Jan 7 13:06:01 RPi CRON[6562]: (CRON) info (No MTA installed, discarding output)
Jan 7 13:07:01 RPi CRON[6579]: (pi) CMD (/home/pi/heartbeatgenerator.sh 2>&1)
Jan 7 13:07:07 RPi CRON[6575]: (CRON) info (No MTA installed, discarding output)
Jan 7 13:07:54 RPi dhcpcd[520]: wlan0: Router Advertisement from fe80::21d:aaff:feb0:8f20
Jan 7 13:07:58 RPi dhcpcd[520]: wlan0: Router Advertisement from fe80::21d:aaff:feb0:8f20
Jan 7 13:08:01 RPi CRON[6608]: (pi) CMD (/home/pi/heartbeatgenerator.sh 2>&1)
Jan 7 13:08:02 RPi CRON[6604]: (CRON) info (No MTA installed, discarding output)
Jan 7 13:08:02 RPi dhcpcd[520]: wlan0: Router Advertisement from fe80::21d:aaff:feb0:8f20
Jan 7 13:09:00 RPi dhcpcd[520]: wlan0: Router Advertisement from fe80::21d:aaff:feb0:8f20
Jan 7 13:09:01 RPi CRON[6636]: (pi) CMD (/home/pi/heartbeatgenerator.sh 2>&1)
Jan 7 13:09:01 RPi CRON[6632]: (CRON) info (No MTA installed, discarding output)
Jan 7 13:09:04 RPi dhcpcd[520]: wlan0: Router Advertisement from fe80::21d:aaff:feb0:8f20
Jan 7 13:09:08 RPi dhcpcd[520]: wlan0: Router Advertisement from fe80::21d:aaff:feb0:8f20
Jan 7 13:10:01 RPi CRON[6672]: (pi) CMD (/home/pi/extase2influx/extase2influx.sh 2>&1)
Jan 7 13:10:01 RPi CRON[6673]: (pi) CMD (/home/pi/heartbeatgenerator.sh 2>&1)
Jan 7 13:10:01 RPi CRON[6674]: (pi) CMD (/home/pi/ows2influx/ows2influx.sh 2>&1)
Jan 7 13:10:06 RPi pi: /home/pi/extase2influx/extase2influx.sh INFO: Database entry successfull. Written 1490 bytes
Jan 7 13:10:06 RPi CRON[6661]: (CRON) info (No MTA installed, discarding output)
Jan 7 13:10:07 RPi CRON[6662]: (CRON) info (No MTA installed, discarding output)
Jan 7 13:10:12 RPi pi: /home/pi/ows2influx/ows2influx.sh INFO-OWS: Database entry successfull. Written 1376 bytes
Jan 7 13:10:12 RPi CRON[6660]: (CRON) info (No MTA installed, discarding output)
Jan 7 13:11:01 RPi CRON[6868]: (pi) CMD (/home/pi/heartbeatgenerator.sh 2>&1)
Jan 7 13:11:07 RPi CRON[6864]: (CRON) info (No MTA installed, discarding output)
I don't see anything strange and I don't see any reason why the cronjob heartbeat.sh fails at minute 08 and 09 of every hour.
Has some of you any clue?
Related
"launcher.sh" is invoked upon every reboot of the system (done through crontab)
In the launcher.sh, a main python script, a memory monitoring python script are invoked.
It works perfectly fine. Even upon reboot also, both the python scripts are getting executed successfully.
One day, by mistake, the NUC system (in which the scripts are running) power button was pressed accidentally(March 16, 12:10 pm). After that, the system gets rebooted; Only the memory monitoring python script was getting executed; Not the main python script.
(i) Can someone help us to understand the reason for this observation?
FYI: Later on, the system is restarted intensionally; Since then, it works fine. (Both the scripts are getting executed)
Pulled out the "last" and "last reboot" results from that system. Please find below:
'''
last reboot
reboot system boot 4.15.0-1094-oem Sun Mar 21 06:01 still running
reboot system boot 4.15.0-1094-oem Thu Mar 18 14:05 - 06:01 (2+15:56)
reboot system boot 4.15.0-1094-oem Mon Mar 15 11:42 - 06:01 (5+18:18)
reboot system boot 4.15.0-1094-oem Sun Mar 14 06:01 - 06:01 (6+23:59)
reboot system boot 4.15.0-1094-oem Thu Mar 11 16:55 - 06:01 (2+13:06)
reboot system boot 4.15.0-1094-oem Mon Mar 8 10:39 - 16:54 (3+06:15)
reboot system boot 4.15.0-1094-oem Sun Mar 7 06:01 - 10:37 (1+04:35)
reboot system boot 4.15.0-1094-oem Sat Mar 6 10:27 - 06:01 (19:33)
reboot system boot 4.15.0-1094-oem Mon Mar 1 14:40 - 10:25 (4+19:45)
reboot system boot 4.15.0-1094-oem Mon Mar 1 11:14 - 14:39 (03:25)
last
linuxdev :0 :0 Sun Mar 21 06:02 still logged in
reboot system boot 4.15.0-1094-oem Sun Mar 21 06:01 still running
linuxdev :0 :0 Thu Mar 18 14:05 - 06:01 (2+15:55)
reboot system boot 4.15.0-1094-oem Thu Mar 18 14:05 - 06:01 (2+15:56)
linuxdev :0 :0 Tue Mar 16 12:11 - crash (2+01:53)
linuxdev :0 :0 Mon Mar 15 11:42 - 12:10 (1+00:27)
reboot system boot 4.15.0-1094-oem Mon Mar 15 11:42 - 06:01 (5+18:18)
linuxdev :0 :0 Sun Mar 14 06:02 - crash (1+05:39)
reboot system boot 4.15.0-1094-oem Sun Mar 14 06:01 - 06:01 (6+23:59)
linuxdev :0 :0 Thu Mar 11 16:55 - down (2+13:05)
reboot system boot 4.15.0-1094-oem Thu Mar 11 16:55 - 06:01 (2+13:06)
linuxdev :0 :0 Mon Mar 8 10:40 - down (3+06:14)
reboot system boot 4.15.0-1094-oem Mon Mar 8 10:39 - 16:54 (3+06:15)
linuxdev :0 :0 Sun Mar 7 06:02 - down (1+04:34)
reboot system boot 4.15.0-1094-oem Sun Mar 7 06:01 - 10:37 (1+04:35)
linuxdev :0 :0 Sat Mar 6 10:28 - down (19:32)
reboot system boot 4.15.0-1094-oem Sat Mar 6 10:27 - 06:01 (19:33)
linuxdev :0 :0 Mon Mar 1 14:40 - down (4+19:45)
reboot system boot 4.15.0-1094-oem Mon Mar 1 14:40 - 10:25 (4+19:45)
linuxdev :0 :0 Mon Mar 1 11:14 - down (03:24)
reboot system boot 4.15.0-1094-oem Mon Mar 1 11:14 - 14:39 (03:25)
'''
A follow up question, (ii) when will we observe "crash" in "last" command?
I have a Raspberry Pi 3B+ running RetroPie and am trying to set up my PS3 controller to always run in 'slave' mode to reduce latency issues. I got the idea from this post. I tested after running the command and it does indeed make a difference.
Problem is, it goes back to 'defaults' after the controller disconnects or rebooting the device. So I'm trying to make it always apply.
I have this shell script (yes, I know it's badly written - I plan to clean it up once I have it all working):
#!/bin/sh
concount=0
while [ ! "$(hcitool con | grep -o "[[:xdigit:]:]\{11,17\}")" ]; do
sleep 0.1
if [ $concount -eq 30 ]; then
break
else
echo "Try $concount - Device not found, retrying."
fi
concount=$(($concount + 1))
done
if [ $concount -eq 30 ]; then
echo "Device not found after $concount checks."
else
sudo hcitool sr $(hcitool con | grep -o "[[:xdigit:]:]\{11,17\}") slave
echo "Device found and set to slave"
fi
The delay part is because it would fire off before the controller was finished connecting and fail. This essentially gives it 3 seconds to work.
In any case, it works fine when I run it manually via command line and the latency is greatly reduced.
Connections:
> ACL 00:26:43:CC:B0:FB handle 11 state 1 lm SLAVE
Ping: 00:26:43:CC:B0:FB from B8:27:EB:68:0E:9E (data size 44) ...
4 bytes from 00:26:43:CC:B0:FB id 0 time 14.97ms
4 bytes from 00:26:43:CC:B0:FB id 1 time 16.09ms
4 bytes from 00:26:43:CC:B0:FB id 2 time 9.78ms
4 bytes from 00:26:43:CC:B0:FB id 3 time 11.11ms
4 bytes from 00:26:43:CC:B0:FB id 4 time 13.58ms
I made a file /etc/udev/rules.d/50-btslave.rules containing:
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="054C", ATTR{idProduct}=="0268", RUN+="/home/pi/btslave.sh"
(idvendor/idproduct came from reading the syslog)
and added this to 99-sixaxis.rules.
ACTION=="add", SUBSYSTEMS=="input", ATTRS{name}=="*PLAYSTATION(R)3 Controller", TAG+="systemd", RUN+="/home/pi/btslave.sh"
then did udevadm control --reload to apply the rules.
When I try to reconnect, the syslog doesn't seem to show anything different. It goes back to 'master' and I get the higher latency as well as spikes.
Feb 12 20:31:14 retropie kernel: [ 2121.796762] sony 0005:054C:0268.0005: unknown main item tag 0x0
Feb 12 20:31:15 retropie kernel: [ 2122.292506] input: Sony PLAYSTATION(R)3 Controller Motion Sensors as /devices/platform/soc/3f201000.serial/tty/ttyAMA0/hci0/hci0:11/0005:054C:0268.0005/input/input7
Feb 12 20:31:15 retropie kernel: [ 2122.293773] input: Sony PLAYSTATION(R)3 Controller as /devices/platform/soc/3f201000.serial/tty/ttyAMA0/hci0/hci0:11/0005:054C:0268.0005/input/input6
Feb 12 20:31:15 retropie kernel: [ 2122.294645] sony 0005:054C:0268.0005: input,hidraw2: BLUETOOTH HID v80.00 Joystick [Sony PLAYSTATION(R)3 Controller] on b8:27:eb:68:0e:9e
Feb 12 20:31:15 retropie systemd[1]: Started sixaxis helper (sys/devices/platform/soc/3f201000.serial/tty/ttyAMA0/hci0/hci0:11/0005:054C:0268.0005/input/input6).
Feb 12 20:31:15 retropie systemd[1]: Started sixaxis helper (/dev/input/event3).
Feb 12 20:31:15 retropie sixaxis-helper.sh[1403]: Calibrating: Sony PLAYSTATION(R)3 Controller (00:26:43:CC:B0:FB)
Feb 12 20:31:16 retropie sixaxis-helper.sh[1403]: Setting 600 second timeout on: Sony PLAYSTATION(R)3 Controller (00:26:43:CC:B0:FB)
Connections:
> ACL 00:26:43:CC:B0:FB handle 11 state 1 lm MASTER
4 bytes from 00:26:43:CC:B0:FB id 0 time 36.31ms
4 bytes from 00:26:43:CC:B0:FB id 1 time 35.97ms
4 bytes from 00:26:43:CC:B0:FB id 2 time 36.07ms
4 bytes from 00:26:43:CC:B0:FB id 3 time 36.10ms
4 bytes from 00:26:43:CC:B0:FB id 4 time 34.82ms
When I move the script elsewhere and test again, it shows an error in syslog that the script couldn't be found:
Feb 12 20:40:36 retropie systemd-udevd[1579]: failed to execute '/home/pi/btslave.sh' '/home/pi/btslave.sh': No such file or directory
Feb 12 20:40:36 retropie systemd-udevd[1577]: Process '/home/pi/btslave.sh' failed with exit code 2.
Feb 12 20:40:36 retropie systemd-udevd[1591]: failed to execute '/home/pi/btslave.sh' '/home/pi/btslave.sh': No such file or directory
Feb 12 20:40:36 retropie systemd-udevd[1574]: Process '/home/pi/btslave.sh' failed with exit code 2.
Feb 12 20:40:36 retropie systemd-udevd[1592]: failed to execute '/home/pi/btslave.sh' '/home/pi/btslave.sh': No such file or directory
Feb 12 20:40:36 retropie systemd-udevd[1577]: Process '/home/pi/btslave.sh' failed with exit code 2.
So that tells me that the event does seem to fire. It's just... not actually doing it. I scoured Google for a while and went nowhere. Am I missing something here or is there an easier way to go about this?
Thank you.
So, a few hours later and I managed to figure it out after a whole lot of debugging (and some ideas from a reddit post). Apparently udev is fired way too early in the sequence and no amount of 'waiting' would actually be able to retrieve the controller's address. It needed to fire much later.
So, I removed the udev rule and opted to just edit /usr/bin/sixaxis-helper.sh:
Added
hcitool sr "$SIXAXIS_MAC" slave
after
sixaxis_calibrate
(way at the bottom) It's ugly but it works. :) Controller immediately pairs to 'slave' mode and latency is all sexy-like.
Leaving it here for those who wish to implement the same solution. For now, I'm happy and can move on. Maybe I'll revisit later on and try to improve upon it so it doesn't require me to edit an existing script (or someone else takes up the challenge).
In the Crontab -e
I have added the code:
48 17 * * 1-5 /home/user/cript.sh >/dev/null 2>&1
in the system logs I receive: /var/log/syslog
Nov 9 17:48:01 HP-Pavilion cron[963]: (user) RELOAD (crontabs/user)
Nov 9 17:48:01 HP-Pavilion CRON[18951]: (user) CMD (/home/user/cript.sh >/dev/null 2>&1)
Nov 9 17:48:02 HP-Pavilion: [34529.848963] ieee80211 phy0: rt2x00queue_flush_queue: Warning - Queue 2 failed to flush
Nov 9 17:48:02 HP-Pavilion kernel: [34530.360969] ieee80211 phy0: rt2x00queue_flush_queue: Warning - Queue 2 failed to flush
Nov 9 17:48:03 HP-Pavilion kernel: [34530.872983] ieee80211 phy0: rt2x00queue_flush_queue: Warning - Queue 2 failed to flush
Nov 9 17:48:04 HP-Pavilion kernel: [34532.021114] ieee80211 phy0: rt2x00queue_flush_queue: Warning - Queue 2 failed to flush
Nov 9 17:48:05 HP-Pavilion kernel: [34532.581126] ieee80211 phy0: rt2x00queue_flush_queue: Warning - Queue 2 failed to flush
my script contains a command line:
./a.out -f abc_`date+"%Y%m%d"`.txt
Now why won't the file gets created ???
When I start this program using Crontab ?
If I just run the script directly from the command line as:
./cript.sh
then it runs fine and a file gets created but If i put it in the Crontab, the output file doesn't get created. What could be the issues.
I am beginner at crontab.
Thanks
Re-direct the output to some file instead of /dev/null, check for the file once the script is executed.
you may b able to figure out what the problem is.
This problem occurs on a Pogoplug E02 running Debian jessie.
At startup the network interface takes several seconds to come online. A short delay is required after the "networking" script completes to ensure that ensuing network operations occur properly.
I wrote the following script and inserted it using update-rc.d. The script inserted correctly and executes at boot time in proper sequence, after networking and before the network-dependent scripts which were modified to depend on netdelay
cat /etc/init.d/netdelay
#! /bin/sh
### BEGIN INIT INFO
# Provides: netdelay
# Required-Start: networking
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Delay 5s after eth0 up for Pogoplug
# Description:
### END INIT INFO
PATH=/sbin:/usr/sbin:/bin:/usr/bin
./lib/init/vars.sh
./lib/lsb/init-functions
log_action_msg "Pausing for eth0 to come online"
/bin/sleep 5
log_action_msg "Continuing"
exit 0
When the script executes at startup there is no delay. I've used both sleep and /bin/sleep in the script but neither effect the desired delay. Boot log showing this attached below.
Thu Jan 1 00:00:25 1970: Configuring network interfaces...done.
Thu Jan 1 00:00:25 1970: INIT: Entering runlevel: 2
Thu Jan 1 00:00:25 1970: Using makefile-style concurrent boot in runlevel 2.
Thu Jan 1 00:00:26 1970: Starting SASL Authentication Daemon: saslauthd.
Thu Jan 1 00:00:29 1970: Pausing for eth0 to come online.
Thu Jan 1 00:00:30 1970: Continuing.
Thu Jan 1 00:00:33 1970: ntpdate updating system time.
Wed Feb 1 05:33:40 2017: Starting enhanced syslogd: rsyslogd.
(The Pogoplug has no hardware clock and has no idea what time it is until ntpdate has run.)
Can someone see where the problem might be?
I started with cronjobs a while ago, but up until yesterday I've run into a problem I can't figure/find out.
#reboot me /etc/application/start-script.sh
I have Raspbian Jessie (minimal) installed on a Raspberry Pi Zero. One of the users has a cronjob command #reboot. When I check "sudo /etc/init.d/cron status", I can see the cronjob is picked up after a reboot and executed. The only thing is that any output is dropped, the "No MTA installed"-message, (care?).
#!/bin/bash
# My start script
logfile=/home/me/logfile.log
echo "Starting program..." >> $logfile
application
echo "Program started!" >> $logfile
As you can see, it should create a log file, and it does this after a reboot when the script is called as a cronjob. This script works perfectly fine when you manualy execute it, it writes the output to the logfile AND starts the program.
The problem is: the program is not launched when the .sh script is called as a cronjob.
Why is only the application not started when the script is executed???
"sudo /etc/init.d/cron status" output
Mar 17 22:14:45 pizza-pi systemd[1]: Starting Regular background program processing daemon...
Mar 17 22:14:45 pizza-pi systemd[1]: Started Regular background program processing daemon.
Mar 17 22:14:45 pizza-pi cron[292]: (CRON) INFO (pidfile fd = 3)
Mar 17 22:14:45 pizza-pi cron[292]: (CRON) INFO (Running #reboot jobs)
Mar 17 22:14:45 pizza-pi CRON[296]: pam_unix(cron:session): session opened for user me by (uid=0)
Mar 17 22:14:45 pizza-pi CRON[318]: (me) CMD (etc/application/start-script.sh)
Mar 17 22:14:45 pizza-pi CRON[296]: (CRON) info (No MTA installed, discarding output)
Mar 17 22:14:45 pizza-pi pam_unix(cron:session): session closed for user me
Edit the /etc/rc.local file and add the following line in /etc/init.d/cron/start be sure that it should before exit 0.
Follow this link https://rahulmahale.wordpress.com/2014/09/03/solved-running-cron-job-at-reboot-on-raspberry-pi-in-debianwheezy-and-raspbian/
Hope answer is useful for you