Linux Wordpress App Service - Sending Supervisor STDOUT to Log Stream

Question

Linux Wordpress App Service - Sending Supervisor STDOUT to Log Stream

spurro 60

Stack: Wordpress

container image: mcr.microsoft.com/appsvc/wordpress-debian-php:8.3

I have some startup commands executing from Startup.sh, and I am sending all output to /dev/stdout and dev/stderr

Supervisor is running Startup.sh on the app service correctly, but the output never shows up in the Log Stream. I know the output exists, because I can see my logging statements in files that appear in /tmp/ such as:

/tmp/post-startup-script-stdout---supervisor-_di1pcyn.log

How do I get stdout/stderr to appear in the log stream during app service startup?

Bhargavi Naragani 5,270 Reputation points Microsoft External Staff Moderator

2025-06-06T13:35:06.55+00:00
Hi @spurro,

Supervisor captures your script’s output and stores it in /tmp/…log files but doesn't forward anything to the container's main stdout/stderr. Azure App Service only picks up logs from the container's main stdout & stderr, or from .log files written under /home/LogFiles.

You need to configure Supervisor to forward logs to stdout/stderr, not file paths in /tmp.
Example Supervisor config (/etc/supervisor/conf.d/startup.conf):

[program:startup] command=/home/startup.sh autostart=true autorestart=true stdout_logfile=/dev/stdout stdout_logfile_maxbytes=0 stderr_logfile=/dev/stderr stderr_logfile_maxbytes=0

stdout_logfile=/dev/stdout: Pipes output to the container log stream.

stdout_logfile_maxbytes=0: Prevents log rotation (required when using stdout device).

Same for stderr.

Place this configuration in /etc/supervisor/conf.d/startup.conf or modify your existing supervisord.conf file if one is already present.

Could you please confirm if you have enabled Application logging as mentioned in the doc: https://learn.microsoft.com/en-us/azure/app-service/troubleshoot-diagnostic-logs#enable-application-logging-linuxcontainer

Also, there are two ways of managing log files in container. Docker best practices suggest that all logs be redirected to the STDOUT. This allows commands like docker logs or az webapp log.

Refer to this doc link might be helpful: https://learn.microsoft.com/en-us/azure/app-service/configure-custom-container?pivots=container-linux#access-diagnostic-logs-1

https://learn.microsoft.com/en-us/azure/app-service/troubleshoot-diagnostic-logs#access-log-files

Hope this is helpful, if you have any further concerns or queries, please feel free to reach out to us.
spurro 60 Reputation points

2025-06-06T14:52:44.1666667+00:00

Hi @Bhargavi Naragani this is amazing information, thank you!

My only issue is this:

I have made the edits and placed the file in /etc/supervisor/conf.d but that file is gone when the service restarts.

I have also edited /etc/supervisord.conf directly, which contains all of the [program] sections already. However my changes are not persisted on app restart.

I could use the startup command to copy my modified config from /home/ to /etc/, however that seems to defeat the purpose, since the startup command runs after supervisor has already started
Bhargavi Naragani 5,270 Reputation points Microsoft External Staff Moderator

2025-06-06T15:23:37.4233333+00:00
Hi @spurro,

You're absolutely right about the issue with Supervisor config files not persisting across restarts. This behavior is expected on Azure App Service for Linux, where the underlying container is ephemeral: meaning any changes made to /etc or other system directories are wiped out on every restart or scale-out.

Azure App Service uses a read-only base image for the container (in your case, mcr.microsoft.com/appsvc/wordpress-debian-php:8.3), and it gets reinitialized every time your app restarts. So, edits to /etc/supervisor/conf.d/ or /etc/supervisord.conf are temporary, they won’t survive container restarts, scale-outs, or re-deployments.

The best way to persist your supervisor config changes is to:

Keep your custom config file in /home/, the /home directory has persisted across restarts.

Use the startup.sh script to copy the config at container start:
#!/bin/bash # Copy custom supervisor config to /etc at runtime cp /home/supervisord.conf /etc/supervisord.conf # Optionally restart Supervisor (if needed, or run your own processes) supervisord -c /etc/supervisord.conf
This ensures the Supervisor uses your config each time the container starts and yes, it feels like a workaround, but this is the accepted method in containerized environments where you don't control the base image directly.

If you're frequently customizing Supervisor behavior, consider building a custom Docker image based on the official WordPress image, where you bake in your supervisord.conf directly and no need to copy configs at runtime, fully version-controlled and repeatable Use a custom container with App Service

https://learn.microsoft.com/en-us/azure/app-service/overview#storage
spurro 60 Reputation points

2025-06-08T23:57:54.97+00:00
@Bhargavi Naragani thank you! This gave me enough information to figure out a solution. For anyone else who happens to come across this:

I made a custom supervisord.conf file for Startup.sh to copy to /etc/supervisord.conf as noted above.

"eform-update" is a new program entry I added to my custom supervisord.conf, after post-startup-script

[program:eform-update] command=bash /home/dev/eformupdate.sh autostart=false autorestart=false startretries=0 stdout_logfile=/dev/stdout stdout_logfile_maxbytes=0 stderr_logfile=/dev/stderr stderr_logfile_maxbytes=0

I set autostart=false and autorestart=false, along with the output redirections.

The goal is for Startup.sh to update the supervisor config, reload the config without restarting, then starting my process which requires the logging output.

In Startup.sh:

cp /home/dev/supervisord.conf /etc/supervisord.conf supervisorctl update supervisorctl start eform-update

The supervisor command "update" will update the config without fully restarting supervisor and allow any processes started after to use this new configuration. I then manually start my new process.

Accepted answer

0 additional answers

Your answer

Bhargavi Naragani 5,270 Reputation points Microsoft External Staff Moderator

2025-06-06T13:35:06.55+00:00

Hi @spurro,

Supervisor captures your script’s output and stores it in /tmp/…log files but doesn't forward anything to the container's main stdout/stderr. Azure App Service only picks up logs from the container's main stdout & stderr, or from .log files written under /home/LogFiles.

You need to configure Supervisor to forward logs to stdout/stderr, not file paths in /tmp.
Example Supervisor config (/etc/supervisor/conf.d/startup.conf):

[program:startup] command=/home/startup.sh autostart=true autorestart=true stdout_logfile=/dev/stdout stdout_logfile_maxbytes=0 stderr_logfile=/dev/stderr stderr_logfile_maxbytes=0

stdout_logfile=/dev/stdout: Pipes output to the container log stream.

stdout_logfile_maxbytes=0: Prevents log rotation (required when using stdout device).

Same for stderr.

Place this configuration in /etc/supervisor/conf.d/startup.conf or modify your existing supervisord.conf file if one is already present.

Could you please confirm if you have enabled Application logging as mentioned in the doc: https://learn.microsoft.com/en-us/azure/app-service/troubleshoot-diagnostic-logs#enable-application-logging-linuxcontainer

Also, there are two ways of managing log files in container. Docker best practices suggest that all logs be redirected to the STDOUT. This allows commands like docker logs or az webapp log.

Refer to this doc link might be helpful: https://learn.microsoft.com/en-us/azure/app-service/configure-custom-container?pivots=container-linux#access-diagnostic-logs-1

https://learn.microsoft.com/en-us/azure/app-service/troubleshoot-diagnostic-logs#access-log-files

Hope this is helpful, if you have any further concerns or queries, please feel free to reach out to us.
spurro 60 Reputation points

2025-06-06T14:52:44.1666667+00:00

Hi @Bhargavi Naragani this is amazing information, thank you!

My only issue is this:

I have made the edits and placed the file in /etc/supervisor/conf.d but that file is gone when the service restarts.

I have also edited /etc/supervisord.conf directly, which contains all of the [program] sections already. However my changes are not persisted on app restart.

I could use the startup command to copy my modified config from /home/ to /etc/, however that seems to defeat the purpose, since the startup command runs after supervisor has already started
Bhargavi Naragani 5,270 Reputation points Microsoft External Staff Moderator

2025-06-06T15:23:37.4233333+00:00

Hi @spurro,

You're absolutely right about the issue with Supervisor config files not persisting across restarts. This behavior is expected on Azure App Service for Linux, where the underlying container is ephemeral: meaning any changes made to /etc or other system directories are wiped out on every restart or scale-out.

Azure App Service uses a read-only base image for the container (in your case, mcr.microsoft.com/appsvc/wordpress-debian-php:8.3), and it gets reinitialized every time your app restarts. So, edits to /etc/supervisor/conf.d/ or /etc/supervisord.conf are temporary, they won’t survive container restarts, scale-outs, or re-deployments.

The best way to persist your supervisor config changes is to:

Keep your custom config file in /home/, the /home directory has persisted across restarts.

Use the startup.sh script to copy the config at container start:
#!/bin/bash # Copy custom supervisor config to /etc at runtime cp /home/supervisord.conf /etc/supervisord.conf # Optionally restart Supervisor (if needed, or run your own processes) supervisord -c /etc/supervisord.conf
This ensures the Supervisor uses your config each time the container starts and yes, it feels like a workaround, but this is the accepted method in containerized environments where you don't control the base image directly.

If you're frequently customizing Supervisor behavior, consider building a custom Docker image based on the official WordPress image, where you bake in your supervisord.conf directly and no need to copy configs at runtime, fully version-controlled and repeatable Use a custom container with App Service

https://learn.microsoft.com/en-us/azure/app-service/overview#storage
spurro 60 Reputation points

2025-06-08T23:57:54.97+00:00

@Bhargavi Naragani thank you! This gave me enough information to figure out a solution. For anyone else who happens to come across this:

I made a custom supervisord.conf file for Startup.sh to copy to /etc/supervisord.conf as noted above.

"eform-update" is a new program entry I added to my custom supervisord.conf, after post-startup-script

[program:eform-update] command=bash /home/dev/eformupdate.sh autostart=false autorestart=false startretries=0 stdout_logfile=/dev/stdout stdout_logfile_maxbytes=0 stderr_logfile=/dev/stderr stderr_logfile_maxbytes=0

I set autostart=false and autorestart=false, along with the output redirections.

The goal is for Startup.sh to update the supervisor config, reload the config without restarting, then starting my process which requires the logging output.

In Startup.sh:

cp /home/dev/supervisord.conf /etc/supervisord.conf supervisorctl update supervisorctl start eform-update

The supervisor command "update" will update the config without fully restarting supervisor and allow any processes started after to use this new configuration. I then manually start my new process.

Answer 1

Hi @spurro,

I'm glad that you were able to resolve your issue and thank you for posting your solution so that others experiencing the same thing can easily reference this!

Since the Microsoft Q&A community has a policy that "The question author cannot accept their own answer. They can only accept answers by others ", I'll repost your solution in case you'd like to "Accept " the answer.

Issue:

Linux Wordpress App Service - Sending Supervisor STDOUT to Log Stream

Solution:

thank you! This gave me enough information to figure out a solution. For anyone else who happens to come across this:

I made a custom supervisord.conf file for Startup.sh to copy to /etc/supervisord.conf as noted above.

"eform-update" is a new program entry I added to my custom supervisord.conf, after post-startup-script

[program:eform-update]
command=bash /home/dev/eformupdate.sh
autostart=false
autorestart=false
startretries=0
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0

I set autostart=false and autorestart=false, along with the output redirections.

The goal is for Startup.sh to update the supervisor config, reload the config without restarting, then starting my process which requires the logging output.

In Startup.sh:

cp /home/dev/supervisord.conf /etc/supervisord.conf
supervisorctl update
supervisorctl start eform-update

The supervisor command "update" will update the config without fully restarting supervisor and allow any processes started after to use this new configuration. I then manually start my new process.

Please click Accept Answer and kindly upvote it so that other people who faces similar issue may get benefitted from it.

Share via

Linux Wordpress App Service - Sending Supervisor STDOUT to Log Stream

0 additional answers

Your answer