It fully initializes the address structure, so no need for pre-initialization,
and also returns the length of the address, so no need to recalculate using
SOCKADDR_UN_LEN().
socklen_t is unsigned, so let's not use an int for it. (It doesn't matter, but
seems cleaner and more portable to not assume anything about the type.)
As of the commit aae9a96d4b removing --follow
option in systemctl command, OUTPUT_FOLLOW has never been set anywhere. Let's
remove it.
The condition expression of the if-statement in show_journal() that refers to
OUTPUT_FOLLOW now thus evaluates always to true. Hence, the call of
sd_journal_wait() is in dead code, and the outer infinite for-loop is
meaningless, which we remove as cleanup.
There is no functional change by this commit.
This prevents an error in pam_systemd when logging in.
sshd[2623165]: pam_unix(sshd:session): session opened for user tony.stark(uid=10001) by (uid=0)
sshd[2623165]: pam_systemd(sshd:session): Failed to get user record: Invalid argument
Bug: https://bugs.gentoo.org/708824
For #8495: it is arguably useful to not show the length of the password
in public spaces. It is possible to press TAB or BS to cancel the asterisks,
but this is not very discoverable. Let's make it discoverable by showing
a message (in gray). The message is "erased" after the first character
is entered.
test-ask-password-api would crash if ^D was pressed.
If think the callers generally expect a non-empty strv as reply. Let's
return an error if we have nothing to return.
Also modernize test-ask-password-api a bit.
Previously, when doing an async PK query we'd store the original
callback/userdata pair and call it again after the PK request is
complete. This is problematic, since PK queries might be slow and in the
meantime the userdata might be released and re-acquired. Let's avoid
this by always traversing through the message handlers so that we always
re-resolve the callback and userdata pair and thus can be sure it's
up-to-date and properly valid.
When we do an async pk request, let's store which action/details we used
for the original request, and when we are called for the second time,
let's compare. If the action/details changed, let's not allow the access
to go through.
We use those strings as hash keys. While writing "a...b" looks strange,
"a///b" does not look so strange. Both syntaxes would actually result in the
value being correctly written to the file, but they would confuse our
de-deplication over keys. So let's normalize. Output also becomes nicer.
Add test.
