Hi, When implementing socket activation for PulseAudio, the question came up of how to ship the enablement when running "make install".
In my first incarnation I simply shipped a /usr/lib/systemd/user/socket.target.wants/pulseaudio.socket symlink. I did this because I considered this a vendor choice (as opposed to an administrator choice) and that's probably what I'd do downstream (although I will add an additional condition in the unit so that it doesn't run when the user has an "ALSA Sound Profile" (where "Sound Profiles" are our downstream way of managing this choice for users), but this is out of scope here). However, this decision sparked some debate about whether we really should add such a "hard" enablment during make install. Perhaps the user .socket unit should just have an [Install] section and it should be up to the packagers to call "systemctl --global enable" at package install time. This would mirror system services for the most part... with the exception that system services should really be calling preset... So that led me to ask myself: does systemctl preset support user units? The man page doesn't make it clear that e.g. the --global switch applies to preset as well as enable, but in testing it (happily) appears to work! So I'm going to answer that question with a "yes, it does work!" So, as preset works for user-units, I'm thinking that we should NOT ship a /usr/lib/systemd/user/socket.target.wants/pulseaudio.socket symlink and leave it to downstream packagers to call "systemctl preset --global pulseaudio.socket" when the package is first installed. This will create the /etc/systemd/user/socket.target.wants/pulseaudio.socket symlink for us and all is well. [As a side note, if this is the recommended approach, then we should probably add appropriate RPM macros to macros.systemd for user unit presets...] There are, however, two questions still remain: 1. As we have two units, pulseaudio.socket and pulseaudio.service, and as the desired behaviour is to enable only the socket but not the service (i.e. by default rely on socket activation - don't waste resources unless a client actually connects; this is a bit of an assumption - perhaps this should be desirable?) should we: a) Recommend packagers only call "systemctl preset --global pulseaudio.socket" b) Recommend packagers call "systemctl preset --global pulseaudio.socket pulseaudio.service", but remove the [Install] section from the .service c) Recommend packagers call "systemctl preset --global pulseaudio.socket pulseaudio.service", but ship a preset file in /usr/lib/systemd/user-preset/50-pulseaudio.preset that has "disable pulseaudio.service" in it. systemd.preset(5) suggests not to do c) but I think this could be an example of an exception to that rule (to me this seems cleanest)? Perhaps there are other socket+service pairs where this makes sense too however, and this should be encapsulated in the preset logic more generally? (i.e. the default logic is "if a .service unit is set to be enabled, double check to see if it has a corresponding .socket unit which will be enabled and if so, skip enabling the .service". 2. On factory reset, I do not see any calls to systemctl preset, for either the system or user units. Am I missing something or is this something which should be part of the factory reset logic (i.e. a unit with ConditionNeedsUpdate=/etc to call systemctl preset - if so, it would presumably also need to reload systemd if any work was done for system units, but we can assume this is safely completed before any user instances kick in). Thoughts welcome :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
