Request: syncthing-inotify

Syncthing is working here so I’ll leave it as is, as I have been burned yesterday and today by trying to update pihole (on XU4). If I can’t fix this I’ll start a new thread or else wait until v141 comes out. In the meantime a fresh install of pihole on a Pi3 is working fine.

John

I have updated my dietpi installation to v140, so I uninstalled syncthing and reinstalled it, in order to make it install syncthing-inotify too.

I have a few issues, though:

  1. should syncthing-inotify be visible in htop? I can’t see any mention of it there
  2. maybe because of this, syncthing-inotify is not currently working on my installation: no propagation of modified files or folders happens.

If you follow the instructions in my last message above it should work - I am not sure if the minor edit I had to do to get it working slipped under Fourdee’s radar…

I’m sure it would work, but since Fourdee has added syncthing-inotify to DietPi, I think the least I can do is to provide information/feedback about it.
I can confirm, after reinstalling everything from scratch, that syncthing installs syncthing-inotify correctly, and both are visible as running in htop, but syncthing-inotify does not correctly detect file changes and therefore it does not propagate them to the other syncthing nodes.

Just for interest can you post the contents of /etc/systemd/system/syncthing-inotify@.service

and /etc/systemd/system/syncthing.service?

root@DietRasPi:~# cat /etc/systemd/system/syncthing-inotify.service
[Unit]
Description=Syncthing Inotify File Watcher
After=network.target syncthing.service
Requires=syncthing.service

[Service]
User=root
ExecStart=/usr/bin/syncthing-inotify -logfile=/var/log/syncthing-inotify.log -logflags=3
SuccessExitStatus=2
RestartForceExitStatus=3
Restart=on-failure
ProtectSystem=full
ProtectHome=read-only

[Install]
WantedBy=multi-user.target



root@DietRasPi:~# cat /etc/systemd/system/syncthing.service
[Unit]
Description=Syncthing
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/syncthing -logfile=/var/log/syncthing.log -logflags=3
User=root

[Install]
WantedBy=multi-user.target

The main difference between these and my working versions is that syncthing.service does not have

[unit]
Wants=syncthing-inotify@.service

(Not sure if the “@” symbol is needed - I see it isn’t used in your version - but as long as the correct file name is referred to it should be OK).

John

I don’t have any syncthing-inotify@.service, just the one without the @ symbol.
I will try your version later and see if it starts working properly.
I have noticed that currently syncthing won’t detect the file changes even during the scheduled rescans. I need to scan manually in order for it to detect the changes properly and propagate them to the other syncthing nodes. There’s definitely something wrong with the default installation.

Strange, during testing this was working for me on C2.

Check for any errors in service:

systemctl status syncthing-inotify.service -l

And also, check log for any errors:

cat /var/log/syncthing-inotify.log

Paste results here and i’ll take a look.

I can’t see any errors (sorry I can’t copy and paste, I hope the attachment is fine anyway).

Yep,service looks good.
Pictures, screenshots, SSH pastes, its all good :slight_smile:

Remember that DietPi-RAMlog clears logs every 1 hour. So you may need to reboot, then try to recreate the issue in Syncthing, then recheck log file again straight afterwards.

Another option is DietPi-RAMlog mode #2, which backs up logs, before clearing:
https://dietpi.com/forum/t/dietpi-survey-information/32/1

Oh, I forgot about that…
I will try to recreate the problem as soon as I can. Not today for sure, though… We are too busy with the New Year’s Eve preparations.
Oh, by the way… Happy New Year, everybody! :slight_smile:

I can’t seem to have any valid information in the log. It’s always empty, even immediately after I make changes to a synced file.
It really looks like syncthing-inotify does not detect file changes at all.

I have also tried John’s version of the services. Still no go.
I added a file to the shared folder, and syncthing-inotify did not detect it, nor propagated it correctly to the other syncthing nodes.
Since my folder is hosted on a NAS, I’m wondering if this could be a limitation of syncthing and/or inotify, which does not correctly monitor/detect files that are mounted on a NAS.
I will try sharing a real local folder and see if it still fails.

Ok… That’s what I thought.
Local folder syncs correctly.
Mounted folder doesn’t.
I guess this is a limitation in syncthing and/or syncthing-inotify :frowning:

Just tried this and same here.

That’s a real pity… This kind of defeats all the purpose of syncthing-inotify for me :frowning:
Thanks for taking the time to try this.

I’ll see if I can find a way round this apparent restriction. Also I have just set up syncthing on a new Orange Pi Zero using Fourdee’s method and it works perfectly.

This is what I have found - I have a directory of photos on a QNAP NAS. I have this mounted on an XU4 - /mnt/photos

This is synced to remote server. If I add a file to the QNAP it is not synced.

If I add the file to the same directory but via /mnt/photos - it gets synced instantly.

Obviously syncthing-inotify is watching the XU4 directory not the QNAP directory.

John

That’s exactly the same behavior I am experiencing.
I guess the only workaround is to set the mounted folders with a high rescan frequency (60 seconds or so) while leaving the native folders managed by inotify. But this, of course, does not reduce the amount of cpu power “consumed” by the board.