You almost certainly have no need of the systemd-logind service, and it is part of how systemd makes a right old pig's ear of a machine that is supposedly not using systemd. (You almost certainly have no need of elogind, either.)
Non-Linux-based operating system operators can stop here, because neither systemd-logind nor elogind apply to anything other than Linux-based operating systems; and there is no "almost" about it. Although Laurent Bercot's utmps, mentioned below, may be of some interest; albeit that the Unix login database and standard "utmpx" Unix API are hardwired into the bases of most non-Linux-based operating systems and are not replaceable components.
The Unix login database has been around since the 1970s, and has undergone at least two revisions on most operating systems, adding fields to and extending field widths in fixed-length-record tables. It has numerous problems to this day, not the least of which is that in order to allow user applications like GUI terminal emulators to register themselves as login sessions, the tables have to be writable by at minimum a special group that is applied set-GID to a helper program. In several modern operating systems, it is now considered defunct, and system programs do not maintain the table data as they once did.
Laurent Bercot's utmps was one project to solve this (as a stop-gap measure only, and particularly aimed at systems using musl libc). It provided replacements for the "utmpx" routines in the system C library that instead of accessing the login database directly talked to what was essentially a database server, which handled security restrictions on the actual table files and concurrency. It kept the idea that the actual database comprised machine-readable data files, and it kept the long-standing standard "utmpx" Unix API. It is self-contained with low coupling: relying upon no other servers internally; not bringing in nor setting up any other software mechanisms to run, in its software packaging; and severable and replaceable, at two different points, with something else to provide either the Unix API or just the database server part, should the need arise.
systemd-logind is essentially a reinvention of the same client-server idea, except that:
The Unix API is not retained; instead applications have to speak an entirely new Desktop Bus API (org.freedesktop.login1), indirectly via the Desktop Bus broker. This new API covers far more than just a login database.
The server requires other servers to be run.
It is not packaged as a self-contained decoupled thing, separately installable/deinstallable from other things. It is in the all-in-one systemd package that contains everything from Z shell extensions through systemd-logind to systemd's own kernel plus "Initial RAM disc" installer.
The machine-readable flat table files are replaced by human-readable one-file-per-record files under /run/systemd/users/, /run/systemd/seats/, and /run/systemd/sessions/.
These are all parsed at runtime from human-readable to machine form by systemd softwares, and come with notices in comments on their first lines that they must not be parsed.
Conventional wisdom on Debian Linux when not using systemd is to not only uninstall all of the systemd packages, "essential" and otherwise, but to "pin" their installation priority to an impossible negative value to ensure that they are never auto-installed by APT/dpkg. This may seem extreme, and to an extent it is. One can run nosh service and system management where systemd software is present but unused.
But unfortunately, the extreme pinners have a point; because in such a scenario systemd mechanisms auto-start by unexpected and undocumented routes, generate a lot of log noise, and yet do not meaningfully function or yield any benefit. What happens is this:
The system starts from a position where the system-wide Desktop Bus broker is running, because other services require it, but no systemd things are running.
The the external formats conversion mechanism has converted the system-wide Desktop Bus "service" files and dbus-daemon-launch-helper is in place to turn the highly flawed and wrongheaded Desktop Bus activation into instead proper service control actions.
In particular, the /usr/lib/dbus-1/system-services/org.freedesktop.login1.service file has been processed.
This file is installed by the all-in-one systemd package.
Because of it, attempts to "Desktop Bus activate" org.freedesktop.login1 will be diverted to starting a proper org.freedesktop.login1 service, which (as for other Desktop Bus "bus names") is an alias of the actual service that "provides" that "bus name" on the Desktop Bus.
In this case the actual service is the systemd-logind service.
Because the systemd packages are still installed, they have run pam-auth-upate to (per the systemd PAM profile) automatically install the pam_systemd.so module into the package-managed-do-not-touch part of the /etc/pam.d/common-session PAM configuration file.
This means that anything using PAM to create and destroy login sessions — e.g. programs such as login, su, sshd, and login-envuidgid — will run the pam_systemd.so hooks into the log-on/log-off process.
These hooks attempt to tell systemd-logind about login sessions appearing and disappearing.
pam_systemd.so, in the normal way for Desktop Bus things, contacts the Desktop Bus broker asking for the org.freedesktop.login1 server.
The Desktop Bus broker, via dbus-daemon-launch-helper and as a consequence of that /usr/lib/dbus-1/system-service/org.freedesktop.login1.service file, ends up running system-control start org.freedesktop.login1 and thus starting the systemd-logind service.
On a system actually using systemd, systemd-logind.service would already be running and already registered with its "bus name".
However, systemd has hooks into Desktop Bus such that if systemd is running much the same sort of diversion, from "Desktop Bus activation" to starting a real systemd service, would happen if it were not started.
This is not some novel mechanism at all, and at one point years ago the Upstart developers tried to add similar hooks for Upstart (only to have that blocked by the systemd developers).
systemd-logind having started and registered itself with its "bus name" on the system-wide Desktop Bus, pam_session.so can now talk to its Desktop-Bus-Flavoured replacement for the Unix "utmpx" API.
pam_session.so tells systemd-logind about log-in/log-out activity.
One of the several things that systemd-logind does, though, is speak to another Desktop Bus service, this one named org.freedesktop.systemd1.
When things tell it about login sessions and virtual terminals coming and going, it translates this into requests to systemd to start/stop a whole load of things, including session-number.scope units, user@UID.service units, user-runtime@UID.service units, and autovt@device.service units, amongst others.
The Desktop Bus broker, via dbus-daemon-launch-helper and as a consequence of a parallel /usr/lib/dbus-1/system-service/org.freedesktop.systemd1.service file, ends up running system-control start org.freedesktop.systemd1.
Fortunately, there is no service bundle with this "bus name" as its alias, but the intent is to "Desktop Bus activate" the main systemd program itself. By a circuitous, undocumented, and unexpected route, the mere fact that the systemd packages are installed has led, step by step, to attempting to start two of the major parts of systemd.
This is not the only place where "Desktop Bus activation", and the strong coupling between and weak cohesion within systemd modules, leads to this sort of thing.
There are other systemd hooks in addition to the PAM module, put in place by systemd package installation, that start up systemd stuff by roundabout routes, such as the systemd source in /etc/nsswitch.conf that attempts to contact org.freedesktop.resolve1 over the Desktop Bus and thus automatically starts the systemd-resolved service.
The nosh toolset tries to mitigate this strong coupling in several ways:
Its own packages are split into packages that install files, and packages that enable stuff to run.
As of version 1.41, the org.freedesktop.login1 "bus name" is specially deny-listed by the the external formats conversion mechanism so that it creates no org.freedesktop.login1 service.
This does result in some log noise from the Desktop Bus broker service, however, as it will report repeated failures to activate a service for this "bus name".
The org.freedesktop.systemd1 "bus name" is also specially deny-listed by the the external formats conversion mechanism.
One function of systemd-logind, not de-coupleable from its other functions in systemd itself, is replaced by the standalone ttylogin-starter utility running as a service.
This mechanism is self-contained, the program not doing other things at the same time, and entirely optional; one can just set up terminals in /etc/ttys, never use it at all, and the system functionality will not be degraded in other areas because this specific service is not running.
Another function of systemd-logind, not de-coupleable from its other functions in systemd itself, is replaced by the standalone login-monitor-active utility running as a service.
This is similarly self-contained and entirely optional.
It expects the conventional login database files in the conventional places, but if another login database system comes along it can be disabled and something else run in its place without losing or degrading other parts of the system.
GUIX's/Devuan's elogind addresses the strong coupling by being a systemd-logind shim that speaks the Desktop Bus API, but does very little, with most of the functionality stubbed out.
In particular, it does not actually do the things that ttylogin-starter and login-monitor-active do, at all.
So it does not provide very much of its own apart from a dummy service to answer pam_systemd.so and its ilk, and one still needs the nosh-toolkit-supplied services to get