kill applications using synced folders before unsyncing

[bobpaul]

There's a problem involving sync'd folder integrity if applications are using the sync'd files when the folder is unsync'd. This was solved in psd by killing any running applications (browsers) that are using this space.

I think one solution for ASD might be to have an array of "applications_syncd" in the config file. ASD could kill these apps when ASD is stopped (unsync) the same way that PSD does with browsers. Perhaps even like PSD, ASD could refuse to start if any of those applications are running when ASD is started (sync).

I've been trying to think of a good solution that doesn't involve killing processes, but I'm having difficulty.

Explanation of problem:

1. ASD starts, moves folder to /dev/shm/ and replaces folder with a symlink to /dev/shm/folder
2. Application opens, following symlink and opening file handles to /dev/shm/folder/files{1,2,3...}
3. ASD stops, deleting the symlink and moving the folder from /dev/shm back to disk. Application still holds some file handles to the now non-existant /dev/shm/folder/files{1,2,3...}
4. Application continues to run, opening new files, now on the disk at /real/path/to/folder/files{4,5,6...}
5. When application closes it flushes and closes all of its file handles, some to /dev/shm and some to disk. The files on disk are now in an inconsistent state and might not be what the program expects the next time it starts.

Ideally ASD starts at boot and ends at shutdown, meaning it will start before the application(s) and end after the application(s) ends. But if ASD is ever updated, ASD will stop so its package can be removed, then start again after the new package is installed, making the issue extremely likely during package upgrades to ASD.

At the very least the documentation should warn users to stop applications and services that are using ASD before updating its package or otherwise stopping ASD.

[testbird]

I think the first thing in tackling these timing problems with linking/unlinking a path into RAM would be to check for probmles (issue #6) and report errors if they happen (issue #8)

Then, if problems are detected, rather then going about to kill processes, the user gets the message and may adjust the timing (properly shut down its processes, adjust the time to execute asd, etc.). But if asd wants to behave nicely and complete the given (sync+unlink) command, it could set up a watch on the directory (inotifywait) and continue once the files are closed (in case no -kill switch is given).

BTW I find the lingo sync/unsync may not be as precise as it could be (symlink/mount, sync/write-to-disk,unlink/unmoung?).

[testbird]

if ASD is ever updated, ASD will stop so its package can be removed,
then start again after the new package is installed

An update may only stop the syncing (cron job) temporarily and leave any ramdirs in place.
After the update, the cron job will call the new version, and on shutdown the new init script has to sync all existing ramdirs back to disk (including any that are not configued any more, issue #7).

Uninstalling of the package can try to sync and unlink the rampath, and move the .persistent-path back to its original location if the unlink succeeded. Otherwise, asking to close the processes, killing or rebooting may be necessary.

[graysky2]

Asd shouldn't need to be aware of application using sync targets; it has recovery features to handle ungraceful shutdowns, see the check function for example.

[testbird]

Uhh? asd be better aware of open files, as regular startups and shutdowns (e.g. manual, during updates, uninstall) can cause data loss/corruption just as well.

[graysky2]

Yes, I have this noted in the man page:

BUGS
       Discover a bug? Please open an issue on the project page linked below.

              o  Currently, asd cannot handle open files on a sync target so if a hung process has something open there,  it
                 can be messy.

[testbird]

Sorry I didn't notice the man page update.

Well, a fix should only require a call to lsof $PATH before proceding or aborting.
A simple check would elevate asd's reliability so much for system files etc.