Running command as admin breaks it, and user's crontab runs as admin?

[EnderFlop]

Hello! I'm working on Raspbian. I'm running into an issue where a shell script I want to run crashes if it is run with "sudo". I don't know why, and it's a third party program. All I know is I have to run it without admin. This is easy enough, just bash running the script on my pi account results in it working. However, when I schedule the script to run on reboot, the same error occurs! This is running on the local "crontab -e", not "sudo crontab -e". Anyone know why it crashes when run through crontab? How can I fix it? Thanks!

Here you can see it crashes when run with sudo, and succeeds when run without.

Here is the command I have running in pi's "crontab -e"

And here's the error I get when looking at the failure log after reboot (note, same error as when run with sudo!)

 

[EnderFlop]

Bump

 

[sphen]

I saw the original post but do not have the experience to help. I wonder whether the same happened for others here. If they know the answer, it usually pops up quickly.

I am posting them here in case it helps point you in the right direction, but I am most assuredly the wrong person to help here. This post is an attempt to help you make progress since you bumped the thread. Here were my original thoughts when I first saw your original post with a few things for you to think about. They may not be helpful or related:

• Something with the PATH environment? The PATH variable may be different between the two ways that you are running the command. The sudo version's PATH may not be allowing it to find a file with the information that it needs.
• Could it be other shell environment variables that differ behind the regular and sudo versions of the command?
• Running jobs in different ways may or may not invoke the same dotfiles depending on how they are run. I found this webpage in a quick search that may help:
  
  

  How to Install Dotfiles

  Before installing and configuring dotfiles via using git, some knowledge of it is required. Dotfiles are configuration files and cache storage for some of the

  linuxopsys.com
• The error message is concerning. Why is the code trying to read that "version" property of a variable named "undefined"? That triggers a red flag for me - why is that variable (or whatever it is) named "undefined"?? Maybe add some debug "echo" statements in front of the line with the error command to see the values of important variables and how they differ between the two executions?

-> Can you ask TuxBot? TuxBot is a cool feature here on Linux.org. It responds like a person with AI-generated answers from ChatGPT. To use it well, you may want to type out one or more of the messages from the screenshots. It can't read text from a screenshot.

I hope that helps and it stimulates better suggestions from those with more relevant experience.

 

[wizardfromoz]

@EnderFlop welcome to linux.org

Don't bump please, it is rude.

If someone has an answer, they will contribute.

Good luck.

Chris Turner
wizardfromoz

 

[JasKinasis]

It may just be that the root account doesn't have the config file ~/.config/telebot/telebot.yml?
In bash, ~/ is a shortcut to the current users home directory, which for a normal user would be /home/username/. But if something is running as root, it will resolve to /root/.
So for the script/program to run successfully as the root user, you may need to have a copy of the config at /root/.config/telebot/telebot.yml, possibly?

I don't know why your crontab is running as root though. I'm pretty certain the users crontab runs as the user, not root. The system-wide crontab runs as root.

Another option could be to put a crontab file to /etc/chron.d/ and specify a normal chron job, but add an extra field to specify which user to run as. You should put the extra field between the timing fields and the command to run.
e.g.

1 1 * * *  username /path/to/command

Other than that, I'm out of ideas ATM.

 

[sphen]

sudo by default runs from the current user account keeps its environment with superuser privileges. Some environment variables may be changed or added if you use sudo. I thought about that but did not include it in my response. I thought that the general "environment variable" mention was good enough.

if I want to run in the root shell, I type "sudo su -" first. Then I type the command without "sudo" and it runs in the root account's environment.

(True confession: I am loathe to admit this, but I use "sudo su -" all too often from my admin account out of habit. It's cheating, and I know it.)

 

[vs2-free-users]

Hi,

at the most time its a problem with the enviroment vars like PATH and so on. Check if your script need special enviroment vars to run.

 

[sphen]

Okay, I just ran into a sudo and PATH issue. I have seen it before, but it bit me again just now and it reminded me of this thread.

TL;DR: I found a test case where sudo changes the PATH environment, but it is disguised. I have not figured out what changes it, but it is in the system.

Details:
I have been playing with various Linux desktop distros, including Debian with Cinnamon and MATE desktops. When I type the "shutdown ..." command from my admin account, it says, "bash: Shutdown: command not found". When I type "sudo shutdown ... " next, it finds and runs the shutdown command. See this transcript:

admin@debianexample:~$ # NOTE: This is Debian from an admin account with sudo privileges:
admin@debianexample:~$
admin@debianexample:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
admin@debianexample:~$ sudo echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
admin@debianexample:~$
admin@debianexample:~$ which shutdown
admin@debianexample:~$ sudo which shutdown
/usr/sbin/shutdown
admin@debianexample:~$

I have not taken the time to figure out how /usr/sbin is being added to the "path" when sudo is invoked.

Tested with plain vanilla installations of Debian desktop. I used tasksel during installation to choose "Cinnamon" and "MATE" versions and have not modified anything, really. The sudo path behavior is the same on both.