Error in rules Scheduler module on PostgreSQL

do you mean that the scheduler doesn't perform it's task (whether the cron runs or not)?
If so -
I'm using postgres and hitting the same situation.

This is a complete guess, but I think this is due to the data type being unknown to Entity API for rules_wrap_data(). Please provide more info about the data being processed or how track this error down.

Please post the component.

I'm also still having this difficulty, and this may be (or not) related to postgress.
However, I get also this on the error log:
after "cron completed successfully" I get the following message:
Notice: unserialize(): Error at offset 23 of 26 bytes in rules_scheduler_run_task() (line 61 of .../rules/rules_scheduler/rules_scheduler.module), which I suspect is the reason for this error.

See similar issue in this thread: http://drupal.org/node/1615472

has this been resolved as it has been since June 2012 and the additional information requested has been provided. I too am getting this error even after I've cleared out all scheduled task

Attempting to re-run cron while it is already running. Call to a member function restoreBlocks() on a non-object (line 62 of /var/www/html/drupal/sites/all/modules/rules/rules_scheduler/rules_scheduler.module).

The deletes it self however it does not actually run(as the component I have setup send an email notification). I also notice that randomly after a few days or weeks it goes through. I'm using ultimate cron and i recently put on elysia however both are giving the error which makes me inclined to believe that it is an issue with rules_scheduler_tasks.

To anyone having this problem the solution for me was inserting a watchdog error in the rules scheduler module that printed out the array for $task. From that I was able to determine the component type giving me the error. After deleting the component giving the error all my old jobs came up.
If you are not into programming simply export all you components and delete them one by one until you find the offending component.

Placing as closed but feel free to open back. In my opinion the fault is not in scheduler but in a component that may have had an error in creation(although mine worked fine for a while before i got the error)

This is not fixed - what you posted is a workaround, not a solution. Also, assigning an issue to yourself generally means you're working on a patch or otherwise attempting to solve the problem - it's to prevent duplication of effort rather than a claim of credit.

if a rules component has an error, then I'd expect the validity checker to notice. At the very least, we should be getting a helpful log message describing why the component in question failed.

Is more information still required than lollipopp's component? I could provide an export of my rule/component as well if it would help (I'm updaing content, scheduled based on a Date field - nothing complex enough that it should cause an error).

I haven't checked the code, but if I had to guess, I'd say that the problem is in serializing/unserializing an entity reference for rules_scheduler.

It looks like the RulesState object is getting truncated somehow. This is the 'data' value stored in the queue table. It ends up looking like this on unserialize (at rules_scheduler.module line 58 ($state->restoreBlocks() fails):

Array
(
[tid] => 5
[config] => rules_test
[date] => 1352963700
[state] => O:10:"RulesState":3:{s:7:"
[identifier] => unpublish387
)

This may happen in the job_scheduler module. Hopefully may find out a bit more.

Actually, it looks like the RulesState object isn't being correctly serialized in the first place (in rules_scheduler_action_schedule in rules_scheduler/rules_scheduler.rules.inc). It appears to be initiated fine, but when trying to serialize this object immediately after initiation I see the same result as above

O:10:"RulesState":3:{s:7:"

Can't see quite where that is happening. There was talk of a php bug where ArrayObject wasn't serializing (but that was related to having an Iterator in it), so not sure if that is the issue. This must be a very specific issue as otherwise more people should see it. Am on PHP v 5.3.2

-->Found on another site, so have created a new issue here: https://drupal.org/node/2012680

threewinds..moderator or not you should get off your high horse..I didn't assign to me to claim credit. I only did it because I wasn't sure how to fill out the stupid form.

Secondly it is a valid fix. It fixed my problem as the issue was a corrupted component.I only posted it to help any one else having a problem(which it just so happens is the reason I am back here after having the problem again). Your attitude really isn't necessary and is problem the reason there is an exodus to WP from drupal

if a rules component has an error, then I'd expect the validity checker to notice. At the very least, we should be getting a helpful log message describing why the component in question failed.

Which is exactly what I did by putting in the watch dog as the information out of rules isn't sufficient to narrow down the error. Maybe the recommendation should be for whoever maintains the code to add a bit more information when this error is thrown

For me it worked clearing the Rules cache (which I have a feeling is not cleared with other caches). Clearing that cache can be done at: /admin/config/workflow/rules/settings/advanced

Working perfectly for me, hope this helps you.
This applies only to Postgresql users. After a task gets scheduled, if you look in the rules_scheduler table in the database, you will notice that the data column (of type text) has a partial serialized object. Php serialization represents empty data as a null byte (\0) and writing this data out as a string with the null byte in it will result in a truncated string when writing to the database. This led to the question of why is the data column defined as text and not blob (bytea). Bingo! Change your data column to bytea and everything will start working correctly. It doesn't matter that the schema in the rules_scheduler.install file says the data column should be text.
sql to change the data type:
ALTER TABLE rules_scheduler
ALTER COLUMN data TYPE bytea USING data::bytea;

Probably need to get rid of the bogus rows first.

I'm using MySQL, converting the table to blob didn't fix it for me. Still have hanging cron tasks due to this.

It seems the serialization part is ok (i can see the blob values with the null bytes), but when unserializating the string gets truncated and throws a fatal error. At this point, i'm seriously considering @.

Any idea for a solution under MySQL?

Here's a slice of the problem...

O:10:"RulesState":3:{s:7:"\0*\0info";a:3: .....

This is using blob, using text it shows as

O:10:"RulesState":3:{s:7:"*info";a:3: .....

#EDIT: Mine was actually old tasks still stuck in scheduler table or something. Deleting them fixed the problem, and it seems gone for good.

I can confirm that the ALTER TABLE... by paparoach in #18 works for me too, to fix the Scheduler issues with PostgreSQL. Paparoach is right in his observation that the 'data' column in the database only stored up to the first NULL character in the serialized data.
Like dixon_ said in #17, a thourough flush of old caches is neccessary, after altering the column type.

Can somebody please create a patch for this (and maybe a new stable release???)? (as there is no doubt that it is wrong to break serialized data at the first NULL occurence).
I checked other columns in the database that also store serialized data, and they are all of type bytea. This is the only column I found to be of type text (but I didn't check them all).

I upped the priority, because this issue breaks (most/all) rules scheduler functionality for PostgreSQL.

The issue described in for example #19 seems to be a different issue, as it mentions MySQL. I think it should better be investigated independently.

Drupal 7.34
Rules 7.x-2.8
PostgreSQL 9.1+134wheezy4 (Debian stable)

I can confirm the same restoreBlocks() error in MySQL. It it present even if no tasks are scheduled. The issue seems to be present whenever I create a Rule Component. I changed the data column from text to blob, and the issue is still there (after flushing rules and "all" caches). I'm using Rules 2.9. I filed a separate issue for this, since it's MySQL, but it seems they are related and this might be helpful to get to the bottom of it.

:/sites/all/modules# drush cron
PHP Fatal error:  Call to a member function restoreBlocks() on a non-object in /sites/all/modules/rules/rules_scheduler/includes/rules_scheduler.handler.inc on line 31
Fatal error: Call to a member function restoreBlocks() on a non-object in /sites/all/modules/rules/rules_scheduler/includes/rules_scheduler.handler.inc on line 31
Drush command terminated abnormally due to an unrecoverable error.                                                                [error]
Error: Call to a member function restoreBlocks() on a non-object in
/sites/all/modules/rules/rules_scheduler/includes/rules_scheduler.handler.inc, line 31

UPDATE: My issue seemed to stem from me altering the evaluation date via phpMyAdmin in order to test the rule. Apparently that breaks rules. Sorry for false alarm.

I can confirm that change rules_scheduler.data column to bytea fixes problem.

And here is a note which probably can save some time to people who will find this problem: probably you need to clear some(or all if you have dev/stage environment) data from {queue} table. I lost some hours on exploring this little knowledge.

I think that this can be good issue for my first contrib commit later this week.

Hi,

Using Rules 2.9 and postgres 9.4
I encountered the issue described above and applied fix:
ALTER TABLE rules_scheduler
ALTER COLUMN data TYPE bytea USING data::bytea;
Then I removed all existing tasks in the rules_scheduler table and removed corresponding rows in the queue table but I still have the issue...

Don't kow what to do anymore ???

Thx for help

Cleared all(mostly Rules) caches?
And (possibly) changed rules_scheduler_schema() ?

I turned on testing for Rules with PostgreSQL, and it shows this unserialize() error with the rules_scheduler module. So now that we have a test that demonstrates this bug we should be able to write a patch that fixes it.

To test, you will need the patch from #6 in #2999820: [D7] Make tests work with PostgreSQL

Here's a patch that changes the column from 'text' to 'blob' size 'big'. (blob:big is also what rules.module uses for storing rules configurations). Patch includes a hook_update_N().

Testing against MySQL only at this time because of the issue in #2999820: [D7] Make tests work with PostgreSQL. So this test will only tell us if the patch breaks MySQL tests.

I would appreciate it if some PostgreSQL users would download this patch, apply it, run update.php, and test to see if it fixes this problem.

Marked #2012680: RulesState not serializing properly due to text column as a duplicate.

Retesting #26 with PostgreSQL now that #2999820: [D7] Make tests work with PostgreSQL has been committed...

Committed.