glad you worked it out but IMHO a request in appadmin should have created
.table AND the underlying structure on the db (in other words, there
shouldn't be a place on the universe where .table files are created but the
underlying tables on the backend are not created.)
On Monday, December 21, 2015 at 2:54:11 PM UTC+1, Gael Princivalle wrote:
>
> Done!
>
> Here is the solution (part is from another post from Leonel):
> Set db string conection with migrate=False and fake_migrate_all=False
> Delete scheduler.py file
> Delete scheduler table files
> Delete scheduler tables in db
> Set db string conection with fake_migrate_false=True
> Run admin (create table files)
> Remove fake_migrate_all and set migrate=True
> Create again the scheduler
> Run admin, tables are created in the db
>
> AND! Now scheduler works.
>
> Il giorno lunedì 21 dicembre 2015 09:35:20 UTC+1, Niphlod ha scritto:
>>
>> there's no way .table files are created but tables aren't ... please
>> triple check your settings ....
>>
>> On Sunday, December 20, 2015 at 9:28:39 PM UTC+1, Gael Princivalle wrote:
>>>
>>> Now tables files are created in the database folder, but tables are not
>>> created in the postgress DB.
>>> Error in always the same when I try to open a table from the
>>> administration interface.
>>>
>>> ProgrammingError: relation "scheduler_worker" does not exist
>>> LINE 1: SELECT count(*) FROM "scheduler_worker" WHERE ("scheduler_wo...
>>>
>>>
>>> About migrations my db is like that:
>>> db = DAL('postgres://user:pass@localhost:5432/postg_db',
>>> check_reserved=['all'], pool_size=1, entity_quoting=True, bigint_id=True,
>>> migrate=True, fake_migrate_all=True)
>>>
>>> And I've saw also that in the complete scheduler signature you can set
>>> migrate to True so in scheduler.py I have:
>>> Scheduler(db, dict(e_db=e_db, update_products_auto=update_products_auto,
>>> sitemap_txt_auto=sitemap_txt_auto), migrate=True)
>>>
>>> PostgreSQL tables are not created.
>>> So this is a desperate attempt, deleting all scheduler and create it
>>> again. I've done it for resolving this scheduler problem, it don't runs for
>>> all my old four applications that I've moved with "pack all" from 2.9.12.
>>> version to this 2.12.3 version. DB's are new. I've moved data with
>>> export/import linux commands, pg_dump, psql.
>>>
>>> And for new applications scheduler runs.
>>>
>>> How can I make the debug of it?
>>>
>>> Thanks.
>>>
>>>
>>> Il giorno domenica 20 dicembre 2015 13:51:45 UTC+1, Niphlod ha scritto:
>>>>
>>>> you just had to delete corresponding .table files. scheduler tables are
>>>> created as soon as the scheduler is istantiated, unless migrations are
>>>> turned off.
>>>>
>>>> On Friday, December 18, 2015 at 4:17:48 PM UTC+1, Gael Princivalle
>>>> wrote:
>>>>>
>>>>> No I don't.
>>>>>
>>>>> But now I have:
>>>>> Dropped all tables in the database folder
>>>>> Delete all scheduler tables in the postgress database.
>>>>> Delete the scheduler
>>>>> Create the scheduler.
>>>>> I still have the same db error, for example for workers:
>>>>>
>>>>> SELECT count(*) FROM "scheduler_worker" WHERE ("scheduler_wo...
>>>>>
>>>>> table files are created but not for scheduler tables
>>>>> scheduler tables in postgress db are not created.
>>>>>
>>>>> Do you know why?
>>>>>
>>>>> Il giorno venerdì 18 dicembre 2015 15:48:06 UTC+1, Niphlod ha scritto:
>>>>>>
>>>>>> when you dropped tables, did you remember to delete the corresponding
>>>>>> *.table files from the databases/ folder ?
>>>>>>
>>>>>> On Friday, December 18, 2015 at 12:47:38 PM UTC+1, Gael Princivalle
>>>>>> wrote:
>>>>>>>
>>>>>>> >scheduler tables can be dropped manually
>>>>>>> Done
>>>>>>>
>>>>>>> >deleting scheduler.py also.
>>>>>>> Done
>>>>>>>
>>>>>>> >But I still don't think that it's the way to fix the issue you're
>>>>>>> facing.
>>>>>>> Well I'm not able to understand which is this problem, as when I
>>>>>>> create a scheduler in a new app tasks are running.
>>>>>>> For the moment creating a new scheduler is my better idea, if you
>>>>>>> have a better one thanks.
>>>>>>>
>>>>>>> Anyway now I've got this error when I try to open the scheduler
>>>>>>> table, for example scheduler_task.
>>>>>>> My db string have now migrate=True, fake_migrate_all=True.
>>>>>>> My only other idea is rebuild all the app starting from a new one,
>>>>>>> but if I can resolve it in a shorter way I prefer.
>>>>>>>
>>>>>>> Traceback (most recent call last):
>>>>>>> File
>>>>>>> "/home/tasko/webapps/w2p_2_12_3/web2py/applications/hydrover_oleodinamica/controllers/appadmin.py",
>>>>>>> line 238, in select
>>>>>>> nrows = db(query).count()
>>>>>>> File
>>>>>>> "/home/tasko/webapps/w2p_2_12_3/web2py/gluon/packages/dal/pydal/objects.py",
>>>>>>> line 1992, in count
>>>>>>> return db._adapter.count(self.query,distinct)
>>>>>>> File
>>>>>>> "/home/tasko/webapps/w2p_2_12_3/web2py/gluon/packages/dal/pydal/adapters/base.py",
>>>>>>> line 1311, in count
>>>>>>> self.execute(self._count(query, distinct))
>>>>>>> File
>>>>>>> "/home/tasko/webapps/w2p_2_12_3/web2py/gluon/packages/dal/pydal/adapters/postgres.py",
>>>>>>> line 360, in execute
>>>>>>> return BaseAdapter.execute(self, *a, **b)
>>>>>>> File
>>>>>>> "/home/tasko/webapps/w2p_2_12_3/web2py/gluon/packages/dal/pydal/adapters/base.py",
>>>>>>> line 1378, in execute
>>>>>>> return self.log_execute(*a, **b)
>>>>>>> File
>>>>>>> "/home/tasko/webapps/w2p_2_12_3/web2py/gluon/packages/dal/pydal/adapters/base.py",
>>>>>>> line 1372, in log_execute
>>>>>>> ret = self.cursor.execute(command, *a[1:], **b)
>>>>>>> ProgrammingError: relation "scheduler_task" does not exist
>>>>>>> LINE 1: SELECT count(*) FROM "scheduler_task" WHERE ("scheduler_task...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Il giorno venerdì 18 dicembre 2015 11:58:15 UTC+1, Niphlod ha
>>>>>>> scritto:
>>>>>>>>
>>>>>>>> scheduler tables can be dropped manually
>>>>>>>> deleting scheduler.py also.
>>>>>>>> But I still don't think that it's the way to fix the issue you're
>>>>>>>> facing.
>>>>>>>>
>>>>>>>> On Friday, December 18, 2015 at 11:22:57 AM UTC+1, Gael Princivalle
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> >delete what ? the istantiation ?
>>>>>>>>>
>>>>>>>>> Delete the scheduler.py file from models and all scheduler tables.
>>>>>>>>> How can I do it?
>>>>>>>>>
>>>>>>>>> Il giorno venerdì 18 dicembre 2015 10:48:23 UTC+1, Niphlod ha
>>>>>>>>> scritto:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Friday, December 18, 2015 at 10:45:22 AM UTC+1, Gael
>>>>>>>>>> Princivalle wrote:
>>>>>>>>>>>
>>>>>>>>>>> I've set a scheduler in a new application and tasks are running.
>>>>>>>>>>>
>>>>>>>>>>> So probably there's a problem when a app comes from a previous
>>>>>>>>>>> web2py version.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> as long as you let migration happen, no issues whatsoever.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Anyway I think it can be resolved deleting the scheduler and
>>>>>>>>>>> create it again, but I've tried to:
>>>>>>>>>>> Killing the worker - Ok
>>>>>>>>>>> Delete Scheduler Ko
>>>>>>>>>>>
>>>>>>>>>>> When I delete the scheduler.py file from admin web2py creates it
>>>>>>>>>>> again.
>>>>>>>>>>>
>>>>>>>>>>> How can I delete the scheduler?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> delete what ? the istantiation ?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks, regards.
>>>>>>>>>>>
>>>>>>>>>>> Il giorno giovedì 17 dicembre 2015 21:40:36 UTC+1, Gael
>>>>>>>>>>> Princivalle ha scritto:
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks Niphlod.
>>>>>>>>>>>>
>>>>>>>>>>>> >So, here it is the breakdown of the possible issues:
>>>>>>>>>>>> >- are tasks QUEUED or ASSIGNED ?
>>>>>>>>>>>> QUEUED. But if I set the net run time to now + 2 minutes I can
>>>>>>>>>>>> check that task don't run.
>>>>>>>>>>>> Status options don't have ASSIGNED.
>>>>>>>>>>>>
>>>>>>>>>>>> >If they are QUEUED, either they can't be executed yet (i.e.
>>>>>>>>>>>> start_time in the future) or tasks are queued with a group_name
>>>>>>>>>>>> that can't
>>>>>>>>>>>> be processed by a worker .
>>>>>>>>>>>> Main group for all.
>>>>>>>>>>>>
>>>>>>>>>>>> *>Check #1: there should be a scheduler_task row with
>>>>>>>>>>>> group_name "in" scheduler_worker group_names*
>>>>>>>>>>>> >- if tasks SHOULD be ASSIGNED but remain on QUEUED status, no
>>>>>>>>>>>> worker is running or workers can't agree on who is "the ticker".
>>>>>>>>>>>> Well worker is running and main is the group_name.
>>>>>>>>>>>>
>>>>>>>>>>>> *>Check #2 (there should be a scheduler_worker with is_ticker =
>>>>>>>>>>>> True)*
>>>>>>>>>>>> Yes it have.
>>>>>>>>>>>>
>>>>>>>>>>>> Check is complete. I think I will cancel the scheduler and
>>>>>>>>>>>> create it again. Thanks for your help.
>>>>>>>>>>>>
>>>>>>>>>>>> Il giorno giovedì 17 dicembre 2015 21:21:56 UTC+1, Niphlod ha
>>>>>>>>>>>> scritto:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I thought more people liked to see the code : I find myself
>>>>>>>>>>>>> explaining scheduler internals more often than I'd like to :P
>>>>>>>>>>>>>
>>>>>>>>>>>>> soooooooooo. worker names.... worker names are used to
>>>>>>>>>>>>> identify a worker process (it's enforced as unique in the
>>>>>>>>>>>>> model)...
>>>>>>>>>>>>> I'll reply to some ideal "FAQ" questions....
>>>>>>>>>>>>> - Why worker names are important ? Because tasks ASSIGNED to a
>>>>>>>>>>>>> worker_name (assigned_worker_name in scheduler_task) get
>>>>>>>>>>>>> processed by that worker, and that worker only
>>>>>>>>>>>>> - Who chooses worker names ? the worker itself. It does so
>>>>>>>>>>>>> concatenating the hostname and the PID, which results in a good
>>>>>>>>>>>>> (and
>>>>>>>>>>>>> unique) way to identify a process.
>>>>>>>>>>>>> - Who chooses that task "foo" gets processed by worker "bar" ?
>>>>>>>>>>>>> A worker. It's when tasks from QUEUED go to the ASSIGNED
>>>>>>>>>>>>> status... The
>>>>>>>>>>>>> worker that does this is "the ticker". The ticker is "elected"
>>>>>>>>>>>>> with a dumb
>>>>>>>>>>>>> (and slow) - but reliable - algorithm among workers: it's the
>>>>>>>>>>>>> only one that
>>>>>>>>>>>>> can "assign" tasks (either to itself or to other workers). The
>>>>>>>>>>>>> only thing
>>>>>>>>>>>>> that blocks a ticker to assign tasks to a worker is the
>>>>>>>>>>>>> group_name.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, here it is the breakdown of the possible issues:
>>>>>>>>>>>>> - are tasks QUEUED or ASSIGNED ? If they are QUEUED, either
>>>>>>>>>>>>> they can't be executed yet (i.e. start_time in the future) or
>>>>>>>>>>>>> tasks are
>>>>>>>>>>>>> queued with a group_name that can't be processed by a worker .
>>>>>>>>>>>>> *Check #1: there should be a scheduler_task row with
>>>>>>>>>>>>> group_name "in" scheduler_worker group_names*
>>>>>>>>>>>>> - if tasks SHOULD be ASSIGNED but remain on QUEUED status, no
>>>>>>>>>>>>> worker is running or workers can't agree on who is "the ticker".
>>>>>>>>>>>>> *Check #2 (there should be a scheduler_worker with is_ticker =
>>>>>>>>>>>>> True)*
>>>>>>>>>>>>> That should be it.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Note: if tasks are ASSIGNED to a worker that isn't there
>>>>>>>>>>>>> anymore (i.e. is dead or, in your case, you changed hosting
>>>>>>>>>>>>> facility) it's
>>>>>>>>>>>>> not an issue. Any worker, periodically, checks if ALL other
>>>>>>>>>>>>> workers are
>>>>>>>>>>>>> alive (and kicking) and if a worker isn't kicking it's removed
>>>>>>>>>>>>> from the
>>>>>>>>>>>>> scheduler_worker table AND all tasks ASSIGNED to it gets
>>>>>>>>>>>>> redistributed
>>>>>>>>>>>>> among live workers. This in addition to the ticker redistributing
>>>>>>>>>>>>> tasks
>>>>>>>>>>>>> every once in a while if they're ready to be executed but not
>>>>>>>>>>>>> executed yet
>>>>>>>>>>>>> (it can, and it does happen, that a worker is busy processing a
>>>>>>>>>>>>> long-running task while there are other tasks ready to be
>>>>>>>>>>>>> processed (by
>>>>>>>>>>>>> other workers). Every worker gets a fair chance of doing
>>>>>>>>>>>>> something useful
>>>>>>>>>>>>> instead of sleeping)
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thursday, December 17, 2015 at 9:02:11 PM UTC+1, Gael
>>>>>>>>>>>>> Princivalle wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hello to all.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've migrate my webfaction hosting to another webfaction
>>>>>>>>>>>>>> hosting that run CentOS 7 (before it was a previous version
>>>>>>>>>>>>>> of CentOS).
>>>>>>>>>>>>>> I was running web2py 2.9.12, now I have web2py 2.12.3.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've got a strange problem with the scheduler.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Workers are in the db, they run, they are assigned to tasks,
>>>>>>>>>>>>>> but tasks don't run.
>>>>>>>>>>>>>> When I've created new workers tasks have not take
>>>>>>>>>>>>>> automatically the worker name. I've put all worker names by
>>>>>>>>>>>>>> myself.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Perhaps the problem is due to the worker names.
>>>>>>>>>>>>>> In the previous hosting they were like that:
>>>>>>>>>>>>>> s18060957#14459
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And now they have the webserver name:
>>>>>>>>>>>>>> web490.webfaction.com#12949
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> web2py seems to codify the webserver name, but in this new
>>>>>>>>>>>>>> configuration it don't.
>>>>>>>>>>>>>> Is it why Scheduler don't run tasks?
>>>>>>>>>>>>>> How I can resolve that?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks, regards.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
