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

[Gene Heskett]

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>

[Miles Fidelman]

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

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

[Felix Miata]

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/

[David Wright]

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.

[to...@tuxteam.de]

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

[Gene Heskett]

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

[Erik Christiansen]

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

[Gene Heskett]

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

[Greg Wooledge]

On Thu, Jun 06, 2019 at 09:22:02AM +0200, to...@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.

[to...@tuxteam.de]

On Thu, Jun 06, 2019 at 08:26:12AM -0400, Greg Wooledge wrote:
> On Thu, Jun 06, 2019 at 09:22:02AM +0200, to...@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

[bw]

In-Reply-To: <201906052204....@shentel.net>
<snip>

>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.

...

I think the first place I'd look is:

man logind.conf

there may be something there to help you figure it out. Then look into
override if necessary with something like:

systemctl edit getty@.service

[Miles Fidelman]

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

[Miles Fidelman]

One minor nit...

On 6/6/19 3:22 AM, to...@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

[Gene Heskett]

Thanks Tomas

[Gene Heskett]

Might be, but the dead keyboard hit it 30 minutes back so I rebooted and
now its normal. I need a near beer.

[bw]

In-Reply-To: <201906061506....@shentel.net>

>On Thursday 06 June 2019 08:37:36 am bw wrote:
>>

>> In-Reply-To: <[????] 201906052204....@shentel.net>

You have a definite style Gene, and a tenaciousness that I really admire.
I'm assuming after all this time you are doing some work and have a
functioning system going, congratulations.

For future reference, you can prevent any systemd service from starting by
putting a link to /dev/null in /etc/systemd/system AFAIK that is exactly
what 'systemctl mask' does, but the benefit from using systemctl is it
also checks your spelling.

I don't think all the 6 getty@ services are started at boot like with
inittab, the particualt getty appears after the VT is activated. You can
mask one or override it as you want with systemctl edit getty@ttyWHATEVER
and this is pretty cool. You could setup things to do whatever when any
particular VT is activated.

good luck
bw

[Gene Heskett]

On Thursday 06 June 2019 05:55:36 pm bw wrote:

> In-Reply-To: <201906061506....@shentel.net>
>
> >On Thursday 06 June 2019 08:37:36 am bw wrote:
> >> In-Reply-To: <[????] 201906052204....@shentel.net>
> >> <snip>
> >>
> >> >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.
> >>
> >> ...
> >>
> >> I think the first place I'd look is:
> >>
> >> man logind.conf
> >>

Nothing of use there.

> >> there may be something there to help you figure it out. Then look
> >> into override if necessary with something like:
> >>
> >> systemctl edit getty@.service
> >
> >Might be, but the dead keyboard hit it 30 minutes back so I rebooted
> > and now its normal. I need a near beer.
> >
> >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>
>
> You have a definite style Gene, and a tenaciousness that I really
> admire. I'm assuming after all this time you are doing some work and
> have a functioning system going, congratulations.
>

Like Sam Clemens, I have never let my education get in the way of my
learning. But my education is 8th grade, I went to work in the late
40's fixing radio and tv's for a living, before that I wired a house my
stepfather built right after the end of WW-II. I was 12 at the time. I
was a nerd before the word was invented. That scared the girls off so I
was late finding one that wanted to sleep on the bottom. Good woman but
I lost her to a stroke 10 years later. So life's had its ups and downs.

I finished up my working time at 67, the last 18 years at the local CBS
affiliate, as the Chief and often only engineer, one who had a
reputation for fixing things. Along the line I picked up an fcc 1st
phone, and I'm also a C.E.T. Sat for the mensa, but failed, this was
about 6 months after I had a pulmonary embolism which hurt my brain some
I think. Survival rates from those are well under 10%. He's had several
opportunities, but I don't think he wants to deal with me just yet. :)
That got me 4F'd during Korea, they had no use for anyone who scored a 98
on the AFQT. They were looking for machine gun targets I guess. The
next best score out of 130 some other boys was 36.

> For future reference, you can prevent any systemd service from
> starting by putting a link to /dev/null in /etc/systemd/system AFAIK
> that is exactly what 'systemctl mask' does, but the benefit from using
> systemctl is it also checks your spelling.
>
> I don't think all the 6 getty@ services are started at boot like with
> inittab, the particualt getty appears after the VT is activated. You
> can mask one or override it as you want with systemctl edit
> getty@ttyWHATEVER and this is pretty cool. You could setup things to
> do whatever when any particular VT is activated.
>
> good luck
> bw

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/ge...@tty1.service
wants. It also says as a comment:

# On systems without virtual consoles, don't start any getty. Note

# that serial gettys are covered by serial-getty@.service, not this

# unit.

root@coyote:getty.target.wants$ locate serial-getty@.service
/lib/systemd/system/serial-getty@.service

But wouldn't a link to that have to exist in this /etc/systemd tree?

But no serial-getty@.service exists in this tree, but it does exist as
/lib/systemd/system/serial-getty@.service

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.

I am beginning to get a very dim glimmer of how systemd works. And its
not impressing me.

Thanks bw, you gave me some usefull clues. Take care.

[Jonathan Dowland]

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/ge...@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...@ttyS0.service. On my system:

> ▶ systemctl status serial...@ttyS0.service
> ● serial...@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...@ttyS0.service" and see what the result
was. If it were running, "systemctl stop serial...@ttyS0.service" would
stop it, and "systemctl disable serial...@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...@ttyS0.service (or ge...@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.

[Gene Heskett]

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.

[Michael Stone]

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)

[Nicholas Geovanis]

On Fri, Jun 7, 2019 at 5:24 AM Jonathan Dowland <jm...@debian.org> wrote:

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 just learned earlier today of systemd-nspawn as a possible containerization solution (my mind boggles....).

Do you know if removing systemd-sysv would undercut nspawn? 

Have you tried nspawn for that containerization? Any strong views?

 

⢀⣴⠾⠻⢶⣦⠀

[Nicholas Geovanis]

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....  ;-)

Peace out, 73 de Nick

[Nicholas Geovanis]

https://www.midnightscience.net/

[Jonathan Dowland]

On Fri, Jun 07, 2019 at 11:48:17AM -0400, Gene Heskett wrote:
>Neither can I and this "service" is not a familiar term since this is my
>first expedition into systemd territory.

Try the systemd.service manual page to find out more.

>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.

This is quite an aside, but I was interested in this problem. Wheezy was
released in 2013, and Stretch in 2017, 4 years later. I'm finding it hard to
answer what version of Java was in Wheezy, due to its age, but I think it's
OpenJDK 7. Stretch has OpenJDK 8, one major version further on. There are no
doubt compatibility problems between 7 and 8, but relatively few (and certainly
a lot fewer than 8 → 11).

Java's compatibility story is — relative to most comparable languages — very
good. I regularly run a Java program originally written 20 years ago. If you're
going with Python make sure you start with Python 3, not 2.

>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'm surprised you think that, because I find the systemd man-pages to
be excellent. Have you read them or is this hearsay?

> I disagree loudly about that but the exclusion of
>examples from manpages seems like an insidious attack on the users
>intelligence.

…I'd guess hearsay because they have plenty of examples. A quick check shows
EXAMPLES sections in at least systemd.unit(5) and systemd.target(5).

>I give you the present state of the docs for ip as an
>example of how NOT to do a man page.

Much like the tool, I find it terrible. And not comparable to systemd's
man-pages at all. I quite look forward to whatever replaces "ip" (sooner
rather than later)

[Greg Wooledge]

On Fri, Jun 07, 2019 at 08:28:57PM +0100, Jonathan Dowland wrote:
> I'm finding it hard to
> answer what version of Java was in Wheezy, due to its age, but I think it's
> OpenJDK 7.

apt-cache search on a wheezy box shows both 6 and 7.

[Jonathan Dowland]

On Fri, Jun 07, 2019 at 02:21:52PM -0500, Nicholas Geovanis wrote:
>I just learned earlier today of systemd-nspawn as a possible
>containerization solution (my mind boggles....).

Yes. Systemd's main job is to spawn sub-processes. A container is
a process run under various constraints. From what I understand nspawn
adds some additional features, but many of the isolation features are
already present in systemd, without nspawn.

>Do you know if removing systemd-sysv would undercut nspawn?

I suspect it would not work at all if you were not running systemd as
the init system.

>Have you tried nspawn for that containerization? Any strong views?

I haven't tried it at all myself yet. I think it looks like a useful tool and
less invasive than e.g. Docker. You can get many of the isolation features of
containers with systemd's features already, without nspawn. See:

http://0pointer.de/blog/projects/security.html

--

⢀⣴⠾⠻⢶⣦⠀

[rhkr...@gmail.com]

On Friday, June 07, 2019 03:28:57 PM Jonathan Dowland wrote:
> This is quite an aside, but I was interested in this problem. Wheezy was
> released in 2013, and Stretch in 2017, 4 years later. I'm finding it hard
> to answer what version of Java was in Wheezy, due to its age, but I think
> it's OpenJDK 7. Stretch has OpenJDK 8, one major version further on.
> There are no doubt compatibility problems between 7 and 8, but relatively
> few (and certainly a lot fewer than 8 → 11).

From my Wheezy system (if you can interpret the response):

rhk@s19:~/.kde$ java -showversion
java version "1.6.0_38"
OpenJDK Runtime Environment (IcedTea6 1.13.10) (6b38-1.13.10-1~deb7u1)
OpenJDK 64-Bit Server VM (build 23.25-b01, mixed mode)
...


Ok, I guess that would be OpenJDK 6

[Gene Heskett]

No, TBT it never crossed my mind.

[Gene Heskett]

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.

[Gene Heskett]

On Friday 07 June 2019 03:21:52 pm Nicholas Geovanis wrote:

> On Fri, Jun 7, 2019 at 5:24 AM Jonathan Dowland <jm...@debian.org>
wrote:
> > 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 just learned earlier today of systemd-nspawn as a possible
> containerization solution (my mind boggles....).
> Do you know if removing systemd-sysv would undercut nspawn?
> Have you tried nspawn for that containerization? Any strong views?
>

No, again that has never been "on the table", never heard of it until you
mentioned it.

> > ⢀⣴⠾⠻⢶⣦⠀

> > ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
> > ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
> > ⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.

[Gene Heskett]

But first you need to know the name of the man page. You can't read it if
you don't know its true name...

> > I disagree loudly about that but the exclusion of
> >examples from manpages seems like an insidious attack on the users
> >intelligence.
>
> …I'd guess hearsay because they have plenty of examples. A quick check
> shows EXAMPLES sections in at least systemd.unit(5) and
> systemd.target(5).

That's a sample of two, how many manpages has systemd spawned by now?

> >I give you the present state of the docs for ip as an
> >example of how NOT to do a man page.
>
> Much like the tool, I find it terrible. And not comparable to
> systemd's man-pages at all. I quite look forward to whatever replaces
> "ip" (sooner rather than later)

it can't happen fast enough for me, as theres a possibility I might not
last long enough to see it.

[Michael Stone]

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?

[Gene Heskett]

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

[deloptes]

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

[Gene Heskett]

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

[to...@tuxteam.de]

On Fri, Jun 07, 2019 at 09:44:23PM -0400, Gene Heskett wrote:

[...]

> But first you need to know the name of the man page. You can't read it if
> you don't know its true name...

Not a user of systemd here, but... have you ever tried "man -k systemd"?

Cheers
-- t

[Étienne Mollier]

Good Day (or night, depending on your TZ),

I was writing a not about `apropos`, but you fired faster than
myself. ;-)

I count 182 systemd related manual pages on my Sid machine.
Fortunately, among the lot, there is :

systemd.index (7) - List all manpages from the systemd project

Sadly, it is not referenced in the systemd(1) SEE ALSO section,
which I would tend to consider the intuitive starting point of
any person interested in knowing more about how to handled the
arcane of this init process. systemd.index(7) alone is almost
1500 lines long in the meantime, but it references some manual
pages that are not listed by `apropos`.

Kind Regards,
--
Étienne Mollier <etienne...@mailoo.org>

[Jonathan Dowland]

On Sat, Jun 08, 2019 at 11:04:54AM +0200, Étienne Mollier wrote:
>I count 182 systemd related manual pages on my Sid machine.
>Fortunately, among the lot, there is :
>
> systemd.index (7) - List all manpages from the systemd project
>
>Sadly, it is not referenced in the systemd(1) SEE ALSO section,
>which I would tend to consider the intuitive starting point of
>any person interested in knowing more about how to handled the
>arcane of this init process.

I agree with both: it should probably be added to the main entry
point's SEE ALSO section. That would likely be a very simple patch,
which I might attempt myself if I have some time.

[deloptes]

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

[Gene Heskett]

No. And I doubt there would even be a running system left. I don't think
I wrote that it had been removed...

I just didn't know that it could be made so pervasive in one swell foop.

[Gene Heskett]

No, didn't know it existed Tomas, but howinhell is all that supposed to
help? Must be 3 or 4 screens full. What we'd need to do is to feed all
that to grep to see if the problem child device is mentioned.

I think we could, but the resultant cli would be too long. Maybe if we
could nuke the comments and only use the filename? But even then it
would be over a kilobyte. Even that fails:
gene@coyote:/CoCo/pyDriveWire/config$ grep usbS0 `man -k systemd`
grep: deb-systemd-helper: No such file or directory
(no path to it from the instant `pwd`)
grep: (1p): No such file or directory

And 2 minutes later its still stuck there. But does quit with a ctl-c.
Perhaps the list could be a source for locate? But that would blow up on
the comments too.

Somewhat past ridiculous, into sublime, but you get my point. I hope.

Thank for educating me about the -k. However, the -K option seems as if
it may be what is needed. Lets see. No, it doesn't find usbS0. No help
there IOW.

But it does find ttyS. In at least 10% of the pages. Thats less than
usefull.

Nice try, it did look promising. It also would take several hours to grep
the whole man tree.

> Cheers
> -- t

You too.

[Brian]

On Sat 08 Jun 2019 at 11:21:50 -0400, Gene Heskett wrote:

> On Saturday 08 June 2019 04:55:45 am to...@tuxteam.de wrote:
>
> > On Fri, Jun 07, 2019 at 09:44:23PM -0400, Gene Heskett wrote:
> >
> > [...]
> >
> > > But first you need to know the name of the man page. You can't read
> > > it if you don't know its true name...
> >
> > Not a user of systemd here, but... have you ever tried "man -k
> > systemd"?
> >
> No, didn't know it existed Tomas, but howinhell is all that supposed to
> help? Must be 3 or 4 screens full. What we'd need to do is to feed all
> that to grep to see if the problem child device is mentioned.

No you don't. That is only a way a way of saying you don't have a
glimmer of what you are searching for and cannot be bothered to sort it
out. You do, however, have a plethora of bogus reasons to avoid looking
sensibly at where the suggested help given leads you.

--
What a way to run a radio station.
With apologies to Anonymous.

[Erik Christiansen]

On 08.06.19 11:28, Gene Heskett wrote:
> On Saturday 08 June 2019 10:20:09 am deloptes wrote:
> > Did you try running this without systemd? I recall you mentioned
> > somewhere you removed it
> >
> > regards
>
> No. And I doubt there would even be a running system left. I don't think
> I wrote that it had been removed...
>
> I just didn't know that it could be made so pervasive in one swell foop.

Err, Gene, this foop has swelled to 1.2 million lines of code while your
back was turned. Pervasiveness is its essence.

https://linux.slashdot.org/story/19/05/25/0538206/systemd-now-has-more-than-12-million-lines-of-code

Erik

[Jonathan Dowland]

On Sun, Jun 09, 2019 at 05:18:20PM +1000, Erik Christiansen wrote:
>Err, Gene, this foop has swelled to 1.2 million lines of code while your
>back was turned. Pervasiveness is its essence.
>
>https://linux.slashdot.org/story/19/05/25/0538206/systemd-now-has-more-than-12-million-lines-of-code

Is that a lot, for an init system? Or for an init system + the other systems
that are in the systemd source tree (syslog equivalent, udev, etc.)? If so, what
would be an "appropriate" quantity of source code?

[to...@tuxteam.de]

On Sun, Jun 09, 2019 at 09:04:01AM +0100, Jonathan Dowland wrote:
> On Sun, Jun 09, 2019 at 05:18:20PM +1000, Erik Christiansen wrote:
> >Err, Gene, this foop has swelled to 1.2 million lines of code while your
> >back was turned. Pervasiveness is its essence.
> >
> >https://linux.slashdot.org/story/19/05/25/0538206/systemd-now-has-more-than-12-million-lines-of-code
>
> Is that a lot, for an init system? Or for an init system + the other systems
> that are in the systemd source tree (syslog equivalent, udev, etc.)? If so, what
> would be an "appropriate" quantity of source code?

What's much? What's little?

This was just a typical useless anti-systemd slur: 12 million lines of
code! Wow! (and it carries along a negative judgement without really
saying it, so plausibly deniable).

Way to stir up mud in the discussion without really contributing anything
valuable. For whatever reasons I don't understand.

I tend to ignore such things.

And if that sounded like a systemd proponent: I still run stretch
*without* systemd. I don't like its approach. But I like less the
discussion style which has developed around it. We're running in
circles, it seems.

Cheers
-- t

[Curt]

On 2019-06-09, <to...@tuxteam.de> <to...@tuxteam.de> wrote:
>
> What's much? What's little?
>
> This was just a typical useless anti-systemd slur: 12 million lines of

1.2 millions lines, actually, because the url dropped the decimal point,
thus multiplying by a factor of ten the other point, which I agree is
meaningless in and of and by itself.

--
“Decisions are never really made – at best they manage to emerge, from a chaos
of peeves, whims, hallucinations and all around assholery.” – Thomas Pynchon

[Gene Heskett]

And what do we call that Erik, thats much bigger than a normal foop, a
megafoop maybe? Good grief, Charley Brown. And we're stuck with it. :(

[Erik Christiansen]

On 09.06.19 06:59, Gene Heskett wrote:
> And what do we call that Erik, thats much bigger than a normal foop, a
> megafoop maybe? Good grief, Charley Brown. And we're stuck with it. :(

Well now, there are folks who have observed that not all progress is
forward, and not all code bloat and pervasiveness is a benison,
resulting in at least two ways to remain essentially debian without
remaining stuck in the foop, mega or otherwise.

One simple method is from the "Insidious systemd" thread on this list.
Quoting from <20190527144308.0398ce4b@debian9>:

On 27.05.19 14:43, Patrick Bartek wrote:
> I used the "approved" conversion documented on Debian's web site
> somewhere: apt (or apt-get) install sysvinit-core.
...
> Totally automatic. All of systemd's libraries remained along with udev
> and a couple others I don't recall. It freed up about 6 or 7 MB of
> RAM over a systemd boot.

One apt-get install is about as easy as it could be.

Some residual unused libraries mouldering in the background do no harm,
but if they offend, then there is devuan. While my laptop and main
desktop are pre-systemd debian, I've run devuan on another host for some
time. It is only sans-systemd debian, remaining true in other regards.
Downloading an image, putting it on a usb stick, and doing yet another
install is a bit more work, and another list to subscribe to. There are
a number of debian users who appear satisfied with the sysvinit-core
package. To my mind it neatly solves the problem of an old bloke, happy
with traditional sysvinit, having to load wetware RAM with a completely
new way to get the same bucket of water from the well as we've been
doing for decades. (Speaking of self, here.)

Erik

--
"If you want to eat hippopotamus, you've got to pay the freight."
- attributed to an IBM guy, about why IBM software uses so much memory.

[Brian]

On Mon 10 Jun 2019 at 00:52:21 +1000, Erik Christiansen wrote:

>
> On 09.06.19 06:59, Gene Heskett wrote:
> > And what do we call that Erik, thats much bigger than a normal foop, a
> > megafoop maybe? Good grief, Charley Brown. And we're stuck with it. :(
>
> Well now, there are folks who have observed that not all progress is

> forward, .....

Indeed there are; their promotion of "backward progress" mangles the
English language and brings into doubt any subsequent argument being
promoted. Are these the same people who observe "forward regression"
in some processes?

Incidentally, the OP has no intention of changing the init system he
is using. He has enough problems on his plate already.

--
Brian.

[Erik Christiansen]

On 09.06.19 19:11, Brian wrote:
> On Mon 10 Jun 2019 at 00:52:21 +1000, Erik Christiansen wrote:
>
> >
> > On 09.06.19 06:59, Gene Heskett wrote:
> > > And what do we call that Erik, thats much bigger than a normal foop, a
> > > megafoop maybe? Good grief, Charley Brown. And we're stuck with it. :(
> >
> > Well now, there are folks who have observed that not all progress is
> > forward, .....
>
> Indeed there are; their promotion of "backward progress" mangles the
> English language and brings into doubt any subsequent argument being
> promoted. Are these the same people who observe "forward regression"
> in some processes?

No, that's just your lack of understanding being expressed by you. Many
of the nuances of the meaning of "progress" may be found in:

1. To make progress; to move forward in space; to continue
onward in course; to proceed; to advance; to go on; as,
railroads are progressing. "As his recovery progressed."
--Thackeray.

Please think on the following example. A party might progress (continue
onward in course) deeper into a swamp, the mire might progress (advance)
up the sides of their boots, and their progress (procession) may grow
progressively slower and more laboured. Does this progress (advance)
their goals?

Once you apply your mind to it, I'm sure that you can understand these
nuances of the English language. (If English is not your first language,
then your uninformative overly opinionated interruption is excused. ;)

> Incidentally, the OP has no intention of changing the init system he
> is using. He has enough problems on his plate already.

How fortunate Gene is to have you to tell him what he wants. Perhaps
you'll also tell him to be grateful for your decisionmaking on his
behalf?

Incidentally, I thank you for leaving the task of providing informative
contributions, outlining real-world options, to the helpfully inclined.
It'll save confusion.

Erik

[Curt]

On 2019-06-06, Gene Heskett <ghes...@shentel.net> wrote:
>
> 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.

Maybe

sudo systemctl stop serial...@ttyS0.service

if you haven't already tried it.


> Thanks all;
>
> Cheers, Gene Heskett

[Gene Heskett]

On Monday 10 June 2019 04:46:33 am Curt wrote:

> On 2019-06-06, Gene Heskett <ghes...@shentel.net> wrote:
> > 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.
>
> Maybe
>
> sudo systemctl stop serial...@ttyS0.service
>
> if you haven't already tried it.

No, after a reboot, I don't need to.

minicom is working, sorta. Theres enough diffs in the protocol to
call "working" by a rather fuzzy definition. But at least /dev/ttyS0 is
now available for MY use. That was the squawk. I still have not found
where the previous boot, to the same kernel/etc might have decided to
grab /dev/ttyS0 for its own use. The previous boot did send 7 or 8 bytes
of data that was just random line noise to the legacy machine on the
receiving end that cable. Other than that, I'm still clueless.

If I were to file a bug, it would be against java's current (stretch)
jre. It has no backward compatibility with the wheezy version and has
broken another utility we use so badly that the majority of it has now
been re-written in pypy. So we at least have the function, if not
the "purty" we had with the wheezy version of the jre. The purty will be
improved I am sure. The pypy effort is quite young yet.

>
> > Thanks all;
> >
> > Cheers, Gene Heskett

[Curt]

On 2019-06-10, Gene Heskett <ghes...@shentel.net> wrote:
>>
>> Maybe
>>
>> sudo systemctl stop serial...@ttyS0.service
>>
>> if you haven't already tried it.
>
> No, after a reboot, I don't need to.
>
> minicom is working, sorta. Theres enough diffs in the protocol to
> call "working" by a rather fuzzy definition. But at least /dev/ttyS0 is
> now available for MY use. That was the squawk. I still have not found
> where the previous boot, to the same kernel/etc might have decided to
> grab /dev/ttyS0 for its own use. The previous boot did send 7 or 8 bytes
> of data that was just random line noise to the legacy machine on the
> receiving end that cable. Other than that, I'm still clueless.

Well, Michael Stone's guess was a good one (though, apparently, wrong).

Of course, you don't show any logs so it's anybody's guess.

Here's another: modemmanager probing ttyS0 trying to identify a modem.

Probably not, though. Anyway, it's working, which is enough for some of
us in this crazy old world.

> If I were to file a bug, it would be against java's current (stretch)
> jre. It has no backward compatibility with the wheezy version and has
> broken another utility we use so badly that the majority of it has now
> been re-written in pypy. So we at least have the function, if not
> the "purty" we had with the wheezy version of the jre. The purty will be
> improved I am sure. The pypy effort is quite young yet.
>
>>
>> > Thanks all;
>> >
>> > Cheers, Gene Heskett
>
>
> Cheers, Gene Heskett


--

[Michael Stone]

On Mon, Jun 10, 2019 at 01:44:36PM -0000, Curt wrote:
>Well, Michael Stone's guess was a good one (though, apparently, wrong).

The one thing I've learned is that Gene does weird things to his systems
and has issues that nobody else has. I'll throw out a guess, but I won't
waste a lot of time on it. It is certain that systemd doesn't generally
activate a getty on a serial port, so something's turning it on. But,
playing 20,000 questions and getting straight answers to 10,000 of them
after reading 10,000 pages of anecdotes just isn't fun for most people,
so we'll probably just leave this in the "undocumented weirdness" pile
and move on.

>Of course, you don't show any logs so it's anybody's guess.

Bingo.

[Gene Heskett]

On Monday 10 June 2019 09:44:36 am Curt wrote:

> On 2019-06-10, Gene Heskett <ghes...@shentel.net> wrote:
> >> Maybe
> >>
> >> sudo systemctl stop serial...@ttyS0.service
> >>
> >> if you haven't already tried it.
> >
> > No, after a reboot, I don't need to.
> >
> > minicom is working, sorta. Theres enough diffs in the protocol to
> > call "working" by a rather fuzzy definition. But at least
> > /dev/ttyS0 is now available for MY use. That was the squawk. I still
> > have not found where the previous boot, to the same kernel/etc might
> > have decided to grab /dev/ttyS0 for its own use. The previous boot
> > did send 7 or 8 bytes of data that was just random line noise to the
> > legacy machine on the receiving end that cable. Other than that, I'm
> > still clueless.
>
> Well, Michael Stone's guess was a good one (though, apparently,
> wrong).
>
> Of course, you don't show any logs so it's anybody's guess.
>

logs are a mess. Everything I ran for email support on wheezy, that kept
its own logs, is now spamming syslog to the extent that in an hour, any
interesting log events have scrolled well of the 10,000 line buffer I
give each shell. Finding anything in that mess even with grep is almost
impossible, because you can highlight it to do a copy/paste to an email,
and theres nothing in the buffer after switching windows and positioning
the cursor for the paste, its already scrolled off screen, which cancels
the highlight.

Trying to move spamd's log is hopeless because now they have no
permissions to use /var/log. Thats such a pain in the ass to make it
work that I gave it up on wheezy and made a log dir in my home dir and
fixed logrotate to service them there. What the hell, I thought /var/log
was where to find/keep logs, but when only root can use it, its the same
as the belly appendages on a boar hog. Useless. Just because of someones
paranoia.

> Here's another: modemmanager probing ttyS0 trying to identify a modem.
>
> Probably not, though. Anyway, it's working, which is enough for some
> of us in this crazy old world.

> > If I were to file a bug, it would be against java's current
> > (stretch) jre. It has no backward compatibility with the wheezy
> > version and has broken another utility we use so badly that the
> > majority of it has now been re-written in pypy. So we at least have
> > the function, if not the "purty" we had with the wheezy version of
> > the jre. The purty will be improved I am sure. The pypy effort is
> > quite young yet.
> >
> >> > Thanks all;
> >> >
> >> > Cheers, Gene Heskett
> >
> > Cheers, Gene Heskett

Sorry for the bad mood. I can barely walk from the back pain. I've 2
riding mowers all apart in the driveway, 2 crushed disks in my back
making me miserable after 2 days of working on it, and still much of a
day yet getting a rider back in a state I can climb on, twist the key
and mow. And its 3+ feet deep in places in the back yard. That or
$1800 to get far enough up the quality ladder to get rid of the kawasaki
or briggs and scrapiron motors. Both are problem children. Kohler
engines just work. Honda engines just work. And the guy who could pick
up 200 lbs and walk it all over town? At 84 he doesn't live here
anymore.

[andreim...@gmail.com]

On Sb, 08 iun 19, 10:22:54, Jonathan Dowland wrote:
> On Sat, Jun 08, 2019 at 11:04:54AM +0200, Étienne Mollier wrote:
> > I count 182 systemd related manual pages on my Sid machine.
> > Fortunately, among the lot, there is :
> >
> > systemd.index (7) - List all manpages from the systemd project
> >
> > Sadly, it is not referenced in the systemd(1) SEE ALSO section,
> > which I would tend to consider the intuitive starting point of
> > any person interested in knowing more about how to handled the
> > arcane of this init process.
>
> I agree with both: it should probably be added to the main entry
> point's SEE ALSO section. That would likely be a very simple patch,
> which I might attempt myself if I have some time.

Maybe someone here with a GitHub account could open an issue upstream.
It might be enough.

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser