Cronjob not running with sudo

Jones_Dow · 2024-09-04 13:42:55

Hi guys, I am on Arch and trying to get a cronjob running with admin privileges.

Inside my crontab files i have this line of code :

*/1 * * * * echo “Linux is Cool!” >> ~/crontab_log.txt
`
The cronjob executes perfectly when running the job not with sudo, but fails when i do use sudo.

crontab -e (runs the job)
sudo crontab -e (does not run the job)

In both crontab files the content is exactly identical.

What am I missing ? Is there a need to activate the job?

Last edited by Jones_Dow (2024-09-04 13:43:53)

seth · 2024-09-04 14:22:52

Sure it's not? Because it's not writing into what file?
Try "*/1 * * * * echo “Linux is Cool!” >> /tmp/crontab_log.txt"

You're also not "running the job w/ sudo" but editing the roots crontab.

Jones_Dow · 2024-09-04 16:10:57

I am sure it's not running .... I have also tried different commands, like running s script with :

*/3 * * * * /home/.../.local/bin/BatteryNotify

and

*/3 * * * * /home/..../.local/bin/BatteryNotify.sh

Both are running without sudo, but not with it ...

Last edited by Jones_Dow (2024-09-04 16:11:27)

seth · 2024-09-04 16:15:51

And what is "batterynotify.sh"? Will it depend on dbus or a display server?
Try to echo into a file w/ an absolute path - again: this has nothing to do with "sudo", the "sudo" crontab runs as root.

cryptearth · 2024-09-04 16:19:22

Jones_Dow wrote:

Hi guys, I am on Arch and trying to get a cronjob running with admin privileges.
Inside my crontab files i have this line of code :
*/1 * * * * echo “Linux is Cool!” >> ~/crontab_log.txt
`
The cronjob executes perfectly when running the job not with sudo, but fails when i do use sudo.
crontab -e (runs the job)
sudo crontab -e (does not run the job)
In both crontab files the content is exactly identical.
What am I missing ? Is there a need to activate the job?

have you checked the file at

/root/crontab_log.txt

? because when you do

sudo crontab -e

you edit the list for root - so the home directory "~" becomes "/root"

Jones_Dow · 2024-09-04 16:35:40

Weellllll .... now you got me .... the test with the line you suggested worked ...

Like I mentioned before : I was actually trying to run a script ...

When I try to run a script like this : */1 * * * * /home/rainer/.local/bin/Test.sh it does not seem to work.

Inside the script I have this, as a test :

#!/bin/sh
notify-send "Low Battery" "14% of battery remaining."

Is the path maybe incorrect?

Last edited by Jones_Dow (2024-09-04 16:36:35)

seth · 2024-09-04 16:39:17

Please use [code][/code] tags, not "quote" tags. Edit your post in this regard.

https://gist.github.com/AladW/de1c5676d93d05a5a0e1 - this imports the environment from xinit, choose a process that's usable for you.

V1del · 2024-09-04 16:42:27

... and you want to grab the DBUS_SESSION_BUS_ADDRESS from said process.

Jones_Dow · 2024-09-04 17:27:00

I am using a battery script that is actually working with crontab ...

I want to add a script that uses admin privileges to shut down the computer.

This line is actually going into the file in the root directory :

*/1 * * * * echo “we is Cool!” >> ~/crontab_log.txt

Thanks for pointing out the location at /root/.

This is the line i want to use in the crontab to run the script

*/1 * * * * /home/rainer/.local/bin/Test.sh

I am using now the absolute path, but it is still not working.

Inside the script, i have this code merely for testing :

#!/bin/sh
export DISPLAY=:0
export DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus"

notify-send "Low Battery Test" "14% of battery remaining."

The script runs from the terminal, but not when i use the crontab with sudo.

Is the path in the wrong format?

cryptearth · 2024-09-04 18:37:07

I'm no expert in all that dbus magic - but likely the non-graphic cronjob has trouble to access the graphical user session
from what I get you try to add some shutdown - so the whole topic becomes a xy problem: you try to seek an answer for the solution you want to implement rather than looking for alternatives - in this case: enable the user to shutdown the system so you won't need root at all

V1del · 2024-09-04 20:04:57

runuser the notify-send command to your actual user, e.g.

runuser -u jones -c 'notify-send "Low Battery Test" "14% of battery remaining."'

But I agree with the above assertion, all the bits and pieces you presented so far are operations that you do not need the root user for and it would make more sense to execute this directly as the corresponding user./potentially with a systemd timer instead of a cronjob as that will setup DBUS properly automatically.

Unless you're actually asking about something entirely different, in which case, as mentioned please talk about your actual goal instead of your understanding of trying to create a solution, that's potentially the wrong approach. https://xyproblem.info/

seth · 2024-09-04 20:06:33

notify-send foo
sudo notify-send bar # dbus error
sudo DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" notify-send bar # connection error
sudo sudo -u $USER DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" notify-send bar # tadaaa

You want to run notify-send as the target user, but as cryptearth pointed out, this approach might be ass-backwards.
I guess you're intending to run a cron job as root to poll the battery status and warn the user?
Is that because you actually want to shutdown or suspend the system (an active user should be able to do that anyway) or to be able to access the battery status (dto.)?

The only legitimate reason to involve the root would be a udev rule, https://wiki.archlinux.org/title/Laptop … tery_level

Edi: Oh, c'mon…

Last edited by seth (2024-09-04 20:07:09)

Jones_Dow · 2024-09-05 00:27:17

Many thanks for all your inputs. This xy thing makes totally sense... maybe i am just being stubborn ... :-)

So my real problem is that i leave the the laptop running and unattended, the battery runs out of power and the computer shuts down. And what i really want to achieve is that the computer automatically shuts down when the battery is at a certain level, say 3%.

For this i would need/ could use a script and a cronjob that checks the battery every 2 minutes, right?

The script for emitting a notification when the battery is low, i already have ant it's working fine. What's missing is the part that shuts down the computer when the battery level becomes critical.

The cronjob would need to be run with sudo because the script contains

shutdown now

that doesn't execute without admin permissions, correct?

seth · 2024-09-05 06:13:29

The cronjob does not "run with sudo", "sudo crontab -e" simply makes you root and edit your crontable as root.
"systemctl shutdown" should™ allow your regular user to shutdown the system as long as you're logged in, but that's irrelevant - the entire problems you've been facing here are immaterial wrt "shutdown" itself, it doesn't require access to your user session at all.

Have you tried the udev rule I linked to see whether you can avoid polling the battery?
Otherwise, yes, you can use a cronjob to poll the battery level and respond correspondingly.

If you want to run it as root (because your user isn't guaranteed to have an active session all the time) or end up using udev (which runs as roo) you want to "sudo -u rainer DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" notify-send …" or "runuser -u rainer notify-send …" to also notify the specific user.

cryptearth · 2024-09-05 06:26:38

uhm - I could be wrong - but at least kde and gnome already provide proper energy management to do exactky this - but I'm not sure about other setups or what happens if the screen locks utself due to inactivity
anyway - using a minutely cronjob looks like a bad idea to me in the first place - as it has to be actively run
monitoring the battery level and perform a shutdown should be done event driven by the systems power management - not by a user script

seth · 2024-09-05 06:59:13

See the wiki, not all systems provide charging events - sometimes there's no way around polling the battery (which in the grand scheme of things isn't *that* terrible) and I borderline expect the daemons of the fat DEs to fall back to that strategy.

Jones_Dow · 2024-09-05 11:17:10

To clarify, i am using a window manager (Dk), so i have to set up the power management myself. It is also a good way to delve deeper into the understanding and functionalities of Arch. :-)

In case i move forward with a script, how would i call the the script correctly with a cronjob? what would be the best file location?

A test script i use runs when i set up the cronjob without sudo :

*/1 * * * * /home/rainer/.local/bin/Test.sh

but when i use sudo crontab, the script won't execute

V1del · 2024-09-05 12:02:31

Your originally said it executed when doing a plain file write? Assuming it executes see all of the other comments about correctly setting up the environment for notify-send to work when invoked from a root context. Generally speaking scripts/files in your home dir are likely to lack execute permissions for "other" which you'd have to give to the script if it's really not "executed" conversely you probably should put a script intended to be executed "globally"/by root in a more system relevant directory rather than your user home.

Now that we know more about your goals, I strongly suggest you look at the link seth provided, because chances are you don't actually need or want a cronjob for something that can be more accurately handled via udev events.

Jones_Dow · 2024-09-05 20:55:34

Hi guys ... very many thanks for all of your clarifying inputs. Especially for the error analysis and the variety of possible solutions. I could make it work with a script and a cronjob, but i will still try the udev rules .... probably none of you is mad that i didn't implement them immediately, but i will definitely work on it. I have never used them, but the suggestion is very interesting and i will take the chance to learn and implement something new and efficient. And with the discussion here i have learned a lot about the correct use of cronjobs and crontabs. And for next time i will also fomulate better my query and problems. The xy analysis is definitely worth keeping in mind.

cryptearth · 2024-09-06 04:46:36

well - "mad" is the wrong word
for me: I have experience in development for 15+ years now - so I've read a lot of beginners questions - and aside from them repeating (because most beginners use google only to search for a forum to post thier question instead of usibg it to search for answers to thier question) many came up with "a possible" solution and wanted to get it working no matter several experienced users tried to point out there're other and often better solutions.
So when I read "I have a script but need to add root to execute shutdown" I just thought: "No, you don't.". The other thing was about the change of the home path "~": It's always the home of the current user. When you edit roots crontab "~" becomes roots home. From what it looks you seemed confused because you likely thought that "~" will still point to your users home in /home/user.
Overall here're several base concepts at play that hint twards "You're doing it all wrong".

Another thing I also needed years to learn: Polling should be one of the last options as a fallback - use events whenever possible. For a simple "keep an eye on the battery charge" this may sound overkill - but when you scale it up to a couple 100 users all hogging only a few shared database connections you run into timeouts all the time (currently we have such a problem at work with our support system which was migrated to jira). Using active polls as right now grinds this system to a halt. One solution: Use a request queue and a response event bus: The clients add thier requests to the queue and the backend notifies them with a response event when the result is ready.

Back to your battery monitoring: Don't bother to keep asking the battery for its charge - but request it to actively inform you about changes (if possible, of course). You need to bother when it's over 25% - so for 26%-100% you waste charge be keep running code to ask for it. Don't! Tell the system: "Inform me when the charge drops below 25%, please.".

As for run shutdown without root/sudo: I'm not sure how it works - but as I can do it on my kde without having to enter my password the has to be some way. Someone might know.

Arch Linux

#1 2024-09-04 13:42:55

Cronjob not running with sudo

#2 2024-09-04 14:22:52

Re: Cronjob not running with sudo

#3 2024-09-04 16:10:57

Re: Cronjob not running with sudo

#4 2024-09-04 16:15:51

Re: Cronjob not running with sudo

#5 2024-09-04 16:19:22

Re: Cronjob not running with sudo

#6 2024-09-04 16:35:40

Re: Cronjob not running with sudo

#7 2024-09-04 16:39:17

Re: Cronjob not running with sudo

#8 2024-09-04 16:42:27

Re: Cronjob not running with sudo

#9 2024-09-04 17:27:00

Re: Cronjob not running with sudo

#10 2024-09-04 18:37:07

Re: Cronjob not running with sudo

#11 2024-09-04 20:04:57

Re: Cronjob not running with sudo

#12 2024-09-04 20:06:33

Re: Cronjob not running with sudo

#13 2024-09-05 00:27:17

Re: Cronjob not running with sudo

#14 2024-09-05 06:13:29

Re: Cronjob not running with sudo

#15 2024-09-05 06:26:38

Re: Cronjob not running with sudo

#16 2024-09-05 06:59:13

Re: Cronjob not running with sudo

#17 2024-09-05 11:17:10

Re: Cronjob not running with sudo

#18 2024-09-05 12:02:31

Re: Cronjob not running with sudo

#19 2024-09-05 20:55:34

Re: Cronjob not running with sudo

#20 2024-09-06 04:46:36

Re: Cronjob not running with sudo

Board footer