Permission Denied on startup with systemd script about cherrymusic

[devsnd]

Can you verify using `ps` that the server actually runs as the pi user? If thats not the case you could try starting the server using `su pi -c cherrymusic` as startup parameter in the init script. My guess is that whoever built that init script just has the files world readable (e.g. chmod 777). Thats the beauty and the beast of FLOSS ;)

…

On Thu, Jul 4, 2019, 20:17 nebbishOne ***@***.***> wrote: Hello. I am setting up a new Ras Pi 4 today. I am running it with Raspbian Buster (latest version). I installed the pre-reqs for CherryMusic, got the master branch into /opt/cherrymusic just fine. When I run it from the terminal, it works fine. I was able to point it at my music folder and it runs then in a browser just great. Next, I need it to start after a reboot. I first tried the crontab method, but that failed. On reboot, it would log an error saying the basedir path was invalid / must exist. It does, since it works from the terminal. Now I'm trying to get the init.d script as provided working. I believe I configured the conf file correctly for my system, but on start/restart of the service, that logs this error: Jul 04 12:15:10 sixthpi systemd[1]: Starting LSB: CherryMusic Server Daemon... Jul 04 12:15:10 sixthpi cherrymusic[958]: /etc/init.d/cherrymusic: 17: /etc/init.d/cherrymusic: /opt/cherrymusic: Permission denied Jul 04 12:15:10 sixthpi systemd[1]: Started LSB: CherryMusic Server Daemon. I've done 'chown' for my Pi user on the /opt/cherrymusic folder, and I have this in the init.d script now: PATH=/sbin:/usr/sbin:/bin:/usr/bin DESC="CherryMusic" NAME=cherrymusic DIR= /opt/cherrymusic DAEMON=$DIR/cherrymusic PIDFILE=/var/run/$NAME.pid SCRIPTNAME=/etc/init.d/$NAME PYTHON= /usr/bin/python # Permissions USER=pi GROUP=pi Which makes me thing I am telling it to run the service as the Pi user, no? In any case, thanks for any help resolving this issue. I am stuck and don't know what to try next. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#726?email_source=notifications&email_token=AAPDS6WUE72ELCMCLSGCO33P5Y5EZA5CNFSM4H56H23KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4G5NUKGQ>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPDS6VIYNRROILY65CKT4LP5Y5EZANCNFSM4H56H23A> .

[nebbishOne]

Thanks for the help, but sorry, I'm not sure how to "verify using ps". How would I do that when the cherrymusic program won't start?

In the init.d script, which I found referenced on the wiki here, I do see:

start-stop-daemon --start --background --chdir $DIR --chuid $USER:$GROUP --make-pidfile --pidfile $PIDFILE --quiet --exec $PYTHON $DAEMON --test > /dev/null || return 1
        start-stop-daemon --start --background --chdir $DIR --chuid $USER:$GROUP --make-pidfile --pidfile $PIDFILE --quiet --exec $PYTHON $DAEMON -- $DAEMON_ARGS || return 2

The --chuid $USER:$GROUP part is what made me think it should be running as the Pi $User, but I'm not really clear on how Bash works.

The man page for start-stop-daemon says;

-c, --chuid username|uid[:group|gid] Change to this username/uid before starting the process. You can also specify a group by appending a :, then the group or gid in the same way as you would for the chown(1) command (user:group).

Does that help?

Thanks again. I have used CM for quite a long time now and I'd hate to not get it working now on this new Pi.

[devsnd]

Thanks for the help, but sorry, I'm not sure how to "verify using ps". How would I do that when the cherrymusic program won't start?

You could point CMs basedir to a world readable folder to make it start to check, just to narrow down the problem

[nebbishOne]

Thanks for your help, I mean that, but it's still not working. Today I tried going back to the cron job, using the systemd service you have in the Setup Guide in the wiki and again making the init.d idea work. They all fail and I can't tell why and I'm just done.

I am using the screen approach for now, even though that won't survive a reboot and it's fine. I'll come back to this again someday.

I'll close this issue.