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 <#915 (comment)>, 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 <#915 (comment)>, 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 #212 and #213 for some comments on why we're not using forking. The commit that changed that is b78ed44

[yosefy]

clear. but how to split the logs now?

…

On Fri, Aug 11, 2023 at 9:14 PM Konstantin Pavlov ***@***.***> wrote: See #212 <#212> and #213 <#213> for some comments on why we're not using forking. The commit that changed that is b78ed44 <b78ed44> — Reply to this email directly, view it on GitHub <#915 (comment)>, 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...