On Fri, Jun 07, 2019 at 01:23:45AM -0400, Gene Heskett wrote:
Not getting anyplace so far, but the reboot has given me only one agetty running on tty1, which looks like exactly what /etc/systemd/system/getty.target.wants/getty@tty1.service wants. It also says as a comment:
I don't think getty.target is relevant to you unless you are asking systemd to set your system up to that target: the default target is graphical.target, and the other one you are likely to use is multi-user.target. If you haven't knowingly changed your system's default target, it will be graphical.target. If you don't know what a systemd target is, then you likely haven't changed your system to use one other than the default. (You can learn more about systemd targets in the manpage systemd.target. They're vaguely analogous to sysvinit runlevels).
root@coyote:getty.target.wants$ locate serial-getty@.service /lib/systemd/system/serial-getty@.service
That's the "serial getty generator service". It's not a concrete service per se, more a template from which concrete services will derive. A concrete example would be serial-getty@ttyS0.service. On my system:
▶ systemctl status serial-getty@ttyS0.service ● serial-getty@ttyS0.service - Serial Getty on ttyS0 Loaded: loaded (/lib/systemd/system/serial-getty@.service; disabled; vendor preset: enabled) Active: inactive (dead) Docs: man:agetty(8) man:systemd-getty-generator(8) http://0pointer.de/blog/projects/serial-console.html
So my system has a service defined for a getty on ttyS0 but it is both disabled and not running. What I would have suggested to you, if you still had your machine in the state where the getty was running, would be to try "systemctl status serial-getty@ttyS0.service" and see what the result was. If it were running, "systemctl stop serial-getty@ttyS0.service" would stop it, and "systemctl disable serial-getty@ttyS0.service" would disable it from starting automatically again (if it were configured to do so).
But wouldn't a link to that have to exist in this /etc/systemd tree?
No. Systemd reads the contents of /lib/systemd and /etc/systemd; the latter overrides the former, if it specifies units with the same name. This is so that the package manager can freely update and overwrite units supplied in packages (to /lib/systemd), without interfering with any manual configuration that you have performed as a user (in /etc/systemd).
So what sort of a precondition that didn't happen on this reboot, would trigger this above file to grab and lockup /dev/ttyS0 like it did on the last reboot.
If you caused a service to be started that expressed a dependency upon serial-getty@ttyS0.service (or getty@ttyS0.service, that's also possible although unlikely and not useful) then that would be one explanation. I am not aware of any such service, and cannot find one on my system at least.
I am beginning to get a very dim glimmer of how systemd works. And its not impressing me.
You are free to switch back to sysvinit if you wish. To do so you need to install sysvinit-core (and remove systemd-sysv, which will likely be removed by the action of installing sysvinit-core). This will change your init system to sysvinit, although it would not remove all of systemd, and some parts of it are likely depended upon by other stuff on your system. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.