Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

standard/syslog: the request shutdown hook calls closelog() even when the request never opened syslog

Open Beginner friendly
  • Is something wrong?
#24,308 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
Half a day
Newbie friendliness
62/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
c
Domain
backend

Research direction

The unconditional close is in PHP_RSHUTDOWN_FUNCTION(syslog) in ext/standard/syslog.c. Read php_closelog() and the PG(have_called_openlog) flag in main/php_syslog.c (around lines 74-84), and the reset in main/main.c near line 2317. Done means a request that never calls openlog, closelog or syslog skips php_closelog() while still freeing BG(syslog_device). Check it with strace over several requests in a multi-request SAPI, as the issue shows.

Written by the indexing model from the issue text.

Description

Description

ext/standard/syslog.c installs an unconditional request shutdown hook:

PHP_RSHUTDOWN_FUNCTION(syslog)
{
	php_closelog();
	if (BG(syslog_device)) {
		free(BG(syslog_device));
		BG(syslog_device) = NULL;
	}
	return SUCCESS;
}

php_closelog() runs after every request, whether or not this request opened syslog. In a SAPI that serves more than one request per process, that closes a process-wide handle the request may not own, and the next request opens it again.

Note that the state to avoid this already exists: php_openlog() sets PG(have_called_openlog) = 1 and php_closelog() clears it (main/php_syslog.c:74-84), and php_module_startup() resets it to 0 (main/main.c:2317). The shutdown hook simply does not look at it.

Expected

A request that never calls openlog(), closelog() or syslog() should leave the process syslog handle alone. If the handle was opened outside PHP, for example by the embedding application or by a library in the same process, PHP should not close it.

Actual

Embedded SAPI, PHP 8.5.11 (Alpine 3.24.2, musl 1.2.6, OpenSSL 3.5.9), one worker process serving three requests with error_log = syslog and a script that only calls error_log("request"). strace of the worker:

1080  connect(15, {sa_family=AF_UNIX, sun_path="/dev/log"}, 12) = 0
1080  sendto(15, "<13>Oct 13 21:57:46 php: request\n", 33, 0, NULL, 0) = 33
1080  connect(14, {sa_family=AF_UNIX, sun_path="/dev/log"}, 12) = 0
1080  sendto(14, "<13>Oct 13 21:57:46 php: request\n", 33, 0, NULL, 0) = 33
1080  connect(14, {sa_family=AF_UNIX, sun_path="/dev/log"}, 12) = 0
1080  sendto(14, "<13>Oct 13 21:57:46 php: request\n", 33, 0, NULL, 0) = 33

Three requests, three connects: the handle does not survive a request boundary. In the same process, a host that opened syslog before running PHP loses it when the first request ends. php-fpm works around this by calling php_closelog() itself when it takes over the child, with the comment "ensure to close syslog not to interrupt with PHP syslog code" (sapi/fpm/fpm/fpm_stdio.c:144), which is the same interaction seen from the other side.

Suggested fix

Check the existing flag before closing:

PHP_RSHUTDOWN_FUNCTION(syslog)
{
	if (PG(have_called_openlog)) {
		php_closelog();
	}
	...
}

That keeps the per-request BG(syslog_device) cleanup, closes the handle when this request opened it, and leaves a host-owned handle alone.

Version

PHP 8.5.11, and the same code is in the current PHP-8.5 and master branches.

Dominant language
C
Stars
40.4k
Forks
8.2k
Avg merge
2d 24m
Merged PRs (30d)
157

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from php/php-src

All issues in php/php-src

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.