Hello there,
my proposal is to not write the .freshrss.lock file into the system temp dir, but find a cosy place inside the web directory tree for it.
Reason:
A friend of mine had the issue where the lock file got stuck somehow and feed updating was just giving the message "Feed already being actualized". Since this installation is on shared hosting where the system temp dir is not reachable for the customer, it was not possible to delete it. As soon as I changed the lock file path in app/Models/Feeds.php:367 from TMP_PATH to CACHE_PATH, FreshRSS was working all fine, and when it should get stuck again in the future, it's removable via FTP.
It would be awesome if you could implement some change similar to this so my friend doesn't need to merge this change after every update. Thanks!
Hello,
It is easier to change the location of your temp path in https://github.com/FreshRSS/FreshRSS/blob/master/constants.php#L27
lock files are supposed to be outdated after one hour. If the problem persisted for more than one hour, then there might be another issue (such as access rights changed).
For the record, we should probably split this file in two: one for the parts that are changing more often (e.g. version number), and one for the rest.
The issue was more than a day, so yes, there is some problem behind that is causing this, and access rights can easily be the culprit. But since the system temp dir is out of user control on this installation I could not do any debugging.
But I don't want to dig into this, as this is not a fault of FreshRSS, it was just the occation. My proposal is way more general. Basically it is:
Better keep every file needed for FreshRSS in the FreshRSS directory itself, because on shared hosting any other location could be inaccessible and people cannot debug and fix anything there.
So yes, this reasoning in mind, moving the whole temp directory using the constant would be a simple yet powerful approach. It would be perfect if you could implement this and e.g. create a temp directory within FreshRSS tree. This way every shared hosting user would benefit.
Yes, I understand your reasoning @sleeksorrow . On the other hand, I would also like to avoid writing to physical disk when possible (use cases when e.g. a SD card is used like on a Raspberry Pi), and /tmp is often an in-memory location (tmpfs). (By the way there is still a bit of work to do there to make it easier, like the location of the logs.)
I will try to make it easier to switch between /tmp/ and ./FreshRSS/data/tmp/
Ah this is a very good argument for /tmp indeed, didn't think of that. Making it configurable is always great of course, I love options, as I love when everybody is happy :)
For my friend it would be most convenient if an update of FreshRSS does not reset this option.
For my friend it would be most convenient if an update of FreshRSS does not reset this option.
Indeed, that is an important point
@sleeksorrow The patch https://github.com/FreshRSS/FreshRSS/pull/1725 adds the possibility to customize constants in constants.local.php, including TMP_PATH. It will land in /dev and then in FreshRSS 1.9.0 shortly.
I believe this should solve your problem. Feedback / tests welcome.
Thank you so much! It works great for me.
Note to self/other readers: One has to make sure that everything one wants to rely on has to be defined in constants.local.php. E.g. if I want to set TMP_PATH to CACHE_PATH then I need to make sure that DATA_PATH and CACHE_PATH are defined here, too or otherwise I cannot use them. I realize there's no other way, because I can only overwrite constants that are not yet set.
Complete example of constants.local.php for my usecase:
<?php
safe_define('DATA_PATH', FRESHRSS_PATH . '/data');
safe_define('CACHE_PATH', DATA_PATH . '/cache');
safe_define('TMP_PATH', CACHE_PATH);
Thanks for the feedback, @sleeksorrow 馃憤