Re: What is agetty, and why can't it be stopped?
On Friday 07 June 2019 06:24:00 am Jonathan Dowland wrote:
> 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.
>
Neither can I and this "service" is not a familiar term since this is my
first expedition into systemd territory.
And its and intermittent only service. I am the author of several handy
utilities for that old Unix-like os on a box with a 16 bit address buss,
and there are still a good 1000 users of it on this ball of rock &
water. 2 services actually, one is called drivewire, and makes use if
the machines bit banger port at 115kbaud, and this terminal function
that minicom is doing against a hardware serial port on that machine. 2
independent services.
Drivewire was written in Java, and changes in Java from wheezy to stretch
have killed that, but a replacement is being written in python in hopes
it might be a more stable language. We as a group, had no clue that Java
would be changed to be so damned incompatible with itself. So I'm
playing canary in a coal mine testing the python version. For a machine
that was new in the early 80's, I am amazed at the new blood it has
attracted in the last 2 or 3 years. Mailing list sub count has nearly
doubled in the last 4 years. And with that new blood has come quite a
list of of newly designed hardware accessories for it. Sure, its being
built on kitchen tables in runs of 10 or 20, but its happening 35 years
later. That in itself is amazing. And redefines the word retro. I can
recall the days when vacuum tubes were state of the art, and knowing how
they work has given me a nice lengthy ladder up the side of that famous
hog. A rather broad knowledge of physics hasn't hurt a thing either,
including Einsteins work.
> >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.
I can likely go with the flow as long as its documented in readily
accessable form, something that L.P. is good at, he writes nice "papers"
on his stuff but hides that info from the unwashed by not putting out
decent man-pages. I disagree loudly about that but the exclusion of
examples from manpages seems like an insidious attack on the users
intelligence. I give you the present state of the docs for ip as an
example of how NOT to do a man page. 300 lines of "options" without a
word on which is required to get or apply what data or what if any
interactions there may be. I have yet to get a path condition report out
of it like ifconfig gives by default. That is not progress unless you
are using GE's definition from the late '50's.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Reply to: