What do these messages mean?

Troubleshooting
1

I got this message emailed to me from rockstor,

Traceback (most recent call last):
File “/usr/lib64/python2.7/logging/handlers.py”, line 76, in emit
if self.shouldRollover(record):
File “/usr/lib64/python2.7/logging/handlers.py”, line 154, in shouldRollover
msg = “%s\n” % self.format(record)
File “/usr/lib64/python2.7/logging/init.py”, line 724, in format
return fmt.format(record)
File “/usr/lib64/python2.7/logging/init.py”, line 464, in format
record.message = record.getMessage()
File “/usr/lib64/python2.7/logging/init.py”, line 324, in getMessage
msg = str(self.msg)
TypeError: str returned non-string (type list)
Logged from file pool_scrub.py, line 78
Traceback (most recent call last):
File “/usr/lib64/python2.7/logging/handlers.py”, line 76, in emit
if self.shouldRollover(record):
File “/usr/lib64/python2.7/logging/handlers.py”, line 154, in shouldRollover
msg = “%s\n” % self.format(record)
File “/usr/lib64/python2.7/logging/init.py”, line 724, in format
return fmt.format(record)
File “/usr/lib64/python2.7/logging/init.py”, line 464, in format
record.message = record.getMessage()
File “/usr/lib64/python2.7/logging/init.py”, line 324, in getMessage
msg = str(self.msg)
TypeError: str returned non-string (type list)
Logged from file pool_scrub.py, line 39

I assume it means my scheduled pool scrub has failed?

But there is no context to the message. Just a stack trace.

I would like to know whether I should be worried?

2

@petermc Hello again.

Yes and it’s due to a change that happened in our pool api and the fix was released in testing channel just recently (shortly after the change that cause it):

The issue was diagnosed by forum member @kbogert in the following forum thread:

with an initial report and assistance from @KarstenV; and core code contributor @Flyer.

You will need to re-create that scheduled scrub job as then it will contain the new style pool api info.

Hope that helps.

3

Nice work. Thanks.

In short this means the scrub did not run, and nothing more? This has not affected my data?

Plus I can still run a scrub manually?

I only created this scheduled job last week for scrub, so has this not been released to stable updates?

4

@petermc

Correct. The issue was caused by us moving from pool name to internal number and the error was that schedule code still used name, hence the strange error as names (still used in error by schedule code) no longer made sense to the rest of the code which expected internal number references. We needed this rather large change to improve flexibility / usability (pool name changing) later on.

Yes.

Unfortunately this bug was in our last stable release. Not our finest moment.

Unfortunately not. But a new stable release is due shortly.

Partly in response to this and other regressions that are otherwise fixed in testing channel but take longer than we would like to appear in stable, and the fact that all Rockstor developers are, as far as we know, human; there is an ongoing effort to rethink our release cadence / frequency / nature. The primary aim of this effort is to improve code quality and consistency whilst putting in place mechanisms to catch such ‘hick-ups’ and confine them to the testing audience. This was of course our original aim but evidently our existing checks and balances (procedures) failed: hence the re-think.

Hope that helps and apologies to yourself and all our stable channel subscribers as this was a most unfortunate regression which should never have reached stable.

Oh well bit by bit: and thanks for helping to support Rockstor development via your Stable channel subscription.

5

@phillxnet Excellent. No problem. I am really enjoying rockstor, and very much appreciate the effort that everybody puts into it. It is so much better than my crappy NAS!

1 Like
6

very helpful thread.