display-managerinit-scriptx11
Is there a catch-all command to restart display managers (on any given common init system)?
I've got systemctl restart display-manager for systemd-based systems currently, but I don't know that that'll work on every systemd-based system, and it sure won't work on other init systems.
Are there other catch-all commands that are likely to work (given that a particular common init system is installed on a common distro)?
Probably everything you want to know is here on the "Debate Init System To Use" pages that the Debian project put together around making the decision of which initsystem to go with. Within that page is a separate link to each of the choices of initsystems.
For a primer on Systemd this page has pretty much everything one would need to know to get started with it, RHEL7: How to get started with Systemd.
Additional resources that I found helpful in getting a better understanding of the 2 primary choices I'd also read the Wikipedia pages on the respective technologies:
The Gentoo project also maintains a nice comparison of some of the key features across the various initsytems:
Q#1: How does systemd compare to other init systems?
This is a very tough question to address in the space of an SE answer so I'd rather defer to the various sources that I've referenced above. I'll say this though. In reading through much of the articles about systemd of the alternatives it's trying to address many aspects of what were deficient in previous tools used for starting up services on Linux systems. It has a very well thought out design and is attempting to provide it in a very modular way.
So IMO, I would say that it compares very favorably both in terms of the effort in its design, execution of that design, and the adoption of it by several larger Linux distros.
Q#2: What sets it apart -- what can it do that the other init systems cannot?
The are many things that sytemd can do that other systems cannot. Probably 3 of its strongest features are:
On the logging front, systemd has instituted a new logging system called the "Journal", the service is called systemd-journald.service. This is its own topic, you can read more about it here in this article titled: Introducing the Journal. Here's an example of a user, "harald", logging in.
_SERVICE=systemd-logind.service
MESSAGE=User harald logged in
MESSAGE_ID=422bc3d271414bc8bc9570f222f24a9
_EXE=/lib/systemd/systemd-logind
_COMM=systemd-logind
_CMDLINE=/lib/systemd/systemd-logind
_PID=4711
_UID=0
_GID=0
_SYSTEMD_CGROUP=/system/systemd-logind.service
_CGROUPS=cpu:/system/systemd-logind.service
PRIORITY=6
_BOOT_ID=422bc3d271414bc8bc95870f222f24a9
_MACHINE_ID=c686f3b205dd48e0b43ceb6eda479721
_HOSTNAME=waldi
LOGIN_USER=500
systemd uses a novel approach here of using cgroups to both contain and resource limit any services that require forking or limiting of access to resources.
excerpt
Systemd has a very clever solution to the problem of tracking daemons that fork, which coincidentally happens to handle resource limiting at the same time. Where Upstart uses ptrace to watch the forking, systemd runs each daemon in a control group (requires Linux 2.6.24 or newer) from which it can not escape with any amount of forking. This allows easy resource limiting , both for forking and non-forking daemons, since control groups were made for this sort of thing.
Source:Daemon Showdown: Upstart vs. Runit vs. Systemd vs. Circus vs. God
Q#3: Is there anything to lose in switching to it from another init system?
Probably the biggest caveat to switching to systemd over Upstart or sysV init is having to embrace a lot of new complexities. Systemd has a lot of moving parts and is extremely feature rich and with that added capabilities you'll likely be spending a fair amount of time gaining understandings around how it all works.
Q#4: How does administering systemd compare to the others?
As stated in my above answer to Q#3. I'l reiterate here again. Where sysV init was fairly trivial to learn how to manage and navigate in a few hours to days, Upstart will likely take you a week or more to get up to speed, while systemd will likely take you much longer, I'm anticipating taking several weeks to gain enough cursory knowledge about it, where I'll be able to both produce my own .service files, to stopping/starting services with the same ease that I now enjoy with sysV init.
IIRC neither gnome nor kde currently support dpi scaling on wayland, so the answer is currently none.
Update: Work has started on multi-DPI in Gnome 3, no indication yet on whether it would be usable in 3.22...
Best Answer
If you are using Debian (and derivatives like ubuntu),
/etc/X11/default-display-managershould contain the name of the currently active display manager.So something like that should work:
Otherwise, I don't think there is a standardized way of doing so