Tiny Tiny RSS: Community

Warning in update_daemon2.php output

I’m seeing the same “Unable to determine version” messages in my syslog since first part of December. I’m running:
Debian 9, PHP 7.0.33, mariadb 10.1.41

Just checked and found there was a git security update on Dec 10 that seems to have started this. The description of the security update does not mention anything that to me would cause this. Maybe someone else has a suggestion on possible fix?

I am also seeing this message:

PHP Warning:  Unable to determine version (using .../htdocs/tt-rss): 1578578328 040dfc71f in .../htdocs/tt-rss/include/functions.php on line 1937

I have PHP 7.3.11 and Git 2.24.1.

With su ttrssd -c "git log --pretty='%ct %h' -n1 HEAD 2>&1 ; echo $?" I get

1578578328 040dfc71f

But with su apache -s /bin/bash -c "git log --pretty='%ct %h' -n1 HEAD 2>&1 ; echo $?" I get

1578578328 040dfc71f

I tried to change the file ownership of the whole ttrss instance directory to <ttrssuser>:<apacheuser> . Now I got 0 as exit status for both commands, but I still get the error message in my log.

While trying around I noticed that sometimes the ttrssd variant of the git command would give me different exit codes (130, 141) , but I do not see a pattern and did not find anything while searching. Perhaps someone else can interpret what is happening here?

not sure what’s going on but here on debian 10 things work as expected i.e.

mfw:tt-rss (master):$ ls -ld .git
drwxr-xr-x 8 fox fox 4096 Jan 13 13:52 .git
mfw:tt-rss (master):$ sudo -u nobody touch .git/aaaa
touch: cannot touch '.git/aaaa': Permission denied
mfw:tt-rss (master):$ sudo -u nobody git log --pretty='%ct %h' -n1 HEAD
1578578328 040dfc71f
mfw:tt-rss (master):$ echo $?

so it’s not like git requires write access or file ownership or anything else weird.

Weird permission errors can be caused by SELinux if you have it enabled. Have you checked that?

I do not have SELinux enabled.

But perhaps this is some pipe-related behavior, similar to the one described in

there’s no grep or any pipes involved in the command though:

exec('git log --pretty='.escapeshellarg('%ct %h').' -n1 HEAD 2>&1', $output, $rc);

You are right, there does not seem anything pipe-related going on.

If I do

for i in {1..1000}; do su ttrssd -c "git --no-pager log --pretty='%ct %h' -n1 HEAD  ; echo $?" | tail -n 1 ; sleep 1 ; done | sort -n | uniq -c
999 0
1 130

and this put me probably on the wrong track.

I used the same approach with a minimal php file:

$rc = 0;
$output = [];
exec('git log --pretty='.escapeshellarg('%ct %h').' -n1 HEAD 2>&1', $output, $rc);

and then

for i in {1..1000}; do su ttrssd -c "php bla.php" | tail -n 1 ;  done | sort | uniq -c
1000 0

Even if I run multiple of these in parallel I do not see a single non-zero exit code in the output.
But still, the log is getting warnings every minute.
Perhaps it is somehow related to php-fpm?

Does someone have another idea?

Different versions of php installed and used?

so is this related to update daemon or not? daemon doesn’t run under fpm, frontend code does.

There is only one version of PHP on the system.

And yes, it is definitely the update daemon. If I disable it, the warnings vanish.

it’s not fpm then. maybe there’s a pipe involved here after all:

if this is pager-related, replacing “git log” with “git --no-pager log” should help.

try changing it (in include/functions.php)

I changed it, but the message persists. I also started printing the actual content of $rc, and it is always -1.

Those commands are not returning the error code that you expect them to. They are evaluating the $? variable before running su. So you are seeing the exit code for the command prior to performing the su.

Try swapping the double and single quotes around so that the outer shell does not evaluate the $? for you. e.g.

su ttrssd -c 'git log --pretty="%ct %h" -n1 HEAD 2>&1 ; echo $?'

Oh, yes, you are absolutely right. But the PHP experiment is not affected by this mistake, right?

that is correct. the php example will not have that problem (well in my limited knowledge of php anyway!).

Is the execution environment of you bla.php exactly the same as that for update_daemon2.php? It may be that the git executable is not in the path for a cron job. If so then a test of changing git to /usr/bin/git might change things.

You are right, but it already produces the expected output. Only the return code is strange.

Nevertheless, if I change git to /usr/bin/git in bla.php, I get the same output.

maybe we should just ignore this SIGPIPE-related stuff and assume execution was a success as long as two tokens were returned?

I do not have a better idea.

Perfect, no more warnings. Thanks for the fix!