https://www.midnightscience.net/
On Fri, Jun 7, 2019 at 2:25 PM Nicholas Geovanis <nickgeova...@gmail.com> 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.... ;-) > 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> >> >>
