OnSongChange doesn't work


My config file is empty (for some unknown reason there was no ~/.moc/config before) except for one line:
$ cat config
OnSongChange = "/home/pi/.moc/scripts/NotifyLaptop.sh %a %t %r %d"

Unfortunately the script isn't executed. I can run it manually from command line, so we can be sure there's nothing wrong with it. First I thought it was because I encapsuled the paramters in " ' " (like "NotifyLaptop.sh '%a' '%t' ") but obviously that wasn't the reason. So I tried everything I could imagine... and now I'm here hoping for some help ;)

I'm using moc on Debian (raspberry pi):

$ uname -a
Linux pi 3.6.11+ #518 PREEMPT Fri Aug 2 11:39:53 BST 2013 armv6l GNU/Linux

$ mocp -V
This is : Music On Console
Version : 2.5.0-alpha4
Built : May 19 2012 08:03:31
Compiled with : OSS ALSA JACK DEBUG internet streams resample
Author : Damian Pietras
Homepage : http://moc.daper.net/
E-Mail : daper@daper.net
Copyright : (C) 2003-2011 Damian Pietras and others
License : GNU General Public License, version 2 or later

I assume the permissions are ok:

~/.moc $ ls -lh config
-rw-r--r-- 1 pi pi 68 Aug 5 04:46 config

~/.moc $ ls -lh scripts/NotifyLaptop.sh
-rwxr-xr-x 1 pi pi 434 Aug 5 04:39 scripts/NotifyLaptop.sh

There are no error messages. :/


Possibly you haven't told the system's loader which interpreter to use for this script.

Try adding this line at the very top: #!/bin/bash

Hm no, unfortunately that's not the problem. The file already starts with #!/bin/sh :/

I figured out that nothing is ever executed. Even
OnSongChange = "echo %a >> /home/pi/.moc/scripts/test2.txt"
doesn't work.

The OnSongChange option's command is not run under a shell (which is why you needed a "hash-bang") so redirection won't work.

There is a kernel configuration option which affects this (I think -- the documentation is a little unclear). It's CONFIG_BINFMT_MISC from memory, but unless you have an especially finely tuned kernel it's not likely to be the problem.

Try just running that echo command in a script (complete with "hash-bang") and let us know what happens.


thanks. I tried running the echo command in a script - nothing happened. Then I had the idea to copy the scripts to /tmp/. And suddenly it works. o.O But it doesn't make any sense. The paths in config were correct (I copy&pasted them to try). Also the permissions seem to be okay:

~/.moc/scripts $ ls -alh
total 24K
drwxr-xr-x 2 pi pi 4.0K Aug 6 19:42 .
drwx------ 4 pi pi 4.0K Aug 6 20:05 ..
-rwxr-xr-x 1 pi pi 423 Aug 5 10:20 NotifyLaptop.sh
-rw-r--r-- 1 pi pi 32 Aug 6 19:44 test3.txt
-rwxr-xr-x 1 pi pi 60 Aug 6 19:42 test.sh
-rw-r--r-- 1 pi pi 1.3K Aug 6 20:06 test.txt

mocp runs under the same user:
pi 6485 6.8 2.5 24404 6068 pts/0 S+ 20:05 0:08 mocp
pi 6486 22.2 2.5 60148 6040 ? Ssl 20:05 0:29 mocp

current config (works only with /tmp/...):
#OnSongChange = "/home/pi/.moc/scripts/NotifyLaptop.sh %a %t %r %d"
RepeatSongChange = yes
#OnSongChange = "/home/pi/.moc/scripts/test.sh"
OnSongChange = "/tmp/NotifyLaptop.sh "%a" %t %r %d"

The script currently writes the song info into /home/pi/.moc/scripts/test3.txt. So doesn't seem to be an access problem.
The path is correct:
~/.moc/scripts $ pwd

I'm confused now :o

Ha! It works :)

I noticed that ~/.moc had some unusual permissions set:
drwx------ 4 pi pi 4.0K Aug 6 20:24 .moc
Changing that to "drwxr-xr-x" helped.

I'm also confused by this being a problem since I thought mocp is running as "pi" so it should be able to execute files with execute permission for pi...but maybe I'm just a noob ;)

I can't see why changing those permissions should have resolved the problem either. The directory permissions on my machine are exactly as you had originally on yours and more obvious error would have been raised if MOC was unable to see the contents of the ~/.moc directory. MOC does not change its effective user id and the Linux kernel ignores any set-user-id permissions on scripts run in the way MOC runs them (or says it does, anyway).

As an experiment, try echoing the values of $UID and $EUID from within the script. They should match.

The only other explanation I can offer is that at the times when it failed the filesystem was mounted noexec, but that's most unlikely.