profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

graysky · 2015-11-08 19:14:16

Everything looks normal; you stumped me. I do not know why the resync spawns a new window for you.

hamhock · 2015-11-08 19:45:02

graysky wrote:

Everything looks normal; you stumped me. I do not know why the resync spawns a new window for you.

Graysky - thanks for writing the package and trying to solve my issue. I'm wondering if I should revert back to 5.75 or change the timer so that it fires maybe every 6 hours.

Serag4000 · 2015-11-10 14:57:27

I've just updated to v6.18 from v5.xx, and regretfully lost my profiles trying to re-enable PSD (u_u). So, a word of warning to everyone updating, refresh your backup before the update.
Personally, I have a 6 months old backup that I can use, but I guess it's about time for a fresh start.

After the update, PSD did not start automatically, and when I tried:

sudo PSD p

I received a

Cannot find XDG_RUNTME_DIR which should be set by systemd.

PS: An "i" is missing in RUNTIME.

After searching around, I tried running:

sudo echo $XDG_RUNTIME_DIR

Resulting in:

/run/user/1000

However, I did manage to get PSD running using tty2, for some reason. Probably having something to do with being logged-in as the admin account or something.

Afterwards, I enabled the "user" service, & used "visudo" to add the following:

Serag4000 ALL=(ALL) NOPASSWD: /usr/bin/psd-overlay-helper

to a file in

/etc/sudoers.d

PS: Maybe recommend using "visudo" in the help note ?

As per the help note, which somehow resulted in KDM not logging automatically to KDE5. So, I changed it to

%wheel ALL=(ALL) NOPASSWD: /usr/bin/psd-overlay-helper

And now, everything seems OK, all but for:

Cannot find XDG_RUNTME_DIR which should be set by systemd.

on

sudo PSD p

So, the question is, if:

PSD p

Results in:

Profile-sync-daemon v6.18 on Arch Linux
Systemd service is currently active.
Systemd resync-timer is currently active.
Overlayfs v23 is currently active.

Is everything all done correctly ?, and how to solve this "XDG_RUNTME_DIR" issue ?

graysky · 2015-11-11 10:35:14

It is disappointing to hear that the preinstall script in the package didn't work as designed in your case. Did you install psd from source or did you build it from the AUR? Psd is no longer a system service. There is no need to run it with the sudo prefix and that will cause it to run as root and thus look for browser profiles owned by root not by you ie your issue with xdg_runtime_dir. I don't know about the sudoers method you showed. I have documented the recommended method in the manpage. If you are receiving no output for calling simply 'psd p' as your normal user, it means that psd does not find a supported browser or that you have told it not to look for on in the conf file. What does your conf file look like?

Serag4000 · 2015-11-11 18:24:01

I updated from Aur, using Pacaur (^_^;).
I understand it's not a supported option, but I didn't have any issues before, nor got any problems with the ASD update. And for the record, I did double check the change log, and the Aur notices before updating either.

graysky wrote:

I don't know about the sudoers method you showed.

I've just used visudo, as per the recommendation in the Wiki, regarding not editing the sudoers file directly. Just using drop-in files, again, to evade messing around with the actual /etc/sudoers.

Regarding the "Wheel" group, no idea why I had it going, but I was using it with other programs, so I just continued the same with PSD.

graysky wrote:

If you are receiving no output for calling simply 'psd p' as your normal user, it means that psd does not find a supported browser or that you have told it not to look for on in the conf file. What does your conf file look like?

Surprisingly enough, it worked well !
I received normal response without sudo, and everything seemed OK, both browsers synced.
I don't know how others normally interact with PSD, but maybe catching a:

sudo psd

and providing a remark like Pacaur does, would be helpful.

Thanks for the excellent work, and prompt support (^_^).

Last edited by Serag4000 (2015-11-11 18:25:03)

graysky · 2015-11-11 20:48:05

I don't know how Pacaur works or if it honors the post install stuff (it should I would think)! So your psd is working now as expected?

EDIT: v6.19 will refuse to run as root. Thanks for the suggestion.

Last edited by graysky (2015-11-11 21:33:37)

Serag4000 · 2015-11-12 11:04:11

Well, as per below, all looks OK

Profile-sync-daemon v6.18 on Arch Linux

 Systemd service is currently active.
 Systemd resync-timer is currently active.
 Overlayfs v23 is currently active.

Psd will manage the following per /home/serag4000/.config/psd/.psd.conf:

 browser/psname:  chromium/chromium
 owner/group id:  serag4000/1000
 sync target:     /home/serag4000/.config/chromium
 tmpfs dir:       /run/user/1000/serag4000-chromium
 profile size:    97M
 overlayfs size:  25M
 recovery dirs:   2 <- delete with the c option
  dir path/size:  /home/serag4000/.config/chromium-backup-crashrecovery-20151109_161949 (27M)
  dir path/size:  /home/serag4000/.config/chromium-backup-crashrecovery-20151109_163349 (51M)

 browser/psname:  firefox/firefox
 owner/group id:  serag4000/1000
 sync target:     /home/serag4000/.mozilla/firefox/h2hem2de.default
 tmpfs dir:       /run/user/1000/serag4000-firefox-h2hem2de.default
 profile size:    31M
 overlayfs size:  0
 recovery dirs:   1 <- delete with the c option
  dir path/size:  /home/serag4000/.mozilla/firefox/h2hem2de.default-backup-crashrecovery-20151109_164942 (31M)

I've personally double checked to make sure that the links are present & stuff. And lacking any other check to run, I'm just hoping that nothing else is amiss.

Thanks again for your support, and great efforts with P/ASD.

graysky · 2015-11-13 00:29:25

Glad you're up and running. Enjoy.

zajozor · 2015-12-29 14:36:31

Is there a possibility to add support for maxthon ? ( I know it was already asked here once, but i could not find the response)

http://www.maxthon.com/index.php
currently only in aur-mirror http://pkgbuild.com/git/aur-mirror.git/ … on-browser
default dir is .config/maxthon

Or is it possible to get an unsupported browser working by creating a symlink to a directory of a supported browser, but unsed (eg. if i wouldnt use chrome i would symlink .config/chromium to .config/maxthon and set up the sync for chromium) ?

graysky · 2015-12-29 14:47:38

You can make add this on your own. Look in /usr/share/psd/browsers

nedludd · 2015-12-29 18:47:14

Can I specify a different location for my sync target other than XDG_RUNTIME_DIR? Mine is small and fills up with other stuff.

The "VOLATILE" key in "psd.conf" no longer seems to have an effect.

nedludd · 2015-12-29 19:02:50

nedludd wrote:

Can I specify a different location for my sync target other than XDG_RUNTIME_DIR? Mine is small and fills up with other stuff.
The "VOLATILE" key in "psd.conf" no longer seems to have an effect.

Just replaced "VOLATILE" with "XDG_RUNTIME_DIR" in the config file and that seems to work.

zajozor · 2016-01-02 17:53:10

Yo, thanks @graysky I got it working this year.

added a config for it similarly as for the other browsers ( eg. chrome)
( .config/maxthon )

Maxthon also stores its cache on a different place than profile ( .cache/maxthon )
I did make a symlink .cache/maxthon -> .config/maxthon/cache (Maxthon does not have a built in option for specifying cache location afaik)

In the process Maxthon pulls out a few errors about not being able to load profile, so you have to re-log to every site..

But in the end all seems to work:

$ psd p
Profile-sync-daemon v6.20 on Manjaro Linux

 Systemd service is currently active.
 Systemd resync-timer is currently active.
 Overlayfs v23 is currently active.

Psd will manage the following per /home/zajozor/.config/psd/.psd.conf:

 browser/psname:  maxthon/maxthon
 owner/group id:  zajozor/100
 sync target:     /home/zajozor/.config/maxthon
 tmpfs dir:       /run/user/1000/zajozor-maxthon
 profile size:    606M
 overlayfs size:  224M
 recovery dirs:   none

And as well in

$ df -l
Filesystem      Size  Used Avail Use% Mounted on
...
...
tmpfs           1.2G  221M  940M  19% /run/user/1000
overlaid        1.2G  221M  940M  19% /run/user/1000/zajozor-maxthon

Overall feels faster, wondering if there is a better way to benchmark this ? (not even sure what would i want to meter)

Anyways, thanks for Your great work @graysky , keep it up this year as well

graysky · 2016-01-02 18:27:25

zajozor wrote:

Maxthon also stores its cache on a different place than profile ( .cache/maxthon )
I did make a symlink .cache/maxthon -> .config/maxthon/cache (Maxthon does not have a built in option for specifying cache location afaik)
In the process Maxthon pulls out a few errors about not being able to load profile, so you have to re-log to every site.

Glad you got the syntax right and that it's working... note that:

man psd wrote:

*Note that some browsers such as Chrome/Chromium, Firefox (since v21), Midori, and Rekonq actually keeps their cache directories separately from their browser profile directory. It is not within the scope of profile-sync-daemon to modify this behavior; users wishing to relocate this directory, may refer to the following url for several work-arounds: https://wiki.archlinux.org/index.php/Ch … e_in_tmpfs

I recommend simply creating an entry in /etc/fstab for the cache. Example from my system:

tmpfs /home/facade/.cache tmpfs relatime,nodev,nosuid,size=150M 0 0

darkangel_ua · 2016-01-08 07:01:53

Hi

I have a strange issue when using psd. When I enable it for Google Chrome, Chrome stops load flash plugin(internal one). If I just do 'systemctl --user stop psd.service' and re-run browser - everything ok. This is weird

Ubuntu 15.10 x64
Google Chrome: Version 47.0.2526.106 (64-bit)
I'm using overlayfs

graysky · 2016-01-08 13:46:09

See a few of the closed issues on github. Likely the permissions on the plugin are jacked up.

jsavinc · 2016-01-10 22:11:32

Hi folks, new user here,
I've been experiencing an issue using profile-sync-daemon recently.
If the service is enabled, it causes some sort of delay in lightdm registering a session with systemd, which prevents a user session from being started properly, resulting in psd not actually running, and having to put in my password for all kinds of things like shutting down, mounting drives, etc. Logging out and back in again solves the issue. Starting my session (after logging in) takes considerably longer as well. I'm guessing it must have occurred right about a transition to the 'systemctl --user enable psd' way of running psd, since that's when I started noticing the longer startup time.

When this happens, trying to enable or disable psd fails:

systemctl --user status psd psd-resync
Failed to list units: Process org.freedesktop.systemd1 exited with status 1

This is what my journalctl has to say:

lightdm[614]: pam_systemd(lightdm:session): Failed to create session: Connection timed out

I've tried clearing all psd settings and reinstalling, and the problem persists. The only thing that helps is disabling psd, so it must have some role in causing the timeout. Did anybody else experience the same issue?
I'm running psd v6.11.1, and systemd 228.

firekage · 2016-01-12 14:58:08

I'd like to ask for one thing. I installed and configured it but i have one problem - starting firefox does three instanced. The one that i want, and 2 new clean window. What to do with this?

Edit: fixed by itself.

Edit: ok, it is not fixed. It just launch opera by itself when i use also firefox. It just launch it by itself after some time.

Last edited by firekage (2016-01-12 22:44:56)

geo909 · 2016-01-13 22:02:59

Hi,

Could somebody please shed some light on this one? I installed psd from AUR, and I get the following:

jorge@flamingo:~$ psd
 ERROR: Cannot find XDG_RUNTIME_DIR which should be set by systemd.
jorge@flamingo:~$ echo $XDG_RUNTIME_DIR

jorge@flamingo:~$

Running

export XDG_RUNTIME_DIR=/run/user/$UID

fixes the problem. I set that command in /etc/profile and everything seems to be okay now. However it seems that the profile now is saved in /run/user/1000 and not in /tmp as I remember was the case some time ago:

jorge@flamingo:~$ ls /tmp/
google-api-python-client-discovery-doc.cache
serverauth.aQ7CH3vxDZ
systemd-private-6b337bab18cd4c7e98d94dd85e46edd4-colord.service-DpM2Zu
jorge@flamingo:~$ ls /run/user/1000/
bus  gvfs  i3  jorge-firefox-s38ms72r.default  psd.pid  pulse  systemd

Is that the expected behaviour or am I doing something wrong?

Thanks a lot.

graysky · 2016-01-13 22:53:44

@jsavinc - Never seen that before.. how large is the profile(s) you're syncing (could it be a race condition)? You can find out by running `psd p` and adding up the profile sizes.

@firekage - Never seen that before either. Do you have firefox or opera set to resume your previous webpages? If so, stop psd and load the browser, does it open as expected?

@geo909 - That is odd... I haven't seen a case where (I assume systemd) didn't setup XDG_RUNTIME_DIR for you. Glad you found a work around. To your 2nd question, yes, $XDG_RUNTIME_DIR is the default now whereas /tmp was in the past. With the dep of systemd, it just made sense to me to use that since it gets setup for you and the permissions are 700 for increased system privacy.

geo909 · 2016-01-13 23:31:25

graysky wrote:

@geo909 - That is odd... I haven't seen a case where (I assume systemd) didn't setup XDG_RUNTIME_DIR for you. Glad you found a work around. To your 2nd question, yes, $XDG_RUNTIME_DIR is the default now whereas /tmp was in the past. With the dep of systemd, it just made sense to me to use that since it gets setup for you and the permissions are 700 for increased system privacy.

Many thanks for the feedback.
Not sure why XDG_RUNTIME_DIR was not set.. Recently I did some clean up and removed nautilus and some gnome stuff (I run a bare i3), maybe it is related.

laurion · 2016-01-14 14:42:04

Geo909, same thing is happening to me. I'll try your workaround, but I'm a bit concerned systemd didn't set this value. Let me know if you find the answer to that one.

geo909 · 2016-01-14 14:46:27

laurion wrote:

Geo909, same thing is happening to me. I'll try your workaround, but I'm a bit concerned systemd didn't set this value. Let me know if you find the answer to that one.

Hmm, good (?) to know that it's not just me then. I opened a new thread about my XDG variables not being set here:
https://bbs.archlinux.org/viewtopic.php … 0#p1595170

geo909 · 2016-01-16 19:05:07

So, there is a problem with my system and psd.

Using psd with firefox causes the following:
- there is a 30 second delay to show the command prompt after the password is entered at login
- some XDG variables like XDG_RUNTIM_DIR and XDG_VTN are not set, which itself causes other problems

After uninstalling psd, those are fixed..

Any ideas?

Last edited by geo909 (2016-01-16 19:05:39)

graysky · 2016-01-16 21:28:41

How large is your firefox directory and are you using overlayfs (that is speed up large since). 30 sec seems EXCESSIVE. (Post the output of psd p). Psd only checks if $XDG_RUNTIM_DIR is there and quits if it isn't; it doesn't make any modifications to them so I'm not sure what you mean.

Last edited by graysky (2016-01-16 21:28:54)

Arch Linux

#676 2015-11-08 19:14:16

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

#677 2015-11-08 19:45:02

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

#678 2015-11-10 14:57:27

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

#679 2015-11-11 10:35:14

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

#680 2015-11-11 18:24:01

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

#681 2015-11-11 20:48:05

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

#682 2015-11-12 11:04:11

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

#683 2015-11-13 00:29:25

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

#684 2015-12-29 14:36:31

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

#685 2015-12-29 14:47:38

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

#686 2015-12-29 18:47:14

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

#687 2015-12-29 19:02:50

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

#688 2016-01-02 17:53:10

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

#689 2016-01-02 18:27:25

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

#690 2016-01-08 07:01:53

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

#691 2016-01-08 13:46:09

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

#692 2016-01-10 22:11:32

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

#693 2016-01-12 14:58:08

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

#694 2016-01-13 22:02:59

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

#695 2016-01-13 22:53:44

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

#696 2016-01-13 23:31:25

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

#697 2016-01-14 14:42:04

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

#698 2016-01-14 14:46:27

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

#699 2016-01-16 19:05:07

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

#700 2016-01-16 21:28:41

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

Board footer