@robi there is a already bunch of "workarounds" for rsync. Empty directories, executable bit of files cannot be stored in most object storage. So, there is fsmetadata.json file that stores this information outside of the files. When restoring, we use that file to restore back the state. I guess we can extend that file to also save and restore timestamps. If anyone wants this leave a note and I can look into it in the future.

@nebulon thanks!

Since nobody has any suggestions so far, I am going to just kick off the installer again and see if anything goes differently.

@eddowding Plug: https://git.atridad.dev/CTPR Instructions: https://git.atridad.dev/CTPR/docs/ctpr-documentation

@nebulon Thanks. I did search but must have overlooked this.

@atridad yeah, I just bumped the internal default for data directory migration to be 1GB . I tested with ~500GB now and it's all good.

@girish ah yes, that makes sense. And recent ones are being deleted, yes. Thanks again.

Looks like this change broke WP - https://forum.cloudron.io/topic/5385/wp-cli-not-working-on-6-3-5

@girish Thanks for the info and all the work (support) you have done for me Girish

Thanks a bunch @girish worked like a charm

@vladimir-d thanks for debugging this! So, let me create largish archive to see if I can reproduce this.

@christiaan On linode, if you are a new account, you can usually open a support ticket and explain your use case of email hosting to them and they usually unblock port 25.

@jegillikin-0 mm, that shouldn't be the reason. But something for me to ask future users who hit the same problem.

@girish Thanks -- I discovered this, finally. Don't know why I didn't see it immediately.

Found the template with: sudo grep -rnw '/' -e 'rtcsec'

@girish Yes, that would have been the case. Sorry for not responding here, real life has been busy the past few days Thanks for the fix!

Funny, I just noticed this as well the other day but I figured it was just me because I'm running macOS beta so thought the new Safari overhaul killed something. haha. Glad to know it's a known issue and already fixed for the next release.

The full stack trace is: 16/07/2021 17:58:24 :: [console] Error writing to collectd.localhost.df-sdc1.df_complex-used: Unable to read header (/var/lib/graphite/whisper/collectd/localhost/df-sdc1/df_complex-used.wsp) 16/07/2021 17:58:24 :: [console] Unhandled Error Traceback (most recent call last): File "/usr/lib/python3/dist-packages/twisted/python/threadpool.py", line 266, in <lambda> inContext.theWork = lambda: context.call(ctx, func, *args, **kw) File "/usr/lib/python3/dist-packages/twisted/python/context.py", line 122, in callWithContext return self.currentContext().callWithContext(ctx, func, *args, **kw) File "/usr/lib/python3/dist-packages/twisted/python/context.py", line 85, in callWithContext return func(*args,**kw) File "/usr/lib/python3/dist-packages/carbon/writer.py", line 189, in writeForever writeCachedDataPoints() --- <exception caught here> --- File "/usr/lib/python3/dist-packages/carbon/writer.py", line 165, in writeCachedDataPoints state.database.write(metric, datapoints) File "/usr/lib/python3/dist-packages/carbon/database.py", line 124, in write whisper.update_many(path, datapoints) File "/usr/lib/python3/dist-packages/whisper.py", line 740, in update_many return file_update_many(fh, points, now) File "/usr/lib/python3/dist-packages/whisper.py", line 747, in file_update_many header = __readHeader(fh) File "/usr/lib/python3/dist-packages/whisper.py", line 294, in __readHeader raise CorruptWhisperFile("Unable to read header", fh.name) whisper.CorruptWhisperFile: Unable to read header (/var/lib/graphite/whisper/collectd/localhost/df-sdc1/df_complex-free.wsp) The last line gives a hint that the graphite file is corrupt. So, I removed all the whisper files in /home/yellowtent/platformdata/graphite/whisper/collectd/localhost/df-sdc1 and graphs seems to work after that. @atridad Maybe a good idea to check the health of the hard disk ? Also, since we hit the systemd issue on the same server.

For future reference, systemd was acting all strange. We got all sorts of errors. # systemctl restart box Failed to restart box.service: Connection timed out See system logs and 'systemctl status box.service' for details. # systemctl status box Failed to get properties: Connection timed out # systemctl status box Failed to get properties: Failed to activate service 'org.freedesktop.systemd1': timed out (service_start_timeout=25000ms) Restarting the server seems to fix it.

@privsec That worked, thanks!