Description of problem: 1. document linked in /usr/lib/systemd/system/taskd.service is nonexistent and a website not owned by the developers of the project. should probably point to either https://gothenburgbitfactory.github.io/taskserver-setup/ or https://taskwarrior.org/docs/ 2. it seems that starting the taskd service immediately after the network is available causes the service to fail. may be worthwhile to include a timer in the package as suggested in https://wiki.archlinux.org/title/Taskd#taskd.service_fails_to_start_on_boot . another approach is to restart the service if it goes offline, my systemd knowledge is a bit lacking there though Version-Release number of selected component (if applicable): 1.1.0 How reproducible: for 2: each reboot it reoccurs Steps to Reproduce: for 2: 1. enable the systemd service 2. reboot Actual results: for 2: service fails with temporary failure in name resolution, and doesn't reattempt Expected results: for 2: The service starts on boot Additional info:
Thanks for the bug report, Joshua. Upstream moved websites so all links in the sources need to be updated. I expect a new release will include these changes. If there aren't too many changes, we can carry patches in Fedora. I'll take a look. I do remember running into the service issue myself too. I'll file an issue upstream and see what the devs say. Cheers, Ankur
Looks like these are both fixed upstream in 1.2.0, we're just waiting for a new release: https://github.com/GothenburgBitFactory/taskserver/blob/d1fb597ce8b0b3cba3bf655e6a2525b92cb430b7/scripts/systemd/taskd.service#L4 - TD-117 Wrong systemd target, taskd can fail if multi-user.target is up earlier than the network (thanks to Sebastian Sonne).
EPEL 7 entered end-of-life (EOL) status on 2024-06-30. EPEL 7 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug.