search

graysky2 / anything-sync-daemon

Symlinks and syncs user specified dirs to RAM thus reducing HDD/SDD calls and speeding-up the system.
https://wiki.archlinux.org/index.php/Anything-sync-daemon
MIT License
345 stars 45 forks source link

asd.service does not start #55

Closed hiredgunhouse closed 2 years ago

hiredgunhouse commented 5 years ago

I'm using Ubuntu 16.04, I followed the installation instructions on the official wiki but when I boot my system asd.service does not start. Here's output from sudo systemctl status asd.service:

● asd.service - Anything-sync-daemon
   Loaded: loaded (/usr/lib/systemd/system/asd.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since nie 2019-06-02 19:45:47 CEST; 8min ago
     Docs: man:asd(1)
           man:anything-sync-daemon(1)
           https://wiki.archlinux.org/index.php/Anything-sync-daemon
  Process: 1483 ExecStart=/usr/bin/anything-sync-daemon sync (code=exited, status=1/FAILURE)
 Main PID: 1483 (code=exited, status=1/FAILURE)

cze 02 19:45:47 althea systemd[1]: Starting Anything-sync-daemon...
cze 02 19:45:47 althea anything-sync-daemon[1483]: Bad entry in your WHATTOSYNC array detected:
cze 02 19:45:47 althea anything-sync-daemon[1483]:  /home/peter/asd-test
cze 02 19:45:47 althea anything-sync-daemon[1483]: Edit /etc/asd.conf correcting the mistake and try again.
cze 02 19:45:47 althea systemd[1]: asd.service: Main process exited, code=exited, status=1/FAILURE
cze 02 19:45:47 althea systemd[1]: Failed to start Anything-sync-daemon.
cze 02 19:45:47 althea systemd[1]: asd.service: Unit entered failed state.
cze 02 19:45:47 althea systemd[1]: asd.service: Failed with result 'exit-code'.

here's output from sudo asd p:

Anything-sync-daemon v5.85 on Ubuntu 16.04.6 LTS

 Systemd service is currently failed.
 Systemd resync service is currently active.
 Overlayfs v23 is currently active.

Asd will manage the following per /etc/asd.conf settings:

 owner/group id:     peter/1000
 target to manage:   /home/peter/asd-test
 sync target:        /home/peter/.asd-test-backup_asd
 tmpfs target:       /dev/shm/asd-peter/home/peter/asd-test
 dir size:           1,5G
 overlayfs size:     
 recovery dirs:      none

I'm guessing this is either related to root vs regular user since I can stop the service and start it manually (via systemctl start...) and it seems to work or it is related to my home directory being encrypted via encryptfs. Anyway the error message is not very helpful. Is it possible to see some more specific log output that would point me to the root of actually issue? Looking forward to fixing this since I'd love to use asd. I have moved from Windows where I used ramdisks heavily and I want to achieve the same thing on Linux and asd seems to be the only solution that is comparable to what I had on Windows.

hiredgunhouse commented 5 years ago

It seems like the encrypting of my home dir is the problem. When I run systemctl start asd.service after I'm logged in as the user the service starts fine. Is there a solution to this problem?

hiredgunhouse commented 5 years ago

BTW. the asd p command takes really long to finish, it freezes at Asd fill manage the following per /etc/asd.conf settings: line and takes a minute or so before it continues :/

luxus commented 3 years ago

same issue and behavior here... it starts when I start it after the system boots.. maybe the asd.service try to start before the directory is ready? how is the correct way to maybe wait until the mounts are ready and then start asd.service? Edit: adding After=mountname.mount to the service file fixed it for me

manorit2001 commented 2 years ago

BTW. the asd p command takes really long to finish, it freezes at Asd fill manage the following per /etc/asd.conf settings: line and takes a minute or so before it continues :/

https://github.com/graysky2/anything-sync-daemon/commit/a63a2e47cad6379ad2e22614e317e665f206d049 I think this should be helpful. asd p command tries to find the directory sizes which usually takes some time when run for the first time, successive runs are usually cached by linux and give faster outputs.

same issue and behavior here... it starts when I start it after the system boots.. maybe the asd.service try to start before the directory is ready? how is the correct way to maybe wait until the mounts are ready and then start asd.service? Edit: adding After=mountname.mount to the service file fixed it for me

Yeah, I think this must be the case only. I haven't worked with encrypted home directories so don't really know what the issue might be but am glad you figured it out