Activating a script using udev when power supply is connected/disconnected - linux

I'm trying to get udev to run a couple of small scripts when I connect/disconnect the powersupply. I have the following code in /etc/udev/rules.d/50-caff.rules :
SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_STATUS}=="Charging", RUN+="/home/haukur/rules/off.sh"
SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_STATUS}=="Discharging", RUN+="/home/haukur/rules/on.sh"
Here is on.sh:
#!/bin/sh
caffeine -a
and off.sh:
#!/bin/sh
caffeine -d
Anyway, I wrote these, wrote udevadm control --reload-rules into bash and... nothing happened. caffeine doesn't appear to activate at all when I plug or unplug the power supply.
According to /var/log/syslog (Ubuntu's replacement for /var/log/messages) udev recognizes when I pull the plug:
Feb 26 08:44:52 (none) udevd[3838]: starting '/home/haukur/rules/off.sh'
but when it tries to run off.sh (which itself tries to run caffeine), it returns this error:
udevd[2719]: '/home/haukur/rules/off.sh'(err) '** (caffeine:3840): WARNING **: Command line `dbus-launch --autolaunch=62907743a139af9b3c86412e00000026 --binary-syntax --close-stderr' exited with non-zero exit status 1: Autolaunch error: X11 initialization failed.\n'
Do you know any way to get around this? Running Ubuntu 12.04 LTS with xmonad WM.

If the application "caffeine" needs to access you desktop, you probably need to export the DISPLAY before calling the program:
export DISPLAY=:0
You may simply prepend this to the command invocation:
DISPLAY=:0 caffeine -a

Related

bash script to auto run on boot, make screen, execute a command and detach

I am using Centos 7 and on boot I would like to:
Make a screen
Execute a command: osrm-routed --algorithm=MLD
~/osrm-backend/profiles/australia-latest.osrm
Detatch from screen (possibly not needed, just as long as I can
access it myself after its running in future)
Here is something I have thought about, although not correct and wont work
filename: mapstart.sh
Contents of file:
#!/bin/bash
/usr/bin/screen -dmS mapapi osrm-routed --algorithm=MLD ~/osrm-backend/profiles/australia-latest.osrm
With your help with the script. I am not sure the best way to run that on boot with centos 7.
Appreciate your help and input.
For those who would like to know. The issue was with OSRM and centos. I was able to get it running using the full paths of everything and the following in crontab -e
To get the full path of osrm-backend i ran the command of:
which osrm-routed
It returned the result of:
/usr/local/bin/osrm-routed
That then enabled me to add the full path of the command I was trying to run from crontab -e which is required. From there it worked running the below in crontab -e
#reboot /usr/bin/screen -dm -S pistartup /usr/local/bin/osrm-routed --algorithm=MLD ~/osrm-backend/profiles/australia-latest.osrm
break down of all the above:
runs command at reboot only:
#reboot
full path to screen command:
/usr/bin/screen
create screen with name of pistartup and detach:
-dm -S pistartup
my particular command i wanted to run inside the screen:
/usr/local/bin/osrm-routed --algorithm=MLD ~/osrm-backend/profiles/australia-latest.osrm
Now when ever the machine is rebooted. it has created a screen and run my command. To resume the screen manually If i ever wanted to, i could issue the command of:
screen -r pistartup

Executing bash script on wakeup

Since some time I have a Prolbem with my Linux distribution (Kubuntu 18.04). Every time my linux comes back from standby modus the touchpad is not working properly anymore (can't grab and drag files or other objects).
I already found a solution for my Problem:
modprobe psmouse -r
modprobe psmouse
This code does solve the problem. However, after this the rightclick area which I always disable at sartup is enabled again.
I have a script that runs on startup which executes the following:
synclient RightButtonAreaLeft=0
synclient RightButtonAreaTop=0
What I am now trying to do, is to write a script that runs whenever the system is waking up form standby modus.
I wrote the script like this:
#!/bin/bash
exec 1> /home/luc/Schreibtisch/update.log 2>&1
set -x
case $1/$2 in
pre/*)
echo "Going to $2..."
# Place your pre suspend commands here, or `exit 0`
# if no pre suspend action required
exit 0
;;
post/*)
echo "Waking up from $2..."
sh /home/luc/Schreibtisch/test.sh
sh /home/luc/Schreibtisch/test2.sh
;;
esac
Where test.sh runs the modprobe commands and test2.sh runs the synclient commands.
After going to standby modus and waking up again I'm getting the following log:
+ case $1/$2 in
+ echo 'Waking up from suspend...'
Waking up from suspend...
+ sh /home/luc/Schreibtisch/test.sh
+ sh /home/luc/Schreibtisch/test2.sh
Failed to connect to X Server.
Failed to connect to X Server.
And the grabing and draging of the files works perfectly but the rightclick is still enabled.
My question is now if it is possible to execute the synclient commands after the X Server is ready?
Kind regards
Pepsilon
It looks like i have found a workaround for the problem of the touchpad not working properly after wakeup.
In my /etc/modprobe.d/blacklist.conf the module i2c_i801 was blacklisted.
After removing this module form the blacklist my touchpad now works fine after standby mode.

No cursor motion capability occurs when startup linux script execute minicom script with at commands

I have created a startup Linux script for a board that runs Debian jessie Armbian 8.1. I need at startup to run at command in a modem attached to it via USB interface. I've put the script inside rc.local:
#!/bin/sh -e
cd /home/user/Script/
sh script.sh
exit 0
In the folder Script I have a script:
#!/bin/sh
minicom -S at_command.txt
The at_command contains:
send at+creg=1
send exit
! killall minicom
The issue is that when I run the script manually it works correctly,
however when I start the the board the at commands do not execute.
Since the board is Debian I also followed the link: ttp://www.stuffaboutcode.com/2012/06/raspberry-pi-run-program-at-start-up.html and to adapt the script to run according LSBInitScripts but I got the same behavior. When running sudo /etc/init.d/myScript start manually everything works great, but after Linux startup no at_command is executed. I added in the rc.local the following commands for debugging:
set -x;
exec 2>>/home/user/Script/minicom-rc.log;
date +"$0 %c" >&2
And in the generated log file I got this printout:
+ date +/etc/rc.local %c
/etc/rc.local Fri 02 Mar 2018 04:02:43 PM EET
+ cd /home/user/Script/
+ sh script.sh
No cursor motion capability (cm)
What I have done wrong?
I am guessing it is related to there being no terminal during startup.
Maybe try adding the following line before starting minicom:
export TERM=linux-c-nc
In this scenario you alternatively use my atinout program which is a program specifically made for sending AT commands to a modem from the command line (assuming the modem is /dev/ttyUSB0):
echo at+creg=1 | atinout - /dev/ttyUSB0 -
or possibly
atinout /home/user/at_commands.txt /dev/ttyUSB0 /dev/null

sudo not working correctly after some time

I have Linux server (CentOS release 6.4) which is able to process source code sent by users. On the server is a Java application which starts a bash script which will run compilation and execution commands of these source codes in a limited way (time and memory are limited, no Internet, executed by limited user).
The Java program must be always be running, so it can register new job requests.
When started, the Java program works fine, but after some time (talking in days), commands are not executed properly. I get the following error message:
sudo: sorry, you must have a tty to run sudo
the line which is causing that is:
sudo -u codiana $COMMAND &
where $COMMAND is command to execute along with its arguments
After application restart (kill and start again) everything works.
Is there some time limit on Linux which can cause that?
You can comment /etc/sudoers:
#Defaults requiretty
Edit:
man sudoers | grep requiretty -A 5
requiretty If set, sudo will only run when the user is logged in
to a real tty. When this flag is set, sudo can only be
run from a login session and not via other means such
as cron(8) or cgi-bin scripts. This flag is off by
default.
So if this is not desired open /etc/sudoers with you text editor of choice and comment out this line.

Simple replacement of init to just start console

On a very simple PC, I want to replace Ubuntu 12.04 /sbin/init by the most simple bash script in order to have the very minimum number of running processes. Obviously, no X, no USB, no detection of new hardware, no upgrade, no apt, "nothing", I just need a working console with a DHCP-based Wi-Fi IP address (ssid, passphrase are already stored in /etc/network/interfaces). That's all. Currently, I have tried this in replacement of /sbin/init:
#!/bin/sh
mount -o rw,remount /
mount -t proc none /proc
udevd --daemon
mkdir /run/network
ifup -a &
while [ 1 ]; do
/sbin/getty -8 115200 tty1 vt100
done
It's working as I'm getting an IP address and I can login but:
A) While running shutdown, I get "shutdown: Unable to shutdown system:"
B) control-c is not working in the console
C) After a login, I get: "bash: cannot set terminal process group (-1): Inappropriate ioctl for device"
D) After a login, I get: "bash: no job control in this shell"
Also, I have noticed that all the user-space processes have a "?" in the tty column when running ps avx. How can I fix those problems? I don't want to use upstart in order to really control what is started on the PC and have the very bare minimum.
I ended up using Busybox init. Great tiny init...
You could leverage runlevels and based on your question runlevel 3 is what you want to use.
If you have some services that you do not wish to start, you could turn them off too for that runlevel.
For booting into runlevel 3, you just append the boot argument to the kernel in your boot loader:
<EXISTING_BOOT_CMD> 3
If your distro uses systemd instead of sysvinit, they are instead called as targets. The equivalent of runlevel 3 in systemd is usually named as multi-user.target
The kernel boot argument you would need to pass in this case is systemd.unit=multi-user.target
<EXISTING_BOOT_CMD> systemd.unit=multi-user.target
An alternative, if you do not want to touch the boot loader:
systemctl enable multi-user.target

Resources