Hi all,
For the archives, I'd just like to report that inverse support has
identified and fixed the problem in sogo-ealarms-notify.
(Fixed: 41bbbfacd9a63d7de53273a05a4f119ebda302ba)
MJ
On 9/17/20 3:20 PM, mj (li...@merit.unu.edu) wrote:
Hi,
With MySQL4DebugEnabled = YES in sogo.conf, the following is logged:
# /bin/su -s /bin/bash -c '/usr/sbin/sogo-ealarms-notify' sogo
2020-09-17 14:30:24.653 sogo-ealarms-notify[24890:24890] MySQL4
connection established 0x0x56369b188fd0
2020-09-17 14:30:24.653 sogo-ealarms-notify[24890:24890] ----------
-[MySQL4Channel openChannel]: <MySQL4Channel[0x0x56369b1ca320]
connection=0x0x56369b188fd0> opens channel count[0]
2020-09-17 14:30:24.653 sogo-ealarms-notify[24890:24890] MySQL4
channel 0x0x56369b1ca320 opened (connection=0x0x56369b188fd0,sogo)
2020-09-17 14:30:24.653 sogo-ealarms-notify[24890:24890]
<MySQL4Channel[0x0x56369b1ca320] connection=0x0x56369b188fd0> SQL: BEGIN;
2020-09-17 14:30:24.653 sogo-ealarms-notify[24890:24890]
<MySQL4Channel[0x0x56369b1ca320] connection=0x0x56369b188fd0> query
has no results.
2020-09-17 14:30:24.653 sogo-ealarms-notify[24890:24890]
<MySQL4Channel[0x0x56369b1ca320] connection=0x0x56369b188fd0> SQL:
SELECT t1.c_alarm_number, t1.c_name, t1.c_path, t1.c_recurrence_id,
t1.c_uid FROM sogo_alarms_folder t1 WHERE t1.c_alarm_date >=
1600345500 AND t1.c_alarm_date <= 1600345800;
2020-09-17 14:30:24.653 sogo-ealarms-notify[24890:24890]
<MySQL4Channel[0x0x56369b1ca320] connection=0x0x56369b188fd0> query
has results, entering fetch-mode.
2020-09-17 14:30:24.653 sogo-ealarms-notify[24890:24890]
<MySQL4Channel[0x0x56369b1ca320] connection=0x0x56369b188fd0> SQL:
ROLLBACK;
2020-09-17 14:30:24.654 sogo-ealarms-notify[24890:24890]
<MySQL4Channel[0x0x56369b1ca320] connection=0x0x56369b188fd0> query
has no results.
2020-09-17 14:30:24 417 [Warning] Aborted connection 417 to db:
'sogo-db' user: 'sogo-user' host: 'localhost' (Got an error reading
communication packets)
Anyone?
MJ
On 9/17/20 1:05 PM, mj (li...@merit.unu.edu) wrote:
Hi,
We're running sogo v5 on debian. Last tuesday we upgraded from stretch
to buster. Ever since, mysql started giving errors for every run of
the sogo-ealarms-notify cronjob:
Sep 17 11:56:01 sogo CRON[6311]: (sogo) CMD
(/usr/sbin/sogo-ealarms-notify > /dev/null 2>&1)
mysql [Warning] Aborted connection 148 to db: 'sogo-db' user:
'sogo-user' host: 'localhost' (Got an error reading communication
packets)
Database connectivity otherwise works fine: /SOGo and ActiveSync
interface works, calenders/contacts are all displayed without issues.
For the record: After the upgrade from we also changed to the buster
SOGo repo. Today we also tried with the latest v5 nightlies to see if
that fixes this, but alas: no.
Buster comes with mariadb-server-10.3, which we are running, using the
'traditional' (old style) sogo database layout.
Installed sogo packages:
# apt-show-versions|grep -e sogo
sogo:amd64/buster 5.0.0.20200917-1 uptodate
sogo-activesync:amd64/buster 5.0.0.20200917-1 uptodate
# apt-show-versions|grep -e sope
libsope-appserver4.9:amd64/buster 4.9.r1664.20200915 uptodate
libsope-core4.9:amd64/buster 4.9.r1664.20200915 uptodate
libsope-gdl1-4.9:amd64/buster 4.9.r1664.20200915 uptodate
libsope-ldap4.9:amd64/buster 4.9.r1664.20200915 uptodate
libsope-mime4.9:amd64/buster 4.9.r1664.20200915 uptodate
libsope-xml4.9:amd64/buster 4.9.r1664.20200915 uptodate
sope4.9-dbg:amd64/buster 4.9.r1664.20200915 uptodate
sope4.9-gdl1-mysql:amd64/buster 4.9.r1664.20200915 uptodate
sope4.9-libxmlsaxdriver:amd64/buster 4.9.r1664.20200915 uptodate
Anyone with an idea what to look for / where to look at?
Why would the sogo-ealarms-notify cause this problem, while the
regular sogo components works fine? Anyone else seeing this?
Hope to get some insights here! Thanks! :-)
MJ
--
users@sogo.nu
https://inverse.ca/sogo/lists