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?
Related
I have been trying to get the last system reboot time with seconds in SLES 12 version with below commands but none of them giving the time with seconds.
who -b
system boot 2020-07-30 23:02
last reboot
reboot system boot 4.12.14-95.54-de Thu Jul 30 23:02 - 11:41 (3+12:39)
As uptime -s doesn't work in SLES, is there any command to get the last system reboot time with seconds.
Use the option -F / --fulltimes of last to display the times including seconds.
last -F reboot
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).
I have stopped ttyS0 (initctl stop serial DEV=ttyS0). The ttyS0 process stops for the session but reappears post to reboot, I want to disable ttyS0 at boot as it throws errors like:
Feb 19 20:19:42 sdm2 init: serial (ttyS0) main process (608881) terminated with status 1
Feb 19 20:19:42 sdm2 init: serial (ttyS0) main process ended, respawning
Feb 19 20:19:42 sdm2 init: initLogger main process (608986) terminated with status 1
I couldnt find any /etc/init/ttyS0.conf but serial.conf exists.
I searched for 'respawn' in an attempt to turn it OFF, but I found 'respawn' in serial.conf.
instance $DEV
respawn
pre-start exec /sbin/securetty $DEV
./init/serial.conf-33-exec /sbin/agetty /dev/$DEV $SPEED vt100-nav
Though /etc/ttyS0.conf doesnt exists,but I used 'echo manual | sudo tee /etc/init/ttyS0.override' to stop the ttyS0 at boot time.
-Also I removed ttyS0 from securetty.
-There is no mention of ttyS0 in inittab file.
-In grub.conf I have two console entries tty0 and console=ttyS0,115200 as well.
-/dev/ttyS0 exists but /etc/init/ttyS0.conf does nt.
Could anyone assist in stopping ttyS0 after reboot.
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.
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