You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I use sanoid and syncoid for my replication needs, and I use Nagios to monitor that the whole setup is working as intended. However, when it doesn't, I think some sort of log entry on the remote system would be nice to have. Preferably in the system log so that journalctl can find it (or if it doesn't find it, I would know where to start the fault-finding).
In my case, I initiate a syncoid run from a bash script (under Ubuntu, not that it should matter), that includes lines such as logger --tag="$SYSTEMLOGTAG" --priority notice "Starting replication" (with some IP and dataset info) prior to calling syncoid. This works fine for me on the system that sends the snapshots.
But I want similar log entries on the remote system as well, the one being sshd to. Regardless if datasets are pushed to the remote system, or pulled from the remote system.
Is there an easy way to get that outcome? If not, I guess this can be considered a feature request. :-)
Granted, this is not very meaningful if there is only one sending and only one receiving system... But if many hosts push to one and the same target system, it would be.
(Having a look at the source code, it seems the remote commands executed via ssh are all native ZFS commands with inputs/outputs piped from/to local commands. So to get the result I'm looking for I guess the minimum effort would be to implement a new, separate call to sshafter the attempted zfs send or zfs receive command (using the same credentials), that is only executed if a syncoid command line option is present. E.g., use ssh to remotely execute a custom script [e.g. "syncoid-post-transfer-log" that could be placed in /usr/local/bin], and pass the originating IP address, the latest known status code plus the recently executed zfs send or zfs receive commands as parameters. And it would be up to each user to format the log messages (on the remote system) according to local tastes and needs.)
The text was updated successfully, but these errors were encountered:
This is out of scope for syncoid and should be added to your wrapper script. Just check for the exit code and on failure you can call your logger on the remote system.
I use
sanoid
andsyncoid
for my replication needs, and I use Nagios to monitor that the whole setup is working as intended. However, when it doesn't, I think some sort of log entry on the remote system would be nice to have. Preferably in the system log so thatjournalctl
can find it (or if it doesn't find it, I would know where to start the fault-finding).In my case, I initiate a
syncoid
run from a bash script (under Ubuntu, not that it should matter), that includes lines such aslogger --tag="$SYSTEMLOGTAG" --priority notice "Starting replication"
(with some IP and dataset info) prior to callingsyncoid
. This works fine for me on the system that sends the snapshots.But I want similar log entries on the remote system as well, the one being
ssh
d to. Regardless if datasets are pushed to the remote system, or pulled from the remote system.Is there an easy way to get that outcome? If not, I guess this can be considered a feature request. :-)
Granted, this is not very meaningful if there is only one sending and only one receiving system... But if many hosts push to one and the same target system, it would be.
(Having a look at the source code, it seems the remote commands executed via
ssh
are all native ZFS commands with inputs/outputs piped from/to local commands. So to get the result I'm looking for I guess the minimum effort would be to implement a new, separate call tossh
after the attemptedzfs send
orzfs receive
command (using the same credentials), that is only executed if asyncoid
command line option is present. E.g., usessh
to remotely execute a custom script [e.g. "syncoid-post-transfer-log" that could be placed in /usr/local/bin], and pass the originating IP address, the latest known status code plus the recently executedzfs send
orzfs receive
commands as parameters. And it would be up to each user to format the log messages (on the remote system) according to local tastes and needs.)The text was updated successfully, but these errors were encountered: