# V6.2 -- DietPi-Sync Behaving Differently?

**URL:** <https://dietpi.com/forum/t/v6-2-dietpi-sync-behaving-differently/2006>\
**Category:** General Discussion\
**Created:** [21 February 2018 06:35 UTC](https://dietpi.com/forum/t/v6-2-dietpi-sync-behaving-differently/2006 "2018-02-21T06:35:25Z")\
**Posts on this page:** 17\
**Page:** 1

<div class="post-metadata">

**Author:** ![midnightwatcher](https://dietpi.com/forum/letter_avatar_proxy/v4/letter/m/57b2e6/32.png) [@midnightwatcher](https://dietpi.com/forum/u/midnightwatcher)\
**Post date:** [21 February 2018 06:35 UTC](https://dietpi.com/forum/t/v6-2-dietpi-sync-behaving-differently/2006/1 "2018-02-21T06:35:25Z")

</div>

I updated to DietPi 6.2 and attempted to run DietPi-Sync this evening in an SSH session, however DietPi-Sync appears to be stuck, or is it just no longer displaying what it’s doing? I need to confirm what files are being copied when doing a manual sync. Is this no longer possible? All I’m seeing is something similar to this:

[SUB1] DietPi-Sync \> sync  
[…] DietPi-Sync | Running command: rsync -avP4 --delete --log-file=/var/log/dietpi-sync.log --exclude-from=/tmp/.dietpi-sync\_exclude --include-from=/tmp/.dietpi-sync\_include /mnt/Server\_Media/ /mnt/Server\_Backup/

---

<div class="post-metadata">

**Author:** ![MichaIng](https://dietpi.com/forum/user_avatar/dietpi.com/michaing/32/7_2.png) [@MichaIng](https://dietpi.com/forum/u/MichaIng)\
**Post date:** [21 February 2018 12:22 UTC](https://dietpi.com/forum/t/v6-2-dietpi-sync-behaving-differently/2006/2 "2018-02-21T12:22:18Z")

</div>

Hi midnightwatcher,

jep we switched the rsync command into our error handled G\_RUN\_CMD. This means that there is no output on screen, just in case of an error you will see an error message, showing necessary information and the last lines of the commands output, that high likely are related to the error.

However, you can always review the verbose output of the last sync at /var/log/dietpi-sync.log, for dietpi-backup it’s dietpi-backup.log.

Generally, if you see the moving dot in the front, this means a command is running within our error handled functions. The output from the actual command is redirected to /tmp/G\_ERROR\_HANDLER\_COMMAND and can be always reviewed there, only showing up on screen, is an actual error occurred, in ready for github copy&paste way 🕶. With this we also try to reduce (unnecessary?) terminal output, showing what is interesting and preserving an overview over what is going on (especially within long dietpi-software installations, we felt, this might be beneficial), but always enabling to review more details, if necessary. Feedback on how and where we solved this good/bad is welcome! Work on this is still in progress.

---

<div class="post-metadata">

**Author:** ![midnightwatcher](https://dietpi.com/forum/letter_avatar_proxy/v4/letter/m/57b2e6/32.png) [@midnightwatcher](https://dietpi.com/forum/u/midnightwatcher)\
**Post date:** [21 February 2018 18:28 UTC](https://dietpi.com/forum/t/v6-2-dietpi-sync-behaving-differently/2006/3 "2018-02-21T18:28:25Z")

</div>

Thank you for the reply, Michalng. This feels like a step back, however. I prefer to do a dry run first, but even that no longer tells me what’s going on and having to then navigate to a log file when doing a sync via SSH seems to be a bit of a hassle when compared to the old way. If we cannot revert back to a real-time verbose/output, is there a way we can easily view the DietPi-Sync log file from within DietPi-Sync itself? If not, can that option be added?

---

<div class="post-metadata">

**Author:** ![Fourdee](https://dietpi.com/forum/user_avatar/dietpi.com/fourdee/32/11_2.png) [@Fourdee](https://dietpi.com/forum/u/Fourdee)\
**Post date:** [21 February 2018 19:33 UTC](https://dietpi.com/forum/t/v6-2-dietpi-sync-behaving-differently/2006/4 "2018-02-21T19:33:18Z")

</div>

> [@midnightwatcher](#):
>
> Thank you for the reply, Michalng. This feels like a step back, however. I prefer to do a dry run first, but even that no longer tells me what’s going on and having to then navigate to a log file when doing a sync via SSH seems to be a bit of a hassle when compared to the old way.

Thanks for the feedback.

I’ll review this, see if we can improve.

**EDIT** : MichaIng has already covered most of this, but I had a quick look.

Ok, so currently, only the end result is shown (with status of success of failure). We essentially wanted to reduce the onscreen print during dietpi-backup and dietpi-sync, and, allow our global error system to handle errors more efficiently.

```plaintext
			#Sync
			G_RUN_CMD rsync $rync_options --log-file=$LOGFILE --exclude-from="$FP_EXCLUDE_GLOBAL" --include-from="$FP_INCLUDE_GLOBAL" "$FP_SOURCE"/ "$FP_TARGET"/
			echo -e "Sync completed: $(date +"%d-%m-%Y_%H%M")" >> "$FP_TARGET/$SYNC_STATS_FILENAME"

			#Menu
			if (( $G_USER_INPUTS )); then

				if (( $SYNC_DRY_RUN == 0 )); then

					whiptail --title "Sync completed" --msgbox "$FP_SOURCE\n\nHas been synced to:\n$FP_TARGET\n\nLog file: $LOGFILE" --backtitle "$WHIP_BACKTITLE" 13 60

				else

					whiptail --title "Dry Run Sync completed" --msgbox "$FP_SOURCE\n\nHas been synced with a Dry Run (NO modifications) to:\n$FP_TARGET\n\nLog file: $LOGFILE" --backtitle "$WHIP_BACKTITLE" 13 60

				fi

			fi

```

The menus after command is completed, also mentions the logfile location /var/log/dietpi-sync.log, which contains verbose rsync operation, if required by end user.

---

<div class="post-metadata">

**Author:** ![Fourdee](https://dietpi.com/forum/user_avatar/dietpi.com/fourdee/32/11_2.png) [@Fourdee](https://dietpi.com/forum/u/Fourdee)\
**Post date:** [21 February 2018 19:48 UTC](https://dietpi.com/forum/t/v6-2-dietpi-sync-behaving-differently/2006/5 "2018-02-21T19:48:24Z")

</div>

@MichaIng

Maybe a solution here is we could implement:

```nohighlight
G_WHIP_VIEWLOG /log/file.log

```

And have a prompt inside the global to ask user if they would like to view the logfile, then display it?

I’ll take a crack at this one 😃

[https://github.com/Fourdee/DietPi/issues/1546](https://github.com/Fourdee/DietPi/issues/1546)

---

<div class="post-metadata">

**Author:** ![midnightwatcher](https://dietpi.com/forum/letter_avatar_proxy/v4/letter/m/57b2e6/32.png) [@midnightwatcher](https://dietpi.com/forum/u/midnightwatcher)\
**Post date:** [21 February 2018 21:38 UTC](https://dietpi.com/forum/t/v6-2-dietpi-sync-behaving-differently/2006/6 "2018-02-21T21:38:51Z")

</div>

Thank you, Fourdee, that would be a reasonable compromise. Would this also prompt the user to view the log after a dry run?

---

<div class="post-metadata">

**Author:** ![Fourdee](https://dietpi.com/forum/user_avatar/dietpi.com/fourdee/32/11_2.png) [@Fourdee](https://dietpi.com/forum/u/Fourdee)\
**Post date:** [21 February 2018 21:50 UTC](https://dietpi.com/forum/t/v6-2-dietpi-sync-behaving-differently/2006/7 "2018-02-21T21:50:17Z")

</div>

> [@midnightwatcher](#):
>
> Would this also prompt the user to view the log after a dry run?

Yep 🙂

Will make it for v6.3 update, we’ll try to keep this update small, so we can aim release within 1 week.

---

<div class="post-metadata">

**Author:** ![midnightwatcher](https://dietpi.com/forum/letter_avatar_proxy/v4/letter/m/57b2e6/32.png) [@midnightwatcher](https://dietpi.com/forum/u/midnightwatcher)\
**Post date:** [22 February 2018 08:10 UTC](https://dietpi.com/forum/t/v6-2-dietpi-sync-behaving-differently/2006/8 "2018-02-22T08:10:58Z")

</div>

Excellent. One final question - - Will there be a way to identify how many MB/s files are being copied/synced like the previous version?

---

<div class="post-metadata">

**Author:** ![MichaIng](https://dietpi.com/forum/user_avatar/dietpi.com/michaing/32/7_2.png) [@MichaIng](https://dietpi.com/forum/u/MichaIng)\
**Post date:** [22 February 2018 13:00 UTC](https://dietpi.com/forum/t/v6-2-dietpi-sync-behaving-differently/2006/9 "2018-02-22T13:00:39Z")

</div>

Possible would be also to allow users setting verbose mode in sync/backup config. I guess most (at least me) don’t need logs and that way we can skip whiptail question every time, which can be also not answered if run by cron job e.g.

I guess the size of transferred data is part of verbose rsync?

---

<div class="post-metadata">

**Author:** ![Fourdee](https://dietpi.com/forum/user_avatar/dietpi.com/fourdee/32/11_2.png) [@Fourdee](https://dietpi.com/forum/u/Fourdee)\
**Post date:** [22 February 2018 19:48 UTC](https://dietpi.com/forum/t/v6-2-dietpi-sync-behaving-differently/2006/10 "2018-02-22T19:48:42Z")

</div>

> [@MichaIng](#):
>
> I guess the size of transferred data is part of verbose rsync?

Yep, contained at end of logfile.

> Possible would be also to allow users setting verbose mode in sync/backup config. I guess most (at least me) don’t need logs and that way we can skip whiptail question every time, which can be also not answered if run by cron job e.g.

Yep, good idea.

---

<div class="post-metadata">

**Author:** ![midnightwatcher](https://dietpi.com/forum/letter_avatar_proxy/v4/letter/m/57b2e6/32.png) [@midnightwatcher](https://dietpi.com/forum/u/midnightwatcher)\
**Post date:** [8 March 2018 04:04 UTC](https://dietpi.com/forum/t/v6-2-dietpi-sync-behaving-differently/2006/11 "2018-03-08T04:04:51Z")

</div>

Hi gentlemen, I updated to version 6.3 and did a dry run of DietPi-Sync. When it completed it had asked if I wanted to view the log, however when I clicked OK was unable to see any details. I’m using JuiceSSH on my Nexus 6P phone.

---

<div class="post-metadata">

**Author:** ![Fourdee](https://dietpi.com/forum/user_avatar/dietpi.com/fourdee/32/11_2.png) [@Fourdee](https://dietpi.com/forum/u/Fourdee)\
**Post date:** [8 March 2018 16:46 UTC](https://dietpi.com/forum/t/v6-2-dietpi-sync-behaving-differently/2006/12 "2018-03-08T16:46:25Z")

</div>

> [@midnightwatcher](#):
>
> Hi gentlemen, I updated to version 6.3 and did a dry run of DietPi-Sync. When it completed it had asked if I wanted to view the log, however when I clicked OK was unable to see any details. I’m using JuiceSSH on my Nexus 6P phone.

Hi,

Thanks for the report.

Confirmed, we’ll get this resolved for v6.4, which will be released as a hotfix tomorrow.

---

<div class="post-metadata">

**Author:** ![midnightwatcher](https://dietpi.com/forum/letter_avatar_proxy/v4/letter/m/57b2e6/32.png) [@midnightwatcher](https://dietpi.com/forum/u/midnightwatcher)\
**Post date:** [10 March 2018 03:58 UTC](https://dietpi.com/forum/t/v6-2-dietpi-sync-behaving-differently/2006/13 "2018-03-10T03:58:22Z")

</div>

Hi Fourdee, I see that 6.4 is now available and attempted to update, however now I am receiving an error stating that “Available free space on RootFS is low (0 MB)” and that I need to free up at least 500 MB of space. I’m surprised by this since the Z83 has a 32GB eMMC.

Any idea what could have happened??

---

<div class="post-metadata">

**Author:** ![Fourdee](https://dietpi.com/forum/user_avatar/dietpi.com/fourdee/32/11_2.png) [@Fourdee](https://dietpi.com/forum/u/Fourdee)\
**Post date:** [10 March 2018 15:09 UTC](https://dietpi.com/forum/t/v6-2-dietpi-sync-behaving-differently/2006/14 "2018-03-10T15:09:42Z")

</div>

> [@midnightwatcher](#):
>
> Hi Fourdee, I see that 6.4 is now available and attempted to update, however now I am receiving an error stating that “Available free space on RootFS is low (0 MB)” and that I need to free up at least 500 MB of space. I’m surprised by this since the Z83 has a 32GB eMMC.
> 
> Any idea what could have happened??

Hi,

Strange, whats the results of?:

```plaintext
df -h
G_TREESIZE /

```

---

<div class="post-metadata">

**Author:** ![midnightwatcher](https://dietpi.com/forum/letter_avatar_proxy/v4/letter/m/57b2e6/32.png) [@midnightwatcher](https://dietpi.com/forum/u/midnightwatcher)\
**Post date:** [10 March 2018 18:27 UTC](https://dietpi.com/forum/t/v6-2-dietpi-sync-behaving-differently/2006/15 "2018-03-10T18:27:57Z")

</div>

root@DietPi:~# df -h

```nohighlight
Filesystem Size Used Avail Use% Mounted on
udev 957M 0 957M 0% /dev
tmpfs 194M 8.7M 185M 5% /run
/dev/mmcblk0p2 28G 28G 16K 100% /
tmpfs 968M 0 968M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 968M 0 968M 0% /sys/fs/cgroup
tmpfs 967M 8.0K 967M 1% /tmp
tmpfs 20M 32K 20M 1% /var/log
tmpfs 10M 1.5M 8.6M 15% /DietPi
tmpfs 194M 12K 194M 1% /run/user/0
/dev/sda2 7.3T 5.0T 2.0T 72% /media/root/Media_Server

```

root@DietPi:~# G\_TREESIZE /

```nohighlight
du: cannot access '/proc/2958/task/2958/fd/4': No such file or directorydu: cannot access '/proc/2958/task/2958/fdinfo/4': No such file or directory
du: cannot access '/proc/2958/fd/3': No such file or directory
du: cannot access '/proc/2958/fdinfo/3': No such file or directory
5.0 TB /
4.9 TB /media
26.1 GB /root
1.2 GB /usr
271.2 MB /lib
240.9 MB /var
36.1 MB /boot
8.7 MB /sbin
8.7 MB /run
8.6 MB /bin
5.3 MB /etc
1.4 MB /DietPi
52.0 KB /mnt
16.0 KB /lost+found
16.0 KB /home
12.0 KB /srv
8.0 KB /tmp
4.0 KB /opt
4.0 KB /lib64
0.0 KB /sys
0.0 KB /proc
0.0 KB /dev

```

---

<div class="post-metadata">

**Author:** ![Fourdee](https://dietpi.com/forum/user_avatar/dietpi.com/fourdee/32/11_2.png) [@Fourdee](https://dietpi.com/forum/u/Fourdee)\
**Post date:** [10 March 2018 19:47 UTC](https://dietpi.com/forum/t/v6-2-dietpi-sync-behaving-differently/2006/16 "2018-03-10T19:47:32Z")

</div>

> [@midnightwatcher](#):
>
> 26.1 GB /root

26.1GB of data is inside /root directory.

You’ll need to run following command to find out more:

```plaintext
G_TREESIZE /root

```

Then continue to follow the highest number with command again, eg:

```plaintext
G_TREESIZE /root/thisfolder

```

---

<div class="post-metadata">

**Author:** ![midnightwatcher](https://dietpi.com/forum/letter_avatar_proxy/v4/letter/m/57b2e6/32.png) [@midnightwatcher](https://dietpi.com/forum/u/midnightwatcher)\
**Post date:** [10 March 2018 20:22 UTC](https://dietpi.com/forum/t/v6-2-dietpi-sync-behaving-differently/2006/17 "2018-03-10T20:22:39Z")

</div>

Thanks Fourdee, I think I found the problem. It looks like DietPi-Sync tried to backup one of my external drives locally, will report back later this evening …

Update: Confirmed. I’ve deleted the offending directory and updated to 6.4 without issue. I’ve also now properly mounted my drives using their UUID in fstab and did a bit of cleaning up to ensure I don’t have a repeat of the same issue.

Thanks for your help!