I can't find the issue that added this, but from what I remember:
- the installer has a blocking cron run at the end - this makes it take longer and shows up in profiling, including via drush.
- we show a warning when cron hasn't run for X period of time.
- this used to happen immediately after installing
- to avoid the site from showing warnings just after install, we added a cron run to the end of the installer
- this was probably (not sure) before poormanscron was added to core
1. Remove the cron run from the installer and see if the warning even shows up any more now that poormanscron is enabled by default.
2. If the warning does show up, discuss some more.
| Comment | File | Size | Author |
|---|---|---|---|
| #35 | skip-cron-during-install.gif | 1.08 MB | ressa |
| #1 | cron-installer-2422681-1.patch | 808 bytes | berdir |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes, plain diff MR !10480
Comments
Comment #1
berdirAh, the comment in the code actually explains why it is done. *Because* of update.module. But with poormans cron, that's possibly OK too, then you get the warning on the second or third or so page request, but fairly soon enough as well.
That said, thinking about it, I'm actually relying on this right now, because my install profile includes default content and search_api, and I expect the search index to be populated after an installation, which happens because of the cron run. But I guess I can always add that back in my install profile, 5s more won't make a huge difference there.
Comment #3
catchHmm so that comment also mentions search as well.
I'm wondering whether we should revisit #1599622: Run poormanscron via a non-blocking HTTP request first, all the blockers to that issue are in now.
Comment #19
catchComment #21
berdirMR is green, but the previous run had 5+ random fails, and the JS one I can reproduce locally (sometimes), but also on 11.x I get that error there.
Still, that's a lot of bad luck, wondering if the removed cron somehow increaess the chance of those random fails.
Comment #22
longwaveI have been seeing multiple random fails on many core MRs recently, up to four jobs failing but that pass on retry, so not sure this is any worse.
Comment #23
nicxvan commentedThis also fixes #3491780: Theme hooks not found warning on Umami install
Comment #24
nicxvan commentedI tested this against 3491780 which is why I found this old issue.
The issue there is that during install we don't load all theme hooks, but this is an issue during cron because items are rendered.
I think @longwave's comment has been addressed, feel free to put it back in needs work if you think it needs more discussion.
Comment #25
catchThis looks really good. I had assumed Drupal CMS included automated_cron but it looks like it doesn't, opened #3492390: Add automated_cron to base recipe.
I think it would be good to manually test (unless we have exact test coverage) that installing umami or standard via the UI and cli, and then visiting the site, and then getting to admin/reports as quickly as possible via the admin menu, doesn't result in warnings on the status report that would be solved by running cron. It should not be possible, but it would be good to confirm.
Comment #26
nicxvan commentedComment #27
berdirDid some manual testing, with the UI installer, rushing through the configure page as quickly as I can.
On standard, it works well, I when I click on reports => status as quick as I can tells me that cron did run 8-10s ago and update status is there. Also no message on admin/config. Based on the timing of 8-10s, I suspect that cron already runs during the installer?
Umami is a bit slower because it has quite a bit it needs to index. I don't see a message on admin/config but the status report then is a bit confused. Cron is reported as having run also some 10s ago, but update module reports that it has no data. waiting a bit and refreshing then shows data. Maybe cron runs before update.module is enabled? I first thought that maybe the timestamp is set before the cron actually runs, but that doesn't seem to be the case.
It's only a warning and only on the status page and you have to be fairly quick to get there, I feel like that's an acceptable tradeoff?
Comment #28
catchI have a feeling it would run on the install_configure_form step since we have Drupal fully installed at that point, but haven't verified this. If so then that's good though because it'll be in kernel destruct and hence non-blocking on most environments, but also still very early in the process relative to being able to browse to an admin page.
It's also theoretically possible it could even end up running during the batch after automated_cron - but if that's the case, then same thing.
Comment #29
moshe weitzman commentedFWIW, I would not be surprised if automatic cron took some time to run, after it gets installed. In other words, I think it would be fine if it did nothing at install time. Its OK that module information would be unavailable for a bit.
Comment #30
alexpottI checked this and we don't because we are relying on the terminate event and that is not called during the installer. It's only called by index.php and not be the request handling in install_drupal() ... so we only hit automated cron on the redirect to the frontpage from the installer. Which oddly feels good considering the update module is enabled on install_configure_form submission and we don't have an email address yet - as user 1 is configured there too.
Comment #31
catchOK yes that seems ideal actually and probably consistent with @berdir's 8 seconds - it would include the entire request + browser rendering of the front page which is likely to be at least a second with caches being built etc. + some human clicking time to get to the reports page, plus the loading time of that page until it retrieves the timestamp.
Comment #32
catchThat covers the manual testing I think.
Comment #33
catchNo wait we should fix the message in CronForm, not sure the test is really necessary but the grammar fix would be good..
Comment #34
catchWe already have test coverage of the form, and it explicitly checks that we don't show 'years' on the page for when cron has never run, so it needs to be adapted anyway.
Comment #35
ressaI have been running the installer repeatedly lately, making side-by-side recordings comparing Drupal 11.1 and Drupal 11.2, and I noticed a lot of time was spent on Cron.
So I was glad to find this issue, since the patch gets the Standard install down to around 5 seconds -- a big improvement, slicing even more time off, Drupal 11.1's 15 seconds and Drupal 11.2's 10 seconds.
Don't run Cron during install
Comment #36
catchTentatively tagging for release highlights.
Comment #37
nicxvan commentedI think this is ready now, I think @berdir answered @alexpott's concern.
I was a little unsure about 33-34, but I think @catch was saying the text change was correct and I agree.
Comment #38
catchJust to confirm 33-34 I think that's all OK now yeah.
Comment #39
alexpottSaving issue credit
Comment #40
alexpottCommitted 32a1337 and pushed to 11.x. Thanks!
Comment #42
andypostLooks like it needs follow-up as help is not shown after install
Comment #44
alexpottJust found another reason why this is a good idea. During install we limit theme hooks to only those from system module - see \Drupal\Core\Theme\Registry::build() so any cron hooks that doing any theming are going to struggle.
I think separating cron from the installer is the best way to go here - rather than trying to make the full theme system available once all the modules and themes are installed.
Comment #45
casey commentedPatch from 32a1337 for usage with composer patches on D11.1 projects.