search

graysky2 / profile-sync-daemon

Symlinks and syncs browser profile dirs to RAM thus reducing HDD/SDD calls and speeding-up browsers.
https://wiki.archlinux.org/index.php/Profile-sync-daemon
Other
910 stars 88 forks source link

[OpenRC] Does not unsync on shutdown #103

Closed abchk1234 closed 9 years ago

abchk1234 commented 9 years ago

Hi graysky,

I used profile-sync-daemon on Manjaro, with OpenRC on a couple of systems.

What I noticed is that psd does not unsync the profile from /tmp to home folder on shutdown, so I am left with a missing firefox profile (the backup folder was there though, so I removed the broken symlink and renamed the backup folder).

To correct this behavior I added to /etc/local.d/rc.local.shutdown.stop

/usr/bin/profile-sync-daemon resync
/usr/bin/profile-sync-daemon unsync

Also if I remember correctly, I could not start psd by enabling it as rc-update add psd, but I needed to add to /etc/local.d/rc.local.start

/usr/bin/profile-sync-daemon sync

(I got the above commands from the cron job).

I am not sure why I am having this issue though, as the provided OpenRC service looks correct in theory.

graysky2 commented 9 years ago

This is not good as you are basically parroting with OpenRC should be doing natively. I will send this report on to a friend who develops for Gentoo for an opinion. I might spin up a manjaro VM and see if I can repeat as well.

abchk1234 commented 9 years ago

I did it because the default service was not working for me (leaving broken link on shutdown), I will also try to recreate this issue on a VM.

graysky2 commented 9 years ago

No luck getting openrc to run on the manjaro VM I created following the wiki page for openrc... just hangs on the splash screen upon a reboot... I will try it with Arch in a VM.

abchk1234 commented 9 years ago

@graysky2

More info (was able to reproduce the issue on VM): http://pastebin.com/rMnF7bFk

For Manjaro you could try an OpenRC ISO: https://forum.manjaro.org/index.php?topic=19215.0

Edit- The splash screen issue was probably because you were using plymouth, which does not work well with OpenRC. I have amended the wiki about this issue.

graysky2 commented 9 years ago

I haven't used openrc before but I do have an Arch VM up and running with it. I can start psd with openrc rc-service psd start and it runs correctly. I can't figure out how to get openrc to manage auto startup/shutdown. As I understand it, running rc-update add psd should do it. When I run that twice, it seems to have been added to the queue because:

rc-update add psd
 * rc-update: psd already installed in runlevel `default'; skipping

But when I reboot the VM, psd is not started automatically.

abchk1234 commented 9 years ago

Yup, you have nailed the issue I think.

Even though psd is present in the default runlevel, it does not seem to get started due to some reason, nor does it get displayed in the output of rc-status

graysky2 commented 9 years ago

How can I see the openrc logs from a boot up to try to diagnose? Again, I am not an openrc user.

abchk1234 commented 9 years ago

Depends on which method you chose to install: https://wiki.archlinux.org/index.php/Openrc#Boot_logging (boot logs are stored in /var/log/rc.log

My initial guess is that something is possibly wrong/missing in the psd OpenRC service..

graysky2 commented 9 years ago

I figured it out: the shebang in that script is #!/sbin/runscript ... if I change that to #!/usr/bin/runscript everything seems to work. Perhaps this is due to the sbin symlink from quite a while back. Can you make this change and confirm that it fixes your problem?

abchk1234 commented 9 years ago

Thx for the debugging :)

Perhaps the issue is that devfs and localmount are in different runlevels (just a wild guess)

$ ls /etc/runlevels/boot/
bootmisc@  hwclock@     loopback@  net.lo@  swap@       termencoding@
fsck@      keymaps@     modules@   procfs@  swapfiles@  tmpfiles.setup@
hostname@  localmount@  mtab@      root@    sysctl@     urandom@

$ ls /etc/runlevels/sysinit/
devfs@  dmesg@  kmod-static-nodes@  sysfs@  tmpfiles.dev@  udev@

$ ls /etc/runlevels/default/
acpid@       dbus@   metalog@   psd@             xdm@
consolekit@  local@  netmount@  udev-postmount@
graysky2 commented 9 years ago

I think the issue is the shebang. See my comment above. On my Arch VM using openrc arg method, I installed psd using make install-openrc-all and then symlinked my /etc/init.d/psd to /etc/openrc/init.d/psd to allow openrc to see the script. Then I just changed the shebang and it worked.

% head -n 3 /etc/openrc/init.d/psd
#!/usr/bin/runscript
# Copyright 1999-2015 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
ghost commented 9 years ago

greysky2 ... I saw your quickly disapearing post in gentoo forums. You seem to have run into an issuse caused by a change in openrc, runscript is now openrc-run. From what I can gather the reporter probably just updated to openrc-0.13.7 where this changed occured ... all init scripts need their shebang replaced with /sbin/openrc-run (and btw /usr/bin/runscript is from minicom ... which is the rational given for this tumult).

best ... khay

abchk1234 commented 9 years ago

I was about to suggest the same thing about openrc-run :) https://github.com/OpenRC/openrc/blob/master/NEWS

@Khayyam, we are already using openrc-run https://github.com/manjaro/packages-openrc

abchk1234 commented 9 years ago

I can confirm that with the change in shebang, psd appears in rc-status and seems activated at boot as well.

$ rc-status 
Runlevel: default
 dbus                                                              [  started  ]
 metalog                                                           [  started  ]
 consolekit                                                        [  started  ]
 netmount                                                          [  started  ]
 psd                                                               [  started  ]
 acpid                                                             [  started  ]
 udev-postmount                                                    [  started  ]
 local                                                             [  started  ]
Dynamic Runlevel: hotplugged
Dynamic Runlevel: needed
 xdm-setup                                                         [  started  ]
 dhcpcd                                                            [  started  ]
Dynamic Runlevel: manual
graysky2 commented 9 years ago

@Khayyam - Thank you for confirming my suspicion about the shebang. Yes, I posted to the gentoo forum but deleted it once I was pretty sure I figured it out on my own.

If I use a shebang value of /sbin/openrc-run as you suggest, in my Arch VM (using 0.13.6) openrc does not work. I have to use a value of /usr/bin/runscript for it to work. What version of openrc does gentoo currently ship? I looked at the latest stage3 tarball (20141204) and you guys do NOT have /usr/bin/runscript in there at all.

So I would seem to be needing two different openrc scripts: 1) For Arch and clones with #!/usr/bin/runscript 2) For Gentoo and clones with #!/sbin/openrc-run

Is this correct?

ghost commented 9 years ago

greysky ... sorry, am actually eating right now ... the version with openrc-run was stabilised for amd64 yesterday or the day before, it may not be the current stages

abchk1234 commented 9 years ago

@graysky2 0.13 according to the news

and you could use #!/usr/bin/openrc-run for Arch and its derivatives (checked that it works)

ghost commented 9 years ago

aadityabagga, except that not all versions of openrc will have that ... hehe ... you know this change was introduced because minicom also has runscript, so a major change, to a major package, for a corner case

ghost commented 9 years ago

oh, and btw, I'm probably wrong about the path to openrc-run ... I've not had the pleasure of updating to 0.13.7 as its not yet stabalised for all arches.

abchk1234 commented 9 years ago

@graysky2

Maybe the following could be used in the PKGBUILD

package() {
  cd "$pkgname-$pkgver"
  if [ -x /usr/bin/systemctl ] && [ -e /run/systemd ]; then
    make DESTDIR="$pkgdir" install-systemd-all
  elif [ -x /usr/bin/openrc-run ] && [ -e /run/openrc ]; then
   make DESTDIR="$pkgdir" install-openrc-all
  fi
  install -Dm644 MIT "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
}
graysky2 commented 9 years ago

I could make a configure script that will identify the location of runscript and then fix up the Makefile to use the correct path. Do we know that the new version of OpenRC 0.13.7 will ship runscript or is it openrc-run that should be in the shebang?

Option 2 is to simply provide a skel script that is not live on the filesystem, but in /usr/share/psd or the like. This will require the user to manage the shebang automatically. Since I don't run openrc myself, I think I might like this option better.

abchk1234 commented 9 years ago

As Khayyam said runscript is deprecated and will be removed sooner or later, so openrc-run seems the better choice.

OpenRC has been shipping openrc-run since 0.13.0 according to the Changelog.

You could deal with the package whichever way you like.

Thx for the help, its solved for me.

graysky2 commented 9 years ago

Version 5.64 should be good to go, thanks for the report and the discussion, all!

https://github.com/graysky2/profile-sync-daemon/compare/v5.63...v5.64

abchk1234 commented 9 years ago

Just a thought...

If you could check for and install the service files in the source itself (eg openresolv), or in the PKGBUILD (https://github.com/graysky2/profile-sync-daemon/issues/103#issuecomment-70411963) it would be helpful, as one would not have to edit the PKGBUILD every time when upgrading..

graysky2 commented 9 years ago

Problem is if a users builds it on a system with openresolv but intends to use it on a systemd system, it will be jacked up.

abchk1234 commented 9 years ago

Sure, but I think that is a universal problem and not specific to psd.

graysky2 commented 9 years ago

Short of installing all init scripts by default, I don't know of a systematic way...