Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #209668 > unrolled thread

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

Back to article view | Back to linux.debian.user

Contents

  What is agetty, and why can't it be stopped? Gene Heskett <gheskett@shentel.net> - 2019-06-06 04:10 +0200
    Re: What is agetty, and why can't it be stopped? Miles Fidelman <mfidelman@meetinghouse.net> - 2019-06-06 04:50 +0200
    Re: What is agetty, and why can't it be stopped? Felix Miata <mrmazda@earthlink.net> - 2019-06-06 04:50 +0200
      Re: What is agetty, and why can't it be stopped? David Wright <deblis@lionunicorn.co.uk> - 2019-06-06 05:20 +0200
        Re: What is agetty, and why can't it be stopped? Miles Fidelman <mfidelman@meetinghouse.net> - 2019-06-06 17:00 +0200
    Re: What is agetty, and why can't it be stopped? <tomas@tuxteam.de> - 2019-06-06 09:30 +0200
      Re: What is agetty, and why can't it be stopped? Gene Heskett <gheskett@shentel.net> - 2019-06-06 13:20 +0200
        Re: What is agetty, and why can't it be stopped? Erik Christiansen <dvalin@internode.on.net> - 2019-06-06 13:40 +0200
          Re: What is agetty, and why can't it be stopped? Gene Heskett <gheskett@shentel.net> - 2019-06-06 14:20 +0200
      Re: What is agetty, and why can't it be stopped? Greg Wooledge <wooledg@eeg.ccf.org> - 2019-06-06 14:30 +0200
        Re: What is agetty, and why can't it be stopped? <tomas@tuxteam.de> - 2019-06-06 14:40 +0200
          Re: What is agetty, and why can't it be stopped? Gene Heskett <gheskett@shentel.net> - 2019-06-06 21:10 +0200
      Re: What is agetty, and why can't it be stopped? Miles Fidelman <mfidelman@meetinghouse.net> - 2019-06-06 17:00 +0200
    Re: What is agetty, and why can't it be stopped? Michael Stone <mstone@debian.org> - 2019-06-07 18:00 +0200
      Re: What is agetty, and why can't it be stopped? Gene Heskett <gheskett@shentel.net> - 2019-06-08 03:40 +0200
        Re: What is agetty, and why can't it be stopped? Michael Stone <mstone@debian.org> - 2019-06-08 04:10 +0200
          Re: What is agetty, and why can't it be stopped? Gene Heskett <gheskett@shentel.net> - 2019-06-08 05:50 +0200
            Re: What is agetty, and why can't it be stopped? deloptes <deloptes@gmail.com> - 2019-06-08 07:20 +0200
              Re: What is agetty, and why can't it be stopped? Gene Heskett <gheskett@shentel.net> - 2019-06-08 10:50 +0200
                Re: What is agetty, and why can't it be stopped? deloptes <deloptes@gmail.com> - 2019-06-08 16:30 +0200
                  Re: What is agetty, and why can't it be stopped? Gene Heskett <gheskett@shentel.net> - 2019-06-08 17:30 +0200
                    Re: What is agetty, and why can't it be stopped? Erik Christiansen <dvalin@internode.on.net> - 2019-06-09 09:20 +0200
                      Re: What is agetty, and why can't it be stopped? Jonathan Dowland <jmtd@debian.org> - 2019-06-09 10:10 +0200
                        Re: What is agetty, and why can't it be stopped? <tomas@tuxteam.de> - 2019-06-09 10:30 +0200
                          Re: What is agetty, and why can't it be stopped? Curt <curty@free.fr> - 2019-06-09 12:00 +0200
                      Re: What is agetty, and why can't it be stopped? Gene Heskett <gheskett@shentel.net> - 2019-06-09 13:10 +0200
                        Re: What is agetty, and why can't it be stopped? Erik Christiansen <dvalin@internode.on.net> - 2019-06-09 17:00 +0200
                          Re: What is agetty, and why can't it be stopped? Brian <ad44@cityscape.co.uk> - 2019-06-09 20:20 +0200
                            Re: What is agetty, and why can't it be stopped? Erik Christiansen <dvalin@internode.on.net> - 2019-06-10 06:10 +0200
    Re: What is agetty, and why can't it be stopped? Curt <curty@free.fr> - 2019-06-10 10:50 +0200
      Re: What is agetty, and why can't it be stopped? Gene Heskett <gheskett@shentel.net> - 2019-06-10 13:20 +0200
        Re: What is agetty, and why can't it be stopped? Curt <curty@free.fr> - 2019-06-10 15:50 +0200
          Re: What is agetty, and why can't it be stopped? Michael Stone <mstone@debian.org> - 2019-06-10 16:20 +0200
          Re: What is agetty, and why can't it be stopped? Gene Heskett <gheskett@shentel.net> - 2019-06-10 18:00 +0200

Page 1 of 2  [1] 2  Next page →

#209668 — What is agetty, and why can't it be stopped?

Greetings all;

This machine has only one serial port, which I normally use a session of  
minicom to connect as a terminal quit a bit dumber than a vt102, to a 
TRS-80 Color Computer 3 in the basement. But my normal config for 
minicom is /dev/ttyS0, but it claims the device is taken.

Sure enough, an lsof|grep ttyS0 shows an agetty attached to it.  And a 
killall agetty as root only changes its pid until I've done the killall 
as rapidly as I can uparrow and repeat it 6 or 7 times.

grepping thru  /etc does not seem to find any hits, so I've no clue whats 
starting it.  So next I will do a search thru synaptic and remove it if 
it will let me, or somehow disable it forever.

And the search for agetty in synaptic is also empty.
But as root, a locate agetty hits paydirt.

root@coyote:~$ locate agetty
/sbin/agetty
/usr/share/doc/util-linux/modems-with-agetty.txt
/usr/share/man/man8/agetty.8.gz

And the man 8 agetty page seems to indicate its a serial connection, I've 
heard of as being available for troubleshooting even if its not fully 
booted. Great, except I'm not sure I could go to the coco's keyboard and 
run supercomm to see into linux, never tried it. In any event, the coco 
is expecting a cr, and will respond by launching a shell bound to that 
serial port on its end of the cable.

So what I'd like for it to do, is be totally silent during the rest of 
this machines boot, and once a user, me, is logged in, go away just as 
silently, freeing the only serial hardware port for my own use.

Next problem with minicom running as me is that it has no permissions to 
save as its .dfl, the options it needs to Just Work as opposed to 
messing around in its config screens finding a group of setting that 
will work with the shells available on the coco, which of course is not 
running its native rsdos, but a unix like system called nitros9 these 
days.  Its os9 plus a few shots of unix testosterone.
  
What do I do next to get rid of this nearly invisible agetty gizmo once 
this machine is booted?  It might be handy if this machine is truly 
hung, but I can count those instances on one hand with fingers left over 
in the 21 years I have been a linux only house.

Thanks all;

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>

[toc] | [next] | [standalone]

#209671

agetty is "alternatative getty" - it's the terminal driver that listens 
on each terminal port

it's launched by init (or systemd), most likely in respawn mode - you'll 
need to find the init file (or systemd equivalent) that launches it, and 
change the config

do a "man getty" or "man agetty" and you should find what you need

Miles Fidelman

On 6/5/19 10:04 PM, Gene Heskett wrote:
> Greetings all;
>
> This machine has only one serial port, which I normally use a session of
> minicom to connect as a terminal quit a bit dumber than a vt102, to a
> TRS-80 Color Computer 3 in the basement. But my normal config for
> minicom is /dev/ttyS0, but it claims the device is taken.
>
> Sure enough, an lsof|grep ttyS0 shows an agetty attached to it.  And a
> killall agetty as root only changes its pid until I've done the killall
> as rapidly as I can uparrow and repeat it 6 or 7 times.
>
> grepping thru  /etc does not seem to find any hits, so I've no clue whats
> starting it.  So next I will do a search thru synaptic and remove it if
> it will let me, or somehow disable it forever.
>
> And the search for agetty in synaptic is also empty.
> But as root, a locate agetty hits paydirt.
>
> root@coyote:~$ locate agetty
> /sbin/agetty
> /usr/share/doc/util-linux/modems-with-agetty.txt
> /usr/share/man/man8/agetty.8.gz
>
> And the man 8 agetty page seems to indicate its a serial connection, I've
> heard of as being available for troubleshooting even if its not fully
> booted. Great, except I'm not sure I could go to the coco's keyboard and
> run supercomm to see into linux, never tried it. In any event, the coco
> is expecting a cr, and will respond by launching a shell bound to that
> serial port on its end of the cable.
>
> So what I'd like for it to do, is be totally silent during the rest of
> this machines boot, and once a user, me, is logged in, go away just as
> silently, freeing the only serial hardware port for my own use.
>
> Next problem with minicom running as me is that it has no permissions to
> save as its .dfl, the options it needs to Just Work as opposed to
> messing around in its config screens finding a group of setting that
> will work with the shells available on the coco, which of course is not
> running its native rsdos, but a unix like system called nitros9 these
> days.  Its os9 plus a few shots of unix testosterone.
>    
> What do I do next to get rid of this nearly invisible agetty gizmo once
> this machine is booted?  It might be handy if this machine is truly
> hung, but I can count those instances on one hand with fingers left over
> in the 21 years I have been a linux only house.
>
> Thanks all;
>
> Cheers, Gene Heskett

-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
In our lab, theory and practice are combined:
nothing works and no one knows why.  ... unknown

[toc] | [prev] | [next] | [standalone]

#209672

Gene Heskett composed on 2019-06-05 22:04 (UTC-0400):

> root@coyote:~$ locate agetty
> /sbin/agetty
Maybe this will be a useful clue:

In Stretch, any gettys running on vtty[1-6] are actually agettys.
Files in /etc/systemd/system/getty.target.wants/ are symlinks to:
	/lib/systemd/system/getty@service
# ps -A | grep get
 1021 tty3     00:00:00 agetty
 1022 tty4     00:00:00 agetty
 1023 tty2     00:00:00 agetty
 1451 tty1     00:00:00 agetty
 3932 tty6     00:00:00 agetty
12733 tty5     00:00:00 agetty

Why all this would tie up the serial port I don't know.
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#209674

On Wed 05 Jun 2019 at 22:43:53 (-0400), Felix Miata wrote:
> Gene Heskett composed on 2019-06-05 22:04 (UTC-0400):
> 
> > root@coyote:~$ locate agetty
> > /sbin/agetty
> Maybe this will be a useful clue:
> 
> In Stretch, any gettys running on vtty[1-6] are actually agettys.
> Files in /etc/systemd/system/getty.target.wants/ are symlinks to:
> 	/lib/systemd/system/getty@service
> # ps -A | grep get
>  1021 tty3     00:00:00 agetty
>  1022 tty4     00:00:00 agetty
>  1023 tty2     00:00:00 agetty
>  1451 tty1     00:00:00 agetty
>  3932 tty6     00:00:00 agetty
> 12733 tty5     00:00:00 agetty
> 
> Why all this would tie up the serial port I don't know.

Perhaps it's Gene's braille terminal.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#209695

On 6/5/19 11:15 PM, David Wright wrote:

> On Wed 05 Jun 2019 at 22:43:53 (-0400), Felix Miata wrote:
>> Gene Heskett composed on 2019-06-05 22:04 (UTC-0400):
>>
>>> root@coyote:~$ locate agetty
>>> /sbin/agetty
>> Maybe this will be a useful clue:
>>
>> In Stretch, any gettys running on vtty[1-6] are actually agettys.
>> Files in /etc/systemd/system/getty.target.wants/ are symlinks to:
>> 	/lib/systemd/system/getty@service
>> # ps -A | grep get
>>   1021 tty3     00:00:00 agetty
>>   1022 tty4     00:00:00 agetty
>>   1023 tty2     00:00:00 agetty
>>   1451 tty1     00:00:00 agetty
>>   3932 tty6     00:00:00 agetty
>> 12733 tty5     00:00:00 agetty
>>
>> Why all this would tie up the serial port I don't know.

Depends on how the serial port is configured.  It's pretty standard for 
it to be set up as a console, by default, in which case an instance of 
getty would be running waiting for a user to login.

Miles Fidelman

[toc] | [prev] | [next] | [standalone]

#209677

[Multipart message — attachments visible in raw view] — view raw

On Wed, Jun 05, 2019 at 10:04:09PM -0400, Gene Heskett wrote:

[agetty]

People have given very useful answers, so I'll restrict myself
to some history.

Gene, you've been wasting your time with junk OSes, otherwise
you'd know who "getty" is. Agetty is just an alternative
implementation of that.

Back then [TM], when we were young and handsome [1], a Unix
box had several terminals connected to it. Typically users
would show up at one of these terminals, perhaps hit ENTER,
and be presented with some greeting -- something like "Login:",
perhaps.

Entering user name and password gave the user an interactive
session, courtesy of a shell.

The process responsible to start all of this was "getty",
which just waited on a terminal until something happens,
and then set off the whole authentication - session dance.

Getty stayed the parent of that whole session "process
tree", which at the end of the session folded nicely back.
On termination of getty's child, getty itself terminated.

To get the ball rolling again, getty's parent (typically
init) started a new getty (in our jargon, "respawn"). You
could configure that behaviour in a file called /etc/inittab.

So, what you're seeing is not "agetty" "changing its PID",
as you see (I don't think Unix allows that!), but a "new"
instance of agetty being started. And you can kill as fast
as you will -- I don't think you're going to out-kill init.

I don't know where /etc/inittab is under that newfangled
init system, but I'm sure others will chime in. On a
recent (stretch) Debian with SysV, this file still exists,
and you can see (this is just the relevant snippet):

  # Note that on most Debian systems tty7 is used by the X Window System,
  # so if you want to add more getty's go ahead but skip tty7 if you run X.
  #
  1:2345:respawn:/sbin/getty 38400 tty1
  2:23:respawn:/sbin/getty 38400 tty2
  3:23:respawn:/sbin/getty 38400 tty3
  4:23:respawn:/sbin/getty 38400 tty4
  5:23:respawn:/sbin/getty 38400 tty5
  6:23:respawn:/sbin/getty 38400 tty6
  
  # Example how to put a getty on a serial line (for a terminal)
  #
  #T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100
  #T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100

Cf. man inittab for details. See? Still gettys being started
here, for the Linux virtual consoles. And some examples on
how to do it for serial terminals.

Cheers

[1] My memory is foggy, so I won't commit myself to remember
   whether some dinosaurs roamed the world at that time.

-- t

[toc] | [prev] | [next] | [standalone]

#209684

On Thursday 06 June 2019 03:22:02 am tomas@tuxteam.de wrote:

> On Wed, Jun 05, 2019 at 10:04:09PM -0400, Gene Heskett wrote:
>
> [agetty]
>
> People have given very useful answers, so I'll restrict myself
> to some history.
>
> Gene, you've been wasting your time with junk OSes, otherwise
> you'd know who "getty" is. Agetty is just an alternative
> implementation of that.
>
> Back then [TM], when we were young and handsome [1], a Unix
> box had several terminals connected to it. Typically users
> would show up at one of these terminals, perhaps hit ENTER,
> and be presented with some greeting -- something like "Login:",
> perhaps.
>
> Entering user name and password gave the user an interactive
> session, courtesy of a shell.
>
> The process responsible to start all of this was "getty",
> which just waited on a terminal until something happens,
> and then set off the whole authentication - session dance.
>
> Getty stayed the parent of that whole session "process
> tree", which at the end of the session folded nicely back.
> On termination of getty's child, getty itself terminated.
>
> To get the ball rolling again, getty's parent (typically
> init) started a new getty (in our jargon, "respawn"). You
> could configure that behaviour in a file called /etc/inittab.
>
> So, what you're seeing is not "agetty" "changing its PID",
> as you see (I don't think Unix allows that!), but a "new"
> instance of agetty being started. And you can kill as fast
> as you will -- I don't think you're going to out-kill init.
>
> I don't know where /etc/inittab is under that newfangled
> init system, but I'm sure others will chime in. On a
> recent (stretch) Debian with SysV, this file still exists,
> and you can see (this is just the relevant snippet):
>
>   # Note that on most Debian systems tty7 is used by the X Window
> System, # so if you want to add more getty's go ahead but skip tty7 if
> you run X. #
>   1:2345:respawn:/sbin/getty 38400 tty1
>   2:23:respawn:/sbin/getty 38400 tty2
>   3:23:respawn:/sbin/getty 38400 tty3
>   4:23:respawn:/sbin/getty 38400 tty4
>   5:23:respawn:/sbin/getty 38400 tty5
>   6:23:respawn:/sbin/getty 38400 tty6
>
>   # Example how to put a getty on a serial line (for a terminal)
>   #
>   #T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100
>   #T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100
>
Yes, I recall those days. But until now ttyS0 and S1 if it existed, were 
free for my to use. Now it seems to want to grab everything in sight.

This is MY machine, and it should be able to do what I want it to do.  I 
finally did kill the one that was grabbing ttyS0. In fact it appears I 
killed them all, htop cannot find one running now, and neither can an 
lsof, Yet the machine seems to be running normally.

> Cf. man inittab for details. See? Still gettys being started
> here, for the Linux virtual consoles. And some examples on
> how to do it for serial terminals.
>
No man page for inittab seems to be installed.  That seems to be a head 
scratcher right there.

> Cheers
>
> [1] My memory is foggy, so I won't commit myself to remember
>    whether some dinosaurs roamed the world at that time.

Mines not the greatest after all these years either, but I don't think 
so, allthough we did have an honest democrat occasionally.  Definitely a 
conciderably more endangered specie today.

grepping thru /etc/systemd is also a puzzle, there seems to be only 1 
wanting ttyS1, which does not exist on this mobo. Nothing mentions 
ttyS0, so I still have not identified what starts it. So I'm going back 
to bed.

Thanks Tomas
> -- t


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>

[toc] | [prev] | [next] | [standalone]

#209685

On 06.06.19 07:14, Gene Heskett wrote:
> >   # Example how to put a getty on a serial line (for a terminal)
> >   #
> >   #T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100
> >   #T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100
> >
> Yes, I recall those days. But until now ttyS0 and S1 if it existed, were 
> free for my to use. Now it seems to want to grab everything in sight.

Er, Gene, does your /etc/inittab have either of those lines uncommented
to activate a getty on them? If so, just comment them again. If not, did
your upgrade land you in systemdix land, so the traditional way is gone.

> This is MY machine, and it should be able to do what I want it to do.  I 
> finally did kill the one that was grabbing ttyS0. In fact it appears I 
> killed them all, htop cannot find one running now, and neither can an 
> lsof, Yet the machine seems to be running normally.
> 
> > Cf. man inittab for details. See? Still gettys being started
> > here, for the Linux virtual consoles. And some examples on
> > how to do it for serial terminals.
> >
> No man page for inittab seems to be installed.  That seems to be a head 
> scratcher right there.

Nah, systemd replaces the traditional SysV init stuff, if you let it be
installed. Then you have to learn new ways.

Erik

-- 
manual, n.:
A unit of documentation. There are always three or more on a given item.
One is on the shelf; someone has the others.
The information you need is in the others.               - Ray Simard

[toc] | [prev] | [next] | [standalone]

#209687

On Thursday 06 June 2019 07:39:02 am Erik Christiansen wrote:

> On 06.06.19 07:14, Gene Heskett wrote:
> > >   # Example how to put a getty on a serial line (for a terminal)
> > >   #
> > >   #T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100
> > >   #T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100
> >
> > Yes, I recall those days. But until now ttyS0 and S1 if it existed,
> > were free for my to use. Now it seems to want to grab everything in
> > sight.
>
> Er, Gene, does your /etc/inittab have either of those lines
> uncommented to activate a getty on them? If so, just comment them
> again. If not, did your upgrade land you in systemdix land, so the
> traditional way is gone.

Yup, and so is /etc/inittab, it doesn't exist.

> > This is MY machine, and it should be able to do what I want it to
> > do.  I finally did kill the one that was grabbing ttyS0. In fact it
> > appears I killed them all, htop cannot find one running now, and
> > neither can an lsof, Yet the machine seems to be running normally.
> >
> > > Cf. man inittab for details. See? Still gettys being started
> > > here, for the Linux virtual consoles. And some examples on
> > > how to do it for serial terminals.
> >
> > No man page for inittab seems to be installed.  That seems to be a
> > head scratcher right there.
>
> Nah, systemd replaces the traditional SysV init stuff, if you let it
> be installed. Then you have to learn new ways.

So its apparent. But I watched the D-Day stuff live, so I'm going to 
catch up on the sleep I missed from 4 to 7 this morning.

Thanks  Erik


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>

[toc] | [prev] | [next] | [standalone]

#209689

On Thu, Jun 06, 2019 at 09:22:02AM +0200, tomas@tuxteam.de wrote:
> Getty stayed the parent of that whole session "process
> tree", which at the end of the session folded nicely back.
> On termination of getty's child, getty itself terminated.

I'm pretty sure getty has always used exec() to replace itself with
login(1) or a login(1) equivalent.  There's no reason for it to sit
around holding memory.

> I don't know where /etc/inittab is under that newfangled
> init system, but I'm sure others will chime in.

There isn't one under systemd.

This might be a starting point:

========================================================================
wooledg:~$ grep -ri serial /lib/systemd/system
/lib/systemd/system/getty@.service:Documentation=http://0pointer.de/blog/projects/serial-console.html
/lib/systemd/system/getty@.service:# that serial gettys are covered by serial-getty@.service, not this
/lib/systemd/system/getty.target:Documentation=http://0pointer.de/blog/projects/serial-console.html
/lib/systemd/system/serial-getty@.service:Description=Serial Getty on %I
/lib/systemd/system/serial-getty@.service:Documentation=http://0pointer.de/blog/projects/serial-console.html
/lib/systemd/system/getty-pre.target:Documentation=http://0pointer.de/blog/projects/serial-console.html
/lib/systemd/system/wacom-inputattach@.service:Description=inputattach for Wacom ISDv4-compatible serial devices
/lib/systemd/system/wacom-inputattach@.service:ExecStart=/usr/bin/isdv4-serial-inputattach /dev/%I

wooledg:~$ cat /lib/systemd/system/serial-getty@.service
#  SPDX-License-Identifier: LGPL-2.1+
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Serial Getty on %I
Documentation=man:agetty(8) man:systemd-getty-generator(8)
Documentation=http://0pointer.de/blog/projects/serial-console.html
BindsTo=dev-%i.device
After=dev-%i.device systemd-user-sessions.service plymouth-quit-wait.service getty-pre.target
After=rc-local.service

# If additional gettys are spawned during boot then we should make
# sure that this is synchronized before getty.target, even though
# getty.target didn't actually pull it in.
Before=getty.target
IgnoreOnIsolate=yes

# IgnoreOnIsolate causes issues with sulogin, if someone isolates
# rescue.target or starts rescue.service from multi-user.target or
# graphical.target.
Conflicts=rescue.service
Before=rescue.service

[Service]
# The '-o' option value tells agetty to replace 'login' arguments with an
# option to preserve environment (-p), followed by '--' for safety, and then
# the entered username.
ExecStart=-/sbin/agetty -o '-p -- \\u' --keep-baud 115200,38400,9600 %I $TERM
Type=idle
Restart=always
UtmpIdentifier=%I
TTYPath=/dev/%I
TTYReset=yes
TTYVHangup=yes
KillMode=process
IgnoreSIGPIPE=no
SendSIGHUP=yes

[Install]
WantedBy=getty.target
========================================================================

Now, I'm definitely no systemd guru.  I do know that the @ sign in the
service name is magical -- it acts like a wildcard of some kind, meaning
this is a service that can have a bunch of instances running.

It points to <http://0pointer.de/blog/projects/serial-console.html> which
looks like it's definitely worth reading.  You'll want to digest that
before doing anything else.

[toc] | [prev] | [next] | [standalone]

#209692

[Multipart message — attachments visible in raw view] — view raw

On Thu, Jun 06, 2019 at 08:26:12AM -0400, Greg Wooledge wrote:
> On Thu, Jun 06, 2019 at 09:22:02AM +0200, tomas@tuxteam.de wrote:
> > Getty stayed the parent of that whole session "process
> > tree", which at the end of the session folded nicely back.
> > On termination of getty's child, getty itself terminated.
> 
> I'm pretty sure getty has always used exec() to replace itself with
> login(1) or a login(1) equivalent.  There's no reason for it to sit
> around holding memory.

Makes sense, yes.

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#209701

On Thursday 06 June 2019 08:32:02 am tomas@tuxteam.de wrote:

> On Thu, Jun 06, 2019 at 08:26:12AM -0400, Greg Wooledge wrote:
> > On Thu, Jun 06, 2019 at 09:22:02AM +0200, tomas@tuxteam.de wrote:
> > > Getty stayed the parent of that whole session "process
> > > tree", which at the end of the session folded nicely back.
> > > On termination of getty's child, getty itself terminated.
> >
> > I'm pretty sure getty has always used exec() to replace itself with
> > login(1) or a login(1) equivalent.  There's no reason for it to sit
> > around holding memory.
>
> Makes sense, yes.
>
Thanks Tomas

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>

[toc] | [prev] | [next] | [standalone]

#209694

One minor nit...

On 6/6/19 3:22 AM, tomas@tuxteam.de wrote:
> Back then [TM], when we were young and handsome [1], a Unix
> box had several terminals connected to it. Typically users
> would show up at one of these terminals, perhaps hit ENTER,
> and be presented with some greeting -- something like "Login:",
> perhaps.
>
> Entering user name and password gave the user an interactive
> session, courtesy of a shell.

No longer so young, and never handsome, but still connecting to our 
servers via a terminal connection (SSH specifically).  Pretty common for 
servers - why bother with popping an X-window or other GUI for sys admin 
work.  Lots of getty instances running, sitting on network ports, just 
waiting for logins.

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
In our lab, theory and practice are combined:
nothing works and no one knows why.  ... unknown

[toc] | [prev] | [next] | [standalone]

#209724

On Wed, Jun 05, 2019 at 10:04:09PM -0400, Gene Heskett wrote:
>grepping thru  /etc does not seem to find any hits, so I've no clue whats
>starting it.

Did you happen to tell the kernel that ttyS0 was a console? (cat 
/proc/cmdline)

[toc] | [prev] | [next] | [standalone]

#209736

On Friday 07 June 2019 11:58:47 am Michael Stone wrote:

> On Wed, Jun 05, 2019 at 10:04:09PM -0400, Gene Heskett wrote:
> >grepping thru  /etc does not seem to find any hits, so I've no clue
> > whats starting it.
>
> Did you happen to tell the kernel that ttyS0 was a console? (cat
> /proc/cmdline)
No, TBT it never crossed my mind.

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>

[toc] | [prev] | [next] | [standalone]

#209740

On Fri, Jun 07, 2019 at 09:31:42PM -0400, Gene Heskett wrote:
>On Friday 07 June 2019 11:58:47 am Michael Stone wrote:
>
>> On Wed, Jun 05, 2019 at 10:04:09PM -0400, Gene Heskett wrote:
>> >grepping thru  /etc does not seem to find any hits, so I've no clue
>> > whats starting it.
>>
>> Did you happen to tell the kernel that ttyS0 was a console? (cat
>> /proc/cmdline)
>No, TBT it never crossed my mind.

So if you cat /proc/cmdline there's nothing about console= there?

[toc] | [prev] | [next] | [standalone]

#209742

On Friday 07 June 2019 10:00:48 pm Michael Stone wrote:

> On Fri, Jun 07, 2019 at 09:31:42PM -0400, Gene Heskett wrote:
> >On Friday 07 June 2019 11:58:47 am Michael Stone wrote:
> >> On Wed, Jun 05, 2019 at 10:04:09PM -0400, Gene Heskett wrote:
> >> >grepping thru  /etc does not seem to find any hits, so I've no
> >> > clue whats starting it.
> >>
> >> Did you happen to tell the kernel that ttyS0 was a console? (cat
> >> /proc/cmdline)
> >
> >No, TBT it never crossed my mind.
>
> So if you cat /proc/cmdline there's nothing about console= there?
BOOT_IMAGE=/vmlinuz-4.9.0-9-rt-amd64 
root=UUID=0e698024-1cf3-4dbc-812d-10552c01caab ro

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>

[toc] | [prev] | [next] | [standalone]

#209745

Gene Heskett wrote:

> BOOT_IMAGE=/vmlinuz-4.9.0-9-rt-amd64
> root=UUID=0e698024-1cf3-4dbc-812d-10552c01caab ro

Gene,
I can barely follow your problems with Stretch. I am just amazed how this
could be that hard. I was wondering if you possibly copied configurations
from your jessie, or is it related to the linuxcnc distro.

Last time I had massive issues was at the time of woody-sarge-edge.

regards

[toc] | [prev] | [next] | [standalone]

#209752

On Saturday 08 June 2019 01:18:21 am deloptes wrote:

> Gene Heskett wrote:
> > BOOT_IMAGE=/vmlinuz-4.9.0-9-rt-amd64
> > root=UUID=0e698024-1cf3-4dbc-812d-10552c01caab ro
>
> Gene,
> I can barely follow your problems with Stretch. I am just amazed how
> this could be that hard. I was wondering if you possibly copied
> configurations from your jessie, or is it related to the linuxcnc
> distro.
>
It could be. And the linuxcnc developers/spinners are being made aware of 
these problem's also.  That particular kernel you see above I will 
state, has the best latency figures I have ever seen on this particular 
machine, which with a normal kernel is so horrible I'd never consider 
actually running a machine with it.  Milliseconds of lag normally. But 
latency-test shows about 20 microseconds.  So one could even run 
software stepping, slowly but it would run.  Would be great if the 
stepping was offloaded to an accessory pci card. Normally we use intel 
cpu's because their latency-test figures can be as good as 4 
microseconds for a puny powered atom board. Intel has of course disco'ed 
that particular board, and I wish I had bought more of them when they 
were available.

But we normally need more than the 17 lines we can get from a parport to 
do a good job of controlling things. To that end a Mesa 5i25 card in a 
pci slot, can give us 34 control lines on 2 breakout boards, or sub a 
Mesa 7i76 for one of the breakouts which gives us up to 4 stepper 
drivers, 16 other outputs heavy enough to drive small relays, 1 3 line 
ABZ encoder input and 32 other inputs, more than enough to control a 
tool changer, work pallet loaders, whatever we can dream up. And for 
carving furniture parts, some of the jigs can get pretty complex with 
their own motors to be controlled.

> Last time I had massive issues was at the time of woody-sarge-edge.

Thats a while back. Wheezy has been great for us, but all good things 
must come to and end, if only because newer hardware demands it.

So we are having growing pains, some of which are directly related to our 
realtime kernel needs. And there have been times in the past where we've 
had to disable PAE on 32 bit installs because the PAE latency was bad, 
same for a full 64 bit install, the bigger stack frame = lots more 
latency. Linuxcnc itself is growing as we find and fix bugs and add 
abilities. Since it can control virtually any machine, it is more 
complex than the commercial offerings designed for a single machine.  
Not well known, the utube videos have been taken down, but Toys TRO 
engines are (or were, they've been secretive about it) carved from a 
solid block of alu by linuxcnc. No commercial software can do that 
without moving the partially carved engine block around to other 
machines to do a specific operation. Capable of running a 9 axis 
machine, its was at one time considered munitions subject to export 
controls.

> regards


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>

[toc] | [prev] | [next] | [standalone]

#209758

Gene Heskett wrote:

> It could be. And the linuxcnc developers/spinners are being made aware of
> these problem's also.  That particular kernel you see above I will
> state, has the best latency figures I have ever seen on this particular
> machine, which with a normal kernel is so horrible I'd never consider
> actually running a machine with it.  Milliseconds of lag normally. But
> latency-test shows about 20 microseconds.  So one could even run
> software stepping, slowly but it would run.  Would be great if the
> stepping was offloaded to an accessory pci card. Normally we use intel
> cpu's because their latency-test figures can be as good as 4
> microseconds for a puny powered atom board. Intel has of course disco'ed
> that particular board, and I wish I had bought more of them when they
> were available.

Did you try running this without systemd? I recall you mentioned somewhere
you removed it

regards

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web