I enabled hw watchdog in systemd (RuntimeWatchdogSec=10) and believe that it was actually enabled:
# dmesg | grep watchdog
[ 3.328676] systemd[1]: Hardware watchdog 'OMAP Watchdog', version 0
[ 3.336760] systemd[1]: Set hardware watchdog to 10s.
Then I wanted to test out if the system really restarts when systemd stops working. As I could not find systemd documentation regarding which systemd daemon feeds the hw watchdog, I tried to kill wildly all systemd daemons one after another (systemd-udevd, systemd-timesyncd, systemd-networkd, systemd-journald, etc) until the console became non function after I killed the systemd daemon (which has a symlink /sbin/init in my system). Until this point, my system still did not restart. Any hints?
I've found out that systemd daemon actually opened /dev/watchdog:
# lsof /dev/watchdog
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
systemd 1 root 4w CHR 10,130 0t0 6871 /dev/watchdog
And in my kernel CONFIG_WATCHDOG_NOWAYOUT is not set --> When I killed systemd, no process opened /dev/watchdog and the hardware watchdog was just disabled. When I enabled CONFIG_WATCHDOG_NOWAYOUT, board resets when systemd stops.
Related
Systemd allows starting/stopping service from udev rule using SYSTEMD_USER_WANTS environment and StopWhenUnneeded option. But, service will be started when device is inserted and stopped when device is removed. What I need is vice versa:
start service when device removed
stop service when device inserted
Since it is user service, running 'systemctl start/stop ...' from udev rule fails.
udev rule for this question is
..., ACTION=="add", RUN+="/usr/bin/su USER -c 'systemctl --user stop my-service'"
..., ACTION=="remove", RUN+="/usr/bin/su USER -c 'systemctl --user stop my-service'"
The important points are:
Instead of SYSTEMD_WANTS/SYSTEMD_USER_WANTS, service should be start/stop using systemctl since start/stop does not match device add/remove.
To start/stop service from other user su + systemctl --user is used.
Program pass to RUN udev key should be either from /usr/lib/udev or absolute pass must be used (man udev).
I have the following script:
whie true
do
#code
sleep 60
done
I then wanted to create a service to start the machine and launch this script as service:
created my.service at /etc/systemd/system/my.service
[Unit]
Description=my Script
[Service]
Type=forking
ExecStart=/bin/script.sh
[Install]
WantedBy=multi-user.target
problem occurs when i systemctl start my.service
it goes to while true loop and hang in there, how can i run this service and make it run in the background ?
According to systemd specification at link. Type=forking is not exactly correct kind of start-up in your case
If set to forking, it is expected that the process configured with
ExecStart= will call fork() as part of its start-up. The parent
process is expected to exit when start-up is complete and all
communication channels are set up. The child continues to run as the
main service process, and the service manager will consider the unit
started when the parent process exits. This is the behavior of
traditional UNIX services. If this setting is used, it is recommended
to also use the PIDFile= option, so that systemd can reliably identify
the main process of the service. systemd will proceed with starting
follow-up units as soon as the parent process exits.
The Type=simple can be correct one. You can try with it
If set to simple (the default if ExecStart= is specified but neither
Type= nor BusName= are), the service manager will consider the unit
started immediately after the main service process has been forked
off. It is expected that the process configured with ExecStart= is the
main process of the service. In this mode, if the process offers
functionality to other processes on the system, its communication
channels should be installed before the service is started up (e.g.
sockets set up by systemd, via socket activation), as the service
manager will immediately proceed starting follow-up units, right after
creating the main service process, and before executing the service's
binary. Note that this means systemctl start command lines for simple
services will report success even if the service's binary cannot be
invoked successfully (for example because the selected User= doesn't
exist, or the service binary is missing).
I've set up a raspberry pi to execute a command if a USB stick is inserted, and the command calls an executable on the stick.
This works about 80% of the time, but intermittently fails - seemingly at random. Because of the unpredictability I assume this is a race condition, however I'm not too familiar with where the risks are as I've pieced together the approach from information online. Most of the information comes from here.
The USB stick is auto-mounted with the following entry in /etc/fstab. I'm aware of the risk of /dev/sda1 changing but that does not appear to be the problem here:
/dev/sda1 /media/usb vfat defaults,rw,nofail,user,umask=000 0 0
A service waits for the USB to mount with the following configuration
[Unit]
Description=USB Mount Trigger
Requires=media-usb.mount
After=media-usb.mount
[Service]
ExecStart=/script.sh
[Install]
WantedBy=media-usb.mount
media-usb.mount comes from systemctl list-units -t mount, and /script.sh calls the USB stick's executable.
In failure cases, where the USB's executable is not called, I see the following from systemctl status service_name:
Nov 15 22:49:14 raspberrypi systemd[1]: Dependency failed for USB Mount Trigger.
Nov 15 22:49:14 raspberrypi systemd[1]: service_name.service: Job service_name.service/start failed with result 'dependency'.
In these cases if I execute systemctl list-units -t mount I do not see media-usb.mount and my USB stick is not mounted to /media/usb.
I think that an error / race condition in service_name.service causing the USB mount to die, because (I believe) a successful mount is required to trigger the service. If the USB is never inserted, systemctl status service_name simply reports Active: inactive (dead), so something is triggering the service to try to execute.
I want to enable core dump generation for a systemd service which gives a SEGV status and exits.
scd.service: main process exited, code=killed, status=11/SEGV
Unit scd.service entered failed state.
scd.service failed.
my bashrc file already has ulimit -c unlimited.
after running systemd-coredumpctl the output is
No coredumps found.
Note : I am able to generate core dump for normal programs executed via terminal but unable to do so for a systemd service
You need to set LimitCORE=infinity in your service file (scd.service), not your bashrc.
More info in https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Process%20Properties
Firstly this is a double post with serverfault, Please advise what is better site for this type of question.
This is my first time with upstart. I can not get the following script to launch when waiting for the network to initiate. It will work if using standard
start on runlevel [2345]
stop on runlevel [!2345]
I have also tried various combinations of
start on filesystem and net-device-up IFACE=eth0
start on filesystem and net-device-up IFACE!=lo
Any suggestions would be grateful
description "test for on network start"
start on (started network-interface
or started network-manager
or started networking)
stop on (stopping network-interface
or stopping network-manager
or stopping networking)
script
touch /home/ec2-user/myFile.txt
end script
the event that signifies that the network is completely configured is static-network-up. You will most likely also need the file system event for any service that uses /home, /var, and /usr.