There are several "Disk is full" messages, but this definitely should be happening, because the disk has a large amount of free space:
Message Write to file system failed. Disk is full. public://advagg_css/css__KH2_pCwF-sFzggn8i8LbreRdMqSd5LWvLgbY4oiNvnY__7cwkO2AVU3qa_SmaxSE4ALL-w4EGTQi9Cqtgq2afdxU__1Xfen4mIa_N5CvMntFY4Mx8RWVmvmvvdUNPPMIE2ZTU.css.gz
In addition, there are several "Write failed." messages.
Write failed. Target: public://advagg_css/file_advagg_hu5G7H.css
These are occurring for a variety of users at a variety of different times. I will try to debug this further, but I first wanted to check if this was a known problem with advagg on Pantheon.
Comments
Comment #2
mikeytown2 CreditAttribution: mikeytown2 commentedUnknown to me but it I don't run Pantheon. This is how that watchdog message is getting generated: http://cgit.drupalcode.org/advagg/tree/advagg.missing.inc#n1014
Looks real as in you ran out of disk space.
Comment #3
mike503 CreditAttribution: mike503 commentedcould the directory have hit it's maximum amount of files? that's been the case with modules like this in the past.
I came on here looking for reports of advagg not properly cleaning up old generated files or a "safe" way to handle that outside of the module... could be the same kind of thing though. This has happened on normal local and remote POSIX filesystems for us, I do not remember if it was advagg or something else though.
Comment #4
mikeytown2 CreditAttribution: mikeytown2 commented@mike503
You can "safely" remove all generated advagg files (rm); they will usually get auto regenerated. There is the slight chance of a momentary 404 if the delete and the request happens at the same time; hence the air quotes around safely; once the remove operation is done there shouldn't be any issues. If you where to rename the advagg_css/advagg_js directory and then delete it, that should be 100% safe.
You can also adjust the
drupal_stale_file_threshold
variable (see drupal_delete_file_if_stale()) if you want to be more aggressive when removing older aggregates (no longer valid, checks last accessed time). To check the current setting go to the admin/config/development/performance/advagg/operations page and under Cron Maintenance Tasks -> Clear All Stale Files it should say "Remove all stale files. Scan all files in the advagg_css/js directories and remove the ones that have not been accessed in the last X TIME". The core default value for this is 30 days.Comment #5
mike503 CreditAttribution: mike503 commented@mikey - yeah, that would be the case, except we have full-page caching enabled at the CDN level. the markup that gets cached at the edge still refers to assets that might be stale (In which case, there's nothing really this module can do to figure out if it's safe or not)
Unless the asset filenames persist or will generate by themselves in the same place at runtime. But I don't believe that's how it works.
Comment #6
mikeytown2 CreditAttribution: mikeytown2 commentedDefine asset filenames.
The aggregated css/js files will be generated on demand; similar to core's image presets.
Comment #7
mike503 CreditAttribution: mike503 commentedRequest comes through for /page/foo
CSS/JS assets don't exist yet - avdagg generates them, and Drupal spits out the /sites/default/files/advagg_css/foobarbaz.css etc
Remove the files off the filesystem
Next request comes through, markup is still referencing foobarbaz.css - does advagg hash things in a consistent way to regenerate it in place? or will it be a completely different filename then?
Comment #8
mikeytown2 CreditAttribution: mikeytown2 commentedYes it does. It will be the same filename; the request will create a file. Note that if the file can not be created the data will continue to be served from advagg and it will complain pretty loudly via watchdog.
Comment #9
mikeytown2 CreditAttribution: mikeytown2 commentedAny updates on this issue? Should I close it out?
Comment #10
mikeytown2 CreditAttribution: mikeytown2 commentedComment #11
mikeytown2 CreditAttribution: mikeytown2 commented