Nginx-plus ingress controller doesnt create symbolic link for access.log for stdout

[reddyblokesh]

Describe the bug Nginx-plus ingress controller doesnt create symbolic link for access.log -> /dev/stdout To Reproduce Steps to reproduce the behavior:

1. Deploy nginx plus ingress controller using helm charts for version 3.4.3
2. View logs on k logs -f
3. no access logs captured rather redirected to /var/log/nginx/access.log

Expected behavior should be able to redirect to stdout and in k logs -f

Your environment

• Version of the Ingress Controller - 3.4.3/1.25.3-nginx-plus-r31-p1
• Version of Kubernetes: Client Version: v1.28.4 Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3 Server Version: v1.26.13
• Kubernetes platform : selhosted k8 fabric
• Using NGINX or NGINX Plus : Nginx plus ingress controller

Additional context nginx config has access.log configured: grep access.log /etc/nginx/nginx.conf

access_log  /dev/stdout  main;
access_log syslog:server=unix:/var/lib/nginx/nginx-syslog.sock,nohostname,tag=nginx response_time;
access_log  /dev/stdout  stream-main;

Note: same helmchart and same version(3.4.3) works for nginx ingress controller (opensource) but not for nginx plus ingress controller.

[github-actions[bot]]

Hi @reddyblokesh thanks for reporting!

Be sure to check out the docs and the Contributing Guidelines while you wait for a human to take a look at this :slightly_smiling_face:

Cheers!

[oseoin]

Hi @reddyblokesh, are you using Ingress or custom resources? I haven't been able to reproduce on 3.4.3, I can see that /var/log/nginx/access.log gets created but it remains empty and logs are correctly sent to stdout. Could you also try running grep access.log /etc/nginx/conf.d/* in case the log configuration is coming from another file? Thanks!

[reddyblokesh]

1. grep access.log /etc/nginx/conf.d/* access_log /var/log/nginx/access.log main; access_log on;

2. grep stdout /etc/nginx/nginx.conf access_log /dev/stdout main; access_log /dev/stdout stream-main;

3. /var/log/nginx/access.log gets created but doesnt create symbolic link to /dev/stdout : ls -la /var/log/nginx/ : total 36 drwxrwxr-x. 1 nginx root 24 Feb 19 13:41 . drwxr-xr-x. 1 root root 19 Feb 19 13:41 .. -rw-rw----. 1 nginx root 34935 May 17 10:38 access.log -rw-rw----. 1 nginx root 0 Feb 19 13:41 error.log

[reddyblokesh]

to reproduce this we tried to upgrade nginx ingress controller to nginx plus in another namespace running a different app in backend and we faced the same issue even there. so it looks like a bug ? can you please confirm or should we build a custom image but adding a symlink similar to what we have in docker-mn ?

[oseoin]

@reddyblokesh just to understand your use-case are you using Ingress or VirtualServer (custom resources), and are you using the snippets feature? If you are not using snippets to add access_log /var/log/nginx/access.log main; access_log on; then it could be a bug with our Plus templates.

We currently do not manually add symlinks, but they are added upstream in the OSS container that we build from, so we can investigate adding the links to our Plus images.

[reddyblokesh]

• we are adding as part of values.yaml in ingress template :

config: entries: ingress-template: | access_log /var/log/nginx/access.log main;

• so i doubt its not creating symlinks as part of oss container !!
• do let me its best to create custom image with symlinks added or do you want to investigate this more ?

[oseoin]

@reddyblokesh to clarify:

• Our OSS image is based on the official NGINX image: https://hub.docker.com/_/nginx, which creates a symlink
• Our Plus image is built from the Debian image, which we install NGINX Plus into, and we do not create a symlink.

For now, I recommend you either build a custom image with the symlink, or change your example above to use /dev/stdout instead of /var/log/nginx/access.log. We will investigate adding the symlinks for a future release to better align the OSS and Plus images.

Is there a reason that you use /var/log/nginx/access.log instead of /dev/stdout? Knowing the use-case will help prioritise the work to add the symlinks.

[pdabelf5]

@jasonwilliams14 fyi

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 10 days with no activity.