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.
Related
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
I am using phram and ramoops to store the latest system log in a reserved memory, so that once my machine crashed I could dump the panic log after reboot. MTD driver phram and module ramoops are used to automatically record the system log to memory:
/# insmod /lib/modules/phram.ko phram=phram-oops,<addr>,<len>
/# ls -l /dev/mtdchar/param-oops
crw-r--r-- 1 root root 90, 24 Jul 20 16:34 phram-oops
It worked well until recently I reused this driver to also backup the boot loader log - during the boot, phram-oops backs up the u-boot log to one reserved memory area; and after Linux shell is up, dump the u-boot log, clear phram-oops by dd if=/dev/zero bs=65536 count=1 of=/dev/mtdchar/param-oops, rmmod phram and insmod phram with a new memory area for panic log. Then dumping the system logs of last boot. Until this step, /dev/mtdchar/phram-oops still works fine:
/# ls -l /dev/mtdchar/phram-oops
crw-r--r-- 1 root root 90, 24 Jul 20 16:34 /dev/mtdchar/phram-oops
However, after running dd if=/dev/zero bs=65536 count=1 of=/dev/mtdchar/phram-oops” again to clear the memory, driver/dev/mtdchar/phram-oops` becomes a file!!!
/# ls -l /dev/mtdchar/phram-oops
-rw-r--r-- 1 root root 65536 Jul 20 16:34 /dev/mtdchar/phram-oops
And as a result the previous logs remains in the memory and could not be cleared. Any idea about how a driver turns to a file? And how to fix it?
It seems this problem was caused by hotplug - it requires some delay after rmmod phram and before insmod phram with a new address. Otherwise, the device driver is very likely not correctly loaded and as a result the dd command could create it as a normal file.
I want my application be notified (signaled) if my BBB Board is
going to suspend or resume.
So I added a hook-script in
#! /bin/sh
#/etc/pm/sleep.d/15_myapp
case "$1" in
suspend)
pkill -SIGUSR1 myapp>/dev/null 2>&1
;;
resume)
pkill -SIGALRM myapp >/dev/null 2>&1
;;
*)
;;
esac
exit $?
So far so good, every time I try to suspend the board
ajava#debainBBB:~# pm-suspend
I get immediately the Message on the same Consule with a description of
my pkill signal:
User defined signal 1
the suspend-process is then broken.
So I checked the /var/log/pm-suspend.log
Running hook /usr/lib/pm-utils/sleep.d/000kernel-change suspend suspend:
/usr/lib/pm-utils/sleep.d/000kernel-change suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/00logging suspend suspend:
Linux jetMaster 3.12.19-rt30+ #29 PREEMPT RT Wed Jun 25 15:02:55 CEST 2014 armv7l GNU/Linux
Module Size Used by
rfcomm 35643 0
bluetooth 238755 3 rfcomm
usb_f_acm 7016 2
u_serial 11485 1 usb_f_acm
usb_f_mass_storage 45500 2
libcomposite 42382 12 usb_f_acm,usb_f_mass_storage
musb_dsps 7540 0
at25 4594 0
lm75 4802 0
rtc_ds1307 8243 0
musb_am335x 1680 0
total used free shared buffers cached
Mem: 506180 66696 439484 0 7104 32204
-/+ buffers/cache: 27388 478792
Swap: 0 0 0
/usr/lib/pm-utils/sleep.d/00logging suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/00powersave suspend suspend:
/usr/lib/pm-utils/sleep.d/00powersave suspend suspend: success.
Running hook /etc/pm/sleep.d/15_myapp suspend suspend:
As you can see there is no success after calling my script.
But I already have checked the exit-status of my hook-script its 0 (i .e success)
Have any of you folks any idea what's going on here?
Why am I getting the signal description as out put of pm-suspend?
Thanks.
--- UPDATE --------------------------------------------------
The Problem seems to be the standard behavior of the Signal defined here
signal(7)
Apparently every Signal ending with terminating the process causes
the pm-suspend to fail.
The Problem seems to be the standard behavior of the Signal defined here signal(7) Apparently every Signal ending with terminating the process causes the pm-suspend to fail.
I have a processor AT91SAM9G20 running a 2.6 kernel. Watchdog is enabled at bootstrap level and configured for 16 seconds. Watchdog mode register can be configured only once.
When code hangs either in bootstrap, bootloader or kernel, the board reboots. But once kernel comes up even though watchdog is not refreshed in any of the applications, the board is not being reset after 16 seconds, but 15 minutes.
Who is refreshing the watchdog?
In our case, the watchdog should be influenced by applications, so that the board can reset if our application hangs.
These are the running processes:
1 root init
2 root [kthreadd]
3 root [ksoftirqd/0]
4 root [watchdog/0]
5 root [events/0]
6 root [khelper]
63 root [kblockd/0]
72 root [ksuspend_usbd]
78 root [khubd]
85 root [kmmcd]
107 root [pdflush]
108 root [pdflush]
109 root [kswapd0]
110 root [aio/0]
740 root [mtdblockd]
828 root [rpciod/0]
982 root [jffs2_gcd_mtd10]
1003 root /sbin/udevd -d
1145 daemon portmap
1158 dbus dbus-daemon --system
1178 root /usr/sbin/ifplugd -i eth0 -fwI -u0 -d5 -l -q
1190 root /usr/sbin/ifplugd -i eth1 -fwI -u0 -d5 -l -q
1221 default avahi-daemon: running [SP14.local]
1226 root /usr/sbin/dropbear
1246 root /root/bin/host_app
1254 root /root/bin/mini_httpd -c *.cgi -d /root/bin -u root -E /root/bin/
1256 root -sh
1257 root /sbin/syslogd -n -m 0
1258 root /sbin/klogd -n
1259 root /usr/bin/tail -f /var/log/messages
1265 root ps -e
We are using the watchdog for soft lockups available in kernel-2.6.25-ts.at91sam9g20/kernel/softlockup.c
If you enabled the watchdog driver in your kernel, the watchdog driver sets up a kernel timer, in charge of resetting the watchdog. The corresponding code is linux/drivers/watchdog/at91sam9_wdt.c. So it works like this:
If no application opens the /dev/watchdog file, then the kernel takes care of resetting the watchdog. Since it is a timer, it won't appear as a dedicated kernel thread, but handled by the soft IRQ thread. Now, if an application opens this file, it becomes responsible of the watchdog, and can reset it by writing to the file, as documented by the documentation linked in Richard's post.
Is the watchdog driver configured in your kernel?
If not, you should configure it, and see if the reset still happens. If it still happens, it is likely that your reset comes from somewhere else.
If your kernel is too old to have a proper watchdog driver (not present in 2.6.25) you should backport it from 2.6.28. Or you can try to disable the watchdog in your bootloader and see if the reset still occurs.
In July 2016 commit 3fbfe92647 (watchdog: change watchdog_need_worker logic) in the 4.7 kernel to watchdog_dev.c enabled the same behavior as shodanex's answer for all watchdog timer drivers. This doesn't seem to be documented anywhere other than this thread and the source code.
/*
* A worker to generate heartbeat requests is needed if all of the
* following conditions are true.
* - Userspace activated the watchdog.
* - The driver provided a value for the maximum hardware timeout, and
* thus is aware that the framework supports generating heartbeat
* requests.
* - Userspace requests a longer timeout than the hardware can handle.
*
* Alternatively, if userspace has not opened the watchdog
* device, we take care of feeding the watchdog if it is
* running.
*/
return (hm && watchdog_active(wdd) && t > hm) ||
(t && !watchdog_active(wdd) && watchdog_hw_running(wdd));
This may give you a hint: http://www.mjmwired.net/kernel/Documentation/watchdog/watchdog-api.txt
It makes perfect sense to have a user space daemon handling the watchdog. It probably defaults to a 15 minute timeout.
we had a similar problem regarding WDT on AT91SAM9263. Problem was with bit 29 WDIDLEHLT of WDT_MR (Address: 0xFFFFFD44) register. This bit was set to 1 but it should be 0 for our application needs.
Bit explanation from datasheet documentation:
• WDIDLEHLT: Watchdog Idle Halt
0: The Watchdog runs when the system is in idle mode.
1: The Watchdog stops when the system is in idle state.
This means that WDT counter does not increment when kernel is in idle state, hence the 15 or more delay until reset happens.
You can try "dd if=/dev/zero of=/dev/null" which will prevent kernel from entering idle state and you should get a reset in 16 seconds (or whatever period you have set in WDT_MR register).
So, the solution is to update u-boot code or other piece of code that sets WDT_MR register. Remember this register is write once...
Wouldn't the kernel be refreshing the watchdog timer? The watchdog is designed to reset the board if the whole system hangs, not just a single application.