New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Logind shutdown refactor #21838
Logind shutdown refactor #21838
Conversation
6067b66
to
ae2eb6b
Compare
ae2eb6b
to
2e876fc
Compare
|
Added test case. It uses wraps nspawn and uses pexpect to log in on the console. Then spawn screen to have two ptys where the script can check the wall message. |
40194b8
to
7c972f9
Compare
|
Ic. So I shall remove the commit here and potentially have separate discussion about it I guess |
7c972f9
to
8a05ecc
Compare
|
I installed the necessary dependencies for TEST-69 in CentOS CI, but the test still keeps failing on CentOS Stream 8. Also, the deps need to be installed in Ubuntu CI as well (/cc @bluca) - |
|
added and re-triggered the focal-amd64 run |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this. Looks like a refactoring was overdue.
8a05ecc
to
4a9f0d4
Compare
|
updated based on previous comments |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice. Several coding style nits.
An elapse time of zero means NOW which should trigger a wall message.
The code at this point is not able to tell whether it was called as halt/poweroff/reboot or shutdown with time "now". The code also takes a shortcut to skip logind if called as root. That however means asking shutdown for immediate action won't trigger a wall message. As per systemd#8424 (comment) all commands should trigger a wall message. That simplifies the code as we can try logind first always.
Something calling directly into the dbus interface to request a shutdown may not bother turning wall messages on explicitly. This has the convenient side effect that no separate polkit auth is required to turn on wall messages. Was annoying as having a wall message is the default behavior of the commandline tools. Now it's the other way around ie eg systemctl reboot --no-wall requires auth to explicitly turn off the wall message.
The wall mechanism uses the scheduled_shutdown_type to determine what message to send so it needs to be filled in also for the cases that call for shutdown without schedule. It's really a hackish way. The overall code needs refacturing.
4a9f0d4
to
bce6a95
Compare
|
Thanks. Most comments are addressed. Please do the rest of them. |
|
Working on it. GH fooled me by hiding he big diff so didn't see all :) |
Avoid hardcoded strings and string compares related to shutdown actions. Instead put everything into a common structure. Reuse existing HandleAction as index since it's already exposed as property for the button handlers.
For shutdowns don't fall back to starting the target directly if talking to logind failed with auth failure. That would just lead to another polkit auth attempt.
Wraps nspawn to be able to use pexpect. The test logs in on the console and runs screen. In one screen window it types in shutdown commands and checks whether a wall message was sent to the other.
bce6a95
to
48f3bc5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! LGTM.
| HandleAction manager_handle_for_item(const ActionTableItem* a) { | ||
| if (a && a < action_table + ELEMENTSOF(action_table)) | ||
| return a - action_table; | ||
| return _HANDLE_ACTION_INVALID; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks very hackish to me. I would simply include the enum value in a member of the ActionTableItem structure. At least I would add assert(a >= action_table && a < action_table + ELEMENTSOF(action_table)) here as calling this function with anything not satisfying these constraints is a misuse of the function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, there are tons of improvements that can be applied still and I didn't even get to the thing I actually wanted to do :-) As I wrote elsewhere the rabbit hole is deep. When is a pr considered enough of an improvement to merge it though? If I change this, will someone else chime in and demand yet another change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK. Let's merge this as is. If necessary, let's apply followups.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would agree with you if this would be existing code. However, this is code you are introducing with this PR, thus I would much prefer if it would not add a questionable code pattern that would need yet another PR to clean up. However, I don't have a say in whether this PR should be accepted as it is or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At least, the function checks NULL, so it satisfies minimum criteria.
We usually introduce functions like the following way.
void function(Object *obj) {
assert(obj);
...;
}
Here, it avoids only case that obj == NULL. But it can easily triggers segfault or so by e.g.
Object obj;
function((Object*) ((uint8_t*) &obj + 1));
The situation @dnicolodi concerns sounds a kind of such case for me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note, I do not say @dnicolodi's suggestion is bad. I think it is not a strong requirement for this PR being merged.
If you'd like, please submit a followup PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will do. Thank you!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks OK in general, just some minor things.
(Sorry for the post-merge review, been on parental leave the past months)
|
(I understand that some of the points I raised are already fixed in the meantime by later commits, ignor those then) |
|
Sure, no worries. Congrats, hope you had a good time :) |
Did the refactor last to show where this is coming from. The previous commits could be picked separately. Esp the shutdown -c fix makes sense right away IMO.