We are running VyOS 1.2.6 fully-virtualised on a pair of XenServer 6.5 SP1 platforms.

Both VMs have the webproxy service configured as follows:

set service webproxy cache-size '100'
set service webproxy default-port '3128'
set service webproxy listen-address 10.71.254.0
set service webproxy url-filtering squidguard auto-update update-hour '23'
set service webproxy url-filtering squidguard block-category 'gambling'
set service webproxy url-filtering squidguard block-category 'malware'
set service webproxy url-filtering squidguard block-category 'porn'
set service webproxy url-filtering squidguard block-category 'dangerous_material'
set service webproxy url-filtering squidguard block-category 'ddos'
set service webproxy url-filtering squidguard block-category 'dialer'
set service webproxy url-filtering squidguard block-category 'drugs'
set service webproxy url-filtering squidguard block-category 'mixed_adult'
set service webproxy url-filtering squidguard block-category 'phishing'
set service webproxy url-filtering squidguard block-category 'proxy'
set service webproxy url-filtering squidguard block-category 'remote-control'
set service webproxy url-filtering squidguard block-category 'redirector'
set service webproxy url-filtering squidguard block-category 'warez'
set service webproxy url-filtering squidguard default-action 'allow'
set service webproxy url-filtering squidguard local-block 'www.betfred.com'
set service webproxy url-filtering squidguard log 'gambling'
set service webproxy url-filtering squidguard redirect-url 'http://www.google.co.uk'
set service webproxy whitelist destination-address '78.109.170.125'
set service webproxy whitelist destination-address '185.31.224.1'
set service webproxy whitelist destination-address '89.206.171.234'
set service webproxy whitelist destination-address '83.104.213.97'
set service webproxy whitelist destination-address '94.236.107.145'
set service webproxy whitelist destination-address '91.228.166.13'
set service webproxy whitelist destination-address '91.228.166.14'
set service webproxy whitelist destination-address '91.228.166.15'
set service webproxy whitelist destination-address '91.228.166.16'
set service webproxy whitelist destination-address '91.228.166.88'
set service webproxy whitelist destination-address '91.228.167.21'
set service webproxy whitelist destination-address '91.228.167.26'
set service webproxy whitelist destination-address '91.228.167.132'
set service webproxy whitelist destination-address '91.228.167.133'
set service webproxy whitelist destination-address '38.90.226.36'
set service webproxy whitelist destination-address '38.90.226.37'
set service webproxy whitelist destination-address '38.90.226.38'
set service webproxy whitelist destination-address '38.90.226.39'
set service webproxy whitelist destination-address '38.90.226.40'
set service webproxy whitelist destination-address '41.71.77.123'
set service webproxy whitelist destination-address '188.225.81.21'
set service webproxy whitelist destination-address '119.29.72.159'
set service webproxy whitelist destination-address '5.144.157.73'
set service webproxy whitelist destination-address '52.20.149.84'
set service webproxy whitelist destination-address '3.212.254.55'

When the scheduled update runs, we see the following in /var/log/squidguard/squidGuard.log:

2020-11-24 00:17:03 [16644] INFO: New setting: dbhome: /opt/vyatta/etc/config/url-filtering/squidguard/db
2020-11-24 00:17:03 [16644] INFO: New setting: logdir: /var/log/squid3
2020-11-24 00:17:03 [16644] init domainlist /opt/vyatta/etc/config/url-filtering/squidguard/db/local-ok-default/domains
2020-11-24 00:17:03 [16644] FATAL: /opt/vyatta/etc/config/url-filtering/squidguard/db/local-ok-default/domains: Permission denied
2020-11-24 00:17:03 [16644] ERROR: Going into emergency mode
2020-11-24 09:53:58 [16644] ERROR: Ending emergency mode, stdin empty

The squid process is running but HTTP traffic does not pass (resulting in end-user impact) and /var/log/squid3/access.log does not get updated.

The user and group on /opt/vyatta/etc/config/url-filtering/squidguard/ are set incorrectly:

ls -lah /opt/vyatta/etc/config/url-filtering/squidguard/
total 20K
drwxr-xr-x 4 root root 4.0K Nov 2 17:06 .
drwxr-sr-x 3 root vyattacfg 4.0K Oct 21 15:35 ..
drwxr-xr-x 64 root root 4.0K Nov 23 23:17 archive
d-ws-w--wT 64 radius_user proxy 4.0K Nov 24 09:58 db
-rw-r--r-- 1 root root 49 Nov 23 23:21 updatestatus

And the subdirectories are set with a user of "radius_user" and group of "99":

/opt/vyatta/etc/config/url-filtering/squidguard/db# ls -lah
total 448K
d-ws-w--wT 64 radius_user proxy 4.0K Nov 24 09:58 .
drwxr-xr-x 4 root root 4.0K Nov 2 17:06 ..
lrwxrwxrwx 1 radius_user 99 9 May 11 2005 ads -> publicite
drwxr-xr-x 2 radius_user 99 4.0K Nov 23 23:17 adult
lrwxrwxrwx 1 radius_user 99 8 May 11 2005 aggressive -> agressif
drwxr-xr-x 2 radius_user 99 4.0K Nov 23 23:17 agressif
drwxr-xr-x 2 radius_user 99 4.0K Nov 23 23:17 arjel
drwxr-xr-x 2 radius_user 99 4.0K Nov 23 23:17 associations_religieuses
drwxr-xr-x 2 radius_user 99 4.0K Nov 23 23:17 astrology
......

Manually changing the user and group to proxy fixes the issue temporarily until the next scheduled download. When the ownership is set incorrectly it also causes the "commit" action to hang indefinitely if any changes are made to the webproxy configuration, requiring a CTRL+C and correcting the ownership manually, after which a commit succeeds.