Re: What is agetty, and why can't it be stopped?
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.
Reply to: