Adding it to rc.local should be all you need.
The chmod 755 just means everyone can read and execute the script, while
the owner can write it as well. The chmod +x line just makes sure it's
executable, the 755 line does that for you.
On the other hand, this is the permissions thing I was talking about in
the other post.
All files (including executables, whether they be programs or scripts)
should have the permissions they need, and nothing more. This means that
if root is the only user that will ever execute a program, then it
should be permissions 500 and owned by root.
This means root can read and execute the program, but even root can't
write to the file.
If pi needs to execute a program, and you have another group where you
keep startup type things, then pi and that startup group should be the
only ones who can execute/read that file. It's a bit tough to transfer
the concept of least access permissions, but it's critical for security
purposes, and honestly, this is something even mainstream distributions
constantly get wrong, not because they don't know what they're doing,
but because they're trying to make things easier for their users. If
all programs/directories/libraries/configuration files (you get the
idea) were all given the least permissions, then they'd always be
getting support reports about user bob who has no reason to look in the
/etc/conf.d directory being unable to list the files in such a directory.
So, they simply throw up their hands, and provide read access to
practically the entire world, when in reality, that's rarely the best
policy.
But, you didn't want to read all of that.
To make a long story short.
permissions 755 should be more than adequate to execute your script upon
startup.
The thing you need to be aware of though, is the possibility that your
program may not be intended for noninteractive use.
It's possible that your command requires a full-blown interactive
environment in order to act properly.
It isn't likely that's your problem, but it's a possibility.
It's more likely that the owner of the script doesn't belong to the
group that is allowed to use the audio device, and so when not
interactive, and inheriting the permissions of the user running the
script, the script isn't allowed to execute certain commands, because
the group who owns the script doesn't have permission for the required
resource.
It's equally likely that the script is loading before the sound device
is initialized, so it runs perfectly well, but it just doesn't produce
any output.
Add a touch command to the script, and have it touch a file in your home
directory every time it runs, then after you reboot the pi, you can
check the timestamp on the file, to see if it actually executed during
startup or not.
That's one of the simplest ways to determine if a script ran properly.
You could also add lines to some log file or other, but just make sure
that permissions are set to allow writing to said log file.
These are common troubleshooting tricks for many system administrators.
It's a simple thing, but easy to overlook while trying to get things
working.
On 4/17/2021 11:56 PM, Glenn K0LNY wrote:
Hi,===========================================================
I still haven't gotten my bash script to run on startup.
It runs if I run the script in the CLI.
I've read some pages that say make it executable with chmod 755 and some say
use chmod +x
I even saw one that said to use chmod a +x
Anyway, I've put it in rc.local and in crontab with paths.
In crontab I used @reboot before the path and script file.
I've looked at the adding it to the service file, and that seems more
complicated than it should be.
Any help appreciated.
Glenn
===========================================================
The raspberry-vi mailing list
Archives: //www.freelists.org/archives/raspberry-vi
Administrative contact: <mike.ray@xxxxxxxxxxxxxx>
-----------------------------------------------------------
Raspberry Pi and the Raspberry Pi logo are trademarks of the Raspberry Pi
Foundation.
This list is not affiliated to the Raspberry Pi Foundation and the views and
attitudes expressed by the subscribers to this list do not reflect those of
the Foundation.
Mike Ray, list creator, January 2013
