[SOLVED] V3.9.2-3 through v3.9.2-9: Schedule Task Screen errors out

I couldn’t open a ticket for this, as the support site seems to be inaccessible. When trying to get to the Scheduled Task screen, I get an error message (with no further detail in it), and no task scheduling screen comes up. After a reboot earlier today I had some issues with unmounted shares, but I believe I fixed those and this is unrelated:

This is the error that shows up:

Houston, we’ve had a problem.

Unknown internal error doing a GET to /api/sm/tasks/?page=1&format=json&page_size=5000&count=

It does not matter whether I attempt to access the scheduled tasks from the sidebar or the System dropdown menu. Also refreshing the screen (or using Ctrl-Shift-r) does not fix it either.

1 Like

@Hooverdan, I also confirm this issue. Same behaviour you reported. It happened after upgrading two different boxes to v3.9.2-7.

And it still pops up after a v3.9.2-8 upgrade. :sweat:

Marcio, I am seeing the same thing…I am updating the heading as well.

1 Like

I had this issue many times over the last 2-3 years, but it always disappeared after reboot :sweat_smile:

I did a couple of reboots, but that has not worked for me, unfortunately.

Do you see any stacktrace or error messages in /opt/rockstor/var/log/rockstor.log when this error happens?

@Suman,
I just re-executed that transaction and here’s the tail of the rockstor log file - I also sent you the log directory in its entirety.

[23/Dec/2017 19:47:10] ERROR [storageadmin.middleware:32] Exception occured while processing a request. Path: /api/sm/tasks/ method: GET
[23/Dec/2017 19:47:10] ERROR [storageadmin.middleware:33] invalid literal for int() with base 10: '4xRAID5’
Traceback (most recent call last):
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/core/handlers/base.py”, line 132, in get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/views/decorators/csrf.py”, line 58, in wrapped_view
return view_func(*args, **kwargs)
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/views/generic/base.py”, line 71, in view
return self.dispatch(request, *args, **kwargs)
File “/opt/rockstor/eggs/djangorestframework-3.1.1-py2.7.egg/rest_framework/views.py”, line 452, in dispatch
response = self.handle_exception(exc)
File “/opt/rockstor/eggs/djangorestframework-3.1.1-py2.7.egg/rest_framework/views.py”, line 449, in dispatch
response = handler(request, *args, **kwargs)
File “/opt/rockstor/eggs/djangorestframework-3.1.1-py2.7.egg/rest_framework/generics.py”, line 241, in get
return self.list(request, *args, **kwargs)
File “/opt/rockstor/eggs/djangorestframework-3.1.1-py2.7.egg/rest_framework/mixins.py”, line 44, in list
return self.get_paginated_response(serializer.data)
File “/opt/rockstor/eggs/djangorestframework-3.1.1-py2.7.egg/rest_framework/serializers.py”, line 618, in data
ret = super(ListSerializer, self).data
File “/opt/rockstor/eggs/djangorestframework-3.1.1-py2.7.egg/rest_framework/serializers.py”, line 213, in data
self._data = self.to_representation(self.instance)
File “/opt/rockstor/eggs/djangorestframework-3.1.1-py2.7.egg/rest_framework/serializers.py”, line 568, in to_representation
self.child.to_representation(item) for item in iterable
File “/opt/rockstor/eggs/djangorestframework-3.1.1-py2.7.egg/rest_framework/serializers.py”, line 426, in to_representation
attribute = field.get_attribute(instance)
File “/opt/rockstor/eggs/djangorestframework-3.1.1-py2.7.egg/rest_framework/fields.py”, line 299, in get_attribute
return get_attribute(instance, self.source_attrs)
File “/opt/rockstor/eggs/djangorestframework-3.1.1-py2.7.egg/rest_framework/fields.py”, line 70, in get_attribute
instance = getattr(instance, attr)
File “/opt/rockstor/src/rockstor/smart_manager/models/task_def.py”, line 63, in pool_name
pn = Pool.objects.get(id=task_metadata[‘pool’]).name
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/manager.py”, line 127, in manager_method
return getattr(self.get_queryset(), name)(*args, **kwargs)
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/query.py”, line 325, in get
clone = self.filter(*args, **kwargs)
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/query.py”, line 679, in filter
return self._filter_or_exclude(False, *args, **kwargs)
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/query.py”, line 697, in _filter_or_exclude
clone.query.add_q(Q(*args, **kwargs))
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/sql/query.py”, line 1310, in add_q
clause, require_inner = self._add_q(where_part, self.used_aliases)
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/sql/query.py”, line 1338, in _add_q
allow_joins=allow_joins, split_subq=split_subq,
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/sql/query.py”, line 1209, in build_filter
condition = self.build_lookup(lookups, col, value)
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/sql/query.py”, line 1102, in build_lookup
return final_lookup(lhs, rhs)
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/lookups.py”, line 105, in init
self.rhs = self.get_prep_lookup()
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/lookups.py”, line 143, in get_prep_lookup
return self.lhs.output_field.get_prep_lookup(self.lookup_name, self.rhs)
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/fields/init.py”, line 727, in get_prep_lookup
return self.get_prep_value(value)
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/fields/init.py”, line 985, in get_prep_value
return int(value)
ValueError: invalid literal for int() with base 10: ‘4xRAID5’

Note: the “4xRAID5” is my major pool that I have created (a while ago when I first installed Rockstor) for data storage.

1 Like

Thanks for the detailed info @Hooverdan Please update to 3.9.2-9. It should fix the issue.

@Suman,
I am on 3.9.2-9 now, but the error seems to persist. To be sure, I rebooted the system and executed the Scheduled tasks again. Here’s the tail again, the only difference to the previous one I can currently see is that the application is now complaining about another share (one I’ve set up for the RockOn service):

[28/Dec/2017 09:07:58] ERROR [storageadmin.middleware:32] Exception occured while processing a request. Path: /api/sm/tasks/ method: GET
[28/Dec/2017 09:07:58] ERROR [storageadmin.middleware:33] invalid literal for int() with base 10: 'RockOnShare’
Traceback (most recent call last):
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/core/handlers/base.py”, line 132, in get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/views/decorators/csrf.py”, line 58, in wrapped_view
return view_func(*args, **kwargs)
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/views/generic/base.py”, line 71, in view
return self.dispatch(request, *args, **kwargs)
File “/opt/rockstor/eggs/djangorestframework-3.1.1-py2.7.egg/rest_framework/views.py”, line 452, in dispatch
response = self.handle_exception(exc)
File “/opt/rockstor/eggs/djangorestframework-3.1.1-py2.7.egg/rest_framework/views.py”, line 449, in dispatch
response = handler(request, *args, **kwargs)
File “/opt/rockstor/eggs/djangorestframework-3.1.1-py2.7.egg/rest_framework/generics.py”, line 241, in get
return self.list(request, *args, **kwargs)
File “/opt/rockstor/eggs/djangorestframework-3.1.1-py2.7.egg/rest_framework/mixins.py”, line 44, in list
return self.get_paginated_response(serializer.data)
File “/opt/rockstor/eggs/djangorestframework-3.1.1-py2.7.egg/rest_framework/serializers.py”, line 618, in data
ret = super(ListSerializer, self).data
File “/opt/rockstor/eggs/djangorestframework-3.1.1-py2.7.egg/rest_framework/serializers.py”, line 213, in data
self._data = self.to_representation(self.instance)
File “/opt/rockstor/eggs/djangorestframework-3.1.1-py2.7.egg/rest_framework/serializers.py”, line 568, in to_representation
self.child.to_representation(item) for item in iterable
File “/opt/rockstor/eggs/djangorestframework-3.1.1-py2.7.egg/rest_framework/serializers.py”, line 426, in to_representation
attribute = field.get_attribute(instance)
File “/opt/rockstor/eggs/djangorestframework-3.1.1-py2.7.egg/rest_framework/fields.py”, line 299, in get_attribute
return get_attribute(instance, self.source_attrs)
File “/opt/rockstor/eggs/djangorestframework-3.1.1-py2.7.egg/rest_framework/fields.py”, line 70, in get_attribute
instance = getattr(instance, attr)
File “/opt/rockstor/src/rockstor/smart_manager/models/task_def.py”, line 52, in share_name
sn = Share.objects.get(id=task_metadata[‘share’]).name
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/manager.py”, line 127, in manager_method
return getattr(self.get_queryset(), name)(*args, **kwargs)
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/query.py”, line 325, in get
clone = self.filter(*args, **kwargs)
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/query.py”, line 679, in filter
return self._filter_or_exclude(False, *args, **kwargs)
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/query.py”, line 697, in _filter_or_exclude
clone.query.add_q(Q(*args, **kwargs))
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/sql/query.py”, line 1310, in add_q
clause, require_inner = self._add_q(where_part, self.used_aliases)
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/sql/query.py”, line 1338, in _add_q
allow_joins=allow_joins, split_subq=split_subq,
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/sql/query.py”, line 1209, in build_filter
condition = self.build_lookup(lookups, col, value)
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/sql/query.py”, line 1102, in build_lookup
return final_lookup(lhs, rhs)
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/lookups.py”, line 105, in init
self.rhs = self.get_prep_lookup()
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/lookups.py”, line 143, in get_prep_lookup
return self.lhs.output_field.get_prep_lookup(self.lookup_name, self.rhs)
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/fields/init.py”, line 727, in get_prep_lookup
return self.get_prep_value(value)
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/fields/init.py”, line 985, in get_prep_value
return int(value)
ValueError: invalid literal for int() with base 10: ‘RockOnShare’

1 Like

@suman: For me, this bug stays there even after several reboots. And for the last three versions (now 3.9.2-9) running in two different boxes.

Thank you for your patience @yorgabr and @Hooverdan . I am travelling and have been bad with pushing fixes swiftly. Please try 3.9.2-10 and let us know.

1 Like

@suman - well, for me it looks like it worked. After the upgrade I can finally see me scheduled tasks screen again!

I’ll watch it until my next planned reboot and hope it will continue to work and then will mark it as solved.

Thank you!

One thing I have noticed is that a Scrub task that I had set up before the Task screen errors started occurring now had the Pool set to “N/A” (see the red box where it now has the correct pool associated) - though I do remember that when I set it up it had the appropriate pool assigned to the task.

Deleting the old task and creating a new one, seems to have addressed that. Maybe the task format/storage had changed since I had defined the task.

Thank you so much for this correction, @suman! It’s working for me now, both boxes.

@Hooverdan Hello again.

Yes that is exactly it, and the “N/A” was a placeholder of sorts to east the transition. We use to reference all pool activity by name including within task definitions, but then the hole project was moved to using database id’s to allow for pool renaming and to make more robust the general mechanism. Unfortunately this broke the tasks stuff as we also later did the same for shares, on my first pass at fixing scheduled tasks I introduced, by way of a quick fix, storing the id also so that we could still display the name where it was needed. @suman later improved on this with some transition code so that we could managed without the redundant name storage. So the up shoot was a quicker initial fix with some slightly confusing behaviour there after (the N/A for pool name for example) until the tasks were transitioned to using id only. Probably an over site in my original fixes but we got there in the end, at least for scrubs anyway. But some more prep has now gone into scheduled snapshots so that should be a smoother transition.

Hope that helps.

1 Like

@phillxnet
yup, that helps. Thanks for the detailed explanation. Glad it works now, and my tasks are executing, too.