Ticket #949 (closed defect: fixed)

Opened 13 years ago

Last modified 13 years ago

edsc explodes on encountering old discussd

Reported by: jweiss Owned by:
Priority: low Milestone: The Distant Future
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:


I tried to start edsc and saw the following in the *Messages* buffer:
Loading discuss...done
Starting discuss....
waiting for discuss...
Started edsc process.... version 2.5 (Sat Oct 2 20:31:43 UTC 2010) builder@…:/build/builder-debathena-discuss_10.0.13-0debathena1~ubuntu10.04-i386-Fb_PAD/debathena-discuss-10.0.13/edsc)
Listing meetings...
error in process filter: discuss-read-form: End of file during parsing
error in process filter: End of file during parsing

some debugging indicated that it's failing to connect to bloom-beacon. In a similar case discuss reports:
peter-petrelli:~/Mail$ discuss charon-maint
Discuss version 1.7. Type '?' for a list of commands.
discuss: RPC server too old while authenticating to discuss server
Error going to Charon_Maintainers_Archive: Connection reset by peer

I assume beacon is running a k4 only discussd, and while that is a separate problem, edsc should simply declare the relevant meeting unavailable and not fail outright. (I'll send mail to news about beacon's discussd under seperate cover, which may moot this bug, unless there are other ancient discussds out there, but if my .meetings didn't have one, they're pretty rare).

Change History

comment:1 Changed 13 years ago by jweiss

  • Status changed from new to closed
  • Resolution set to duplicate

duplicate of #603

comment:2 Changed 13 years ago by mitchb

  • Status changed from closed to reopened
  • Resolution duplicate deleted

comment:3 Changed 13 years ago by mitchb

  • Status changed from reopened to closed
  • Resolution set to fixed

This is really somewhere between "fixed" and "invalid," but it's not quite the same as #603. Beacon wasn't so much running a krb4 discussd as a completely broken one that just violated everything. It's not entirely clear that a client responding to that daemon unpredictably is disallowed, but I've fixed beacon's discussd. We'll cope with 603 under separate cover... conceivably also by me insisting on replacing the relevant daemons...

Note: See TracTickets for help on using tickets.