[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: What is agetty, and why can't it be stopped?



On Friday 07 June 2019 03:25:53 pm Nicholas Geovanis wrote:

> You know Gene, I used to take the vacuum tubes to Walgreens to test
> them in the tube-tester right by the front door ;-)
> Gene OM, Google the Crystal Set Society....  ;-)

I had one of those when I was about 10yo.

Worked fairly well if the antenna was long enough.

> Peace out, 73 de Nick
>
> On Fri, Jun 7, 2019 at 10:48 AM Gene Heskett <gheskett@shentel.net> 
wrote:
> > 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>


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: