June 15, 2019

Uncontrolled Syncthing *sync-conflict* for all or many files

Problem:

Uncontrolled Syncthing *sync-conflict* for all or many files.

Background:

I had three devices setup with syncthing for maybe a couple years now. I accidentally sudo rm -rf / my laptop. YES, true i fogort that damned period in ./ while on my SD-Card which i was trying to purge. I quickly Ctrl-C, but it was too late – what a disaster! Fortunately ~/ and my external USB Disk stayed intact for the most part. But I had to reinstall Xubuntu from scratch. After reinstalling Syncthing, the syncs kept causing many many sync-conflict files. These were mostly for large 4GB video files and conflict creation was rampant and uncontrollable. My syncs are all in my ~/SYNCfolder, so I kept performing find ~/SYNC/ -name "*sync-conflict*" -delete (after analysis that the originals were good of course), but the conflicts repeatedly resurrected. Some searches were suspect, and some solutions only worked for text files – worthless.

Tentative Solution:

I found the idea of a “database reset” referenced in a github issue, so i looked it up:
-reset-database
Reset the database, forcing a full rescan and resync. Create .stfolder
folders in each sync folder if they do not already exist. Caution:
Ensure that all sync folders which are mountpoints are already
mounted. Inconsistent versions may result if the mountpoint is later
mounted and contains older versions.
I performed syncthing -reset-database on all three devices and so far the conflicts have subsided with the exception of a couple files.
Whew, continuous uncontrollable disaster #2 averted. As for disaster #1, i’m still repairing that one.

As always, Good Luck!
Please comment or tip me or use any/all of my affiliate links; Thank YOU!


Please consider crypto tipping:
  

April 30, 2019

Shotcut-launcher

Shotcut

Problem #1:
Re-launching Shotcut will over-write any error logs saved from the last execution.

Problem #2:
Downloading new versions force you to edit panel shortcuts that you may have created.

Solution:
Shell wrapper: (read it, know it)

Please consider crypto tipping:
  

October 19, 2018

HAProxy logging on RHEL7

How to configure RHEL7 rsyslog for haproxy logging.

Problem: The haproxy config (/etc/haproxy/haproxy.cfg) reports how to enable logs; however, this seems to be syslogd specific which is not what is running in RHEL7

Solution: enable logging via rsyslog configs:
Modify /etc/rsyslog.conf to include:

# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514
# Provides TCP syslog reception
$ModLoad imtcp $InputTCPServerRun 514

*note: maybe only UDP or maybe only TCP is needed.

Modify /etc/rsyslog.d/listen.conf

SYSLOGD_OPTIONS="-m 0 -r"
local2.* /var/log/haproxy.log

*note: this could just as easily be /etc/rsyslog.d/haproxy.conf, i chose the prior only because it pre-existed.

*note: local2 is the default in haproxy, but this could be changed if desired.

*note: the -r is required, the -m 0 is not, but meant to reduce junk. If it is looking up DNS and you don’t want, then add -x

Now sudo systemctl restart rsyslog and tail -f /var/log/haproxy.log to see the records.

Note: There are many and more complex settings, this is just a most basic configuration.

As always, good luck!

~~
resources used:

  1. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-syslog_tuning_tips.html
  2. https://linux.die.net/man/8/rsyslogd

Please consider crypto tipping: