Tiny Tiny RSS: Community

Warning in update_daemon2.php output

#1

Describe the problem you’re having:

When I run update_daemon2.php either directly via command line php update_daemon2.php or via systemd units, I get warnings in the output:

PHP Warning: Unable to determine version (using /srv/ttrss): 1576755694 e9b4834b6 in /srv/ttrss): 1576755694 e9b4834b6 in /srv/ttrss/include/functions.php on line 1929

Now, what’s interesting is when I look at that code branch it happens when $rc != 0… but its clearly getting a timestamp and git commit hash. I dumped the value of $rc to console and its -1. I have no clue wtf -1 is…

If I run git log --pretty="%ct %h" -n1 HEAD 2>&1 as the user running the update daemon, the exit code is 0.

If I change the conditional to allow for $rc == -1, then the function returns successfully (19.12-e9b4834b6 in this case).

tt-rss version (including git commit id):

Git commit e9b4834b6ba788f43b8ce0bca13a9526df11d472

Platform (i.e. Linux distro, PHP, PostgreSQL, etc) versions:

Archlinux (kernel 5.4.3.arch1-1), PHP 7.4.1, git 2.24.1, mariadb 10.4.11

Please provide any additional information below:

I don’t know when this started to occur, but if I go to the preferences panel there is a sensible version string: Tiny Tiny RSS v19.12-e9b4834b6 © 2005-2019 Andrew Dolgov, but I have no idea if the webui version string is related to what update_daemon2.php is doing.

#2

that’s interesting, i must admit i never thought about command line processes and new version code because this stuff just works somewhere in the background and i rarely check it.

no idea why would git return -1 exitcode but i’ll try to investigate this tomorrow.

e: this works fine here (debian 10)

why is it always arch

anyway it could be something related to php 7.4, otherwise not sure.

#3

I spent some time searching for any mention of negative return codes, and couldn’t find anything. Maybe its Arch, but it smells like PHP 7.4 a bit more (the timing could be right for when I pulled PHP 7.4).

Anyways, for now I just accept -1 so there’s no logspam. It’s not that big of an issue, and I should probably wrap up services like these into some more standard docker containers.

#4

you can try replacing git with other random commands (like echo) to see if there’s any difference.
my guess would be this -1 coming from git.

#5

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?

#6

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
0

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

1578578328 040dfc71f
1

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?

#7

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 $?
0

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

#8

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

#9

I do not have SELinux enabled.

But perhaps this is some pipe-related behavior, similar to the one described in
https://stackoverflow.com/a/19120674/2815561

#10

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);
#11

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:

<?php
$rc = 0;
$output = [];
chdir('.../htdocs/tt-rss');
exec('git log --pretty='.escapeshellarg('%ct %h').' -n1 HEAD 2>&1', $output, $rc);
print($output[0]);
print(PHP_EOL);
print($rc);
print(PHP_EOL);
?>

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?

#12

Different versions of php installed and used?

#13

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

#14

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.

#15

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)

#16

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

#17

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 $?'

#18

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

#19

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.

#20

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.