[SOLVED] Starting LEDBlink script at startup.

jsarch27 · 2021-08-01 23:25:04

I have a script called LEDBlink which is as follows:

#!/bin/sh

modprobe -r ec_sys
modprobe ec_sys write_support=1

echo -n -e "\x0a" | sudo dd of="/sys/kernel/debug/ec/ec0/io" bs=1 seek=12 count=1 conv=notrunc 2> /dev/null

xinput test-xi2 --root 3 | gawk '/RawKeyRelease/ {getline; getline; print $2; fflush()}' | while read -r key; do 
if [[ size{$key}!=0 ]]; then
echo -n -e "\x8a" | sudo dd of="/sys/kernel/debug/ec/ec0/io" bs=1 seek=12 count=1 conv=notrunc 2> /dev/null
fi
echo -n -e "\x0a" | sudo dd of="/sys/kernel/debug/ec/ec0/io" bs=1 seek=12 count=1 conv=notrunc 2> /dev/null

done

This is designed to blink a red LED on top of my laptop when a key is pressed. It functions as intended when run manually with sudo, however, I have been unsuccessful at getting it to run on startup. I have tried creating a systemd service, however, the script does not run properly (I think this may be due to the fact that my script must run continuously in the background). I have tried adding it to my .xinitrc (not ideal as I would like this to run without having to start X) as follows:

exec xcompmgr&
exec slstatus&
xbindkeys&
sh /path/to/LEDBlink&
exec dwm

however this prevents dwm from starting properly.
Is there a way to get my script to start at startup using .xinitrc, a systemd service or otherwise?

Last edited by jsarch27 (2021-08-02 13:50:46)

lmn · 2021-08-02 00:11:22

Something doesn't add up in regards to

xinput ...

and

jsarch27 wrote:

(not ideal as I would like this to run without having to start X)

For systemd and user sessions read this.
A regular systemd unit also doesn't know about your X session or user, that's why that avenue isn't working.

As to why your window manager isn't starting.
That is probably because the loop waiting for input, it can not receive.

seth · 2021-08-02 06:30:28

1. your xinitrc is broken, see the link below
2. remove the occurrences of "exec" but for "exec dwm"
3. the problem is the sudo invocation, it's expecting you to enter a password, what's not going to happen in your xinitrc - though since running in the background I'm not sure why it would block the xinitrc execution (of dwm)
- Either remove the internal sudo calls, invoke the script with sudo and grant yourself passwordless execution rights for the script in your sudoers. Or
- get rid of the privilegue requirements in the script:
* add the "write_support=1" option to your modprobe configuration for the module
* use an udev rule to give your user writing access to /sys/kernel/debug/ec/ec0/io (eg. w/ a special gid that you're part of)

jsarch27 · 2021-08-02 12:17:50

seth wrote:

3. the problem is the sudo invocation, it's expecting you to enter a password, what's not going to happen in your xinitrc - though since running in the background I'm not sure why it would block the xinitrc execution (of dwm)
- Either remove the internal sudo calls, invoke the script with sudo and grant yourself passwordless execution rights for the script in your sudoers.

I have tried editing sudoers as following:

## sudoers file.
##
## This file MUST be edited with the 'visudo' command as root.
## Failure to use 'visudo' may result in syntax or file permission errors
## that prevent sudo from running.
##
## See the sudoers man page for the details on how to write a sudoers file.
##

##
## Host alias specification
##
## Groups of machines. These may include host names (optionally with wildcards),
## IP addresses, network numbers or netgroups.
# Host_Alias	WEBSERVERS = www1, www2, www3

##
## User alias specification
##
## Groups of users.  These may consist of user names, uids, Unix groups,
## or netgroups.
# User_Alias	ADMINS = millert, dowdy, mikef

##
## Cmnd alias specification
##
## Groups of commands.  Often used to group related commands together.
# Cmnd_Alias	PROCESSES = /usr/bin/nice, /bin/kill, /usr/bin/renice, \
# 			    /usr/bin/pkill, /usr/bin/top
# Cmnd_Alias	REBOOT = /sbin/halt, /sbin/reboot, /sbin/poweroff

##
## Defaults specification
##
## You may wish to keep some of the following environment variables
## when running commands via sudo.
##
## Locale settings
# Defaults env_keep += "LANG LANGUAGE LINGUAS LC_* _XKB_CHARSET"
##
## Run X applications through sudo; HOME is used to find the
## .Xauthority file.  Note that other programs use HOME to find   
## configuration files and this may lead to privilege escalation!
# Defaults env_keep += "HOME"
##
## X11 resource path settings
# Defaults env_keep += "XAPPLRESDIR XFILESEARCHPATH XUSERFILESEARCHPATH"
##
## Desktop path settings
# Defaults env_keep += "QTDIR KDEDIR"
##
## Allow sudo-run commands to inherit the callers' ConsoleKit session
# Defaults env_keep += "XDG_SESSION_COOKIE"
##
## Uncomment to enable special input methods.  Care should be taken as
## this may allow users to subvert the command being run via sudo.
# Defaults env_keep += "XMODIFIERS GTK_IM_MODULE QT_IM_MODULE QT_IM_SWITCHER"
##
## Uncomment to use a hard-coded PATH instead of the user's to find commands
# Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
##
## Uncomment to send mail if the user does not enter the correct password.
# Defaults mail_badpass
##
## Uncomment to enable logging of a command's output, except for
## sudoreplay and reboot.  Use sudoreplay to play back logged sessions.
# Defaults log_output
# Defaults!/usr/bin/sudoreplay !log_output
# Defaults!/usr/local/bin/sudoreplay !log_output
# Defaults!REBOOT !log_output

##
## Runas alias specification
##

##
## User privilege specification
##
root ALL=(ALL) ALL

## Uncomment to allow members of group wheel to execute any command
%wheel ALL=(ALL) ALL

## Same thing without a password
# %wheel ALL=(ALL) NOPASSWD: ALL

## Uncomment to allow members of group sudo to execute any command
# %sudo	ALL=(ALL) ALL

## Uncomment to allow any user to run sudo if they know the password
## of the user they are running the command as (root by default).
# Defaults targetpw  # Ask for the password of the target user
# ALL ALL=(ALL) ALL  # WARNING: only use this together with 'Defaults targetpw'

## Read drop-in files from /etc/sudoers.d
@includedir /etc/sudoers.d

username ALL=(root) NOPASSWD: /home/username/dev/LEDBlink #EDITED HERE

However I am still prompted for a password when I

 sudo sh /home/username/dev/LEDBlink

. Is there anything I am missing here or could there be an issue specific to my script?

Trilby · 2021-08-02 12:55:59

Well, yeah. You modified your sudoers file so 'username' could run /home/username/dev/LEDBlink as root without a password. But then you tried to run 'sh' with sudo. Make the script executable, if it isn't already, then get rid of the "sh" in your last command.

jsarch27 · 2021-08-02 13:48:07

Trilby wrote:

Well, yeah. You modified your sudoers file so 'username' could run /home/username/dev/LEDBlink as root without a password. But then you tried to run 'sh' with sudo. Make the script executable, if it isn't already, then get rid of the "sh" in your last command.

Thanks, I am now able to run LEDBlink without a password prompt. I was then able to insert "sudo /home/username/dev/LEDBlink&" before "exec dwm" in my .xinitrc which solved the issue.

Arch Linux

#1 2021-08-01 23:25:04

[SOLVED] Starting LEDBlink script at startup.

#2 2021-08-02 00:11:22

Re: [SOLVED] Starting LEDBlink script at startup.

#3 2021-08-02 06:30:28

Re: [SOLVED] Starting LEDBlink script at startup.

#4 2021-08-02 12:17:50

Re: [SOLVED] Starting LEDBlink script at startup.

#5 2021-08-02 12:55:59

Re: [SOLVED] Starting LEDBlink script at startup.

#6 2021-08-02 13:48:07

Re: [SOLVED] Starting LEDBlink script at startup.

Board footer