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

ptmkenny created an issue. See original summary.

mikeytown2’s picture

Category: Bug report » Support request

Unknown 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.

mike503’s picture

could 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.

mikeytown2’s picture

@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.

mike503’s picture

@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.

mikeytown2’s picture

Define asset filenames.

The aggregated css/js files will be generated on demand; similar to core's image presets.

mike503’s picture

Request 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?

mikeytown2’s picture

markup is still referencing foobarbaz.css - does advagg hash things in a consistent way to regenerate it in place?

Yes 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.

mikeytown2’s picture

Any updates on this issue? Should I close it out?

mikeytown2’s picture

Status: Active » Postponed (maintainer needs more info)
mikeytown2’s picture

Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)