发表文章

[Shell] 功能请求: 允许指定将存储 crashrecovery 备份的目录 Feature request: allow specifying a directory where crashrecovery backups will be stored[profile-sync-daemon]

Busimus 2017-10-9 70

我最近遇到了一个非常利基的问题, 这与不重新同步。

长话短说: 我的浏览器配置文件很大, 我的系统 SSD 很慢, 只要检测到不状态, psd 就需要很长时间才能创建备份。我不介意, 但 systemd 有一个25秒的服务, 从用户登录开始的限制。

因此, 如果我在不状态下登录, 那么我的系统在登录屏幕上挂起25秒, 之后 systemd 执行以下操作:

  1. 杀死 psd 重新同步过程, 这给我留下了一个不完整的 crashrecovery 备份,
  2. 使我的用户会话无效, 从而以特殊的方式破坏系统的其余部分。

解决这些痛苦后果的唯一方法是以 root 身份登录, 禁用 psd.service , 之后, 我可以作为用户安全地登录并以手动方式启动 psd.service
这不是一个很好的解决方案。

但我有一个非常快的硬盘驱动器。如果您可以将配置文件中的选项添加到指定 crashrecovery 将被创建的目录中, 那么我可以将它指向我的硬盘, 在25秒内写入完整的文件夹不会有问题。

当然, 除非你对如何解决这个问题有更好的建议。因为这是我得到的最好的一个。

编辑: 刚意识到这个问题基本上是一个#197的副本。不太可能, 因为这个解决方案不会帮助那些没有选择快速存储的人, 但是它可以帮助一些。

原文:

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.

相关推荐
最新评论 (8)
graysky2 2017-10-9
1

实现的一个问题是, 如果您希望恢复目录复制到另一个分区 (可能在较慢的媒体上), 则会产生相反的效果。

...浏览器配置文件有多大? 除非它通过 USB 接口运行, 否则任何现代 SSD 都应该使用 100 MB 左右的配置文件。 25秒似乎太过份了

原文:

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 2017-10-9
2

我的铬型材的峰值是1.5GB。
其中大部分是由于一些网站在文件系统目录中留下的垃圾, 不管是什么原因。我设法把它降低到 600MB, 这是非常接近我的 SSD 可以写25秒 (我知道这一点, 因为损坏的 crashrecovery 备份是在这个大小)。

如果希望恢复目录复制到另一个分区, 可能是在较慢的媒体上

嗯, 我不。

原文:

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.

graysky2 2017-10-9
3

600 MB 是疯狂的。 我有几个配置文件在我的, 它只有 128 m 使用像 ncdu 这样的 util 来查看是什么占用了所有的空间并修复它。

原文:

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 2017-10-9
4

这简直是疯了我已经用了这个配置文件好几年了, 所以它自然而然地增加了加班时间。
我把它下到600MB 与 ncdu , 其余的是大量的扩展和本地存储, 不再容易的目标了。

我清理了一下本地存储器, 现在是500MB 了。我不认为它会变得更小。
尽管如此, time 说要复制它需要超过30秒, 所以我还没有脱离危险区域。

原文:

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 2017-10-9
5

不知道我能做些什么来帮助你..。

原文:

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

Busimus 2017-10-9
6

我是说这是问题的标题

但当然, 我想我会尝试我的运气与拉请求, 如果我设法实现这一点自己。

原文:

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 2017-10-9
7

你认为将目录复制到不同的磁盘会改善这一点吗? 你有没有一个更快的 SSD, 你是不是在使用/家?

原文:

...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 2017-10-9
8

正如我在我的原始帖子中所说, 我的系统 SSD 是缓慢的, 但我有一个硬盘, 是快速的。它需要1秒写一个500MB 的个人资料, 硬盘, 而不是超过30秒的情况下, 我的 SSD。

因此, 如果我可以指定在我的硬盘上的 psd.conf , 我想它创建 crashrecovery 文件夹, 那么我将永远不必担心我的配置文件是疯狂的大, 它会导致重新同步的问题。

原文:

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.

返回
发表文章
Busimus
文章数
2
评论数
4
注册排名
60002