<html><head></head><body><div>On Sat, 2015-09-12 at 11:08 -0700, Alex Carver wrote:</div><blockquote type="cite">Ok, so serious questions, then, that no one ever seems to answer online<br>
that I can find:<br>
<br>
1. If a feature of systemd is not needed at all, does it still load?<br>
Case in point, according to the docs PulseAudio is a core module of PID<br>
1. If I have no audio hardware, is that still going to be in the memory<br>
footprint? It appears from some reading that the packaged versions that<br>
would come with any major distro would have every single module built in<br>
which case the only way to turn things off is to compile systemd from<br>
scratch. I can't find anything about turning features off if the<br>
compile-time switch was turned on.<br></blockquote><div><br></div><div>Pulseaudio is its own dæmon. I do not have it on any of my embedded systems (even the testing ones). You can still communicate directly with ALSA just fine.</div><div><br></div><div>Offer of proof: Fedora 22 is a systemd-based system. Pulseaudio is started as part of the X11 startup process or the user session. The PA daemon runs as user gdm or user $UID, and is not started by the system. PulseAudio can make use of the udev library to simplify the process of finding hardware sound interfaces. One of the points of udev and dynamic device management is that nothing is loaded if there isn't a reason for it (or rather, that capability exists: it is possible to run legacy code that is unaware of udev, which may or may not work in modern systems anyway.)</div><div><br></div><div>Additional offer of proof: The PulseAudio package is a set of packages, none of which are part of systemd. PulseAudio can be killed with the only ramification being that your software will either need to manually or automatically fall back to using ALSA's interface, which may or may not support simultaenous playback of multiple streams (again depending on the ALSA configuration and the hardware which backs it).</div><div><br></div><div>Final proof: The PulseAudio package depends on systemd as built in Fedora 22 (not the other way around). Attempting to remove PA from the system will succeed (but due to the way that the Fedora packagers built the system, this removes a lot of useful functionality, such as GNOME). Though not as much as I would have expected, really:</div><div><br></div><blockquote type="cite"><pre>[<a href="mailto:mbt@aloe">mbt@aloe</a> ~]$ sudo dnf remove pulseaudio</pre><pre>[sudo] password for mbt: </pre><pre>Dependencies resolved.</pre><pre>====================================================================================================================================</pre><pre> Package Arch Version Repository Size</pre><pre>====================================================================================================================================</pre><pre>Removing:</pre><pre> alsa-plugins-pulseaudio x86_64 1.0.29-1.fc22 @System 104 k</pre><pre> gdm x86_64 1:3.16.2-1.fc22 @System 3.3 M</pre><pre> gnome-bluetooth x86_64 1:3.16.1-1.fc22 @System 83 k</pre><pre> gnome-classic-session noarch 3.16.2-1.fc22 @System 114 k</pre><pre> gnome-initial-setup x86_64 3.16.3-1.fc22 @System 2.1 M</pre><pre> gnome-shell x86_64 3.16.3-1.fc22 @System 9.2 M</pre><pre> gnome-shell-extension-alternate-tab noarch 3.16.2-1.fc22 @System 9.4 k</pre><pre> gnome-shell-extension-apps-menu noarch 3.16.2-1.fc22 @System 27 k</pre><pre> gnome-shell-extension-background-logo noarch 3.16.1-1.fc22 @System 56 k</pre><pre> gnome-shell-extension-common noarch 3.16.2-1.fc22 @System 542 k</pre><pre> gnome-shell-extension-launch-new-instance noarch 3.16.2-1.fc22 @System 4.9 k</pre><pre> gnome-shell-extension-places-menu noarch 3.16.2-1.fc22 @System 22 k</pre><pre> gnome-shell-extension-user-theme noarch 3.16.2-1.fc22 @System 7.0 k</pre><pre> gnome-shell-extension-window-list noarch 3.16.2-1.fc22 @System 55 k</pre><pre> gnome-tweak-tool noarch 3.16.2-1.fc22 @System 941 k</pre><pre> pulseaudio x86_64 6.0-8.fc22 @System 3.3 M</pre><pre> pulseaudio-gdm-hooks x86_64 6.0-8.fc22 @System 354 </pre><pre> pulseaudio-module-bluetooth x86_64 6.0-8.fc22 @System 170 k</pre><pre> pulseaudio-module-x11 x86_64 6.0-8.fc22 @System 61 k</pre><pre><br></pre><pre>Transaction Summary</pre><pre>====================================================================================================================================</pre><pre>Remove 19 Packages</pre></blockquote><div><br></div><div>As you can see, systemd fares just fine and no attempt is made to remove it.</div><div><br></div><blockquote type="cite">
2. Can I patch a piece of systemd without forcing a reboot? Right now<br>
most things except the kernel can get restarted individually without<br>
bringing down the whole system. There's no indication that systemd can<br>
be patched piecemeal. At the moment it appears that if a flaw is found<br>
in any portion of systemd, the whole thing would have to be patched and<br>
then rebooted.<br></blockquote><div><br></div><div>The answer is, as always: "it depends". On a great deal.</div><div><br></div><div>Method 1: Memory hot patch. Sure, you can. It's about the only way to update PID 1 ***WHILE IT IS RUNNING***. This is the same regardless of the PID 1 implementation used.</div><div><br></div><div>Method 2: Package update and re-exec. Systemd supports this ('systemctl daemon-reexec). This allows you to upgrade systemd and restart PID 1 without a reboot.</div><div><br></div><div>Method 3: The Old Way. Update the thing and reboot.</div><div><br></div><div>Note also that systemd comprises more than just PID 1. As with any dæmon, you must restart the dæmon for the update to take effect. If you're doing a system update wherein you've updated a substantial number of dæmons, it is often faster to reboot than restart them all at runtime. However, systemd allows both options, giving you the choice in how you want to manage your update application procedures.</div><div><br></div><div>The upside is the time saved: If you start dæmon X, which depends on Y and Z, where Y and Z were only started for X, then they'll get restarted too. Automatically.</div><div><br></div><div>The additonal upside is that if your service is socket activated, NO ACTION IS NECESSARY AT ALL. The service update will apply after the next time the process recycles itself, which you can force to happen at any time with standard POSIX signals.</div><div><br></div><blockquote type="cite">
3. For some of the more unusual inclusions in systemd (e.g. DHCPd) is<br>
it possible to turn that feature off, remove its memory footprint, and<br>
replace it with another? I use DNSMasq as my DHCP daemon because of a<br>
lot of flexibility in the way it hands out leases. From the<br>
systemd-devel posts:<br>
<br>
systemd-networkd learnt minimal DHCPv4 server support in addition to the<br>
existing DHCPv4 client support. It also learnt DHCPv6 client and IPv6<br>
Router Solicitation client support. The DHCPv4 client gained support for<br>
static routes passed in from the server. Note that the [DHCPv4] section<br>
known in older systemd-networkd versions has been renamed to [DHCP] and<br>
is now also used by the DHCPv6 client. Existing<br>
.network files using settings of this section should be updated, though<br>
compatibility is maintained. Optionally, the client hostname may now be<br>
sent to the DHCP server.<br>
<br>
So it's a "minimal DHCPv4 server". If I want something more than<br>
minimal, can I turn it off completely and put in a replacement?<br></blockquote><div><br></div><div>Sure. Nothing forces you to use the components of systemd in a systemd based system. You can refuse to use networkd or journald if you wish. Systemd allows you to hard-mask any unit it knows about by using the SA-override directory /etc/systemd, and symlinking the unit to /dev/null. See also systemctl disable and systemctl enable. Want to use ISC DHCPd? Go for it. Want to take IPv6 configuration away from the kernel and move it to ISC DHCPd? Sure, can do that too. Want to use MySpecialNetworkD to handle everything for you, pulling rules from <a href="https://example.org/system_$UUID">https://example.org/system_$UUID</a>? Well, you can do that, too.</div><div><br></div><div>Your options are exactly as constrained as they've been in the past. Which is to say, they're not.</div><div><br></div><blockquote type="cite">
<br>Maybe some of the angst would calm down a bit if the developers and<br>
documenters would actually explain these things instead of just saying<br>
"look what new feature we added". That's mostly what I see on that<br>
-devel list, a lot of excitement about pulling in yet another feature<br>
but no real documentation about what to do when it doesn't fit a need.<br></blockquote><div><br></div><div>I've found no real lacking in the documentation for systemd; however, as with any system, you need to read all of the documentation at some point to make sense of it. That said, systemd provides a simple and straightforward interface, which itself is inspired in parts by the major bolt-on additions to the init system which Debian and Red Hat maintained in their own distributions for years. (Just why do you think that they were both willing to adopt systemd in the first place? Unified infrastructure and Don't Repeat Yourself are concepts which we all benefit from.) See Debian's public voting system for more information, but they've both adopted the use of systemd, and subsequently adopted a resolution stating that no specific resolution was required to address init system coupling between packages.</div><div><br></div><blockquote type="cite">
<br>
I can't afford to "just try it", I have to know many of these things<br>
ahead of time. But the very act of asking these questions sends a lynch<br>
mob after me with the "just use it and shut up" mantra. I did dig<br>
through a lot of documentation and ask some questions elsewhere prior to<br>
creating my opinions. I was trying to give it the benefit of the doubt<br>
but the documentation I can find is so poor or inapplicable to the use<br>
case (meaning supplied as a distro package rather than built from<br>
source) and the responses to questions terrible that I gave up and just<br>
couldn't support the change to systemd.</blockquote><div><br></div><div>Good thing is that you don't have to. It just works.</div><div><br></div><div>Also, please show me some of this "horrible documentation" that you're talking about. I've used only the documentation. I've never needed to ask the Giant Asshole or any of his minions for help or assistance in any aspect of using or managing systemd. The man pages are very well-written (and aren't giant rambling tomes as can be found in GNU documentation). There are a lot of man pages, sure, but that's because systemd takes the approach of breaking down the entire world into small, manageable problems. There are many different unit types, specifically because of the fact that system maintenance and management is a messy thing to do.</div><div><br></div><div>Systemd gives the system administrator a SINGLE interface for managing "the system". If you still want to do your piecemeal management, you sure can. It's up to you. Nothing is forced on you. You can mask the entire new world if you want, and only run your old systems if you'd like. Personally, I find it much easier to update my software for the new world: I get to drop several kilobytes of code from hardware drivers and daemons, and get a more robust system as well. How that's not win/win, I don't know.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></body></html>