ejabberd_c2s:process_info: got unexpected info

[dhiru1602]

What version of ejabberd are you using?

17.04

What operating system (version) are you using?

Debian Jessie

How did you install ejabberd (source, package, distribution)?

https://apt.jabber.at

What did not work as expected? Are there error messages in the log? What
was the unexpected behavior? What was the expected result?

I have a shared roster group setup so that every registered user will have every other registered user in their roster. I have followed the guide from the link: https://www.ejabberd.im/shared-roster-all (Example 1: everybody can see everybody else)

The roster group works fine and every registered user is able to see every other registered user and their online status. However, In the server logs I see the following spam.

[warning] <0.9062.4>@ejabberd_c2s:process_info:247 got unexpected info: {item,{<<"user1">>,<<"example.com">>,<<>>},both}
[warning] <0.9062.4>@ejabberd_c2s:process_info:247 got unexpected info: {item,{<<"user2">>,<<"example.com">>,<<>>},both}
[warning] <0.9062.4>@ejabberd_c2s:process_info:247 got unexpected info: {item,{<<"user3">>,<<"example.com">>,<<>>},both}

Everytime a user logs in, the above warning is printed repeatedly with the names of all the other registered users. This causes the ejabberd.log file to grow very big. Is there any way I can fix or prevent the warning from being logged?

[zinid]

This is a bug in mod_shared_roster. I mark it as to be fixed by 17.08

[cromain]

mod_shared_roster needs complete rewrite, so we change schedule for this to be correctly done

[genodeftest]

Looks like a duplicate of #1651 to me.

[zinid]

@genodeftest yes, definitely

[cC-Xx]

hi
we have a loop here, #1651 linked to #1846 and #1846 linked to #1651. what to do to avoid this error?

[m1cka]

hi,
i updated ejabberd 17.06 to 17.09.
OS centos 7.4
backend: mysql 5.7
php: 7.1
same problem:
[warning] <0.767.0>@ejabberd_c2s:process_info:254 got unexpected info: {item,{<<"username">>,<<"hostname.com">>,<<>>},both}

 mod_roster:
    db_type: sql
 mod_shared_roster:
    db_type: sql

[acrixl]

ejabberd-17.09
debian 9.1
backend: mnesia
[warning] <0.1289.0>@ejabberd_c2s:process_info:254 got unexpected info: {item,{<<"user">>,<<"domain.com">>,<<>>},both}

[cromain]

added #1706 for resolution, which should fix this issue.

[iprok]

Just have updated to 18.01. The issue is still here

[miniskipper]

Can also confirm that the issue is still there in 18.01.

[zinid]

It would be great if someone can test the fix.

[cC-Xx]

server refused to start with your patch against FreeBSD's port ...

2018-03-19 18:25:31.946 [error] <0.244.0> Supervisor ejabberd_sup had child ejabberd_gen_mod_sup started with gen_mod:start_link() at undefined exit with reason {'EXIT',{function_clause,[{mod_roster,mod_opt_type,[''],[{file,"src/mod_roster.erl"},{line,1186}]},{gen_mod,get_validators,3,[{file,"src/gen_mod.erl"},{line,461}]},{gen_mod,validate_opts,3,[{file,"src/gen_mod.erl"},{line,502}]},{gen_mod,start_module,4,[{file,"src/gen_mod.erl"},{line,195}]},{lists,foreach,2,[{file,"lists.erl"},{line,1338}]},{gen_mod,start_link,0,[{file,"src/gen_mod.erl"},{line,79}]},{supervisor,do_start_child,2,[{file,"supervisor.erl"},{line,365}]},{supervisor,start_children,...}]}} in context start_error

[zinid]

server refused to start with your patch against FreeBSD's port

Because you cannot simply apply the patch to some random ejabberd version.

[cC-Xx]

it's not random

[zinid]

it's not random

Who knows, from your comment it's unclear.

[cC-Xx]

https://www.freshports.org/net-im/ejabberd

[zinid]

You cannot apply the patch to 18.01

[cC-Xx]

hm ... ok ... how to fix error mentioned in subject in version 18.01? is it possible?

[zinid]

is it possible?

Most likely not.

[cC-Xx]

it's not bug, it's a feature? how to fix it? fetch fresh sources (with your patches) from github and try to use it in production? or how?

[zinid]

it's not bug, it's a feature? how to fix it? fetch fresh sources (with your patches) from github and try to use it in production? or how?

I don't think it's a terribly great idea to test this in production. What I really asked to test is only the stuff that didn't work for you and only in the case when it's easy to reproduce the bug in testing environment.

[cC-Xx]

yes, server refused to start ...

[zinid]

Whatever, seems like there are people willing to test it. Also, the stuff I test myself works: roster gets populated, presences get routed, @all@ works correctly, no "unexpected info" in the log.

[Akasch]

For me it seems to work, the errors after login are fixed. Using extauth_program and mod_shared_roster. I think I will test tomorrow with more users.

[Neustradamus]

@Akasch it is good?

[Akasch]

@Neustradamus it works, but if your groups are very big (we had ~1700 jids in some) the Database is swamped with a very height load. For our Server the 40.000 Selects per second there not enough to not fall behind on message processing

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.