What you did awhile back may no longer work today.
About 3 years ago, like many other distros openSUSE began replacing the SysVinit system (ie base on init files) with systemd. Only some init functions might still work but as time goes on, they are all being replaced with systemd commands.
There are various ways to invoke your script automatically…
If your script runs best after User login, particularly if it relies on some User configuration completed… You can generally hook those into the Desktop configuration files. Of course, this requires foreknowledge of the running Desktop.
If your script runs best during system boot, then you can determine when during the boot, find the systemd Unit file that manages that service startup and add your script.
Create a systemd Unit file that invokes your script. When you create your own Unit files, you generally inspect what already exists, find something that is similar to what you want, copy and rename it to /etc/systemd/user/
I personally prefer that last option because it keeps your custom script separate from everything else.
Note that you should never edit original systemd Unit files, you should always copy anything you want to modify to /etc/systemd/systemd/ or /etc/systemd/user/
If the system finds a Unit file with the same name in these locations, it will automatically over-ride the original files.
This way you minimize borking your system with bad changes, and can always undo changes by simply removing your Unit file thereby re-activating the original file.
You’ll find this and much more reading about systemd Unit files.
The real question here is; why do you need to do this?
Sounds like ALSA is not loading the right module for your sound card, in this case you should fix the issue by creating a .conf file that contains the suitable module (or change the options, or blacklist an offending module) instead of using a hack like this.
I missed that you’re running some old, likely unsupported version of openSUSE.
Which openSUSE version are you running?
First launch alsactl manually to make sure it works.
Then, consider if there is any benefit to running automatically, from its description alsactl only gives you access to advanced functions. Do you know the exact command to do whatever you want since simply launching isn’t likely enough to do anything?
As I described, you don’t just place a script in /etc/systemd/user/, Unit files are configuration files, not executables. Unit files are are read and contain commands like ExecStart to execute scripts and binaries.
You should browse existing Unit files like those you will find at /usr/lib/systemd/system/, pick one that you like and use it as a template by copying it to /etc/systemd/user/, rename it to make it your own and modify the file contents to execute your script.
The forums software require you to specify the openSUSE version you use. When you have to choose OTHER VERSION because your run an unsupported one, we of course still (or even more urgently) want to know which version!!
I do intend to do a full upgrade to LEAP 42.3 KDE eventually, but it is currently at a testing phase for me right now. Basically I choose not to use an OS unless I have tested it for at least 3 months. When I tried 42.1 I HATED it. 42.2 I really liked it but it was unstable and eventually died at one of the worst possible time. I am buying a new laptop to experiment with 42.3 and Windows 10, but for the time being, 13.2 is what I will be using for some period of time.
Of course that functions as expected, but we are discussing here the use of sudo in a background environment. More precise, one of the scripts run at boot into a certain runlevel. Apart from what you call no-op and we nonsense, which can of course be repeated and nested at will, there is the interactive action of sudo to ask for the password (as you show above).
sudo would just as well work in a background script run as root (which is the case for those startup scripts). Of course it would be unnecessary then (unless you want to switch to a different user than root), but it would “work”.
If a password is needed (which isn’t the case if run as root in the first place), it won’t work, yes.
Although that could be “workarounded” via /etc/sudoers…