@keanecs94 What do you see if you enter which python, which python3, and which python3.7 ? Sometimes the pathing / links don’t always resolve the way I expect them to, it’d be helpful to see how your system is reaching “python”.
Also, if you have tried uninstalling any other versions of python or pip; that can break other parts of the EPIC software – they can be recovered by doing a system restore, but I’d definitely suggest that you do a system backup before you delete anything via SSH.
I haven’t done any uninstalling, I just installed python3.7 along with the rest.
Have you tried your @reboot cron using that last path to point to the exact python3.7 binary you need to run?
I guess I have not, let me try it.
That worked great! Thanks a lot
Awsome!
Cron is really picky about having exact pathing.
Glad we got there in the end.
Thanks for coming back and letting us know - super helpful to close the loop.
Hey! I’m back. Last time, we were able to figure out path naming issues. However, I was just running my python file every minute, and that was working. Now I have another situation that doesn’t allow me to run the script every minute. I can only run it at reboot (otherwise, new comm handles are opened every minute and they eventually run out, breaking the connection between the scratchpad and my PAC Control). However, the @reboot command does not appear to be working. I commented out the crontab line that made it run every minute, and now it doesn’t run at all, at startup or restart. Any ideas why that may not work? I’ve already found some linux forums suggesting I add a 60 second sleep period first before running the python script, but that didn’t work.
Are you able to share your crontab, either as a screenshot or text that you are using?
@torchard and I have beat on this pretty hard on our end and can not get it to fail.
@reboot works every time, with or without the sleep our test python app run just fine.
BTW, putting a space in Linux file names breaks best practices:
To prevent running into problems with your file paths on your site, we recommend following the best practices for file naming. See the below:
But that said, we tested a space in the file name and fully pathed out with quotes still worked in cron.
I guess we have the following questions:
What happens when you run the script from the console (and not back-grounding it)?
How do you know the script is not working?
How do you know the script is working?
Yes, I agree that’s probably not best practice. I’m not a heavy linux user. That aside, here are my answers to your questions.
When I run the script, it outputs my print statements to the terminal every few seconds, as programmed.
I know it’s not working because when I have the job running each minute, as in the commented code, I am able to send inputs (modbus register information) to my controller and my outputs are updated. That is how the script would behave if it were running. But when I comment the code out and restart the controller, my inputs are not received or turned into updated outputs.
Another note is I have tested the use of specific dates and times for starting the script. I selected a time on crontab just a few minutes into the future. I restarted the controller and did nothing to it, but at that time I selected the code started running again. That is why I feel it’s a reboot-specific problem.
Came across some issues when experimenting with this. It seems as soon as I add a “@reboot” entry and reboot the system the whole crontab file gets overwritten by repeated “^@” (some Unix null character?) Running periodic cron jobs works just fine and will persist during reboot. I add them using crontab -e and use the vim editor just as I would otherwise. I’ve never encoutered this issue on any previous Linux system I’ve used
Welcome to the forums Philip.
Something is going on with the way the cron is being edited. @torchard and I (and many many other customers) have been using this method without issue.
Perhaps add nano and try editing it with that?
See this post on how to use nano vs vim as the editor:
Thanks for the quick response! I have tried using nano with no success unforunately.
After many tries with vim I did however manage to get it working for a while, using:
:set encoding=utf-8
:set nobomb
:wq
So perhaps its some sort of encoding error?
I had a simple script that would just echo a string to a file on reboot that worked kind of fine now. Although it took around a minute after I’ve gained control of the system after rebbot for it to execute the script, which is a behaviour I’ve never seen on my other Linux machines.
I then changed it to run another script on reboot, saved it using the encoding mentioned above. But now it’s back to breaking the crontab again. It seems very wierd that I can get it working sometimes so I will do some more testing and see if there is a way which I can replicate it to always run the @reboot cron job.
I’ve also noticed that when this issue occurs every character in the crontab is replaced by exactly one instance of “^@”
Any other ideas of what could be going wrong here?
Now that you expand it some more, I think I have seen something like that on a Raspberry Pi… What shell program are you using? The latest version of PuTTY?
ie, it was the editor, not the device…
Interesting! I’ve only tried this using the default ssh client for Windows 10, which is OpenSSH I think?
Update on this issue: I think I’ve managed to solve it by having a script writing the crontab file instead of doing it manually, hopefully this way works moving forward without corrupting the crontab file.
Is there some documentation for the specific Linux distro the Groov Epic is running? I’ve tried to find info on it but haven’t found much.
The flavor of Linux is Debian, so you can start there. We take the Debian kernel and use Yocto to build the drivers etc needed for the groov hardware.
Can you flesh out the core of that question?
Sorry I’m a bit new to working with configuring Linux systems so I’m still trying to figure out what to ask etc. But for example, since I’ve used Ubuntu previously I’ve used the “service” command to manage Linux services. But in your distro it’s not used, and systemctl is not used either. So I was looking for some information regarding if you used some other way of mainting Linux services, something that may have been written in a documentation of some sort. If that question makes sense.
EDIT: Basically I wonder what core Linux functionality exists in your distro
Ok, Yes, that makes sense now.
No, nothing documented as shell is an option and not something we can support since it gives you root access and there are volumes upon volumes of Linux wisdom written in paper and on the Internet, it would be pointless for us to duplicate all that.
The only support is here in the forums (and only to the level of ‘the best the community can’).
Since you came in 1/2 way through the @reboot thread, it might help to perhaps start a new thread and help the community know what you are up to, what your plan is, what your goals are for running shell on the groov. I don’t think you have even mentioned if you are using EPIC or RIO or both for example.
Once we have a better bigger picture, we can perhaps brain storm the best way (not always shell given the vast tool set on the groov platform) forward.
