I’m having trouble getting a script working. I’m using manjaro 23.02 64 on raspberry pi 4 B.
I have placed a file named raspberry.conf in /etc/modprobe.d containing “dwc2”.
I added “dtoverlay=dwc2,dr_mode=host” to the config.txt.
I can now start a fan on an external adapter with a terminal command:
sudo sh -c "echo pwm_100 > /dev/ttyUSB0"
I can’t seem to get it to work at boot or login with a script.
I have an extremely simple bash script at /etc/systemd/scripts/startfan.sh containing the bash line and the above command.
I have a service file at /lib/systemd/system/startfan.service containing the following:
I have tried changing ownership and permissions to root for both files and removing the “sudo.”
I’ve tried using a .desktop file (running gnome 40) in my autostart folder and adding a sudoers NOPASSWD line for the script (when it has user ownership and permissions).
I’ve done the “systemctl enable” command for the .service file without errors.
I’m not sure where to look for logs or how to add them.
I have had success with this working in debian based systems but I’m very partial to the modern feel and otherwise better usability/compatibility of manjaro.
EDIT: I should add that when I start the fan using the terminal command it will stay on completely through a reboot but will not start when the pi is powered off and then powered back on.
What am I missing?
It’s been a while since I used arm, but this doesn’t seem arm specific.
I assume you haven’t got any more serial devices, because if you do, you might not be able to guarantee you have the right device when using /dev/ttyUSB0.
Add yourself to the uucp group and you won’t need root.
sudo gpasswd -a $USER uucp
That should be in /usr/local/bin, but I don’t think it’s needed anyway. If it is needed, then to match the service file it should look like this:
#!/usr/bin/bash
echo pwm_100 > /dev/ttyUSB0
And saved as /usr/local/bin/startfan, don’t forget to change the ExecStart= line.
I’m not certain but I think ttyUSB0 on raspberry pi is the power usb-c port and isn’t used for any other data transfer. Would a udev attribute query confirm?
That’s the place for service files installed by packages. /etc/systemd/system is the place for services installed by the admin, ie you.
The proper way to give yourself the permission is using the uucp group, this should work for an autostart script, it shouldn’t affect the systemd service unless it’s run as a user service.
I’ve just tested this and it works on my system, by works I mean the command seems to execute successfully when the service is run manually. I’m on a desktop and my user is part of the uucp group, not that either should matter in this case.
Mar 03 10:42:02 dm-pc systemd[1]: Starting blabla...
Mar 03 10:42:02 dm-pc echo[1341007]: pwm_100 > /dev/ttyUSB0
Mar 03 10:42:02 dm-pc systemd[1]: startfan.service: Deactivated successfully.
Mar 03 10:42:02 dm-pc systemd[1]: Finished blabla.
First of all I can’t thank you enough for trying to help. I have been successful at getting my service to run without errors using the above methods HOWEVER my fan doesn’t start when the system is powered off and back on which is the reason for the service in the first place. I can successfully run a command or script and start the fan and I have been successful in doing other (non-serial) tasks with this method AND I can get a service that calls a script to run without error but it just doesn’t do anything when the system powers back on. I am trying to start a fan on modified 3rd party hardware (a mini desktop type case) designed for raspberry pi. The original drivers are poorly coded or outdated and I have tested them on a few different OS’s and had to fix code on each one to get the fan working. I was sucessful on most other OS’s with the exception of Ubuntu 22 or higher. This is by far my favorite OS and I’m planning to build a home NAS with remote access from outside the network so I have a lot more work ahead but It’s all moot if I can’t have sufficient cooling. This is frustrating as this non-start issue has taken up a couple days now of my time.
I have gone with a more mickey mouse approach and created a home folder and user owned situation in which the script and service are owned by user and I am really close to making this work. The issue I have now is that my sudoers.d file is not sticking. I have added myself to the uucp group as you suggested. When I run:
systemctl --user status startfan.service
I get:
× startfan.service - cooling fan
Loaded: loaded (/home/humble/.config/systemd/user/startfan.service; enabled; preset: enabled)
Active: failed (Result: exit-code) since Fri 2023-03-03 18:16:36 EST; 7s ago
Duration: 2.158s
Process: 4372 ExecStart=/home/humble/Documents/scripts/startfan.sh (code=exited, status=1/FAILURE)
Main PID: 4372 (code=exited, status=1/FAILURE)
CPU: 41ms
Mar 03 18:16:34 pi4 systemd[464]: Started cooling fan.
Mar 03 18:16:34 pi4 sudo[4377]: pam_systemd_home(sudo:auth): Not a user managed by systemd-homed: No home for user humble known
Mar 03 18:16:34 pi4 sudo[4377]: pam_unix(sudo:auth): conversation failed
Mar 03 18:16:34 pi4 startfan.sh[4377]: sudo: a terminal is required to read the password; either use the -S option to read from standard inpu>
Mar 03 18:16:34 pi4 sudo[4377]: pam_unix(sudo:auth): auth could not identify password for [humble]
Mar 03 18:16:36 pi4 startfan.sh[4377]: sudo: a password is required
Mar 03 18:16:36 pi4 systemd[464]: startfan.service: Main process exited, code=exited, status=1/FAILURE
Mar 03 18:16:36 pi4 systemd[464]: startfan.service: Failed with result 'exit-code'.
Here’s my script at ~/Documents/scripts/startfan.sh:
#!/bin/bash
serial_port='/dev/ttyUSB0'
sudo sh -c "echo pwm_100 > $serial_port"
this could probably be simpler but it works.
what’s strange is that if I open the file with something as simple as gnome-text-editor it prompts me for a password.
Here’s my service at ~/.config/systemd/user/startfan.service:
[Unit]
Description=cooling fan
[Service]
ExecStart=/home/humble/Documents/scripts/startfan.sh
[Install]
WantedBy=default.target
and finally I have a /etc/sudoers.d/startfan containing one line:
Yet you’ve only posted errors. I don’t reboot much so I can’t test it at boot. If you have a way of running the systemd service without errors then please post it. All we need to do is get it to run at boot.
I’m not so sure. Why are you using a user service and hacks to run something as root, when a system service will already run it as root.
My point with the service was that works (at least for me), and can be adapted to work at boot. We need to find the right way of running it.
The timer approach (option 3 from my first post) should work, have you tried it? You don’t really need the After= line, I should’ve taken that out.
EDIT:
You’re not trying to run startfan.sh with sudo, you’re using sh for some reason (it’s a symlink to bash, but can vary so it’s not portable, not that it matters much).
Allowing sh aka bash to be run as root without a password is definitely a security risk, and it won’t work via a script like that.
This is a better way of doing it echo pwm_100 | sudo tee /dev/ttyUSB0, and then you’d put tee in the sudoers file. Not that I’m suggesting you do it, this is the wrong approach, it’s just for information.
EDIT2:
I don’t know if you’ve already seen these, but if not then they may help.
I have no sudoers in place atm
I have script named startfan (without the sh) in /usr/bin
I have system.servic and system.timer in etc/systemd/system
Every time i do status it says disabled - even when it has no errors
if the service is active the fan is off even when commands are passed to start it.
Why add in the extra complication of a script and the call to sh?
The command you’re using calls sh aka bash as root to allow the bash redirection (>) to write to a root owned file. The service is already running as root, so it’s not needed.
Have you tried ExecStart=echo pwm_100 > /dev/ttyUSB0 yet? It may yield the same results or it may work.
Also remove the Install section, it’s not needed since it’s called by a timer. That’s why it says enabled disabled etc.
When you change the WantedBy line, you need to disable the service and re-enable it for the change to take effect. Except in this case you can’t re-enable it, which is fine that’s the way it should be.
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
instance name specified.
That’s right it’s meant to be run by the timer. The timer needs to be enabled.
sudo systemctl enable startfan.timer
I’m trying to use the timer as I’m not sure how to guarantee it being run at the right time, without you playing around with things, taking up more of your time. So we use the timer to run it some time after boot when we know the device is ready.
