[Icecast] <on-connect> / <on-disconnect> not working

[Jack Elliott]

Thank you, Petr!

Yes, error.log is not very helpful. With loglevel set to 4 (debug) I 
find that the server does claim to run the commands, but there is 
nothing to indicate what the problem might be:

[2022-07-14  13:05:13] DBUG source/source_run_script Starting command /home/my_username/bin/email_onconnect.sh
[2022-07-14  13:05:13] DBUG source/source_update_settings disconnect script "/home/my_username/bin/email_ondisconnect.sh"

This with Icecast 2.4.0 -- I am waiting for some help with a question I 
have posted in this mailing list to confirm I have the right repo 
selected before I attempt upgrading Icecast. It is a running, 
in-operation service for our radio station and I don't want to break 
anything.

-- 
Jack Elliott
Director of Classical Music Programming
KPOV 88.9 FM
High Desert Community Radio
Bend, OR

On 7/14/22 09:18, Petr Pisar wrote:
> V Thu, Jul 14, 2022 at 08:16:03AM -0700, Jack Elliott napsal(a):
>> Hi,
>>
>> Icecast server 2.4.0 running on Linux.
>>
> Could you try upgrading Icecast? The latest version is 2.4.4 and there were
> some fixes in between.
>
>> I have a couple of shell scripts that send emails on connect and on
>> disconnect. From the command line they work, but when called from
>> icecast they do not.
> [...]
>> I'd like to get these functions working . . . ideas?
>>
> A problem is that Icecast does not log a failed execution of the scripts.
> Neither an exit code of the finished script.
>
> It can only log some fork errors and file permissions before executing them.
> And an attempt to execute a script is logged only if Icecast log level is set
> to debug:
>
> static void _run_script (event_exec_t *self, event_t *event) {
>      pid_t pid, external_pid;
>
>      /* do a fork twice so that the command has init as parent */
>      external_pid = fork();
>      switch (external_pid)
>      {
>          case 0:
>              switch (pid = fork ())
>              {
>                  case -1:
>                      ICECAST_LOG_ERROR("Unable to fork %s (%s)", self->executable, strerror (errno));
>                      break;
>                  case 0:  /* child */
>                      if (access(self->executable, R_OK|X_OK) != 0) {
>                          ICECAST_LOG_ERROR("Unable to run command %s (%s)", self->executable, strerror(errno));
>                          exit(1);
>                      }
>                      ICECAST_LOG_DEBUG("Starting command %s", self->executable);
>                      __setup_empty_script_environment(self, event);
>                      execv(self->executable, __setup_argv(self, event));
>                      exit(1);
>                  default: /* parent */
>                      break;
>              }
>              exit (0);
>          case -1:
>              ICECAST_LOG_ERROR("Unable to fork %s", strerror (errno));
>              break;
>          default: /* parent */
>              waitpid (external_pid, NULL, 0);
>              break;
>      }
> }
>
> You can use "strace" tool to check whether the scripts are actually executed.
> Something like "strace -fq -e execve -p PID_OF_THE_RUNNING_SERVER".
>
> The code is pretty terrible. access() does not answer whether a process can
> exucute a program. Also execv() can fail for various reasons: Different
> effective UID/GID, missing capabilities, violation of SELinux policy. And then
> there can be problems with the executed program itself, like a wrong magic
> number, unsupported architecture, a missing dynamic library, bad script
> interpreter etc.
>
> I recommend Icecast developers to remove the access() call and instead log
> errno after a failed execve. Also logging a status code of the terminated
> executable returned by waitpid() would be helpful.
>
> -- Petr
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20220714/d6f6883c/attachment.htm>