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

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

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

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

Contents

  Re: What is agetty, and why can't it be stopped? bw <bwtnguy@yahoo.com> - 2019-06-07 00:20 +0200
    Re: What is agetty, and why can't it be stopped? Gene Heskett <gheskett@shentel.net> - 2019-06-07 07:30 +0200
      Re: What is agetty, and why can't it be stopped? Jonathan Dowland <jmtd@debian.org> - 2019-06-07 12:30 +0200
        Re: What is agetty, and why can't it be stopped? Gene Heskett <gheskett@shentel.net> - 2019-06-07 17:50 +0200
          Re: What is agetty, and why can't it be stopped? Nicholas Geovanis <nickgeovanis@gmail.com> - 2019-06-07 21:30 +0200
          Re: What is agetty, and why can't it be stopped? Jonathan Dowland <jmtd@debian.org> - 2019-06-07 21:30 +0200
            Re: What is agetty, and why can't it be stopped? Greg Wooledge <wooledg@eeg.ccf.org> - 2019-06-07 21:40 +0200
            Re: What is agetty, and why can't it be stopped? rhkramer@gmail.com - 2019-06-07 23:20 +0200
            Re: What is agetty, and why can't it be stopped? Gene Heskett <gheskett@shentel.net> - 2019-06-08 03:50 +0200
              Re: What is agetty, and why can't it be stopped? <tomas@tuxteam.de> - 2019-06-08 11:00 +0200
                Re: What is agetty, and why can't it be stopped? Étienne Mollier <etienne.mollier@mailoo.org> - 2019-06-08 11:10 +0200
                  Re: What is agetty, and why can't it be stopped? Jonathan Dowland <jmtd@debian.org> - 2019-06-08 11:30 +0200
                    Re: What is agetty, and why can't it be stopped? andreimpopescu@gmail.com - 2019-06-29 08:50 +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? Brian <ad44@cityscape.co.uk> - 2019-06-08 21:30 +0200
          Re: What is agetty, and why can't it be stopped? Nicholas Geovanis <nickgeovanis@gmail.com> - 2019-06-07 21:30 +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? Nicholas Geovanis <nickgeovanis@gmail.com> - 2019-06-07 21:30 +0200
          systemd-nspawn (was Re: What is agetty, and why can't it be stopped?) Jonathan Dowland <jmtd@debian.org> - 2019-06-07 22:00 +0200
          Re: What is agetty, and why can't it be stopped? Gene Heskett <gheskett@shentel.net> - 2019-06-08 03:40 +0200

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

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

In-Reply-To: <201906061506.20757.gheskett@shentel.net>

>On Thursday 06 June 2019 08:37:36 am bw wrote:
>>
>> In-Reply-To: <[????] 201906052204.09390.gheskett@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
>
>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.

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

[toc] | [next] | [standalone]

#209710

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

> In-Reply-To: <201906061506.20757.gheskett@shentel.net>
>
> >On Thursday 06 June 2019 08:37:36 am bw wrote:
> >> In-Reply-To: <[????] 201906052204.09390.gheskett@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/getty@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.

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]

#209716

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.

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

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

#209723

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>

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

#209727

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

https://www.midnightscience.net/

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

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

#209728

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)

-- 

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

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

#209731

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.

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

#209734

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

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

#209739

On Friday 07 June 2019 03:28:57 pm Jonathan Dowland wrote:

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

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]

#209753

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

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

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

#209754

On 6/8/19 10:55 AM, tomas@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"?
> 
> Cheers
> -- t
> 

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.mollier@mailoo.org>

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

#209755

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.

-- 

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

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

#210481

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

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

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

#209760

On Saturday 08 June 2019 04:55:45 am tomas@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.

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.

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]

#209765

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

> On Saturday 08 June 2019 04:55:45 am tomas@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.

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

#209730

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

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 <gheskett@shentel.net> wrote:

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

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

#209738

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

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

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

Worked fairly well if the antenna was long enough.

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


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#209729

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

On Fri, Jun 7, 2019 at 5:24 AM Jonathan Dowland <jmtd@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?


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

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

#209733 — systemd-nspawn (was Re: What is agetty, and why can't it be stopped?)

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

-- 

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

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

#209737

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

> On Fri, Jun 7, 2019 at 5:24 AM Jonathan Dowland <jmtd@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.


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] | [standalone]

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

csiph-web