Dietpi: Backup not possible with an rsync daemon running

[sergiud]

Creating a bug report/issue:

Required Information:

• DietPi version | 6.9
• Distro version | 9.4
• Kernel version | 4.14.32+
• SBC device | Odroid XU4Q with CloudShell2
• Power supply used | 15V 4A
• SDcard used | eMMC

Additional Information (if applicable):

• Running OpenMediaVault with rsync server

Steps to reproduce:

1. Start rsync daemon
2. Start DietPi backup

Expected behaviour:

• Backup start

Actual behaviour:

• Backup does not start because rsync is already running

Extra details:

• Rsync daemon must be stopped prior to starting a backup

[MichaIng]

@sergiud
Thanks very much for your report.

I didn't ever work with rsync in daemon mode, so don't know what's possible. Would it be possible to use the rsync daemon for the backup, if it's already running? I am just thinking, that killing the daemon could interrupt running remote file transfers, or the daemon denies to stop, e.g. if configured as automated cron jobs etc. Killing it forcefully on the other hand could lead to partly transferred/corrupted files?

[sergiud]

The rsync daemon serves only specific paths, so it don't believe it can be used for backup without restarting it. Stopping the dameon, on the other hand, will not cause any major problems.

[Fourdee]

@MichaIng

If the rsync daemon has a fixed service we could add to dietpi-services, else, killall -w rsync ?
However, probably best to killall in case user manually ran via cmdline.

[Fourdee]

Note, error message should already be provided

            #Error: Rsync is already running
            elif (( $(ps aux | grep -ci -m1 "[r]sync") )); then

                Error_Rsync_Already_Running

---

Maybe G_WHIP_YESNO 'Would you like to terminate process?'?
G_TERMINATE_PROCESS rsync = above?

[sergiud]

The rsync daemon can be controlled using the usual systemd mechanism. It would be nice if the daemon is automatically restarted once the backup is complete.

[Fourdee]

@sergiud

The rsync daemon can be controlled using the usual systemd mechanism. It would be nice if the daemon is restarted once the backup is complete.

Service name?

https://docs.vmware.com/en/VMware-Integrated-OpenStack/3.1/com.vmware.openstack.install.doc/GUID-CF3C87B7-315D-4797-B96A-1F7270C7EE3F.html

rsync I believe?

[MichaIng]

@Fourdee @sergiud
Would it be possible to add dietpi-backup/sync location to the list (if it's a list), possibly with limited access for local transfer or something?
€: https://linux.die.net/man/5/rsyncd.conf

• If file exists (and daemon is running), we could add our own [dietpi-backup] and/or [dietpi-sync] modules (at script start) and limit access to localhost (hosts allow). Sadly no rsyncd.conf.d is available to add permanent solution on all images.

Otherwise YESNO sounds good. However what happens to running rsync transfers? Do they go on if/since rsync daemon is just responsible to establish connection and initiate transfer to target location? But killall should kill all child processes as well... In case there is no way to preserve running transfer, default should be (if G_USER_INPUT=0, cron job etc.) to skip dietpi-backup/sync, to not risk any file corruption or unexpected cancellations.
€: @Fourdee /lib/systemd/system/rsync.service runs, if config file exists rsync --daemon. So service and process names are both rsync. But as you said, if user runs rsync --daemon manually, systemd can't control it of course.

[Fourdee]

@MichaIng

Would it be possible to add dietpi-backup/sync location to the list (if it's a list), possibly with limited access for local transfer or something?

Risky for dietpi-backup as we need to stop services prior to backup, else, inuse files etc.

Lets try it with the service control 1st, stop and start, fine if not set in config:

root@DietPi:~# systemctl start rsync
root@DietPi:~# systemctl status rsync -l
● rsync.service - fast remote file copy program daemon
   Loaded: loaded (/lib/systemd/system/rsync.service; enabled; vendor preset: en
abled)
   Active: inactive (dead)
Condition: start condition failed at Mon 2018-06-25 13:00:33 BST; 4s
ago
           └─ ConditionPathExists=/etc/rsyncd.conf was not met

[Fourdee]

@sergiud

Please patch the following files (copy/paste all) and retry dietpi-backup

wget https://raw.githubusercontent.com/Fourdee/DietPi/df2ef464c8f510acad8b00af6e1b33ff6a82bcd4/dietpi/dietpi-backup -O /DietPi/dietpi/dietpi-backup
wget https://raw.githubusercontent.com/Fourdee/DietPi/df2ef464c8f510acad8b00af6e1b33ff6a82bcd4/dietpi/dietpi-services -O /DietPi/dietpi/dietpi-services

[sergiud]

Works. Thank you!

[Fourdee]

@MichaIng

€: @Fourdee /lib/systemd/system/rsync.service runs, if config file exists rsync --daemon. So service and process names are both rsync. But as you said, if user runs rsync --daemon manually, systemd can't control it of course.

Yep, i'll add a killall -w just incase.

I'll leave G_TERMINATE_PROCESS in the mind bank, this is the only thing I can think of that would use it, and, we should reserve G_ for items that are commonly used.

ps ax | grep 'cron[[:space:]]' | sed '/grep/d'

[Fourdee]

@sergiud

Many thanks for verifying working 👍

Completed. Please reopen if required.

[MichaIng]

@Fourdee
Hmm, the issue with the current solution is, that rsync is always handled by dietpi-services now, even that it is disabled and/or does not really start up because of missing config file.

First of all, the service needs to be disabled/dietpi_controlled, and then I think we need to check for [[ -f /etc/rsyncd.conf ]] as well before handling it. This would be at least closest to the default behaviour, as the service is enabled by default, thus automatically starts, as long as file is present.

[Fourdee]

@MichaIng

Yep, agree, needs cleaning up 👍

EDIT: Doing it now, will send commit.