This happens for example when calling act_user_manager_get_user with a non-existing user. The "has no username" warning should only be emitted for existing users (i.e., !act_user_is_nonexisting), and a failed GetAll call should mark the user as non-existing (if it is still unloaded at that time). A failed GetAll could emit a more specific warning. GetAll can fail when FindUserByName/ID succeeds and returns a object path, but the object has already been unregistered again by the time the GetAll call is made. This can happen when asking for uid 0, for example, since a reload_users will unregister all explicitly excluded users, such as root. FindUserByName/Id should probably fail for explicitly excluded users, but libaccountsservice still needs to be prepared for GetAll to fail, I'd say. Anyway, it's just a warning... I have only noticed because we check for all unexpected messages in our test suite and this one pops up occasionally.
Created attachment 88010 [details] [review] Only warn about a missing username for existing users. This silences the bogus warning, which I think should be uncontroversial.
Created attachment 88011 [details] [review] Don't find excluded users. This changes semantics of FindUserByName and FindUserByUID, which I would expect to need discussion. The alternatives are to - continue to allow Find* to return non-human users, but to make a note of them so that reload_users will not unregister them. - do nothing and just accept that there is a (harmless) race. I like the first alternative best (better than the patch), since it would make the "system user" property useful.
Another alternative is to just not exclude users evers, and rely on the client to filter based on the "system user" property. I think that's the intention anyway, no?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/accountsservice/accountsservice/issues/19.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.