Fix missing update_daemon.timestamp on install/upgrade

[saschpe]

Related to issue 2052 and pull request 1976

Maybe not the most beautiful fix on earth...

[nickbroon]

This is clearly a work around or hack, as tt-rss should be creating this file itself, and this is just hiding the underlying issue.
See: https://tt-rss.org/gitlab/fox/tt-rss/blob/master/update.php#L183

The update daemon should be creating this timestamp files, so perhaps it's not being setup/executed properly on DSM6?

[Dr-Bean]

I have to agree with @nickbroon here.
Two suggestions from me: report the issue upstream to see if the bug from the previous version isn't completely fixed yet, or debug and figure out why it's not working in this setup.
Seeing as DSM6 is beta software (alpha even, from our perspective), debugging should probably be the starting point.

[saschpe]

I think I found the issue, config.php should contain this line:

define('PHP_EXECUTABLE', '/usr/local/bin/php56');

But I'm quite sure yours will have:

define('PHP_EXECUTABLE', '/usr/bin/php');

Seems like https://github.com/SynoCommunity/spksrc/pull/1976/files#diff-b29215cbdf055f9967dda542150e9a3aR66 didn't cut it. I'll fix this line and update this pull soon...

[nickbroon]

👍

[Dr-Bean]

If @nickbroon did a clean install of tt-rss on DSM6, then the postinstall line should have already fixed that, right?
Generally speaking, I would think that (re)setting the PHP_EXECUTABLE in the config during postupgrade works for the following use-case: a older version of tt-rss was installed on DSM5; then the owner upgraded to DSM6, and after completion, updated the package to the latest version.

@nickbroon Have you actually tested this?

[nickbroon]

Just built/installed/tested tt-rss_88f6281-5.2_20160102-11.spk
And still seeing the file_get_contents(lock/update_daemon.stamp): failed to open stream: No such file or directory [Last query: SELECT ref_id AS id FROM ttrss_user_entries WHERE owner_uid = 1 ORDER BY ref_id DESC LIMIT 1] tt-rss log message. :-(

tt-rss/config.php still contains define('PHP_EXECUTABLE', '/usr/bin/php');

[saschpe]

So I re-installed this package after upgrading to DSM-7.0beta2 and it works. However, I can't uninstall it anymore to check if the lock file issue is still present. Locks like the uninstall script drop database part got broke somehow. At least it doesn't accept my (otherwise valid) root password anymore.

@Dr-Bean I suggest merging this fix, since the other was incomplete. I'll try to see what can be done about the lock-file issue

[nickbroon]

It won't accept my valid database root password on install either :-(

[saschpe]

@nickbroon Likely the same for other packages, so I guess something bigger changed :-D

[saschpe]

Ping, @LawrenceAusten feel free to comment here too...

[Dr-Bean]

I'm holding off on merging this, because we need the DSM6 toolchains to be able to release a DSM6 compatible package. The user creation stuff has to be finalized as well.
After the above two conditions are met, I think the best way to change the PHP location is by doing a check on SPK_REV, and set PHP_EXECUTABLE in preupgrade. See e.g the method that haproxy uses.

[michailf]

@saschpe The replacement line in both locations contains an extra space. This is why it does not work.

-e "s|define('PHP_EXECUTABLE', '.*');|define('PHP_EXECUTABLE', '${PHP}');|" \

The text gets auto-corrected in these comments but the extra space is in the match portion after 'PHP_EXECUTABLE',

Perhaps the match should contain a match on 0 or more spaces instead of a hard coded space.