Feature request: allow specifying a directory where crashrecovery backups will be stored

[busimus]

I recently encountered a very niche issue that has to do with ungraceful resync.

Long story short: my browser profile is big, my system SSD is slow, whenever ungraceful state is detected it takes a long time for psd to create a backup. I wouldn't mind, but systemd has a 25 second limit on services that start at user login.

So if I log in while in ungraceful state, then my system hangs for 25 seconds on a login screen, after which systemd does the following:

1. Kills psd resync process, which leaves me with an incomplete crashrecovery backup,
2. Invalidates my user session, which breaks the rest of the system in peculiar ways.

The only way around these painful consequences is logging in as root, disabling the psd.service, after which I can safely log in in as my user and start psd.service manually. It's not a great solution.

But I have a very fast hard drive. If you could add the option in the config file to specify the directory in which crashrecovery will be created, then I could point that to my hard drive, which will have no problem writing a full crashrecovery folder in under 25 seconds.

Unless you have a better proposition on how to solve this problem, of course. Because this is the best one I've got.

EDIT: Just realized this issue is basically a copy of #197. Not really, since this solution wouldn't help people who don't have an option of fast storage, but it could help some.

[graysky2]

A problem with implementing would be that if you want the recovery dir to copy to another partition perhaps on slower media, it would have the opposite effect.

...How large is the browser profile? Unless it's running through a USB interface, any modern SSD should be fine with 100 MB or so profile. 25 sec seems excessive.

[busimus]

My chromium profile was 1.5GB at its peak. Most of that was due to junk being left by some website in the File System directory for whatever reason. I managed to get it down to 600MB, which is very close to what my SSD can write in 25 seconds (I know this because the corrupted crashrecovery backups were around this size).

if you want the recovery dir to copy to another partition perhaps on slower media

Well, I don't. :grinning:

[graysky2]

600 MB is insane. I have several profiles in mine and it's only 128 M. Use a util like ncdu to see what is taking up all that space and fix it.

[busimus]

It's hardly insane. I've used this profile for several years, so it naturally grew overtime. I got it down to 600MB with ncdu, the rest is lots of extensions and local storage, no easy targets anymore.

I cleaned up local storage a bit, it's 500MB now. I don't think it'll be getting much smaller. Still, time says it takes over 30 seconds to copy it, so I'm not out of the danger zone quite yet.

[graysky2]

Not sure what I can do to help you...

[busimus]

I mean, it's in the title of the issue.

But sure, I guess I'll try my luck with a pull request if I manage to implement this myself.

[graysky2]

...how do you think copying the directory to a different disk will improve this? Do you have a faster SSD you're not using as /home?

[busimus]

As I said in my original post, my system SSD is slow, but I have an HDD that is fast. It takes 1 second to write a 500MB profile to that HDD, as opposed to over 30 seconds in case of my SSD.

So if I could specify in the psd.conf that I want it to create crashrecovery folders on my HDD, then I will never have to worry about my profile being insanely large and it causing problems with resync.

[ixil]

Is there any chance of this being implemented (@busimus did you make a fork locally?). Less for the reason a large .config/chromium* directories, but rather I like to keep .config clean as this is all I backup, would $XDG_DATA_HOME or $XDG_CACHEbe more appropriate for crashrecovery files

[busimus]

Nah, the systemd issue was fixed so I forgot about it, sorry.