Since the forums have moved, i am reposting this here for those who find it useful.
It is an RC script for FreeBSD that runs the feed updater as a daemon that starts on boot time.
@Zerotronic, I’m using your script and it seems to be working OK except that when I log in to my Tiny Tiny RSS instance using a web browser I see the message “Update daemon is not updating feeds.”
This is not actually true as my feeds are being regularly updated.
Do you know how to ensure that TT-RSS knows the updater is actually running?
There’s definitely a process owned by ttrss running:
/usr/bin/php /usr/local/www/apache24/data/tt-rss/update_daemon2.php
daemon should place a .stamp file in lock directory (i think) if it’s not there check your permissions and/or daemon process owner
@Kapowee, what fox said.
Basicaly ttrss checks that stamp file that lives in /usr/local/www/apache24/data/tt-rss (or wherever your installation lives).
If you ls -lak that folder you should see 3 files
update_daemon-{some-number}.lock, update_daemon.lock and update_daemon.stamp
These should be owned by the user running the update process (the user you set in the rc script as the one running it, eg ttrss:www). Your apache user (by default www:www) should also have permission to read and write in that folder in order to see those files.
All these files including the stamp file get recreated if they get deleted, so if you are 100% sure your permissions are correct but you still have a problem then back those files up in a different folder (just in case), stop the update service (service rcttrss stop) and your web server (service apache24 stop), and delete them. Then start the services again (service apache24 start and service rcttrss start) and see if that fixes your problem.
Edit* correction of ownerships
Edit2* Please make sure you have the latest version of the script. Just so we are all on the same page 
@Zerotronic, You’re right, this was a permissions issue.
I had omitted step 6) in your installation instructions because it didn’t seem quite right.
I shouldn’t have to open up all those folders to be world writable when the user running the script is already a member of the group that owns the folders.
Why don’t you consider using the shell’s “newgrp” command to change group to the “www” user such that the folders only need to be group writable.
That would be more secure.
You are getting us to add this new user to the “www” group so I think you should probably use that.
Please consider this approach.
@Kapowee As i am the only one using my server, and i run my instance locally, security was not one of the main concerns when i wrote that readme.
However you are absolutely right. If security is a concern then you should absolutely not use 777 on these folders. And since the user you create at the beginning of the readme (provided you create a user and don’t want to use the apache www) is already invited to the apache group (www) then you don’t even have to use newgrp. The user already has permissions on these folders, so simply change the permissions to something like 775.
The permissions i used i simply copy/pasted from installation instructions i found online. (I believe at some point the update daemon itself made that suggestion in the logfile when it had no write permissions) I don’t know how the ttrss backend works, but i have a feeling that these permissions are suggested to be 777 not only for the update daemon. Nevertheless i changed them to 775 in my instance, and everything seems to be running fine, so i made that correction in the readme file.