Going to checkout master right now, hang on.
Checking out master (and flushing redis and restarting) didnāt change anything.
I did look through the bugfixes after 0.9.8.4 and I verified that those are now there. Should have gone to master before posting this issue, my apologies for that. But in this case it didnāt solve the problem.
BTW Iām on multisite, since there were a few multisite bugs Iām now going to hack my config and see if this occurs on the main site as well.
EDIT yes it occurs on the main site as well.
Iām seeing this Internal Server Error on my test docker setup, too.
1 Like
Do you also see the āNot Scheduled Yetā messages @riking?
Flush redis to make the screen work again, or replace
@schedules = Scheduler::Manager.discover_schedules.sort do |a,b|
a.schedule_info.next_run <=> b.schedule_info.next_run
end
by
@schedules = Scheduler::Manager.discover_schedules
in lib/scheduler/web.rb
Yes, and yes it happened after clicking Schedule. Basically the exact same thing you reported. I havenāt flushed redis yet though.
(will sort out first thing tomorrow)
curious, can you add a few āputsā statements and find out why its not scheduling stuff? only about 20 lines of code involved in all of this.
If you need an external guinea pig, Iām happy to volunteer. I know Iām somewhat of an odd duck since Iām banging along with Passenger, but Iām happy to help if thereās any way I can be useful.
2 Likes
hi!
I think my problem with deployment through the capistrano related to this topic, yes or not?
when I try to deploy I see these error:
uninitialized constant IceCube::ValidatedRule
/home/deployer/hanuman/releases/20140209154603/lib/freedom_patches/ice_cube.rb:2:in `<module:IceCube>'
/home/deployer/hanuman/releases/20140209154603/lib/freedom_patches/ice_cube.rb:1:in `<top (required)>'
/home/deployer/hanuman/releases/20140209154603/config/initializers/02-freedom_patches.rb:2:in `block in <top (required)>'This is totally unrelated @MpaK we no longer have this gem installed, looks
like a bad merge of a fork or something
we sure do, but its going to have to wait till @zogstrip finalizes the import / export stuff
I fixed the sorting issue, but am unable to reproduce the issue where the scheduler does not run at all.
on a clean docker install my scheduler is firing fine.
1 Like
Oh yeah, it was running. Iāve got a happy face on the update check.
LMK whenever. This ought to be an interesting test case, considering how much my install has been through since, uhā¦(checks)ā¦March 2013 
Sorting issue is gone, when I hit Trigger then a job is scheduled, and it looks like it is re-scheduled after it has ran.
So there is only an initialization issue left. Iāll have a further look tonight, @sam can you give me some pointers where to look?
Ok. Found it. Just to share our shame:
After endless debugging, it seemed like Redis was not storing anything upon startup.
Then we finally remembered the following line in our startup script, right AFTER starting sidekiq.
echo flushdb | /usr/bin/redis-cli
It was put there many, many months ago, trying to work around a totally different and long, long forgotten issue. 
This is the first time that Discourse ever relied on redis. Before this change, redis was ājustā a cache.
2 Likes
Actually it always sort of relies on Redis, when you nuke you would miss out on a pile of scheduled jobs, emails would go missing for example. message bus would also play up.
1 Like
Just unpinned this, no serious issues were found.
1 Like
Backup/Restore is now available in master. Please try it out 
WARNING: backups are safe, but restore might require a server restart (just kill the thins/unicorns).
2 Likes
Backup generates this log (password redacted!) and completes successfully. I now have a 15MB .tar.gz backup file under /public/backup/defaults
Read-only mode appears to work correctly.
However, the āRestoreā and āRollbackā buttons are grayed out and display the āNoā cursor when I attempt to click them.
edit - @zogstrip or @sam, happy to grant you guys temporary admin accounts if you want to look at anything.