Skip to content

Conversation

poettering
Copy link
Member

Triggered by this thread:

https://lists.freedesktop.org/archives/systemd-devel/2018-July/040975.html

plus some other tiny microfixlets


systemd itself:

* `$SYSTEMD_ACTIVATION_UNIT` — set for all NSS and PAM module invocatins that
Copy link
Contributor

@lucab lucab Jul 5, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/invocatins/invocations/
Also, do you want to codify here that the value is the name of the parent unit? (I'm not sure if it is already implicit now or intentionally left undefined)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, what do you mean by "parent" unit? it's the unit that we run the NSS/PAM lookups for.

Copy link
Contributor

@lucab lucab Jul 18, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was only asking if you want to specify in this doc what the value for the environment flag is supposed to be (as the modules may want to check for specific values, like this PR does).

Copy link
Member

@keszybz keszybz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good in general, apart from the minor types.

Nevertheless, I'm starting to think that DynamicUser=yes for basic services like systemd-resolved and systemd-networkd is not the right solution. Dynamic users make a lot of sense for transient services or for stuff which is not always running. But for stuff that we except to be always there, and running on a significant percentage of installations, removes the gains we get. Am I missing some important advantage apart from giving the DynamicUser implementation more testing?

@@ -2828,10 +2828,22 @@ static int exec_child(
}
}

/* We are about to invoke NSS and PAM modules. Let's tell them what we are doing here, maybe they care. This is
* used by nss-resolve to disabled itself when we are about to start systemd-resolved, to avoid deadlocks. Note
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

disabled → disable

@poettering
Copy link
Member Author

poettering commented Jul 17, 2018

But for stuff that we except to be always there, and running on a significant percentage of installations, removes the gains we get. Am I missing some important advantage apart from giving the DynamicUser implementation more testing?

Well it's sexier to use DynamicUser=1 ;-)

I figure this is a discussion to have, but it's kinda independent of this specific PR. Moreover, now that that 5b5d826 has been merged we are basically back to static users for those three services anyway...

@poettering
Copy link
Member Author

I force pushed a new version. I reworded the paragaph @lucab mentioned a bit, but I am not sure what @lucab precisely meant, hence I am not sure it improves anything for him... @lucab?

I also fixed the typo @keszybz found

@poettering
Copy link
Member Author

Ahh, I think I got @lucab's comment now. Will shortly push a new version that explicitly says the value is the unit's name. This was missing in the original version by mistake.

@poettering
Copy link
Member Author

(just to clarify this: the new version i refer to in the comment is the one that is already here... for some reason github showed the message after the push, even though it happened the other way round)

@keszybz keszybz merged commit 54fe2ce into systemd:master Jul 26, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

3 participants