On Mon, 2019-04-01 at 09:34 -0500, Tim Camp wrote:
> Running rddbmgr --modify immediately produced a string of errors
> about "unknown" columns all
> related to the now and next page in rdairplay.
>
> Then crashed on a error about a log file from a now non-existent
> service on one particular workstation.
There could be a number of things going on here. rddbmgr(8) is fairly
aggresssive about cleaning out a lot of the database 'crud' that tended
to accumulate in v2.x databases ('orphaned' tables, etc). When it finds
something like that, it will print a message to standard error about
it, but continue with the schema conversion. That's 'normal' behavior
(in the sense that you should still end up with a valid database at the
end of the process).
OTOH, database *corruption* (things like missing certain columns in a
given table, etc) will cause it to generate an error message to
standard error and then exit with a non-zero exit code, leaving the
database in the state at which it was when the error was encountered.
This is because the corruption was such that it made it impossible to
generate a valid database. Manual intervention is needed to determine
what exactly happened and (perhaps) how to repair the damage.
And, of course, it's possible that rddbmgr(8) *itself* crashed, due to
some internal code bug or local hardware problem, in which case you
should be getting some sort of error indication ('segmentation fault',
'bus error', etc) printed to standard error.
So, when you say that it 'crashed on a error about a log file', which
type of exit do you mean? Pray be specific as to details!
> Next step was, I thought, since this was probably something orphaned
> that I would run rddbcheck (from current schema) before trying to
> convert it again. (I did this on a fresh copy)
> Running rddbcheck went smoothly finding many orphaned items until
> reaching the section checking audio file lengths.
>
> Once it reached this point all the audio on air on four radio
> stations stopped as rddbcheck hung on the first file it was checking.
> I had to do a cntrl-c to exit at which time all audio on four
> stations continued.
> This test machine was running it's own db server but was still
> connecting to my plants /var/snd.
This was likely something totally different from the v3.x rddbmgr(8)
issues. One of the tests rddbcheck(8) will do is to read the play-out
lengths of all of the audio in the audio store and verify them against
the values stored in the database. It sounds like that triggered some
sort of data starvation issue on your network and/or NFS server.
Cheers!
|---------------------------------------------------------------------|
| Frederick F. Gleason, Jr. | Chief Developer |
| | Paravel Systems |
|---------------------------------------------------------------------|
| "There are three possibilities: Pioneer's solar panel has turned |
| away from the sun; there's a large meteor blocking transmission; or |
| someone loaded Star Trek 3.2 into our video processor." |
|---------------------------------------------------------------------|
_______________________________________________
Rivendell-dev mailing list
[email protected]
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
