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
On Fri, Jun 7, 2019 at 10:48 AM Gene Heskett <ghesk...@shentel.net> wrote: > On Friday 07 June 2019 06:24:00 am Jonathan Dowland wrote: > > > On Fri, Jun 07, 2019 at 01:23:45AM -0400, Gene Heskett wrote: > > >Not getting anyplace so far, but the reboot has given me only one > > > agetty running on tty1, which looks like exactly > > >what /etc/systemd/system/getty.target.wants/getty@tty1.service > > >wants. It also says as a comment: > > > > I don't think getty.target is relevant to you unless you are asking > > systemd to set your system up to that target: the default target is > > graphical.target, and the other one you are likely to use is > > multi-user.target. If you haven't knowingly changed your system's > > default target, it will be graphical.target. > > > > If you don't know what a systemd target is, then you likely haven't > > changed your system to use one other than the default. (You can learn > > more about systemd targets in the manpage systemd.target. They're > > vaguely analogous to sysvinit runlevels). > > > > >root@coyote:getty.target.wants$ locate serial-getty@.service > > >/lib/systemd/system/serial-getty@.service > > > > That's the "serial getty generator service". It's not a concrete > > service per se, more a template from which concrete services will > > derive. A concrete > > > > example would be serial-getty@ttyS0.service. On my system: > > > ▶ systemctl status serial-getty@ttyS0.service > > > ● serial-getty@ttyS0.service - Serial Getty on ttyS0 > > > Loaded: loaded (/lib/systemd/system/serial-getty@.service; > > > disabled; vendor preset: enabled) Active: inactive (dead) > > > Docs: man:agetty(8) > > > man:systemd-getty-generator(8) > > > http://0pointer.de/blog/projects/serial-console.html > > > > So my system has a service defined for a getty on ttyS0 but it is both > > disabled and not running. What I would have suggested to you, if you > > still had your machine in the state where the getty was running, would > > be to try "systemctl status serial-getty@ttyS0.service" and see what > > the result was. If it were running, "systemctl stop > > serial-getty@ttyS0.service" would stop it, and "systemctl disable > > serial-getty@ttyS0.service" would disable it from starting > > automatically again (if it were configured to do so). > > > > >But wouldn't a link to that have to exist in this /etc/systemd tree? > > > > No. Systemd reads the contents of /lib/systemd and /etc/systemd; the > > latter overrides the former, if it specifies units with the same name. > > This is so that the package manager can freely update and overwrite > > units supplied in packages (to /lib/systemd), without interfering with > > any manual configuration that you have performed as a user (in > > /etc/systemd). > > > > >So what sort of a precondition that didn't happen on this reboot, > > > would trigger this above file to grab and lockup /dev/ttyS0 like it > > > did on the last reboot. > > > > If you caused a service to be started that expressed a dependency upon > > serial-getty@ttyS0.service (or getty@ttyS0.service, that's also > > possible although unlikely and not useful) then that would be one > > explanation. I am not aware of any such service, and cannot find one > > on my system at least. > > > Neither can I and this "service" is not a familiar term since this is my > first expedition into systemd territory. > > And its and intermittent only service. I am the author of several handy > utilities for that old Unix-like os on a box with a 16 bit address buss, > and there are still a good 1000 users of it on this ball of rock & > water. 2 services actually, one is called drivewire, and makes use if > the machines bit banger port at 115kbaud, and this terminal function > that minicom is doing against a hardware serial port on that machine. 2 > independent services. > > Drivewire was written in Java, and changes in Java from wheezy to stretch > have killed that, but a replacement is being written in python in hopes > it might be a more stable language. We as a group, had no clue that Java > would be changed to be so damned incompatible with itself. So I'm > playing canary in a coal mine testing the python version. For a machine > that was new in the early 80's, I am amazed at the new blood it has > attracted in the last 2 or 3 years. Mailing list sub count has nearly > doubled in the last 4 years. And with that new blood has come quite a > list of of newly designed hardware accessories for it. Sure, its being > built on kitchen tables in runs of 10 or 20, but its happening 35 years > later. That in itself is amazing. And redefines the word retro. I can > recall the days when vacuum tubes were state of the art, and knowing how > they work has given me a nice lengthy ladder up the side of that famous > hog. A rather broad knowledge of physics hasn't hurt a thing either, > including Einsteins work. > > > >I am beginning to get a very dim glimmer of how systemd works. And > > > its not impressing me. > > > > You are free to switch back to sysvinit if you wish. To do so you need > > to install sysvinit-core (and remove systemd-sysv, which will likely > > be removed by the action of installing sysvinit-core). This will > > change your init system to sysvinit, although it would not remove all > > of systemd, and some parts of it are likely depended upon by other > > stuff on your system. > > I can likely go with the flow as long as its documented in readily > accessable form, something that L.P. is good at, he writes nice "papers" > on his stuff but hides that info from the unwashed by not putting out > decent man-pages. I disagree loudly about that but the exclusion of > examples from manpages seems like an insidious attack on the users > intelligence. I give you the present state of the docs for ip as an > example of how NOT to do a man page. 300 lines of "options" without a > word on which is required to get or apply what data or what if any > interactions there may be. I have yet to get a path condition report out > of it like ifconfig gives by default. That is not progress unless you > are using GE's definition from the late '50's. > > Cheers, Gene Heskett > -- > "There are four boxes to be used in defense of liberty: > soap, ballot, jury, and ammo. Please use in that order." > -Ed Howdershelt (Author) > Genes Web page <http://geneslinuxbox.net:6309/gene> > >
