search

marcus67 / little_brother

Parental Control Application implemented in Python 3 packaged for Debian and Ubuntu to monitor and limit kids' play time on Linux hosts
GNU General Public License v3.0
59 stars 9 forks source link

Taskbar / client does not get user informations #157

Closed MrFly closed 3 years ago

MrFly commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

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 commented 3 years ago

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 commented 3 years ago

Mail is on it's way :-)

marcus67 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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