I'd suggest raising this with the Debian maintainer in their bug
tracker, but this doesn't seem like a good thing to deviate on for a
community-maintained package, it seems more vital that it be kept
uptodate (currently it's synced automatically from Debian, then it would
need manual work) and I don't believe that there's a generally good
answer for default timeout.
Upstream seems to set infinity as the timeouts, but I wouldn't say I
agree with that concept, and that it's best to err on the side of
caution to get a machine that can actually shut down or have the service
fail if it's hanging during startup. That is, I believe short timeouts
are the right defaults, if you need longer you can adjust them for your
use case locally.
Note that you're wrong in the aspect of systems abilities: services can
send EXTEND_TIMEOUT_USEC= on the notify socket to extend the timeouts,
assuming they are notifying.
** Changed in: redis (Ubuntu)
Status: New => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2068542
Title:
Redis start is impossible with big DB because of start timeout
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/redis/+bug/2068542/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
