Taskbar / client does not get user informations

[MrFly]

After upgrading from an 0.3x to 0.4.10 the client does not get user informations, according to the log:

2021-11-20 19:22:08,786 - MasterConnector - DEBUG - Executing POST API call 'http://192.168.178.10:5555/api/events'
2021-11-20 19:22:08,810 - App - DEBUG - Executing task app_control.check 0.006 [s] behind schedule... *** END ***
2021-11-20 19:22:08,810 - App - DEBUG - Sleeping for 4.839537 seconds (or until next signal)
2021-11-20 19:22:13,653 - App - DEBUG - Woken by signal
2021-11-20 19:22:13,654 - App - DEBUG - Executing task app_control.scan_processes(ProcessHandler) 0.004 [s] behind schedule... *** START ***
2021-11-20 19:22:13,654 - ClientProcessHandler - DEBUG - Scanning processes for users johann...
2021-11-20 19:22:13,686 - App - DEBUG - Executing task app_control.scan_processes(ProcessHandler) 0.004 [s] behind schedule... *** END ***
2021-11-20 19:22:13,686 - App - DEBUG - Executing task app_control.scan_processes(DeviceHandler) 0.003 [s] behind schedule... *** START ***
2021-11-20 19:22:13,689 - App - DEBUG - Executing task app_control.scan_processes(DeviceHandler) 0.003 [s] behind schedule... *** END ***
2021-11-20 19:22:13,689 - App - DEBUG - Sleeping for 0.094472 seconds (or until next signal)
2021-11-20 19:22:13,784 - App - DEBUG - Woken by signal
2021-11-20 19:22:13,785 - App - DEBUG - Executing task app_control.check 0.001 [s] behind schedule... *** START ***
2021-11-20 19:22:13,785 - UserManager - WARNING - Cannot find user information for user 'johann', will retry later...
2021-11-20 19:22:13,787 - MasterConnector - DEBUG - Executing POST API call 'http://192.168.178.10:5555/api/events'
2021-11-20 19:22:13,809 - App - DEBUG - Executing task app_control.check 0.001 [s] behind schedule... *** END ***
2021-11-20 19:22:13,810 - App - DEBUG - Sleeping for 4.974878 seconds (or until next signal)

The taskbar says "Benutzer 'johann' nicht eingeloggt". This can be worked around by simply restarting the client (service little-brother restart). But this is surely not an option.

Can I fix this by configuration or is it a real bug?

[marcus67]

Hi Johann, thank you for reporting this bug. I will require some more details so that I can fully understand the issue. Since I see an API call, I assume that you are using master and slave processes. Correct? Do both machines have the same user id for user johann? When you say that the problem can be fixed by re-starting the client but this does not help you: when does the error occur again? Please, try to describe a setup that I can use to reproduce the error locally. Thanks a lot!

[MrFly]

Hi Marcus,

Thank you for your fast reply.

You're right, master/slave system. This username exists on server and client - have to, because me and my son are called Johann :-) I mapped the user id in config in server side (johann:1000) - it's the right value on the client BUT also on the server (which is a Raspi btw).

The problem returns on every startup/reboot. The client runs as a daemon and starts on boot. The taskbar starts at login by running run_xxx_taskbar as startup application in gnome (Ubuntu 20.04).

A restart of the service does not help practically, because my son should be able to use the laptop without needing me to restart the daemon. Btw he has no sudo access.

My thinkings:
Could be maybe a problem, that this laptop uses WLAN, which connects after session login and therefore after startup of the daemon, maybe the taskbar starts before WLAN, I don't know - could be a timing problem, which get's resolved on restarting the service.

Please give a call, if you need more infos.

Thanks alot!

[marcus67]

Hi Johann,
so I will try to set it up as follows:

• The master server can be assumed to be stable so it can be running all the time.
• The slave will start up, but I will try try to make the communication with the master fail. This should emulate the condition that the client starts before the WIFI is active.
• Then the "WIFI" will be activated.

I will let you know if this setup can reproduce your symptoms.

By the way: the taskbar is just a display. It does not have any active role in the communication between master and slave. So it's not really important when it starts up with respect to the master and/or the slave.

[marcus67]

OK. That's not it, apparently. In my setup there's no error message regarding a missing user on the slave. Thinking about this, I have to admit that this is absolutely correct, since the slave does NOT know about which users to monitor until it has communicated with the master at least once. To further debug the issue, send me your master and slave configurations to my email address little-brother@web.de, please! If applicable, replace passwords and tokens.
It would also be helpful to have the complete little-brother log file of the slave after reboot and the relevant part of the master log file since the reboot of the slave. Thanks a lot!

[MrFly]

Mail is on it's way :-)

[marcus67]

Thanks a lot for the input! The configurations are OK and the log files do not look suspicious. However, I think I have found a potential problem which I fixed in 0.4.11. It is due to the fact that the slave discards all events of the outgoing queue if the API call to the master was not successful. When the connection is restored the important event START_CLIENT has already been discarded and never reaches the master. Hence, the master will not send important initialization data to the slave (such as the user mapping).

Please, try 0.4.11 and let me know it makes any difference. Thanks!

[MrFly]

Thanks, Marcus, works like a charm (as far as I were able to test in a few minutes).

I updated server side, then the client. After that I rebooted the client, logged in with my son's user id. A few seconds later the WLAN connected automatically, a few seconds after that the taskbar updated itself with the right restrictions - done and works as expected.

Thank you, great job!

One thing, maybe a new issue:
Since 0.4.x I always have to remove /var/lib/little-brother/vitualenv/. I did this meanwhile six times from 0.4.9 to 0.4.11 (+ some times I did not think of it and first tried without deleting).

It would be great, if the installer package could do this job as some pre-cleanup. It's sure not a big problem, just one thing to do for the user, but would reduce the admin's time for updates.

[marcus67]

Closed in b26f8fb.
@MrFly : could you create a new issue for the problem with the virtual environment? That way you'll be kept in the loop. Thanks