application logging to files not working for php wordpress

[yosefy]

even though we setup as in doc: https://unit.nginx.org/news/2023/unit-1.30.0-released/#application-logging

still php error log goes to main unit.log file

"testsite": {
		"stderr": "/tmp/unit_app.log",
		"stdout": "/tmp/unit_app_error.log",
		"user": "unit",
		"type": "php 7.4",
		"targets": {
			"direct": {
				"root": "/sites/site/"
			},

			"index": {
				"root": "/sites/site/",
				"script": "index.php"
			}
		}
	}

thanks

# unitd --version
unit version: 1.30.0
configured as ./configure --prefix=/usr --statedir=/var/lib/unit --control=unix:/var/run/unit/control.sock --pid=/var/run/unit/unit.pid --log=/var/log/unit/unit.log --tmpdir=/var/tmp --user=unit --group=unit --tests --openssl --njs --modulesdir=/usr/lib64/unit/modules --libdir=/usr/lib64 --cc-opt='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fPIC' --ld-opt='-Wl,-z,relro -Wl,-z,now -pie'

[ac000]

Couple of quick questions

1. Is Unit running as a daemon? I.e without the --no-daemon command line argument.
2. Does the unit user have write access to those log files?

[yosefy]

[Service] Type=simple Environment="UNITD_OPTIONS=--log /var/log/unit/unit.log --pid /var/run/unit/unit.pid " ExecStart=/usr/sbin/unitd $UNITD_OPTIONS --no-daemon ExecReload= RuntimeDirectory=unit RuntimeDirectoryMode=0755

i have set it to /tmp/files.log so yep it has rights

On Wed, Aug 2, 2023 at 1:40 PM Andrew Clayton @.***> wrote:

Couple of quick questions

1. Is Unit running as a daemon? I.e without the --no-daemon command line argument.
2. Does the unit user have write access to those log files?

— Reply to this email directly, view it on GitHub https://github.com/nginx/unit/issues/915#issuecomment-1661974742, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADCXF3NKIDAASTZ4CH2CXH3XTIVA7ANCNFSM6AAAAAA3AVLU6E . You are receiving this because you authored the thread.Message ID: @.***>

[ac000]

Please remove the --no-daemon option.

The stdout/stderr options only take effect when running as a daemon. (~Yes, our documentation is wrong!~ now fixed).

[ac000]

Closing as NOTABUG. Feel free to re-open if you're still having issues.

[yosefy]

it wouldn't work with systemd without --no-daemon option do you have some advice on it may be?

On Fri, Aug 11, 2023 at 6:11 PM Andrew Clayton @.***> wrote:

Closing as NOTABUG. Feel free to re-open if you're still having issues.

— Reply to this email directly, view it on GitHub https://github.com/nginx/unit/issues/915#issuecomment-1674947751, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADCXF3IO5KZUPLRZGAXO3QDXUZDSXANCNFSM6AAAAAA3AVLU6E . You are receiving this because you authored the thread.Message ID: @.***>

[ac000]

Also change the Type from simple to forking

That works for me on Fedora...

(NOTE: You should probably copy /usr/lib/systemd/system/unit.service into /etc/systemd/system/ and edit that one instead which will override the one from the package.)

@thresheek

Any reason not to use a systemd service 'Type' of forking and run unit as a daemon by default?

Otherwise users can't make use of per application logging...

[thresheek]

See https://github.com/nginx/unit/pull/212 and https://github.com/nginx/unit/issues/213 for some comments on why we're not using forking. The commit that changed that is https://github.com/nginx/unit/commit/b78ed44f396cbfde7d8353cbc3faaf35c0f4dddf

[yosefy]

clear. but how to split the logs now?

On Fri, Aug 11, 2023 at 9:14 PM Konstantin Pavlov @.***> wrote:

See #212 https://github.com/nginx/unit/pull/212 and #213 https://github.com/nginx/unit/issues/213 for some comments on why we're not using forking. The commit that changed that is b78ed44 https://github.com/nginx/unit/commit/b78ed44f396cbfde7d8353cbc3faaf35c0f4dddf

— Reply to this email directly, view it on GitHub https://github.com/nginx/unit/issues/915#issuecomment-1675185698, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADCXF3PYOSXGKFOWXFXS5HLXUZZB3ANCNFSM6AAAAAA3AVLU6E . You are receiving this because you authored the thread.Message ID: @.***>

[ac000]

@yosefy

I currently see no reason why we shouldn't switch back to forking.

However in the meantime, create the file /etc/systemd/system/unit.service with the following contents

[Unit]
Description=NGINX Unit
Wants=network-online.target
After=network-online.target

[Service]
Type=forking
Environment="UNITD_OPTIONS=--log /var/log/unit/unit.log --pid /var/run/unit/unit.pid"
ExecStart=/usr/sbin/unitd $UNITD_OPTIONS
ExecReload=
RuntimeDirectory=unit
RuntimeDirectoryMode=0755
PIDFile=/var/run/unit/unit.pid

[Install]
WantedBy=multi-user.target

(This will take precedence over the service file from the unit package)

Then do a systemctl restart unit

[ac000]

Re-opening to raise visibility...

[sidz]

Hi guys.

It seems like per application logging obviously doesn't work for dockerized application due to the fact that --no-daemon mode is used.

Does anybody aware of any hack or workaround?

[ac000]

Are you able to run Unit as a daemon(7)? I.e without the --no-daemon option. If not, is there some fundamental reason why?

[lcrilly]

That's how Docker works, Andrew :)

https://github.com/nginx/unit/blob/master/pkg/docker/template.Dockerfile#L89

We expect people to use container logging conventions, but sounds like in this case real log files are required.

@sidz This topic should really be moved to a separate discussion.

[sidz]

I'm okay to open a new issue.

Should I @ac000 ?

[tippexs]

@sidz yes please do. I am happy to link it to this issue but we should open another one to work on the per application logging OR better to say application logging in Docker using Unit.

There are some fundamental differences between the no-daemon and daemon mode. Will use the new issue to elaborate on those and share potential work arounds and solutions