Opened 13 years ago
Closed 13 years ago
Last modified 13 years ago
#11133 closed Patch - Bug Fix (Won't Fix)
Allow mythbackend network initialization to soft-fail
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | minor | Milestone: | unknown |
Component: | MythTV - General | Version: | 0.25.2 |
Severity: | low | Keywords: | |
Cc: | Ticket locked: | yes |
Description
This allows the backend to continue to run and operate on at least one network interface (e.g., lo) instead of panicking and waiting for user input.
Attachments (1)
Change History (6)
Changed 13 years ago by
Attachment: | backend-net-softfail.patch added |
---|
comment:1 Changed 13 years ago by
Resolution: | → Won't Fix |
---|---|
Status: | new → closed |
comment:2 follow-up: 3 Changed 13 years ago by
Network configuration is an administrative task. The change is trivial, but important. The main function, dvr, is maintained in all but the worst cases of network failure. As long as one interface successfully assigns the requested address, that should be enough for mythtv. It should (and does) warn the operator by log message if an interface fails to assign the requested address when listen() is called, but I see now reason for it to quit running when it can still successfully record and run a local frontend. The operator should decide if the failures noted are actually important, not the software.
Regardless, mythbackend should exit when mainserver fails. Currently it doesn't - it just runs housekeeping forever.
If for some reason the above logic is still not good enough, I propose the following alternative:
Read the IP addresses from the database. Get the interface, and call listen() for that interface *only* and lo, requiring all. The framework already is in place.
--- The specific use case I'm addressing here is that if a system has a buggy network interface that randomly fails to assign a requested address but otherwise works (in my case a link-local IPv6 :6543,6544 occasionally fails on one interface that's unimportant to mythtv itself).
comment:3 Changed 13 years ago by
Replying to jcrews@…:
Regardless, mythbackend should exit when mainserver fails. Currently it doesn't - it just runs housekeeping forever.
I mistakenly believed that it did.
comment:4 Changed 13 years ago by
Having just upgraded from 0.25 to 0.26 I have to say the current functionality is not helpful to users.
There is no error message that tells you what has failed and as noted above the backend does not quit, it just appears to not work.
I (and it seems I'm not alone) do not have any IPv6 interfaces on my backend, but Myth automatically adds an BackendServerIP6 entry of ::1 to the settings. Therefore with current functionality the backend won't run on my system without me manually changing the database. The lack of any useful error message made the source of this problem rather hard to track.
The above comments make sense, there is no reason to assume that just because one interface couldn't bind the system should fail. It chooses to bind to a number of addresses on my server, but only one is actually required for it to work.
Ref the thread on the devs list here: http://www.gossamer-threads.com/lists/mythtv/dev/529496#529496
Regards, Graham
comment:5 Changed 13 years ago by
Ticket locked: | set |
---|
I'm rejecting this as it doesn't actually improve anything. Rather than terminating on an improperly configured system, making the user aware of the problem, this continues to run but is unavailable to access. This is a known issue that needs to be resolved, but disabling the sanity check and ignoring it is not the way to do so.