Hi all,
I have had this week a rare issue with an user who complained about
his calendar being shown empty. We're using DAViCal 0.9.9.4 and users
authenticate against LDAP.
After looking at the logs and enabling debug, I found out that user
was authenticating OK, but its user entry was trying to be created once
and again, throwing a 'duplicate key' on 'usr' table.
With debug enabled I saw the following:
--8<--
( correct authentication )
[Sat May 21 14:31:06 2011] [error] [client *user_ip*] davical: LOG:
always: Query: DBGQ: SELECT *, to_char(updated at time zone 'GMT','Dy,
DD Mon
IYYY HH24:MI:SS "GMT"') AS modified, principal.*, 0::BIT(24) AS
privileges FROM usr LEFT JOIN principal USING(user_no) WHERE
lower(username) = lower(:
param)
[Sat May 21 14:31:06 2011] [error] [client *user_ip*] davical: LOG:
always: Query: DBGQ: ":param" => "user_with_problems"
[Sat May 21 14:31:06 2011] [error] [client *user_ip*] davical: LOG:
always: Query: DBGQ: Took: 0,003533 to find 151 rows.
[Sat May 21 14:31:06 2011] [error] [client *user_ip*] davical: ALL:
LDAP:user user_with_problems doesn't exist in local DB, we need to create it
-->8--
151 rows! For me it seems like a bug, user was working all right until
a new principal was added for him (I don't know under which
circumstances), and after that every authentication attempt results in
new usr & principal being created (now we have 152 principals for this
user, fortunately only one 'usr' because of key duplicity constraint).
Of course that makes all calendar queries to fail.
I can remove unused principal rows for this user by hand, but did
anyone suffer this issue too? Could it be a known bug corrected in git
version? If not, what can I do to help you debug this one?
If that helps, there is no other user with this issue (checked with
count() on principals table), and these are the first 3 rows for this user:
--8<--
principal_id | type_id | user_no | displayname |
default_privileges
181659 | 1 | 1225 | USER FULL NAME |
000000000001111000000000
193527 | 1 | 1225 | USER FULL NAME |
000000000001111000000000
193528 | 1 | 1225 | USER FULL NAME |
000000000001111000000000
-->8--
I can provide the full debug log, if you need it.
Thank you very much, regards.
--
Jorge L?pez P?rez
jabber: jorgelp at im.us.es
I have had this week a rare issue with an user who complained about
his calendar being shown empty. We're using DAViCal 0.9.9.4 and users
authenticate against LDAP.
After looking at the logs and enabling debug, I found out that user
was authenticating OK, but its user entry was trying to be created once
and again, throwing a 'duplicate key' on 'usr' table.
With debug enabled I saw the following:
--8<--
( correct authentication )
[Sat May 21 14:31:06 2011] [error] [client *user_ip*] davical: LOG:
always: Query: DBGQ: SELECT *, to_char(updated at time zone 'GMT','Dy,
DD Mon
IYYY HH24:MI:SS "GMT"') AS modified, principal.*, 0::BIT(24) AS
privileges FROM usr LEFT JOIN principal USING(user_no) WHERE
lower(username) = lower(:
param)
[Sat May 21 14:31:06 2011] [error] [client *user_ip*] davical: LOG:
always: Query: DBGQ: ":param" => "user_with_problems"
[Sat May 21 14:31:06 2011] [error] [client *user_ip*] davical: LOG:
always: Query: DBGQ: Took: 0,003533 to find 151 rows.
[Sat May 21 14:31:06 2011] [error] [client *user_ip*] davical: ALL:
LDAP:user user_with_problems doesn't exist in local DB, we need to create it
-->8--
151 rows! For me it seems like a bug, user was working all right until
a new principal was added for him (I don't know under which
circumstances), and after that every authentication attempt results in
new usr & principal being created (now we have 152 principals for this
user, fortunately only one 'usr' because of key duplicity constraint).
Of course that makes all calendar queries to fail.
I can remove unused principal rows for this user by hand, but did
anyone suffer this issue too? Could it be a known bug corrected in git
version? If not, what can I do to help you debug this one?
If that helps, there is no other user with this issue (checked with
count() on principals table), and these are the first 3 rows for this user:
--8<--
principal_id | type_id | user_no | displayname |
default_privileges
181659 | 1 | 1225 | USER FULL NAME |
000000000001111000000000
193527 | 1 | 1225 | USER FULL NAME |
000000000001111000000000
193528 | 1 | 1225 | USER FULL NAME |
000000000001111000000000
-->8--
I can provide the full debug log, if you need it.
Thank you very much, regards.
--
Jorge L?pez P?rez
jabber: jorgelp at im.us.es