Thanks for the answers > Well, there's no tracking of sessions anymore, i.e. polkit and all that stuff > won't work anymore reasonably, and everything else that involves anything > graphical and so on.
Nothing listed is in anyway used on our system as already laid out in the original mail. Your answer implies though there is no real security issue though (like sshd not working or being exploitable to gain access to other accounts) - is this correct? > If I were you I'd actually look what wakes up the system IRL instead of just > trying to blanket remove everything. > Can you clarify how dbus-daemon, systemd-journald, systemd-logind, > systemd-udevd are causing issue/impacting in the above setup some thing more > than "I dont think we need it hence we want to disable it". The approach "if you do not need it, do not run it" works for this case pretty well. Systemd demons take up cycles without doing anything useful for us. We do not do any logging, we do not change the hardware during runtime - so no matter how little time those unit consumes, it impacts scalability. As explained this is not acceptable in our environment. > If you need to perform benchmark on Red Hat and it's derivatives/clones then > disable this would scew the benchmark output on those would it not? Not if you have some "easy" steps to duplicate the environment. > If you need absolute bare minimum systemd [¹] then you need to > create/maintain your entire distribution for that I would not call it a distribution - but yes, building/configuring a new OS out of the basic components supplied by RH/Centos is similar to a new distro. I understand this usage model cannot be compared to laptops or web servers. But basically you are saying systemd is not usable for our High Performance Computing usage case and I might better off by replacing it with sysinitV. I was hoping for some simpler solution, but if it's not possible then that's life. Will certainly make an interesting topic at HPC conferences :P Regards Michael -----Original Message----- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Tuesday, June 07, 2016 11:23 PM To: Hebenstreit, Michael Cc: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] question on special configuration case On Tue, 07.06.16 15:13, Hebenstreit, Michael (michael.hebenstr...@intel.com) wrote: > Sorry for directing this question here, but I did not find any mailing > list that would be a better fit. > > Problem: I'm running an HPC benchmarking cluster. We are evaluating > RH7/CentOS7/OL7 and have a problem with system noise generated by the > systemd components (v 219-19.0.2, see below). > > Background: All cores of the CPU (up to 288) are utilized 99.99% by > the application. Because of the tight coupling node to node (of > programs running on 200+ nodes) every time an OS process wakes up this > automatically delays EVERY process on EVERY node. As those small > interruptions are not synchronized over the cluster, the overall > effect on the effective performance is "time of the single delay" > times "number of nodes in the job". Therefore we need to keep the OS > of our systems are stripped down to an absolute bare minimum. > > a) we have no use for any type of logging. The only log we have is > kernel dmesg > b) there is only a single user at any time on the system (logging in via ssh). > c) The only demons running are those necessary for NFS, ntp and sshd. > d) we do not run Gnome or similar desktop. > > Goal: For these reasons we want to shut down dbus-daemon, > systemd-journald, systemd-logind and after startup also systemd-udevd. > In our special case they do not serve any purpose. Unfortunately the > basic configuration options do not allow this. This is simply not supported on systemd. Systems without journald and udevd are explicitly not supported, and systems without dbus-daemon are only really supported for early boot schemes. You can of course ignore what we support and what not, but of course, then you really should know what you do, and you are basically on your own. Note that you can connect the journal to kmsg, if you like, and turn off local storage, via ForwardToKMsg= and Storage= in journald.conf. > Questions: > Can you provide any guidance? > Will PID 1 (systemd) continue to do its work (first tests were > already successful)? No, it will not. The only daemon of those listed you can realistically do without is logind, and if you do that, then you basically roll your own distro. > What are security implications when shutting down > systemd-logind? Well, there's no tracking of sessions anymore, i.e. polkit and all that stuff won't work anymore reasonably, and everything else that involves anything graphical and so on. If I were you I'd actually look what wakes up the system IRL instead of just trying to blanket remove everything. If you do that, then you are going to have to invest a lot of time dealing with the fallout yourself. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
