Re: usr-merge, was Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[David Wright]

On Fri 03 Jan 2020 at 21:13:42 (-0500), Kenneth Parker wrote:
> On Thu, Jan 2, 2020 at 12:51 PM David Wright  wrote:
> > On Thu 02 Jan 2020 at 06:04:03 (-0500), Steve Litt wrote that usr-merge
> > causes problems with systems that are initramfs-free (and /usr is a
> > mounted filesystem). I don't think Debian has supported such systems
> > in a long while, so you're really on your own with creating and
> > booting those.
> >
> 
>  I'm glad I found this out!  I have a Jessie System with a VERY small Root
> (2G), and separate /usr and /home Partitions on a different Hard Drive.

Yes, but are you booting conventionally using an initramfs (ironically
with the filename initrd…), or are you, like Steve Litt, avoiding any
use of initramfs? Only the latter should cause you any bother.

For someone booting with an initramfs, the effect of usr-merge is to
move all the files in /bin, /sbin and /lib into /usr, which means that
your root partition will be a little emptier. On this laptop's
previous installation of stretch, that would save

9.9M/wrens/bin
10M /wrens/sbin
496M/wrens/lib
4.0K/wrens/lib64

from the root partition. (/wrens is the mountpoint of my old stretch's
root directory.)

> I suspect that Buster wouldn't install well on this at all!  :-)

There's no disadvantage in having a separate /usr partition in Buster;
in fact, it can be an advantage as you can mount it readonly because
none of the files is written to (except when installing software, of
course). I used to do this when I ran systems with multiple users
connected to the Internet with no firewall. With usr-merge, your /bin,
/sbin and /lib would also benefit from being in the readonly partition,
rather than in the read-write / partition.

When you boot, all the files that are required, which were once in
/bin and /sbin, are nowadays in the initramfs. (A lot of them are
actually bundled up in /bin/busybox, which has almost 250 hard
links in my initramfs.)

> Thanks for the info.  I enjoyed reading Bug Report 914897.

Cheers,
David.

Re: usr-merge, was Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[Kenneth Parker]

On Thu, Jan 2, 2020 at 12:51 PM David Wright 
wrote:

> On Wed 01 Jan 2020 at 18:48:00 (+0100), Sven Hartge wrote:
> > David Wright  wrote:
> >
> > > But this does follow the (snipped) comment 'the "/usr Merge" that
> > > might hit a fan someday'. For those *not* preparing packages for
> > > Debian and/or other distributions, can anyone express a downside
> > > to usr-merge, ie for typical "user/consumers".
> >
> > For me the biggest downside was that "dpkg -S", "dlocate" and "apt-file
> > search" and the web-equivalent stopped working reliably, because the
> > final path in the filesystem is no longer the same as it is in the
> > package.
>
> Yes, I notice that the bug (134758) dates back 18 years and originally
> involved the old /usr/X11R6/bin /usr/bin/X11 symlink. It complicates
> using dpkg -S to search for one specific path (in a script, say), but
> for interactive use it's enough to remove the leading / to avoid
> misses caused by usr-merge. (There are already misses caused by
> alternatives, and files created at installation time.)
> apt-file search by default uses --substring-match, but I expect
> someone to post how you turn that option off, which I've never done.
>
> > It also broke some internal CI/CD where the wrong paths were used when
> > the CD chroot was built with usr-merge active but the deployment target
> > was not usr-merged. The same has happened for the Debian buildds.
>
> I thought I was avoiding that by excluding package-builders. Or is
> this something else entirely?
>
> > And it also broke some 3rd party vendor packages which had the same
> > directory in /lib and /usr/lib, but with different contents.
>
> What do these vendors do on conventional (non-Debian/non-linux)
> systems that have ceased to have any /lib long ago?
>
> On Thu 02 Jan 2020 at 06:04:03 (-0500), Steve Litt wrote that usr-merge
> causes problems with systems that are initramfs-free (and /usr is a
> mounted filesystem). I don't think Debian has supported such systems
> in a long while, so you're really on your own with creating and
> booting those.
>

 I'm glad I found this out!  I have a Jessie System with a VERY small Root
(2G), and separate /usr and /home Partitions on a different Hard Drive.  I
suspect that Buster wouldn't install well on this at all!  :-)

Thanks for the info.  I enjoyed reading Bug Report 914897.

Kenneth Parker

Re: usr-merge, was Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[David Wright]

On Thu 02 Jan 2020 at 19:49:45 (+0100), Sven Hartge wrote:
> David Wright  wrote:
> > On Wed 01 Jan 2020 at 18:48:00 (+0100), Sven Hartge wrote:
> >> David Wright  wrote:
>  
> >>> But this does follow the (snipped) comment 'the "/usr Merge" that
> >>> might hit a fan someday'. For those *not* preparing packages for
> >>> Debian and/or other distributions, can anyone express a downside to
> >>> usr-merge, ie for typical "user/consumers".
> 
> >> For me the biggest downside was that "dpkg -S", "dlocate" and
> >> "apt-file search" and the web-equivalent stopped working reliably,
> >> because the final path in the filesystem is no longer the same as it
> >> is in the package.
> 
> > Yes, I notice that the bug (134758) dates back 18 years and originally
> > involved the old /usr/X11R6/bin /usr/bin/X11 symlink. It complicates
> > using dpkg -S to search for one specific path (in a script, say), but
> > for interactive use it's enough to remove the leading / to avoid
> > misses caused by usr-merge. (There are already misses caused by
> > alternatives, and files created at installation time.)
> 
> Not everything is interactive use and having to special-case newly
> installed versus upgraded systems to have the correct matching type is
> really not ideal.

Not ideal, but really not much more than
  if /bin is link to usr/bin:
prefix /bin/foo with /usr
at appropriate points in scripts, no?

> >> It also broke some internal CI/CD where the wrong paths were used when
> >> the CD chroot was built with usr-merge active but the deployment target
> >> was not usr-merged. The same has happened for the Debian buildds.
> 
> > I thought I was avoiding that by excluding package-builders. Or is
> > this something else entirely?
> 
> Those are not packages that are built but software/configuration/file
> distribution via different ways.

It's a simlar problem, isn't it? If the chroot uses a split
configuration, most of the problems go away on account of the
symlinks. It's just the paths that get realname-d which need
fixing up as above.

> >> And it also broke some 3rd party vendor packages which had the same
> >> directory in /lib and /usr/lib, but with different contents.
> 
> > What do these vendors do on conventional (non-Debian/non-linux)
> > systems that have ceased to have any /lib long ago?
> 
> In this case the vendor only ever supported Debian and Ubuntu. (This is
> a very edge-case specialty-use software.)

That would seem easy for them to fix with a simple rename of their
custom versions of the libraries.

> But, to summarize: I'd have liked for this change to be done in a
> different way with *all* systems-maintainers in board.

Reading #914897, that didn't seem likely as views were somewhat entrenched.

Cheers,
David.

Re: usr-merge, was Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[Sven Hartge]

David Wright  wrote:
> On Wed 01 Jan 2020 at 18:48:00 (+0100), Sven Hartge wrote:
>> David Wright  wrote:
 
>>> But this does follow the (snipped) comment 'the "/usr Merge" that
>>> might hit a fan someday'. For those *not* preparing packages for
>>> Debian and/or other distributions, can anyone express a downside to
>>> usr-merge, ie for typical "user/consumers".

>> For me the biggest downside was that "dpkg -S", "dlocate" and
>> "apt-file search" and the web-equivalent stopped working reliably,
>> because the final path in the filesystem is no longer the same as it
>> is in the package.

> Yes, I notice that the bug (134758) dates back 18 years and originally
> involved the old /usr/X11R6/bin /usr/bin/X11 symlink. It complicates
> using dpkg -S to search for one specific path (in a script, say), but
> for interactive use it's enough to remove the leading / to avoid
> misses caused by usr-merge. (There are already misses caused by
> alternatives, and files created at installation time.)

Not everything is interactive use and having to special-case newly
installed versus upgraded systems to have the correct matching type is
really not ideal.

>> It also broke some internal CI/CD where the wrong paths were used when
>> the CD chroot was built with usr-merge active but the deployment target
>> was not usr-merged. The same has happened for the Debian buildds.

> I thought I was avoiding that by excluding package-builders. Or is
> this something else entirely?

Those are not packages that are built but software/configuration/file
distribution via different ways.

>> And it also broke some 3rd party vendor packages which had the same
>> directory in /lib and /usr/lib, but with different contents.

> What do these vendors do on conventional (non-Debian/non-linux)
> systems that have ceased to have any /lib long ago?

In this case the vendor only ever supported Debian and Ubuntu. (This is
a very edge-case specialty-use software.)

But, to summarize: I'd have liked for this change to be done in a
different way with *all* systems-maintainers in board.

S!

-- 
Sigmentation fault. Core dumped.

Re: usr-merge, was Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[David Wright]

On Wed 01 Jan 2020 at 18:48:00 (+0100), Sven Hartge wrote:
> David Wright  wrote:
> 
> > But this does follow the (snipped) comment 'the "/usr Merge" that
> > might hit a fan someday'. For those *not* preparing packages for
> > Debian and/or other distributions, can anyone express a downside
> > to usr-merge, ie for typical "user/consumers".
> 
> For me the biggest downside was that "dpkg -S", "dlocate" and "apt-file
> search" and the web-equivalent stopped working reliably, because the
> final path in the filesystem is no longer the same as it is in the
> package.

Yes, I notice that the bug (134758) dates back 18 years and originally
involved the old /usr/X11R6/bin /usr/bin/X11 symlink. It complicates
using dpkg -S to search for one specific path (in a script, say), but
for interactive use it's enough to remove the leading / to avoid
misses caused by usr-merge. (There are already misses caused by
alternatives, and files created at installation time.)
apt-file search by default uses --substring-match, but I expect
someone to post how you turn that option off, which I've never done.

> It also broke some internal CI/CD where the wrong paths were used when
> the CD chroot was built with usr-merge active but the deployment target
> was not usr-merged. The same has happened for the Debian buildds.

I thought I was avoiding that by excluding package-builders. Or is
this something else entirely?

> And it also broke some 3rd party vendor packages which had the same
> directory in /lib and /usr/lib, but with different contents.

What do these vendors do on conventional (non-Debian/non-linux)
systems that have ceased to have any /lib long ago?

On Thu 02 Jan 2020 at 06:04:03 (-0500), Steve Litt wrote that usr-merge
causes problems with systems that are initramfs-free (and /usr is a
mounted filesystem). I don't think Debian has supported such systems
in a long while, so you're really on your own with creating and
booting those.

Cheers,
David.

Re: usr-merge, was Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[Sven Hartge]

David Wright  wrote:

> But this does follow the (snipped) comment 'the "/usr Merge" that
> might hit a fan someday'. For those *not* preparing packages for
> Debian and/or other distributions, can anyone express a downside
> to usr-merge, ie for typical "user/consumers".

For me the biggest downside was that "dpkg -S", "dlocate" and "apt-file
search" and the web-equivalent stopped working reliably, because the
final path in the filesystem is no longer the same as it is in the
package.

It also broke some internal CI/CD where the wrong paths were used when
the CD chroot was built with usr-merge active but the deployment target
was not usr-merged. The same has happened for the Debian buildds.

And it also broke some 3rd party vendor packages which had the same
directory in /lib and /usr/lib, but with different contents.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Re: usr-merge, was Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[David Wright]

On Wed 01 Jan 2020 at 11:04:32 (+0200), Andrei POPESCU wrote:
> On Ma, 31 dec 19, 16:56:31, to...@tuxteam.de wrote:
> > On Tue, Dec 31, 2019 at 04:23:24PM +0100, Sven Hartge wrote:
> > > to...@tuxteam.de wrote:
> > > > On Tue, Dec 31, 2019 at 03:34:34PM +0100, Sven Hartge wrote:
> > 
> > [...]
> > 
> > > >> The usr-merge is already here, if you install Debian Buster [...]
> > 
> > > > or upgrading from a non-user-merge installation :-)
> > > 
> > > Sure. it is just a bit tedious to first install Stretch to upgrade to a
> > > non-usr-merged Buster.
> > 
> > This wasn't meant as a recommendation :-)
> > 
> > Whoever cares about this will hopefully know easier ways to achieve that.
> > 
> > Rather for those who now look at their setup and wonder...
> 
> debootstrap --no-merged-usr is one option I know of.

I assume once again that this wasn't meant as a recommendation.

But this does follow the (snipped) comment 'the "/usr Merge" that
might hit a fan someday'. For those *not* preparing packages for
Debian and/or other distributions, can anyone express a downside
to usr-merge, ie for typical "user/consumers".

I've read the references posted here, as well as
https://lists.debian.org/debian-devel-announce/2019/03/msg1.html
and the discussions and ballot that led up to it
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914897
and I haven't seen any indication of […] that hasn't hit the fan
already.

I'm not trying to discuss the implementation of the change, nor
the bumps in the road for developing installable packages on varied
targets, but just the cons (I can see pros) for the end user.

Cheers,
David.

Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[Andrei POPESCU]

On Ma, 31 dec 19, 12:22:59, ghe wrote:
> Sven and Andrei, I told you lies. The script's not a daemon. I added
> Sven's suggested lines to the .service file, re-enabled it, rebooted,
> and it came up exactly as I wanted it to.
> 
> Apparently what it does is build an iptables firewall, and quit. Then
> when I ask for things, it  comes up, crudely parses my command, and runs
> iptables commands to do what I ask.

Just for (your) reference, systemd.service(5) has an example that 
matches your needs (Example 3. Stoppable oneshot service).

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


signature.asc
Description: PGP signature

Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[Andrei POPESCU]

On Ma, 31 dec 19, 16:56:31, to...@tuxteam.de wrote:
> On Tue, Dec 31, 2019 at 04:23:24PM +0100, Sven Hartge wrote:
> > to...@tuxteam.de wrote:
> > > On Tue, Dec 31, 2019 at 03:34:34PM +0100, Sven Hartge wrote:
> 
> [...]
> 
> > >> The usr-merge is already here, if you install Debian Buster [...]
> 
> > > or upgrading from a non-user-merge installation :-)
> > 
> > Sure. it is just a bit tedious to first install Stretch to upgrade to a
> > non-usr-merged Buster.
> 
> This wasn't meant as a recommendation :-)
> 
> Whoever cares about this will hopefully know easier ways to achieve that.
> 
> Rather for those who now look at their setup and wonder...

debootstrap --no-merged-usr is one option I know of.

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


signature.asc
Description: PGP signature

Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[Sven Hartge]

ghe  wrote:

> Sven and Andrei, I told you lies. The script's not a daemon. I added
> Sven's suggested lines to the .service file, re-enabled it, rebooted,
> and it came up exactly as I wanted it to.

Aha! Thought as much.

While I myself have written daemons in bash, doing so is at least
unusual.

> Do you still want the files?

In that case: no need anymore.

S!

-- 
Sigmentation fault. Core dumped.

Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[Sven Hartge]

ghe  wrote:
> On 12/31/19 6:09 AM, Sven Hartge wrote:

>> Care to share your Shell-Script? 

> I'd have no problem with that -- it's been very useful to me over the
> years, and I'd be glad for someone to use it.

> However. It was written 20 years ago when I was just figuring out
> Linux and the shell, and it's been 'updated' many times. It's an
> embarrassing mess now. If you're willing to consider it the work of a
> 6 year-old and provide significant slack, I'll gladly publicize it.

In this context I don't care how the script does something, I want to
know *what* it does and how it starts, runs and ends.

This is the relevant part in understanding what is happening to your
system, your unit and why.

S!

-- 
Sigmentation fault. Core dumped.

Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[ghe]

Sven and Andrei, I told you lies. The script's not a daemon. I added
Sven's suggested lines to the .service file, re-enabled it, rebooted,
and it came up exactly as I wanted it to.

Apparently what it does is build an iptables firewall, and quit. Then
when I ask for things, it  comes up, crudely parses my command, and runs
iptables commands to do what I ask.

Like I said, it's been a very long time since I wrote it, and I didn't
know what a daemon was at the time. I thought I did, and there are some
init files imported into the script.

I consider the problem fixed. I thank you for your patience and help.
And I apologize for the bad info I gave you.

Do you still want the files?

-- 
Glenn English

Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[ghe]

On 12/31/19 6:09 AM, Sven Hartge wrote:

> Care to share your Shell-Script? 

I'd have no problem with that -- it's been very useful to me over the
years, and I'd be glad for someone to use it.

However. It was written 20 years ago when I was just figuring out Linux
and the shell, and it's been 'updated' many times. It's an embarrassing
mess now. If you're willing to consider it the work of a 6 year-old and
provide significant slack, I'll gladly publicize it.

But let me look into things a bit more first.

-- 
Glenn English

Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[tomas]

On Tue, Dec 31, 2019 at 04:23:24PM +0100, Sven Hartge wrote:
> to...@tuxteam.de wrote:
> > On Tue, Dec 31, 2019 at 03:34:34PM +0100, Sven Hartge wrote:

[...]

> >> The usr-merge is already here, if you install Debian Buster [...]

> > or upgrading from a non-user-merge installation :-)
> 
> Sure. it is just a bit tedious to first install Stretch to upgrade to a
> non-usr-merged Buster.

This wasn't meant as a recommendation :-)

Whoever cares about this will hopefully know easier ways to achieve that.

Rather for those who now look at their setup and wonder...

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[Sven Hartge]

tony  wrote:
> On 31/12/2019 15:34, Sven Hartge wrote:
>> Kenneth Parker  wrote:
>> 
>>> +1 for information, on where System Files are stored on Debian, as well as
>>> for the reminder of the "/usr Merge" that might hit a fan someday.
>> 
>> The usr-merge is already here, if you install Debian Buster. The
>> installer creates a usr-merged filesystem and you, short of remastering
>> the Installer image to remove the option, have no way of configuring
>> this.

> Well, a while ago, I upgrade my stretch to buster, but I see no
> evidence of symlinks to /usr in my root fs. How come?

Only newly installed systems using the Installer from the Debian Buster
ISOs create a usr-merged system. Upgraded sytems are (not yet) affected.

I personally find the way the usr-merge was and is handled quite
annoying and key DDs, starting with the dpkg Maintainer Guillem Jover,
are also not impressed by the way this was pressed into service, kind of
at the last minute while concerns with it were not addressed.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[Greg Wooledge]

On Tue, Dec 31, 2019 at 04:02:46PM +0100, tony wrote:
> Well, a while ago, I upgrade my stretch to buster, but I see no evidence
> of symlinks to /usr in my root fs. How come?

https://www.debian.org/releases/buster/amd64/release-notes/ch-whats-new.en.html#merged-usr
https://wiki.debian.org/UsrMerge

Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[tony]

On 31/12/2019 15:34, Sven Hartge wrote:
> Kenneth Parker  wrote:
> 
>> +1 for information, on where System Files are stored on Debian, as well as
>> for the reminder of the "/usr Merge" that might hit a fan someday.
> 
> The usr-merge is already here, if you install Debian Buster. The
> installer creates a usr-merged filesystem and you, short of remastering
> the Installer image to remove the option, have no way of configuring
> this.
> 
> Grüße,
> Sven.
> 
Well, a while ago, I upgrade my stretch to buster, but I see no evidence
of symlinks to /usr in my root fs. How come?

Cheers, Tony

Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[Sven Hartge]

to...@tuxteam.de wrote:
> On Tue, Dec 31, 2019 at 03:34:34PM +0100, Sven Hartge wrote:
>> Kenneth Parker  wrote:
 
>>> +1 for information, on where System Files are stored on Debian, as
>>> well as for the reminder of the "/usr Merge" that might hit a fan
>>> someday.
>> 
>> The usr-merge is already here, if you install Debian Buster. The
>> installer creates a usr-merged filesystem and you, short of
>> remastering the Installer image...

> or upgrading from a non-user-merge installation :-)

Sure. it is just a bit tedious to first install Stretch to upgrade to a
non-usr-merged Buster.

S!

-- 
Sigmentation fault. Core dumped.

Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[tomas]

On Tue, Dec 31, 2019 at 03:34:34PM +0100, Sven Hartge wrote:
> Kenneth Parker  wrote:
> 
> > +1 for information, on where System Files are stored on Debian, as well as
> > for the reminder of the "/usr Merge" that might hit a fan someday.
> 
> The usr-merge is already here, if you install Debian Buster. The
> installer creates a usr-merged filesystem and you, short of remastering
> the Installer image...

or upgrading from a non-user-merge installation :-)

Cheers
-- t


signature.asc
Description: Digital signature

Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[Sven Hartge]

Kenneth Parker  wrote:

> +1 for information, on where System Files are stored on Debian, as well as
> for the reminder of the "/usr Merge" that might hit a fan someday.

The usr-merge is already here, if you install Debian Buster. The
installer creates a usr-merged filesystem and you, short of remastering
the Installer image to remove the option, have no way of configuring
this.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[Kenneth Parker]

On Tue, Dec 31, 2019, 8:42 AM Greg Wooledge  wrote:

> On Tue, Dec 31, 2019 at 12:30:05AM -0700, ghe wrote:
> > As I said before, (grumble, grumble, systemd, grumble, grumble). It
> seems to be pretty nicely done system code, but with an absolutely
> abominable user interface. So far, I know of systemd dirs in /lib, /etc,
> and /usr. That's no way to run a *nix railroad.
>
> Debian doesn't have one in /usr, except if usr-merge was performed,
> in which case the one in /lib is also the one in /usr/lib.
>
> So, there's really just /lib and /etc.  (In Debian.  And why do I have
> to write that, on a debian-user mailing list)
>
> The one in /lib is for PACKAGES, from your operating system, which for
> most of us is Debian, but for you may be some Raspthing.  (And hell,
> maybe Raspbian still uses the Red Hat directories, who the fuck knows,
> that's why we can't support Raspbian questions here -- IT'S DIFFERENT!)
>
> The one in /etc is for YOU, the local system administrator, to store
> your locally written unit files.  And also for total-override unit
> files created by "systemctl edit", and also for drop-in directories,
> and also for automatically created symlinks that represent aliases
> and masks and so on.
>
> Unit files in /etc OVERRIDE unit files in /lib because YOU are the
> master of your local system, and YOUR changes are intended to override
> the operating system vendor's shipped files.  It's the same reason
> why /usr/local/bin is in $PATH before /usr/bin and /bin.  It's the
> same reason why files in a user's $HOME directory override system
> defaults.
>

+1 for information, on where System Files are stored on Debian, as well as
for the reminder of the "/usr Merge" that might hit a fan someday.

Kenneth Parker

>

Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[Greg Wooledge]

On Tue, Dec 31, 2019 at 12:30:05AM -0700, ghe wrote:
> As I said before, (grumble, grumble, systemd, grumble, grumble). It seems to 
> be pretty nicely done system code, but with an absolutely abominable user 
> interface. So far, I know of systemd dirs in /lib, /etc, and /usr. That's no 
> way to run a *nix railroad.

Debian doesn't have one in /usr, except if usr-merge was performed,
in which case the one in /lib is also the one in /usr/lib.

So, there's really just /lib and /etc.  (In Debian.  And why do I have
to write that, on a debian-user mailing list)

The one in /lib is for PACKAGES, from your operating system, which for
most of us is Debian, but for you may be some Raspthing.  (And hell,
maybe Raspbian still uses the Red Hat directories, who the fuck knows,
that's why we can't support Raspbian questions here -- IT'S DIFFERENT!)

The one in /etc is for YOU, the local system administrator, to store
your locally written unit files.  And also for total-override unit
files created by "systemctl edit", and also for drop-in directories,
and also for automatically created symlinks that represent aliases
and masks and so on.

Unit files in /etc OVERRIDE unit files in /lib because YOU are the
master of your local system, and YOUR changes are intended to override
the operating system vendor's shipped files.  It's the same reason
why /usr/local/bin is in $PATH before /usr/bin and /bin.  It's the
same reason why files in a user's $HOME directory override system
defaults.

Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[Greg Wooledge]

On Mon, Dec 30, 2019 at 05:07:47PM -0700, ghe wrote:
> root@test:~# systemctl status ipfilter
> ● ipfilter.service - packetFilter
>Loaded: loaded (/usr/lib/systemd/system/ipfilter.service; enabled;
> vendor preset: enabled)

packages.debian.org says:

You have searched for files named /usr/lib/systemd/system/ipfilter.service
in suite buster, all sections, and all architectures.

Sorry, your search gave no results


And then:

You have searched for files named ipfilter.service in suite buster,
all sections, and all architectures.

Sorry, your search gave no results

> The service file:
> 
> root@test:/lib/systemd/system# cat /usr/lib/systemd/system/ipfilter.service
> [Unit]
> Description=packetFilter
> 
> [Service]
> ExecStart=/etc/ipfilterfiles/ipfilter.sh on
> ExecStop=/etc/ipfilterfiles/ipfilter.sh off
> 
> [Install]
> WantedBy=multi-user.target

> When I wrote it,

*sigh*

So, it's not --really-- a systemd unit.  You're just using systemd as
a thin layer on top of a shell script.  But you've not specified what
type of pseudo-service this is.

   Type=
   Configures the process start-up type for this service unit. One of
   simple, exec, forking, oneshot, dbus, notify or idle:

   •   If set to simple (the default if ExecStart= is specified but
   neither Type= nor BusName= are), the service manager will
   consider the unit started immediately after the main service
   process has been forked off. It is expected that the process
   configured with ExecStart= is the main process of the service.

What you're doing here is really closer to oneshot than simple.  I think.
I've never actually *written* a systemd unit file that simply acts as
a thin layer on top of a shell script.

> And this all on the RPi4.

So, it's not a Debian systemd unit file, and it's not running on Debian?
Sheesh.

Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[Sven Hartge]

ghe  wrote:
> On 12/31/19 1:05 AM, Andrei POPESCU wrote:

>>> I guess I misunderstood the term 'daemon.' I thought it was just a 
>>> piece of software that, when run, stays run until it's through -- when 
>>> it's started at boot and has no exit, hangs around in the background 
>>> doing stuff. Unless somebody tells it to stop.
>> 
>> Right. Does your script work like this? I'm asking because typically 
>> scripts do their thing and then exit.

> Yes, it does. It's a huge (for .sh) program (Python was unavailable at
> the time :-) that will, interactively, display and modify the iptables
> chains. There are several other .sh and PERL scripts I've written that
> do similar things -- intended to be daemons, as I understood it.

Care to share your Shell-Script? If it indeed is a daemon that keeps
running, then the lines to add to your unit file are wrong in this
circumstance.

Grüße,
S°

-- 
Sigmentation fault. Core dumped.

Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[Gene Heskett]

On Tuesday 31 December 2019 05:37:54 Joe wrote:

> On Tue, 31 Dec 2019 04:37:10 -0500
>
> Gene Heskett  wrote:
> > On Tuesday 31 December 2019 02:30:05 ghe wrote:
> > > > On Dec 30, 2019, at 05:47 PM, Sven Hartge 
> > > > wrote:
> > > >
> > > > Please show the output of
> > > >
> > > >systemctl cat YOUR_SERVICE_UNIT
> > > >
> > > > This will show all additions and overrides to the unit.
> > >
> > > root@test:~# systemctl cat ipfilter
> > > # /usr/lib/systemd/system/ipfilter.service
> > > [Unit]
> > > Description=packetFilter
> > >
> > > [Service]
> > > ExecStart=/etc/ipfilterfiles/ipfilter.sh on
> > > ExecStop=/etc/ipfilterfiles/ipfilter.sh off
> > >
> > > [Install]
> > > WantedBy=multi-user.target
> > >
> > > > Your shell script isn't really daemon, so it is normal to not
> > > > stay running after it setup the iptables rules.
> > >
> > > I guess I misunderstood the term 'daemon.' I thought it was just a
> > > piece of software that, when run, stays run until it's through --
> > > when it's started at boot and has no exit, hangs around in the
> > > background doing stuff. Unless somebody tells it to stop.
> > >
> > > This code has, under the old init system, been thinking it's a
> > > daemon for a couple decades now. But you're right. On other
> > > systemd computers, I have to start my local firewall by hand, like
> > > I have to with BIND on the DNS server.
> > >
> > > > I think your unit is missing the following:
> > > >
> > > > ,
> > > >
> > > > | [Service]
> > > > | Type=oneshot
> > > > | RemainAfterExit=yes
> > > >
> > > > `
> > >
> > > That makes sense. I'll insert those lines and see what happens.
> > >
> > > I knew it'd be trivial when it came to light what I was missing.
> > > Thanks a lot.
> > >
> > > (grumble, grumble, systemd, grumble, grumble)
> > >
> > > >> And how did that file get in /usr? When I wrote it, it was in
> > > >> /lib/systemd/system.
> > > >
> > > > usr-merge is the keyword here.
> > >
> > > What's that? I never heard of that before, and I certainly didn't
> > > ask for it. One of the reasons I run Debian was that the config
> > > stuff is all in /etc. And, it goes without saying, stays there.
> > >
> > > As I said before, (grumble, grumble, systemd, grumble, grumble).
> > > It seems to be pretty nicely done system code, but with an
> > > absolutely abominable user interface. So far, I know of systemd
> > > dirs in /lib, /etc, and /usr. That's no way to run a *nix
> > > railroad.
> >
> > +100 (or more)
> >
> > > While I have you on the hook, Sven, how/where did you get your
> > > systemd knowledge? I've looked around, and I haven't seen any
> > > mention of what you just told me.
> >
> > I had that same didn't start after a reboot problem, but found this
> > script started iptables ok when executed by hand as ./start-iptables
> > while root in the /etc/iptables dir.
> >
> > #!/bin/bash
> > iptables-restore  >
> > And whenever I add a new rule, I resave the saved-rules with this
> >
> > #!/bin/bash
> > iptables-save >saved-rules
> >
> > A executed from /etc/iptables with ./iptables-saveem
> >
> > It seems to me, that if iptables has been intalled, there ought to
> > be a start script in /etc/init.d, or someplace in the /etc/systemd
> > path, but there is not such a critter in either path (nothing in
> > /usr, but /lib/systemd has 100 or so files) in this stretch install.
> >
> > This works, but leaves me open until I get around to starting it, so
> > I doubt its the approved method.  IMO it ought to be the first
> > active line in the ifup script so its active before the net is
> > brought up.
>
> Does iptables-persistent work for you?

It should, I just installed it. I'll have to change the name of the save 
file to match it in my other scripts, but haven't yet.

> I made my own pseudo-daemon before this existed, stealing a LFS
> skeleton, allowing multiple rulesets for various environments.


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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[Joe]

On Tue, 31 Dec 2019 04:37:10 -0500
Gene Heskett  wrote:

> On Tuesday 31 December 2019 02:30:05 ghe wrote:
> 
> > > On Dec 30, 2019, at 05:47 PM, Sven Hartge 
> > > wrote:
> > >
> > > Please show the output of
> > >
> > >systemctl cat YOUR_SERVICE_UNIT
> > >
> > > This will show all additions and overrides to the unit.  
> >
> > root@test:~# systemctl cat ipfilter
> > # /usr/lib/systemd/system/ipfilter.service
> > [Unit]
> > Description=packetFilter
> >
> > [Service]
> > ExecStart=/etc/ipfilterfiles/ipfilter.sh on
> > ExecStop=/etc/ipfilterfiles/ipfilter.sh off
> >
> > [Install]
> > WantedBy=multi-user.target
> >  
> > > Your shell script isn't really daemon, so it is normal to not stay
> > > running after it setup the iptables rules.  
> >
> > I guess I misunderstood the term 'daemon.' I thought it was just a
> > piece of software that, when run, stays run until it's through --
> > when it's started at boot and has no exit, hangs around in the
> > background doing stuff. Unless somebody tells it to stop.
> >
> > This code has, under the old init system, been thinking it's a
> > daemon for a couple decades now. But you're right. On other systemd
> > computers, I have to start my local firewall by hand, like I have to
> > with BIND on the DNS server.
> >  
> > > I think your unit is missing the following:
> > >
> > > ,
> > >
> > > | [Service]
> > > | Type=oneshot
> > > | RemainAfterExit=yes
> > >
> > > `  
> >
> > That makes sense. I'll insert those lines and see what happens.
> >
> > I knew it'd be trivial when it came to light what I was missing.
> > Thanks a lot.
> >
> > (grumble, grumble, systemd, grumble, grumble)
> >  
> > >> And how did that file get in /usr? When I wrote it, it was in
> > >> /lib/systemd/system.  
> > >
> > > usr-merge is the keyword here.  
> >
> > What's that? I never heard of that before, and I certainly didn't
> > ask for it. One of the reasons I run Debian was that the config
> > stuff is all in /etc. And, it goes without saying, stays there.
> >
> > As I said before, (grumble, grumble, systemd, grumble, grumble). It
> > seems to be pretty nicely done system code, but with an absolutely
> > abominable user interface. So far, I know of systemd dirs in /lib,
> > /etc, and /usr. That's no way to run a *nix railroad.
> >  
> +100 (or more)
> 
> > While I have you on the hook, Sven, how/where did you get your
> > systemd knowledge? I've looked around, and I haven't seen any
> > mention of what you just told me.  
> 
> I had that same didn't start after a reboot problem, but found this 
> script started iptables ok when executed by hand as ./start-iptables 
> while root in the /etc/iptables dir.
> 
> #!/bin/bash
> iptables-restore  
> And whenever I add a new rule, I resave the saved-rules with this
> 
> #!/bin/bash
> iptables-save >saved-rules
> 
> A executed from /etc/iptables with ./iptables-saveem
> 
> It seems to me, that if iptables has been intalled, there ought to be
> a start script in /etc/init.d, or someplace in the /etc/systemd path,
> but there is not such a critter in either path (nothing in /usr, 
> but /lib/systemd has 100 or so files) in this stretch install.
> 
> This works, but leaves me open until I get around to starting it, so
> I doubt its the approved method.  IMO it ought to be the first active
> line in the ifup script so its active before the net is brought up. 
> 

Does iptables-persistent work for you?

I made my own pseudo-daemon before this existed, stealing a LFS
skeleton, allowing multiple rulesets for various environments.

-- 
Joe

Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[mick crane]

On 2019-12-31 09:21, ghe wrote:


But what I'm really looking for is a comprehensive book on systemd like
the 40 pounder 'Learning Python' or other O'Reilly, etc, books that've
saved my life in the past few years. (I'm more comfortable with dead
trees than I am with screens.)


When Microsoft was saying "Where do you want to go today ?" I started 
looking for another OS.
Really pleased to find Linux, although didn't find intuitive there was 
loads of documentation that came with it and all the O'Reilly books to 
help a new user figure out what was going on.
These days I don't bother so much as things seem to Just Work but it 
would be nice to have it a bit easier to find out what systemd is doing.


cheers
mick

--
Key ID4BFEBB31

Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[Gene Heskett]

On Tuesday 31 December 2019 02:30:05 ghe wrote:

> > On Dec 30, 2019, at 05:47 PM, Sven Hartge 
> > wrote:
> >
> > Please show the output of
> >
> >systemctl cat YOUR_SERVICE_UNIT
> >
> > This will show all additions and overrides to the unit.
>
> root@test:~# systemctl cat ipfilter
> # /usr/lib/systemd/system/ipfilter.service
> [Unit]
> Description=packetFilter
>
> [Service]
> ExecStart=/etc/ipfilterfiles/ipfilter.sh on
> ExecStop=/etc/ipfilterfiles/ipfilter.sh off
>
> [Install]
> WantedBy=multi-user.target
>
> > Your shell script isn't really daemon, so it is normal to not stay
> > running after it setup the iptables rules.
>
> I guess I misunderstood the term 'daemon.' I thought it was just a
> piece of software that, when run, stays run until it's through -- when
> it's started at boot and has no exit, hangs around in the background
> doing stuff. Unless somebody tells it to stop.
>
> This code has, under the old init system, been thinking it's a daemon
> for a couple decades now. But you're right. On other systemd
> computers, I have to start my local firewall by hand, like I have to
> with BIND on the DNS server.
>
> > I think your unit is missing the following:
> >
> > ,
> >
> > | [Service]
> > | Type=oneshot
> > | RemainAfterExit=yes
> >
> > `
>
> That makes sense. I'll insert those lines and see what happens.
>
> I knew it'd be trivial when it came to light what I was missing.
> Thanks a lot.
>
> (grumble, grumble, systemd, grumble, grumble)
>
> >> And how did that file get in /usr? When I wrote it, it was in
> >> /lib/systemd/system.
> >
> > usr-merge is the keyword here.
>
> What's that? I never heard of that before, and I certainly didn't ask
> for it. One of the reasons I run Debian was that the config stuff is
> all in /etc. And, it goes without saying, stays there.
>
> As I said before, (grumble, grumble, systemd, grumble, grumble). It
> seems to be pretty nicely done system code, but with an absolutely
> abominable user interface. So far, I know of systemd dirs in /lib,
> /etc, and /usr. That's no way to run a *nix railroad.
>
+100 (or more)

> While I have you on the hook, Sven, how/where did you get your systemd
> knowledge? I've looked around, and I haven't seen any mention of what
> you just told me.

I had that same didn't start after a reboot problem, but found this 
script started iptables ok when executed by hand as ./start-iptables 
while root in the /etc/iptables dir.

#!/bin/bash
iptables-restore saved-rules

A executed from /etc/iptables with ./iptables-saveem

It seems to me, that if iptables has been intalled, there ought to be a 
start script in /etc/init.d, or someplace in the /etc/systemd path, but 
there is not such a critter in either path (nothing in /usr, 
but /lib/systemd has 100 or so files) in this stretch install.

This works, but leaves me open until I get around to starting it, so I 
doubt its the approved method.  IMO it ought to be the first active line 
in the ifup script so its active before the net is brought up. 

Thanks.

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[ghe]

On 12/31/19 1:05 AM, Andrei POPESCU wrote:

>> I guess I misunderstood the term 'daemon.' I thought it was just a 
>> piece of software that, when run, stays run until it's through -- when 
>> it's started at boot and has no exit, hangs around in the background 
>> doing stuff. Unless somebody tells it to stop.
> 
> Right. Does your script work like this? I'm asking because typically 
> scripts do their thing and then exit.

Yes, it does. It's a huge (for .sh) program (Python was unavailable at
the time :-) that will, interactively, display and modify the iptables
chains. There are several other .sh and PERL scripts I've written that
do similar things -- intended to be daemons, as I understood it.

> Try systemd.service(5).

In man? I will.

But what I'm really looking for is a comprehensive book on systemd like
the 40 pounder 'Learning Python' or other O'Reilly, etc, books that've
saved my life in the past few years. (I'm more comfortable with dead
trees than I am with screens.)

-- 
Glenn English

Re: On systemd, raspbian and off-topics [was: systemdq]

[tomas]

On Tue, Dec 31, 2019 at 02:08:17PM +0900, 황병희 wrote:
> > I actually do enjoy off-topic tangents, and [...]
> 
> Me too, happy new year tomás ^^^

Happy new year to yo, too (and to all others here). May your dreams
come true, whether you like systemd or not :-)

Cheers
-- t


signature.asc
Description: Digital signature

Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[Andrei POPESCU]

On Ma, 31 dec 19, 00:30:05, ghe wrote:
> 
> I guess I misunderstood the term 'daemon.' I thought it was just a 
> piece of software that, when run, stays run until it's through -- when 
> it's started at boot and has no exit, hangs around in the background 
> doing stuff. Unless somebody tells it to stop.

Right. Does your script work like this? I'm asking because typically 
scripts do their thing and then exit.
 
> This code has, under the old init system, been thinking it's a daemon 
> for a couple decades now. But you're right. On other systemd 
> computers, I have to start my local firewall by hand, like I have to 
> with BIND on the DNS server. 
> 
> > I think your unit is missing the following:
> > 
> > ,
> > | [Service]
> > | Type=oneshot
> > | RemainAfterExit=yes
> > `
> 
> That makes sense. I'll insert those lines and see what happens. 
> 
> I knew it'd be trivial when it came to light what I was missing. Thanks a lot.
> 
> (grumble, grumble, systemd, grumble, grumble)
> 
> >> And how did that file get in /usr? When I wrote it, it was in
> >> /lib/systemd/system.
> > 
> > usr-merge is the keyword here.
> 
> What's that? I never heard of that before, and I certainly didn't ask 
> for it. One of the reasons I run Debian was that the config stuff is 
> all in /etc. And, it goes without saying, stays there.

usr-merge doesn't touch /etc.
 
> As I said before, (grumble, grumble, systemd, grumble, grumble). It 
> seems to be pretty nicely done system code, but with an absolutely 
> abominable user interface. So far, I know of systemd dirs in /lib, 
> /etc, and /usr. That's no way to run a *nix railroad.
 
If your system is usr-merged then /lib, /bin and /sbin are symlinks to 
their counterparts in /usr. Nothing else is affected.

> While I have you on the hook, Sven, how/where did you get your systemd 
> knowledge? I've looked around, and I haven't seen any mention of what 
> you just told me. 

Try systemd.service(5).

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


signature.asc
Description: PGP signature

Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[ghe]

> On Dec 30, 2019, at 05:47 PM, Sven Hartge  wrote:
> 
> Please show the output of
> 
>systemctl cat YOUR_SERVICE_UNIT
> 
> This will show all additions and overrides to the unit.

root@test:~# systemctl cat ipfilter
# /usr/lib/systemd/system/ipfilter.service
[Unit]
Description=packetFilter

[Service]
ExecStart=/etc/ipfilterfiles/ipfilter.sh on
ExecStop=/etc/ipfilterfiles/ipfilter.sh off

[Install]
WantedBy=multi-user.target

> Your shell script isn't really daemon, so it is normal to not stay
> running after it setup the iptables rules.

I guess I misunderstood the term 'daemon.' I thought it was just a piece of 
software that, when run, stays run until it's through -- when it's started at 
boot and has no exit, hangs around in the background doing stuff. Unless 
somebody tells it to stop.

This code has, under the old init system, been thinking it's a daemon for a 
couple decades now. But you're right. On other systemd computers, I have to 
start my local firewall by hand, like I have to with BIND on the DNS server. 

> I think your unit is missing the following:
> 
> ,
> | [Service]
> | Type=oneshot
> | RemainAfterExit=yes
> `

That makes sense. I'll insert those lines and see what happens. 

I knew it'd be trivial when it came to light what I was missing. Thanks a lot.

(grumble, grumble, systemd, grumble, grumble)

>> And how did that file get in /usr? When I wrote it, it was in
>> /lib/systemd/system.
> 
> usr-merge is the keyword here.

What's that? I never heard of that before, and I certainly didn't ask for it. 
One of the reasons I run Debian was that the config stuff is all in /etc. And, 
it goes without saying, stays there.

As I said before, (grumble, grumble, systemd, grumble, grumble). It seems to be 
pretty nicely done system code, but with an absolutely abominable user 
interface. So far, I know of systemd dirs in /lib, /etc, and /usr. That's no 
way to run a *nix railroad.

While I have you on the hook, Sven, how/where did you get your systemd 
knowledge? I've looked around, and I haven't seen any mention of what you just 
told me. 

-- 
Glenn English

Re: On systemd, raspbian and off-topics [was: systemdq]

[황병희]

> I actually do enjoy off-topic tangents, and [...]

Me too, happy new year tomás ^^^

Sincerely, Byung-Hee from South Korea

-- 
^고맙습니다 _地平天成_ 감사합니다_^))//

Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[Sven Hartge]

ghe  wrote:
> On 12/30/19 3:54 PM, Andrei POPESCU wrote:

>> Please show us the full output of
>> 
>> systemctl status YOUR_SERVICE_UNIT

> root@test:~# systemctl status ipfilter
> ● ipfilter.service - packetFilter
>Loaded: loaded (/usr/lib/systemd/system/ipfilter.service; enabled;
> vendor preset: enabled)
>Active: inactive (dead) since Mon 2019-12-30 16:23:33 MST; 1min 41s ago
>   Process: 393 ExecStart=/etc/ipfilterfiles/ipfilter.sh on (code=exited,
> status=0/SUCCESS)
>   Process: 1520 ExecStop=/etc/ipfilterfiles/ipfilter.sh off
> (code=exited, status=0/SUCCESS)
>  Main PID: 393 (code=exited, status=0/SUCCESS)


Please show the output of

systemctl cat YOUR_SERVICE_UNIT

This will show all additions and overrides to the unit.

> Dec 30 16:23:00 test ipfilter.sh[1520]: [ OK ]   Saved HTTP_BLK to
> /etc/ipfilterfiles/savedHTTP_BLK.sh
> Dec 30 16:23:00 test ipfilter.sh[1520]: [ OK ]   Saved POP_BLK to
> /etc/ipfilterfiles/savedPOP_BLK.sh
> Dec 30 16:23:00 test ipfilter.sh[1520]: [ OK ]   Saved NTP_BLK to
> /etc/ipfilterfiles/savedNTP_BLK.sh
> Dec 30 16:23:01 test ipfilter.sh[1520]: [ OK ]   Saved SMTP_BLK to
> /etc/ipfilterfiles/savedSMTP_BLK.sh
> Dec 30 16:23:01 test ipfilter.sh[1520]: [ OK ]  Accepting all slsware
> Dec 30 16:23:33 test root[1751]: packetFilter: off (ACCEPT all) at Mon
> 30 Dec 2019 04:23:33 PM MST
> Dec 30 16:23:33 test ipfilter.sh[1520]: [ OK ]  Accepting all input
> Dec 30 16:23:33 test ipfilter.sh[1520]: [ OK ]  Accepting and
> masquerading all routing
> Dec 30 16:23:33 test ipfilter.sh[1520]: [ OK ]  Accepting all output
> Dec 30 16:23:33 test systemd[1]: ipfilter.service: Succeeded.

>> immediately after boot and also explain what makes you think the service 
>> is not actually running.

Your shell script isn't really daemon, so it is normal to not stay
running after it setup the iptables rules.

See for example the ferm.service doing the same on my system:

,
| ● ferm.service - ferm firewall configuration
|  Loaded: loaded (/lib/systemd/system/ferm.service; enabled; vendor 
preset: enabled)
| Drop-In: /etc/systemd/system/ferm.service.d
|  └─override.conf
|  Active: active (exited) since Fri 2019-10-04 14:37:39 CEST; 2 months 26 
days ago
|Main PID: 1663 (code=exited, status=0/SUCCESS)
|   Tasks: 0 (limit: 19173)
|  Memory: 0B
|  CGroup: /system.slice/ferm.service
`

It also terminates after doing its thing.

I think your unit is missing the following:

,
| [Service]
| Type=oneshot
| RemainAfterExit=yes
`

> And how did that file get in /usr? When I wrote it, it was in
> /lib/systemd/system.

usr-merge is the keyword here.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[ghe]

On 12/30/19 3:54 PM, Andrei POPESCU wrote:

> Please show us the full output of
> 
> systemctl status YOUR_SERVICE_UNIT

root@test:~# systemctl status ipfilter
● ipfilter.service - packetFilter
   Loaded: loaded (/usr/lib/systemd/system/ipfilter.service; enabled;
vendor preset: enabled)
   Active: inactive (dead) since Mon 2019-12-30 16:23:33 MST; 1min 41s ago
  Process: 393 ExecStart=/etc/ipfilterfiles/ipfilter.sh on (code=exited,
status=0/SUCCESS)
  Process: 1520 ExecStop=/etc/ipfilterfiles/ipfilter.sh off
(code=exited, status=0/SUCCESS)
 Main PID: 393 (code=exited, status=0/SUCCESS)

Dec 30 16:23:00 test ipfilter.sh[1520]: [ OK ]   Saved HTTP_BLK to
/etc/ipfilterfiles/savedHTTP_BLK.sh
Dec 30 16:23:00 test ipfilter.sh[1520]: [ OK ]   Saved POP_BLK to
/etc/ipfilterfiles/savedPOP_BLK.sh
Dec 30 16:23:00 test ipfilter.sh[1520]: [ OK ]   Saved NTP_BLK to
/etc/ipfilterfiles/savedNTP_BLK.sh
Dec 30 16:23:01 test ipfilter.sh[1520]: [ OK ]   Saved SMTP_BLK to
/etc/ipfilterfiles/savedSMTP_BLK.sh
Dec 30 16:23:01 test ipfilter.sh[1520]: [ OK ]  Accepting all slsware
Dec 30 16:23:33 test root[1751]: packetFilter: off (ACCEPT all) at Mon
30 Dec 2019 04:23:33 PM MST
Dec 30 16:23:33 test ipfilter.sh[1520]: [ OK ]  Accepting all input
Dec 30 16:23:33 test ipfilter.sh[1520]: [ OK ]  Accepting and
masquerading all routing
Dec 30 16:23:33 test ipfilter.sh[1520]: [ OK ]  Accepting all output
Dec 30 16:23:33 test systemd[1]: ipfilter.service: Succeeded.


> immediately after boot and also explain what makes you think the service 
> is not actually running.

root@test:~# pfil status

 Running on host: test.slsware.net


--- FILTER table---

Chain INPUT (policy ACCEPT 3 packets, 108 bytes)
num   pkts bytes target prot opt in out source
 destination
1   58  5941 ACCEPT tcp  --  *  *   0.0.0.0/0
 0.0.0.0/0tcp dpt:22
25   380 ACCEPT all  --  *  *   216.17.134.0/24
 0.0.0.0/0
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target prot opt in out source
 destination
Chain OUTPUT (policy ACCEPT 8 packets, 488 bytes)
num   pkts bytes target prot opt in out source
 destination
1   52  7719 ACCEPT tcp  --  *  *   0.0.0.0/0
 0.0.0.0/0tcp spt:22
25   380 ACCEPT all  --  *  *   0.0.0.0/0
 216.17.134.0/24

--- NAT table---

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target prot opt in out source
 destination
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target prot opt in out source
 destination
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target prot opt in out source
 destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target prot opt in out source
 destination


iptaples.sh is big shell script I use on all my computers. pfil (packet
filter) is an alias to save a little typing.

Those steps it goes through in the systemctl status command are some of
the steps it goes through when I stop it by hand (pfil stop). This looks
like it's been started, then immediately stopped. The 'pfil status'
display's the state of the iptables firewall.

If it were running, there'd be many lines from 'pfil status' (attached
if you're interested).


The service file:

root@test:/lib/systemd/system# cat /usr/lib/systemd/system/ipfilter.service
[Unit]
Description=packetFilter

[Service]
ExecStart=/etc/ipfilterfiles/ipfilter.sh on
ExecStop=/etc/ipfilterfiles/ipfilter.sh off

[Install]
WantedBy=multi-user.target


And how did that file get in /usr? When I wrote it, it was in
/lib/systemd/system.

And this all on the RPi4.

-- 
Glenn English
Turning it on:

root@test:/lib/systemd/system# pfil on

 Running on host: test.slsware.net

 Initializing the netfilter chains
[ OK ]  Accepting all slsware
[ OK ]  Netfilter chains initialized
 Loading the netfilter chains for outside IP 216.17.134.204
[ OK ]  TCP SMTP (25) on the local nets
[ OK ]  TCP SMTP (25) from almost anywhere
[ OK ]  TCP POP3 (110, 995) from anywhere
[ OK ]  TCP IMAP (143, 993) from anywhere
[ OK ]  UDP DCC (6277) from anywhere
[ OK ]  TCP HTTP (80) from anywhere
[ OK ]  TCP SSH (22) on the local nets
[ OK ]  TCP FTP (21) from anywhere
[ OK ]  TCP HTTPS (443) from anywhere
[ OK ]  TCP RSYNC (873) on the local nets
[ OK ]  TCP AUTH (113) on the local nets
[ OK ]  TCP SMTP on port 537 from anywhere
[ OK ]  UDP RIP-2 (520) on 224.0.0.9 -- the IANA assignment
[ OK ]  UDP NTP (123) from anywhere
[ OK ]  UDP TRACEROUTE (33434) from anywhere
[ OK ]  UDP and TCP DNS (53) from anywhere
[ OK ]  Netfilter chains loaded
 Enabling the netfilter chains
[ OK ]  Netfilter chains enabled
 Starting other iptables daemons (if any)
 Loading the saved 

Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[chris]

Omg another systemd thread jeez

On Mon, Dec 30, 2019, 6:12 PM Andrei POPESCU 
wrote:

> On Lu, 30 dec 19, 15:12:54, ghe wrote:
> > On 12/30/19 1:08 PM, Greg Wooledge wrote:
> >
> > > Did you forget to "enable" it?
> >
> > Nope. It works by hand, and after boot, systemctl status claims it's
> > running. But is isn't.
>
> Please show us the full output of
>
> systemctl status YOUR_SERVICE_UNIT
>
> immediately after boot and also explain what makes you think the service
> is not actually running.
>
> Kind regards,
> Andrei
> --
> http://wiki.debian.org/FAQsFromDebianUser
>

Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]

[Andrei POPESCU]

On Lu, 30 dec 19, 15:12:54, ghe wrote:
> On 12/30/19 1:08 PM, Greg Wooledge wrote:
> 
> > Did you forget to "enable" it?
> 
> Nope. It works by hand, and after boot, systemctl status claims it's
> running. But is isn't.

Please show us the full output of

systemctl status YOUR_SERVICE_UNIT

immediately after boot and also explain what makes you think the service 
is not actually running.

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


signature.asc
Description: PGP signature

Re: On systemd, raspbian and off-topics [was: systemdq]

[Andrei POPESCU]

On Lu, 30 dec 19, 10:01:55, Gene Heskett wrote:
> But it sure would be nice if the manpages were a little more obvious. 
> :) Options seem to be well explained but commonly used examples that 
> one can play with to learn how it works are thin. A good tut that 
> passed as a manpage would likely reduce the objection chatter a lot by 
> showing that it can be a better way to do things.

For a quick start you only need 'systemctl' with the 'status', 'start', 
'stop', 'restart', 'reload', 'enable' and 'disable' commands, possibly 
also 'mask' (didn't need it so far, 'disable' was always sufficient when 
applied correctly[1]).

The man page for 'systemctl' has a detailed example for the 'status' 
command, the only one where the output is not so easy to understand at 
first look.

For more advanced stuff the wiki pages on systemd seem to be a good 
start[2].

[1] a service can also be enabled via a .socket unit and systemd does 
warn if you only disable the .service unit for a service that also has a 
.socket unit.

[2] https://wiki.debian.org/systemd


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


signature.asc
Description: PGP signature

Re: New list for Raspbian? (was: Re: systemdq)

[ghe]

On 12/30/19 1:08 PM, Greg Wooledge wrote:

> Did you forget to "enable" it?

Nope. It works by hand, and after boot, systemctl status claims it's
running. But is isn't.

> See also .

Already saw it :-)

I'm missing something that is going to be patently obvious when I do it.
I've done the things from many web sites, but it doesn't quite work yet.

And O'Reilly doesn't have a book on systemd yet...

-- 
Glenn English

Re: On systemd, raspbian and off-topics [was: systemdq]

[tomas]

On Mon, Dec 30, 2019 at 11:34:43PM +0200, Andrei POPESCU wrote:
> On Lu, 30 dec 19, 10:23:27, to...@tuxteam.de wrote:
> > On Sun, Dec 29, 2019 at 06:57:12PM -0500, Gene Heskett wrote:
> > 
> > > Chasing us off from asking raspbian related questions here, is a lost 
> > > cause because [...]
> > 
> > Please, don't misrepresent me. I *never* "chased anyone off" from
> > asking raspbian [...]

> At the very least posters should state it's not Debian and not send us 
> on possibly wild goose chases.

On this, we do agree fully. It's minimum courtesy, I'd say.

Cheers
-- t


signature.asc
Description: Digital signature

Re: New list for Raspbian? (was: Re: systemdq)

[Andrei POPESCU]

On Lu, 30 dec 19, 10:13:50, rhkra...@gmail.com wrote:
> On Monday, December 30, 2019 08:48:20 AM Greg Wooledge wrote:
> > On Sun, Dec 29, 2019 at 06:57:12PM -0500, Gene Heskett wrote:
> > > Chasing us off from asking raspbian related questions here, is a lost
> > > cause because they don't have a mailing list, but a forum generally
> > > populated by uppity folks, [...]
> > 
> > That does not mean you can post Raspbian problems HERE.
> > 
> > This list is for Debian problems only.
> 
> It would not be that hard to create a new mailing list for raspbian users, 
> maybe over on groups.io (can even be done for free).

The raspbian-devel[1] list is still listed as "active", though the last post is 
from Jan.19.

[1] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/raspbian-devel

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


signature.asc
Description: PGP signature

Re: New list for Raspbian? (was: Re: systemdq)

[Gene Heskett]

On Monday 30 December 2019 15:16:34 Jude DaShiell wrote:

> On Mon, 30 Dec 2019, ghe wrote:
> > Date: Mon, 30 Dec 2019 14:49:36
> > From: ghe 
> > To: debian-user@lists.debian.org
> > Subject: Re: New list for Raspbian? (was: Re: systemdq)
> > Resent-Date: Mon, 30 Dec 2019 20:06:09 + (UTC)
> > Resent-From: debian-user@lists.debian.org
> >
> > Goodness. My asking for a little help with systemd seems to have
> > started the closest thing to a flame war I remember seeing on a
> > Debian mailing list.
> >
> > I apologize for that, but I learned a lot. SSH works now, but I
> > can't get my own *.service file to work at boot (does manually,
> > though), but I now have several things to look for.
> >
> > With this problem, I probably should have asked the systemd-user
> > list, but it doesn't exist. The systemd-devel list does and they say
> > user questions are welcome, but subscribing to it is a real PITA,
> > and the process didn't work for me (the web page kept saying I
> > didn't respond to the Capcha -- there was none).
> >
> >
> > To the subject at hand:
> >
> > On 12/30/19 10:40 AM, rhkra...@gmail.com wrote:
> > > I find forums much less convenient than mail
> > > lists.
> >
> > As do I. That's why I asked the debian-user list. On this list, you
> > ask a question; you usually get a knowledgeable human on the other
> > end with an answer in just a few minutes.
> >
> > So let me add a vote for the suggestion that a raspian-user list
> > would be a good idea. Even though it would likely quickly fill up
> > with people trying to build science fair projects.
> >
> > A systemd-user list would be a good idea too.

Ya got to be kidding, that list has 1 post I couldn't read w/o joining, 
dated in 2017.

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

Re: New list for Raspbian? (was: Re: systemdq)

[Andrei POPESCU]

On Lu, 30 dec 19, 13:14:55, Charles Curley wrote:
> On Mon, 30 Dec 2019 12:49:36 -0700
> ghe  wrote:
> 
> > A systemd-user list would be a good idea too.
> 
> I'll second that.

-1 from me. There's nothing so special about systemd that would require 
a dedicated list.

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


signature.asc
Description: PGP signature

Re: On systemd, raspbian and off-topics [was: systemdq]

[Andrei POPESCU]

On Lu, 30 dec 19, 10:23:27, to...@tuxteam.de wrote:
> On Sun, Dec 29, 2019 at 06:57:12PM -0500, Gene Heskett wrote:
> 
> > Chasing us off from asking raspbian related questions here, is a lost 
> > cause because [...]
> 
> Please, don't misrepresent me. I *never* "chased anyone off" from
> asking raspbian. On the contrary: I think fringe-Deian questions
> to be on topic here, to get a feel on how different Debian derivatives
> relate to each other. But I know there are people who disagree.

At the very least posters should state it's not Debian and not send us 
on possibly wild goose chases.

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


signature.asc
Description: PGP signature

Re: New list for Raspbian? (was: Re: systemdq)

[Charles Curley]

On Mon, 30 Dec 2019 12:49:36 -0700
ghe  wrote:

> A systemd-user list would be a good idea too.

I'll second that.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: New list for Raspbian? (was: Re: systemdq)

[Gene Heskett]

On Monday 30 December 2019 14:49:36 ghe wrote:

> Goodness. My asking for a little help with systemd seems to have
> started the closest thing to a flame war I remember seeing on a Debian
> mailing list.
>
> I apologize for that, but I learned a lot. SSH works now, but I can't
> get my own *.service file to work at boot (does manually, though), but
> I now have several things to look for.
>
> With this problem, I probably should have asked the systemd-user list,
> but it doesn't exist. The systemd-devel list does and they say user
> questions are welcome, but subscribing to it is a real PITA, and the
> process didn't work for me (the web page kept saying I didn't respond
> to the Capcha -- there was none).
>
>
> To the subject at hand:
>
> On 12/30/19 10:40 AM, rhkra...@gmail.com wrote:
> > I find forums much less convenient than mail
> > lists.
>
> As do I. That's why I asked the debian-user list. On this list, you
> ask a question; you usually get a knowledgeable human on the other end
> with an answer in just a few minutes.
>
> So let me add a vote for the suggestion that a raspian-user list would
> be a good idea. Even though it would likely quickly fill up with
> people trying to build science fair projects.
>
> A systemd-user list would be a good idea too.

+10 Glenn, we need a pair of new lists, but I'd name the new debian list 
debian-arm-user, and if it really worked, raspbian might become the 
media mecca it wants to be, leaving those of us who want to do real but 
non-media work using debian on arm hardware, to wag that dog. I don't 
think having raspbian in the list name would do anything but dilute it 
as you alluded to already. There is lots of other arm based hardware 
being peddled besides the r-pi's, and which are sorely lacking in 
non-media support. A real list, supporting debian linux on some of these 
other platforms, could rake in 1000's of new debian arm users rather 
quickly.
 
Cheers Glenn and a better 2020 to all, 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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: New list for Raspbian? (was: Re: systemdq)

[Jude DaShiell]

On Mon, 30 Dec 2019, ghe wrote:

> Date: Mon, 30 Dec 2019 14:49:36
> From: ghe 
> To: debian-user@lists.debian.org
> Subject: Re: New list for Raspbian? (was: Re: systemdq)
> Resent-Date: Mon, 30 Dec 2019 20:06:09 + (UTC)
> Resent-From: debian-user@lists.debian.org
>
> Goodness. My asking for a little help with systemd seems to have started
> the closest thing to a flame war I remember seeing on a Debian mailing list.
>
> I apologize for that, but I learned a lot. SSH works now, but I can't
> get my own *.service file to work at boot (does manually, though), but I
> now have several things to look for.
>
> With this problem, I probably should have asked the systemd-user list,
> but it doesn't exist. The systemd-devel list does and they say user
> questions are welcome, but subscribing to it is a real PITA, and the
> process didn't work for me (the web page kept saying I didn't respond to
> the Capcha -- there was none).
>
>
> To the subject at hand:
>
> On 12/30/19 10:40 AM, rhkra...@gmail.com wrote:
>
> > I find forums much less convenient than mail
> > lists.
>
> As do I. That's why I asked the debian-user list. On this list, you ask
> a question; you usually get a knowledgeable human on the other end with
> an answer in just a few minutes.
>
> So let me add a vote for the suggestion that a raspian-user list would
> be a good idea. Even though it would likely quickly fill up with people
> trying to build science fair projects.
>
> A systemd-user list would be a good idea too.
>
>

-- 

https://groups.io/g/ThePIGuys
may be able to help.

Re: New list for Raspbian? (was: Re: systemdq)

[Kenneth Parker]

On Mon, Dec 30, 2019 at 11:12 AM Eduardo M KALINOWSKI <
edua...@kalinowski.com.br> wrote:

> On seg, 30 dez 2019, rhkramer wrote:
> > It would not be that hard to create a new mailing list for raspbian
> users,
> > maybe over on groups.io (can even be done for free).
>
> There are already support channels for raspbian:
> https://www.raspberrypi.org/forums/ . True, it's a forum, not a
> mailing list, but it's probably better to use that than to split
> support in two places.
>

+1

I find it amusing that some of the Controversies we experience here occur
there also.  For example, one person innocently posted, about how he had
successfully installed Devuan 64 on a Pi 3 [1], and was happy, only to get
harassed by those, on the Forum that thought Raspbian was the only OS to
ever use. (LOL!)  Add to that a heated SystemD "discussion", and I don't
blame the Moderator for shutting down the Thread!

[1] https://www.raspberrypi.org/forums/viewtopic.php?t=170125

Kenneth Parker

P.S.  I am of the "There's room for multiple Init Systems" crowd, even to
maintaining, both Devuan and Debian (Stretch and Buster) Systems.

Re: New list for Raspbian? (was: Re: systemdq)

[Greg Wooledge]

On Mon, Dec 30, 2019 at 12:49:36PM -0700, ghe wrote:
> SSH works now, but I can't
> get my own *.service file to work at boot (does manually, though), but I
> now have several things to look for.

Did you forget to "enable" it?

See also .

Re: New list for Raspbian? (was: Re: systemdq)

[ghe]

Goodness. My asking for a little help with systemd seems to have started
the closest thing to a flame war I remember seeing on a Debian mailing list.

I apologize for that, but I learned a lot. SSH works now, but I can't
get my own *.service file to work at boot (does manually, though), but I
now have several things to look for.

With this problem, I probably should have asked the systemd-user list,
but it doesn't exist. The systemd-devel list does and they say user
questions are welcome, but subscribing to it is a real PITA, and the
process didn't work for me (the web page kept saying I didn't respond to
the Capcha -- there was none).


To the subject at hand:

On 12/30/19 10:40 AM, rhkra...@gmail.com wrote:

> I find forums much less convenient than mail 
> lists.

As do I. That's why I asked the debian-user list. On this list, you ask
a question; you usually get a knowledgeable human on the other end with
an answer in just a few minutes.

So let me add a vote for the suggestion that a raspian-user list would
be a good idea. Even though it would likely quickly fill up with people
trying to build science fair projects.

A systemd-user list would be a good idea too.

-- 
Glenn English

Re: New list for Raspbian? (was: Re: systemdq)

[Gene Heskett]

On Monday 30 December 2019 12:40:14 rhkra...@gmail.com wrote:

> On Monday, December 30, 2019 10:40:42 AM Eduardo M KALINOWSKI wrote:
> > There are already support channels for raspbian:
> > https://www.raspberrypi.org/forums/ . True, it's a forum, not a
> > mailing list, but it's probably better to use that than to split
> > support in two places.
>
> Disclaimer: I don't have a raspberry pi, so am sort of an innocent
> bystander (from the peanut gallery), but I find forums much less
> convenient than mail lists.
>
> I guess to (probabbly mis-) use some terminology from a different
> context, email is "push" and a forum is "pull".

Whatever, the diff is that everyone on the list gets to at least look at 
_all_ the headlines, tapping the + key (I use kmail from TDE) if this 
one has no interest or you can't contribute meaningfull info, and that 
seems to get a lot more "participation". Forums, where you have to 
search for trigger terms, just don't seem to do it, at least for me. I 
have yet to discover a forum that could use the search term new, to show 
you everything since your last visit. Fetchmail OTOH, pulls everything 
new every 2 minutes here.  Lots more realtime conversational.

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: On systemd, raspbian and off-topics [was: systemdq]

[Celejar]

On Mon, 30 Dec 2019 10:23:27 +0100
 wrote:

> On Sun, Dec 29, 2019 at 06:57:12PM -0500, Gene Heskett wrote:
> > On Sunday 29 December 2019 17:19:06 to...@tuxteam.de wrote:
> 
> [...]
> 
> > Unforch Tomas, we are not likely to see any progress toward acceptance of 
> > systemd [...]
> 
> I'm not asking for "acceptance of systemd" or something (FWIW I
> still run a systemd-free Debian Buster here, for a reason!). I'm
> asking for a polite, civilised way of treating each other. And
> hopin this "LP" (sic!) bashing stops. Just treat each other civilly.
> 
> Is that that hard?

+10

I really appreciate this attitude. I rather like systemd myself,
although I have much less expertise in this sort of low-level system
maintenance than you and many others have.

...

> What I really do care for is (a) to express disagreement in a civil
> manner (you don't like systemd? just don't use it, even better: help
> others with your experience. But don't mention LP [1] at every turn
> in the discussion as if he were the Devil incarnate. This is so wrong
> on so many accounts that I don't know where to start). And (b)
> always think that there are ~3000 readers of this list, so do fix
> your subjects when swerving off-topic. And, oh, (c) accept that there
> are other views, and that (gasp!) they might be right.

+10

Celejar

Re: New list for Raspbian? (was: Re: systemdq)

[rhkramer]

On Monday, December 30, 2019 10:40:42 AM Eduardo M KALINOWSKI wrote:
> There are already support channels for raspbian:
> https://www.raspberrypi.org/forums/ . True, it's a forum, not a
> mailing list, but it's probably better to use that than to split
> support in two places.

Disclaimer: I don't have a raspberry pi, so am sort of an innocent bystander 
(from the peanut gallery), but I find forums much less convenient than mail 
lists.

I guess to (probabbly mis-) use some terminology from a different context, 
email is "push" and a forum is "pull".

Re: New list for Raspbian? (was: Re: systemdq)

[Eduardo M KALINOWSKI]

On seg, 30 dez 2019, rhkramer wrote:

It would not be that hard to create a new mailing list for raspbian users,
maybe over on groups.io (can even be done for free).


There are already support channels for raspbian:  
https://www.raspberrypi.org/forums/ . True, it's a forum, not a  
mailing list, but it's probably better to use that than to split  
support in two places.

--
Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Re: New list for Raspbian? (was: Re: systemdq)

[Gene Heskett]

On Monday 30 December 2019 10:13:50 rhkra...@gmail.com wrote:

> On Monday, December 30, 2019 08:48:20 AM Greg Wooledge wrote:
> > On Sun, Dec 29, 2019 at 06:57:12PM -0500, Gene Heskett wrote:
> > > Chasing us off from asking raspbian related questions here, is a
> > > lost cause because they don't have a mailing list, but a forum
> > > generally populated by uppity folks, [...]
> >
> > That does not mean you can post Raspbian problems HERE.
> >
> > This list is for Debian problems only.
>
> It would not be that hard to create a new mailing list for raspbian
> users, maybe over on groups.io (can even be done for free).
>
> I'm not sure how many people from this list would subscribe.
>
> But, this list might tolerate occasional posts of the nature:
>
> <~quote>
> A new post / thread has been posted over on (e.g.,) raspbian-user
> asking the question:  :
>
>* there have been answers, but none seems to solve the problem
>* no one on the list seems to be able to answer
>* 
>
> Help would be appreciated, either on that list or possibly here if it
> seems relevant to debian users.
> 
>
> If help is needed to create such a list, I can probably find time.
>
> groups.io has three tiers of service, including a free one.  Any of
> them will work as a mailing list, iirc, the free one has a limit
> (maybe 1 GB) on things like files, photos, ... (and maybe
> attachments).
>
> It is possible that Debian would allow it to be hosted on
> lists.debian.org.

That would be the obvious place, but I'd think the debian folks might 
have controlling objections.  And raspbian would likely ignore it.

Never hurts to ask though.

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

New list for Raspbian? (was: Re: systemdq)

[rhkramer]

On Monday, December 30, 2019 08:48:20 AM Greg Wooledge wrote:
> On Sun, Dec 29, 2019 at 06:57:12PM -0500, Gene Heskett wrote:
> > Chasing us off from asking raspbian related questions here, is a lost
> > cause because they don't have a mailing list, but a forum generally
> > populated by uppity folks, [...]
> 
> That does not mean you can post Raspbian problems HERE.
> 
> This list is for Debian problems only.

It would not be that hard to create a new mailing list for raspbian users, 
maybe over on groups.io (can even be done for free).

I'm not sure how many people from this list would subscribe.

But, this list might tolerate occasional posts of the nature:

<~quote>
A new post / thread has been posted over on (e.g.,) raspbian-user asking the 
question:  :

   * there have been answers, but none seems to solve the problem
   * no one on the list seems to be able to answer
   * 

Help would be appreciated, either on that list or possibly here if it seems 
relevant to debian users.


If help is needed to create such a list, I can probably find time.

groups.io has three tiers of service, including a free one.  Any of them will 
work as a mailing list, iirc, the free one has a limit (maybe 1 GB) on things 
like files, photos, ... (and maybe attachments).

It is possible that Debian would allow it to be hosted on lists.debian.org.

Re: On systemd, raspbian and off-topics [was: systemdq]

[Gene Heskett]

On Monday 30 December 2019 04:23:27 to...@tuxteam.de wrote:

> On Sun, Dec 29, 2019 at 06:57:12PM -0500, Gene Heskett wrote:
> > On Sunday 29 December 2019 17:19:06 to...@tuxteam.de wrote:
>
> [...]
>
> > Unforch Tomas, we are not likely to see any progress toward
> > acceptance of systemd [...]
>
> I'm not asking for "acceptance of systemd" or something (FWIW I
> still run a systemd-free Debian Buster here, for a reason!). I'm
> asking for a polite, civilised way of treating each other. And
> hopin this "LP" (sic!) bashing stops. Just treat each other civilly.
>
> Is that that hard?
>
> > Chasing us off from asking raspbian related questions here, is a
> > lost cause because [...]
>
> Please, don't misrepresent me. I *never* "chased anyone off" from
> asking raspbian. On the contrary: I think fringe-Deian questions
> to be on topic here, to get a feel on how different Debian derivatives
> relate to each other. But I know there are people who disagree.
>
> [about off-topic tangents]
>
> > I don't like it, helpfull folks like you don't like it. But thats
> > how it actually works.
>
> I actually do enjoy off-topic tangents, and think they belong into
> such general mailing lists as this. If it deviates too far from my
> interests, I just bow out politelly.
>
> What I really do care for is (a) to express disagreement in a civil
> manner (you don't like systemd? just don't use it, even better: help
> others with your experience. But don't mention LP [1] at every turn
> in the discussion as if he were the Devil incarnate. This is so wrong
> on so many accounts that I don't know where to start). And (b)
> always think that there are ~3000 readers of this list, so do fix
> your subjects when swerving off-topic. And, oh, (c) accept that there
> are other views, and that (gasp!) they might be right.
>
> Cheers
>
> [1] he's writing free software for you & me to use as we wish,
>after all, no?
>
> -- tomás

You and I agree that offtopic is still educational which is as it should 
be as long as its still linux. Seeing new stuff mentioned here can and 
has led to some very helpfull learning. And while I disagree with the 
manner that systemd has been bleeding into linux, my attack of the 
author was out of place. My apologies. But it sure would be nice if the 
manpages were a little more obvious. :) Options seem to be well 
explained but commonly used examples that one can play with to learn how 
it works are thin. A good tut that passed as a manpage would likely 
reduce the objection chatter a lot by showing that it can be a better 
way to do things.

Take care Tomas

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: systemdq

[Greg Wooledge]

On Sun, Dec 29, 2019 at 06:57:12PM -0500, Gene Heskett wrote:
> Chasing us off from asking raspbian related questions here, is a lost 
> cause because they don't have a mailing list, but a forum generally 
> populated by uppity folks, [...]

That does not mean you can post Raspbian problems HERE.

This list is for Debian problems only.

Re: systemdq

[Greg Wooledge]

On Sat, Dec 28, 2019 at 02:57:40PM -0700, Charles Curley wrote:
> Debian (not rasbian) seems to put sshd into place at installation time.
> 
> charles@hawk:~$ locate sshd.service
> /etc/systemd/system/sshd.service
> /var/lib/systemd/deb-systemd-helper-enabled/sshd.service
> charles@hawk:~$
> 
> The second one has to be there. The first is optional and overrides the
> second.

I know this has been mentioned once in this gargantual sprawling
thread of lies and incompetence, but I think it needs repeating.

Debian (and probably Raspbian also, but I have no way to know for sure)
ships a unit file named

  ssh.service

Note that there is no 'd' here.

Within this unit file, there is the following line:

  Alias=sshd.service

This means that SOME OF THE TIME, you can get away with calling it
"sshd.service" -- for example when you try to start or stop it.

However, the Alias name does not always work.  Sometimes you must
use the actual name of the unit -- for example, if you try to create
a drop-in directory under /etc/systemd/service/ to tweak it.

Please trust me: you DO NOT under any circumstances want to create a
drop-in directory using the Alias name.  Bad shit happens.  I found
this out the hard way.

Some of you have already observed that there's an
/etc/systemd/system/sshd.service in Debian.  Let's take a closer look
at that:

lrwxrwxrwx 1 root root 31 Apr 10  2017 /etc/systemd/system/sshd.service -> 
/lib/systemd/system/ssh.service

It's not a file.  It's a symlink, and that symlink points to the REAL
unit file with the name "ssh.service" (no "d").  This is what the Alias
line does.  It creates this alternatively-named reference ("sshd.service")
that you can use to start and stop the service, but NOT to configure
it.

There's been a lot of bad advice given in this thread.  It's extremely
hard to undo that.  All I can do is try to point out the truth and the
falsehoods, and hope that people will update their mental caches.

And the moral of all of this is:

  DO NOT POST RASPBIAN ISSUES IN DEBIAN-USER.

Re: systemdq

[Reco]

Hi.

On Mon, Dec 30, 2019 at 10:33:28AM +0200, Andrei POPESCU wrote:
> dpkg would not even warn if one would install packages from one on the 
> other (they are both "armhf"), but the result is hard to predict.

For Raspberry Pi the result was predictable. If a package was providing
a binary executable or a library - it failed with SIGILL.
If a package was providing some kind of arch-independent script - it
worked.

Starting with Raspberry Pi 2 nearly any Debian-provided binaries have
started to work. The exceptions to this rule are packages that depend on
kernel features which are included in Debian, but are missing in
Raspbian, and OpenGL-dependent ones.

Latter are more-or-less operational with Raspberry Pi 3.


> [1] Not sure if/how this applies with current Raspbian releases. Do they 
> still recompile Debian packages? If yes, why?

Yes, they do. Some packages have Raspbian-specific patches (dhcpcd, to
name a few), most are rebuilt "just in case".

Reco

On systemd, raspbian and off-topics [was: systemdq]

[tomas]

On Sun, Dec 29, 2019 at 06:57:12PM -0500, Gene Heskett wrote:
> On Sunday 29 December 2019 17:19:06 to...@tuxteam.de wrote:

[...]

> Unforch Tomas, we are not likely to see any progress toward acceptance of 
> systemd [...]

I'm not asking for "acceptance of systemd" or something (FWIW I
still run a systemd-free Debian Buster here, for a reason!). I'm
asking for a polite, civilised way of treating each other. And
hopin this "LP" (sic!) bashing stops. Just treat each other civilly.

Is that that hard?

> Chasing us off from asking raspbian related questions here, is a lost 
> cause because [...]

Please, don't misrepresent me. I *never* "chased anyone off" from
asking raspbian. On the contrary: I think fringe-Deian questions
to be on topic here, to get a feel on how different Debian derivatives
relate to each other. But I know there are people who disagree.

[about off-topic tangents]

> I don't like it, helpfull folks like you don't like it. But thats how it 
> actually works.

I actually do enjoy off-topic tangents, and think they belong into
such general mailing lists as this. If it deviates too far from my
interests, I just bow out politelly.

What I really do care for is (a) to express disagreement in a civil
manner (you don't like systemd? just don't use it, even better: help
others with your experience. But don't mention LP [1] at every turn
in the discussion as if he were the Devil incarnate. This is so wrong
on so many accounts that I don't know where to start). And (b)
always think that there are ~3000 readers of this list, so do fix
your subjects when swerving off-topic. And, oh, (c) accept that there
are other views, and that (gasp!) they might be right.

Cheers

[1] he's writing free software for you & me to use as we wish,
   after all, no?

-- tomás


signature.asc
Description: Digital signature

Re: systemdq

[Andrei POPESCU]

On Du, 29 dec 19, 18:57:12, Gene Heskett wrote:
> On Sunday 29 December 2019 17:19:06 to...@tuxteam.de wrote:
> 
> > On Sun, Dec 29, 2019 at 05:11:18PM -0500, chris wrote:
> > > There's nothing wrong with not being a fan of systemd.
> >
> > Absolutely not. Myself, I'm not a fan either.
> >
> > > It's good to let people know there's a active community that isn't
> > > overly impressed [...]
> >
> > But what I definitely don't like either is this dramatization.
> >
> > My wish would be that we, the non-fans and the fans of systemd
> > work together in peace. That's all.
>
> Unforch Tomas, we are not likely to see any progress toward acceptance 
> of systemd until some means of eliciting a meaningfull error message 
> from it comes into existence. 

Could you please provide some examples?

> LP must lay awake nights thinking up ways to makes its output totally 
> unrelated to whats wrong.

I tend to avoid attributing any kind of intention to other people, 
especially ones I've never met.

> Chasing us off from asking raspbian related questions here, is a lost 
> cause because they don't have a mailing list, but a forum generally 
> populated by uppity folks, who when you think you are about to get an 
> answer to your problem, decide to declare the conversation has drifted 
> off topic and refuse to further participate in the discussion, leaving 
> you hanging for a real answer.  So while we do take our questions there, 
> we are forced, language barrier, whatever, to come back here, starting 
> yet another new thread in hopes we will get a usable answer.
> 
> I don't like it, helpfull folks like you don't like it. But thats how it 
> actually works.

From what I see here on d-u you tend to write some posts with maybe 10% 
relevant content and 90% totally unrelated to the issue being discussed 
(while the issue itself might already be off-topic).

One of a forum moderator's job is exactly to take action on such 
occurrences.


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


signature.asc
Description: PGP signature

Re: systemdq

[Andrei POPESCU]

On Du, 29 dec 19, 15:01:21, Jonas Smedegaard wrote:
> Quoting Andrei POPESCU (2019-12-29 14:21:30)
> > 
> > Raspbian (note the 'B') was created because Debian's armhf port requires 
> > an ARMv7 processor, whereas the original Raspberry Pi (Raspberry Pi 1 
> > model B) is ARMv6.
> 
> Raspbian ports are *different* from Debian but possibly use same names. 
> Super confusing at a low level, causing those unaware of the low level 
> differences to clutter further discussions with confusing potentially 
> wrong or misleading suggestions and assumptions.

To expand a little bit on that, the original Raspbian had to 
recompile[1] Debian's armhf port so the packages work on ARMv6 
(Raspberry Pi 1, model B).

dpkg would not even warn if one would install packages from one on the 
other (they are both "armhf"), but the result is hard to predict.

[1] Not sure if/how this applies with current Raspbian releases. Do they 
still recompile Debian packages? If yes, why? What other changes are 
done to it? etc.

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


signature.asc
Description: PGP signature

Re: systemdq

[Andrei POPESCU]

On Du, 29 dec 19, 11:23:33, Gene Heskett wrote:
> On Sunday 29 December 2019 08:21:30 Andrei POPESCU wrote:
> >
> > Debian also has an armhf port[1].
> 
> Not at all obvious from the available downloads selections.

I can only guess you are expecting to find ready-made images.

Considering the variety of ARM-based boards available providing images 
for each and every one that is supported by Debian would be unrealistic.

With Debian being The Universal Operating System it provides "only" the 
necessary pieces and tools to install it.

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


signature.asc
Description: PGP signature

Re: systemdq [Solved]

[Andrei POPESCU]

On Du, 29 dec 19, 14:57:19, ghe wrote:
> 
> Amazing. I'm a self-taught *nix geek, but I've never seen a release
> without SSH. Not since I figured out what SSH is, anyway. Makes me
> question the sanity of the otherwise quite rational 'Pi folks.

Depending on what you mean by "release" Debian doesn't include SSH by 
default. One has to explicitly request it during the installation 
process.

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


signature.asc
Description: PGP signature

Re: systemdq [Solved]

[Andrei POPESCU]

On Du, 29 dec 19, 20:21:48, Reco wrote:
> On Sun, Dec 29, 2019 at 09:40:29AM -0700, ghe wrote:
> > Somebody just forgot to enable SSH while preparing the Raspian Buster
> > release, it looks like.
> 
> Nope. It was deliberate - [1] (note the "ssh" part).
> 
> 
> > And I didn't know enough about systemd to
> > realize that was what the error message was trying to tell me.
> 
> Reading error messages is not a viable substitute to reading the
> documentation. At least the distribution one.
> 
> Small "problems" such as this "ssh-sshd" discrepancy is the reason
> Raspbian is frowned upon here. It's close to Debian yes, except for such
> small yet fundamental parts, which makes it different to Debian.

Except that I was looking at the unit file in Debian ;)

The only difference appears to be that sshd is disabled by default in 
Raspbian.

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


signature.asc
Description: PGP signature

Re: systemdq [Solved]

[Reco]

On Sun, Dec 29, 2019 at 02:57:19PM -0700, ghe wrote:
> On 12/29/19 10:21 AM, Reco wrote:
> 
> > On Sun, Dec 29, 2019 at 09:40:29AM -0700, ghe wrote:
> >> Somebody just forgot to enable SSH while preparing the Raspian Buster
> >> release, it looks like.
> > 
> > Nope. It was deliberate - [1] (note the "ssh" part).
> 
> Amazing. I'm a self-taught *nix geek, but I've never seen a release
> without SSH.

Ubuntu folks used to ship their desktop distribution without a ssh
daemon. Many LiveCD distributions do the same.


> Not since I figured out what SSH is, anyway. Makes me
> question the sanity of the otherwise quite rational 'Pi folks.

If you ship a distribution with a well-known username/password pair,
then giving a remote access to a user by default is not a good idea.
Especially if your distribution is "user-firendly".


> > Reading error messages is not a viable substitute to reading the
> > documentation. At least the distribution one.
> 
> Look. The problem was with the lame systemd error message. It didn't
> provide enough info to figure out how to correct my action.  And I did
> look for dox. I looked for systemd commands, and didn't find anything
> useful. That's why I asked the list. What I needed was a little help
> from somebody who knows systemd.

Systemd is an enigmatic beast, written by enterprise folks (RH/IBM) for
the enterprise folks to solve enterprise needs.
So of course error messages told just about anything but the problem you
were facing.


> When I try to use a CLI program from the 'apt' collection as a user, the
> error message says 'Are you root?' -- useful information.

... and "apt" was written by the humans for the humans. The difference
is obvious.


> If the systemd message had said something like "A unit file isn't
> enabled' or something like that, I probably would have found the
> solution. After a couple responses from the list, I had an idea of how
> to look up a solution. And in 5 minutes, all was well.

See above.


> > Small "problems" such as this "ssh-sshd" discrepancy is the reason
> > Raspbian is frowned upon here. It's close to Debian yes, except for such
> > small yet fundamental parts, which makes it different to Debian.
> 
> I didn't know that. They claim it's the same (with a peculiar /boot
> directory), and in the time I've been using 'Pis, I've never seen one do
> anything different from a Debian box.

The people see ".deb" file extension and think "gee, it's Debian".
It's not.

Reco

Re: systemdq [Solved]

[David Wright]

On Sun 29 Dec 2019 at 14:57:19 (-0700), ghe wrote:
> On 12/29/19 10:21 AM, Reco wrote:
> > On Sun, Dec 29, 2019 at 09:40:29AM -0700, ghe wrote:
> >> Somebody just forgot to enable SSH while preparing the Raspian Buster
> >> release, it looks like.
> > 
> > Nope. It was deliberate - [1] (note the "ssh" part).
> 
> Amazing. I'm a self-taught *nix geek, but I've never seen a release
> without SSH. Not since I figured out what SSH is, anyway. Makes me
> question the sanity of the otherwise quite rational 'Pi folks.
> 
> > Reading error messages is not a viable substitute to reading the
> > documentation. At least the distribution one.
> 
> Look. The problem was with the lame systemd error message. It didn't
> provide enough info to figure out how to correct my action. And I did
> look for dox. I looked for systemd commands, and didn't find anything
> useful. That's why I asked the list. What I needed was a little help
> from somebody who knows systemd.
> 
> When I try to use a CLI program from the 'apt' collection as a user, the
> error message says 'Are you root?' -- useful information.
> 
> If the systemd message had said something like "A unit file isn't
> enabled' or something like that, I probably would have found the
> solution. After a couple responses from the list, I had an idea of how
> to look up a solution. And in 5 minutes, all was well.
> 
> > Small "problems" such as this "ssh-sshd" discrepancy is the reason
> > Raspbian is frowned upon here. It's close to Debian yes, except for such
> > small yet fundamental parts, which makes it different to Debian.
> 
> I didn't know that. They claim it's the same (with a peculiar /boot
> directory), and in the time I've been using 'Pis, I've never seen one do
> anything different from a Debian box.
> 
> With this trouble, though, there was no difference between Debian and
> Raspian. Same systemd, same .system files, same SSH, same systemd
> command to get it started.
> 
> Why it was disabled is a matter for another discussion...

I thought the answer was pretty obvious and is explained on their
Security Page which has a link on [1] (the earlier reference):
https://www.raspberrypi.org/documentation/configuration/security.md
It appears that one of the important differences between Debian and
PIs is that you install a unique OS with Debian, in contrast to PIs
which receive a cloned image. So an installed, but un-reconfigured,
PI is completely insecure: sshd would be a wide-open invitation.

Cheers,
David.

Re: systemdq

[Gene Heskett]

On Sunday 29 December 2019 17:19:06 to...@tuxteam.de wrote:

> On Sun, Dec 29, 2019 at 05:11:18PM -0500, chris wrote:
> > There's nothing wrong with not being a fan of systemd.
>
> Absolutely not. Myself, I'm not a fan either.
>
> > It's good to let people know there's a active community that isn't
> > overly impressed [...]
>
> But what I definitely don't like either is this dramatization.
>
> My wish would be that we, the non-fans and the fans of systemd
> work together in peace. That's all.
>
> Cheers
> -- tomás

Unforch Tomas, we are not likely to see any progress toward acceptance of 
systemd until some means of eliciting a meaningfull error message from 
it comes into existence. LP must lay awake nights thinking up ways to 
makes its output totally unrelated to whats wrong.

Chasing us off from asking raspbian related questions here, is a lost 
cause because they don't have a mailing list, but a forum generally 
populated by uppity folks, who when you think you are about to get an 
answer to your problem, decide to declare the conversation has drifted 
off topic and refuse to further participate in the discussion, leaving 
you hanging for a real answer.  So while we do take our questions there, 
we are forced, language barrier, whatever, to come back here, starting 
yet another new thread in hopes we will get a usable answer.

I don't like it, helpfull folks like you don't like it. But thats how it 
actually works.

Thanks Tomas.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: systemdq

[tomas]

On Sun, Dec 29, 2019 at 05:11:18PM -0500, chris wrote:
> There's nothing wrong with not being a fan of systemd.

Absolutely not. Myself, I'm not a fan either.

> It's good to let people know there's a active community that isn't
> overly impressed [...]

But what I definitely don't like either is this dramatization.

My wish would be that we, the non-fans and the fans of systemd
work together in peace. That's all.

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: systemdq

[chris]

There's nothing wrong with not being a fan of systemd. It's good to let
people know there's a active community that isn't overly impressed and the
link also shows that recent poll shows its quite popular position that
there should be alternatives supported. Thankfully it's still possible to
have a clean system that's systemd-free

On Sun, Dec 29, 2019, 4:30 AM  wrote:

> On Sat, Dec 28, 2019 at 08:38:25PM -0500, chris wrote:
> > dont worry the resistance to systemd is still strong not everyone drinks
> > the kool aid
>
> What I don't understand is why you have to put this under such
> antagonistic terms.
>
> Cheers
> -- tomás
>

Re: systemdq [Solved]

[ghe]

On 12/29/19 10:21 AM, Reco wrote:

> On Sun, Dec 29, 2019 at 09:40:29AM -0700, ghe wrote:
>> Somebody just forgot to enable SSH while preparing the Raspian Buster
>> release, it looks like.
> 
> Nope. It was deliberate - [1] (note the "ssh" part).

Amazing. I'm a self-taught *nix geek, but I've never seen a release
without SSH. Not since I figured out what SSH is, anyway. Makes me
question the sanity of the otherwise quite rational 'Pi folks.

> Reading error messages is not a viable substitute to reading the
> documentation. At least the distribution one.

Look. The problem was with the lame systemd error message. It didn't
provide enough info to figure out how to correct my action. And I did
look for dox. I looked for systemd commands, and didn't find anything
useful. That's why I asked the list. What I needed was a little help
from somebody who knows systemd.

When I try to use a CLI program from the 'apt' collection as a user, the
error message says 'Are you root?' -- useful information.

If the systemd message had said something like "A unit file isn't
enabled' or something like that, I probably would have found the
solution. After a couple responses from the list, I had an idea of how
to look up a solution. And in 5 minutes, all was well.

> Small "problems" such as this "ssh-sshd" discrepancy is the reason
> Raspbian is frowned upon here. It's close to Debian yes, except for such
> small yet fundamental parts, which makes it different to Debian.

I didn't know that. They claim it's the same (with a peculiar /boot
directory), and in the time I've been using 'Pis, I've never seen one do
anything different from a Debian box.

With this trouble, though, there was no difference between Debian and
Raspian. Same systemd, same .system files, same SSH, same systemd
command to get it started.

Why it was disabled is a matter for another discussion...

-- 
Glenn English

Re: systemdq [Solved]

[Reco]

On Sun, Dec 29, 2019 at 09:40:29AM -0700, ghe wrote:
> Somebody just forgot to enable SSH while preparing the Raspian Buster
> release, it looks like.

Nope. It was deliberate - [1] (note the "ssh" part).


> And I didn't know enough about systemd to
> realize that was what the error message was trying to tell me.

Reading error messages is not a viable substitute to reading the
documentation. At least the distribution one.

Small "problems" such as this "ssh-sshd" discrepancy is the reason
Raspbian is frowned upon here. It's close to Debian yes, except for such
small yet fundamental parts, which makes it different to Debian.

Reco

[1] https://www.raspberrypi.org/documentation/remote-access/ssh/

Re: systemdq [Solved]

[Curt]

On 2019-12-29, ghe  wrote:
> On 12/29/19 7:07 AM, Andrei POPESCU wrote:
>
>> The correct solution to your problem would have been:
>> 
>> systemctl enable ssh
>
> Exactly.
>

Right. Thanks for clearing that up!

-- 
"J'ai pour me guérir du jugement des autres toute la distance qui me sépare de
moi." Antonin Artaud

Re: systemdq [Solved]

[ghe]

On 12/29/19 7:07 AM, Andrei POPESCU wrote:

> The correct solution to your problem would have been:
> 
> systemctl enable ssh

Exactly.

The ssh.service files are identical on Debian Buster (this box) and on
Raspian Buster (the RPi4 over there). As is the list of ssh* files --
was before I created sshd.service on the RPi, anyway.

Somebody just forgot to enable SSH while preparing the Raspian Buster
release, it looks like. And I didn't know enough about systemd to
realize that was what the error message was trying to tell me.

-- 
Glenn English

Re: systemdq

[Gene Heskett]

On Sunday 29 December 2019 08:21:30 Andrei POPESCU wrote:

> On Sb, 28 dec 19, 12:06:25, Gene Heskett wrote:
> > On Saturday 28 December 2019 11:08:20 ghe wrote:
> > > On 12/27/19 5:02 PM, Nektarios Katakis wrote:
> > > > Have you tried removing openssh-server package and reinstalling
> > > > it?
> > >
> > > Another hopefully good suggestion. Thanks, and I'll try it.
> > >
> > > > If you re using any version of Debian
> > >
> > > Raspian Buster.
> >
> > One problem, raspian buster is armhf, debian is arm64.
>
> Debian also has an armhf port[1].

Not at all obvious from the available downloads selections.

> Raspbian (note the 'B') was created because Debian's armhf port
> requires an ARMv7 processor, whereas the original Raspberry Pi
> (Raspberry Pi 1 model B) is ARMv6.
>
> [1] https://www.debian.org/ports/#portlist-released
>
> Kind regards,
> Andrei


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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: systemdq [Solved]

[Andrei POPESCU]

On Sb, 28 dec 19, 15:07:27, ghe wrote:
> Trivial in retrospect.
> 
> There were several ssh* files in /lib/systemd/service. None named sshd*.
> I copied the one named ssh.service to sshd.service, enabled it,
> rebooted, and there is was.

For the archives, the Debian package only ships the unit 'ssh.service' 
(in line with '/etc/init.d/ssh'), which contains an 'Alias=sshd'.

As per systemd.unit(5) aliases are only effective when the unit is 
enabled.

The correct solution to your problem would have been:

systemctl enable ssh

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


signature.asc
Description: PGP signature

Re: systemdq

[Jonas Smedegaard]

Quoting Andrei POPESCU (2019-12-29 14:21:30)
> On Sb, 28 dec 19, 12:06:25, Gene Heskett wrote:
> > On Saturday 28 December 2019 11:08:20 ghe wrote:
> > 
> > > On 12/27/19 5:02 PM, Nektarios Katakis wrote:
> > > > Have you tried removing openssh-server package and reinstalling it?
> > >
> > > Another hopefully good suggestion. Thanks, and I'll try it.
> > >
> > > > If you re using any version of Debian
> > >
> > > Raspian Buster.
> > 
> > One problem, raspian buster is armhf, debian is arm64.
> 
> Debian also has an armhf port[1].
> 
> Raspbian (note the 'B') was created because Debian's armhf port requires 
> an ARMv7 processor, whereas the original Raspberry Pi (Raspberry Pi 1 
> model B) is ARMv6.

Thanks a lot for mentioning loudly which system is used.

Raspbian is not Debian.  Please discuss Raspbian-specific issues in 
Raspbian forums.

Feel free to discuss issues here which are same on Debian and 
derivatives of Debian, but as soon as that is suspected to not be the 
case - as is the case here - check that the issue is repeatable with 
Debian, or stop discuss it further here.

Reason for that is that it is super confusing and leads to a lot of 
noise and wrong assumptions to discuss partly incompatible systems.

"armel" and "armhf" and "arm64" are *Debian* names for their ports.

Raspbian ports are *different* from Debian but possibly use same names. 
Super confusing at a low level, causing those unaware of the low level 
differences to clutter further discussions with confusing potentially 
wrong or misleading suggestions and assumptions.

Please don't.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: systemdq

[Andrei POPESCU]

On Sb, 28 dec 19, 12:06:25, Gene Heskett wrote:
> On Saturday 28 December 2019 11:08:20 ghe wrote:
> 
> > On 12/27/19 5:02 PM, Nektarios Katakis wrote:
> > > Have you tried removing openssh-server package and reinstalling it?
> >
> > Another hopefully good suggestion. Thanks, and I'll try it.
> >
> > > If you re using any version of Debian
> >
> > Raspian Buster.
> 
> One problem, raspian buster is armhf, debian is arm64.

Debian also has an armhf port[1].

Raspbian (note the 'B') was created because Debian's armhf port requires 
an ARMv7 processor, whereas the original Raspberry Pi (Raspberry Pi 1 
model B) is ARMv6.

[1] https://www.debian.org/ports/#portlist-released

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


signature.asc
Description: PGP signature

Re: systemdq [Solved]

[Andrei POPESCU]

On Sb, 28 dec 19, 15:07:27, ghe wrote:
> Trivial in retrospect.
> 
> There were several ssh* files in /lib/systemd/service. None named sshd*.
> I copied the one named ssh.service to sshd.service, enabled it,
> rebooted, and there is was.
> 
> An interesting question is why things are different in Raspian Stretch

Because they can :)

> on a 3+. For the time being, I'll just blame the RPi4 OS/motherboard. Or me.

Hardware doesn't matter here.

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


signature.asc
Description: PGP signature

Re: systemdq

[tomas]

On Sat, Dec 28, 2019 at 08:38:25PM -0500, chris wrote:
> dont worry the resistance to systemd is still strong not everyone drinks
> the kool aid

What I don't understand is why you have to put this under such
antagonistic terms.

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: systemdq

[chris]

dont worry the resistance to systemd is still strong not everyone drinks
the kool aid

https://linux.slashdot.org/story/19/12/08/2131220/debian-begins-voting-on-supporting-non-systemd-init-options

https://www.debian.org/vote/2019/vote_002#textb


On Fri, Dec 27, 2019 at 6:40 PM ghe  wrote:

> SSH isn't starting at boot on my server. When I try to set it to do
> that, systemd says it can't do that 'without a command.'
>
> What kind of command makes it happy? Where does it need to be?
>
> (I've futzed with the ssh file in /etc/default, even entered a command:
> (qwerty="42" -- it wasn't impressed). I looked around on the web (lots
> of info about systemd commands, but nothing about what I need.)
>
> Help??
>
> --
> Glenn English
>
>

Re: systemdq

[ghe]

On 12/28/19 2:57 PM, Charles Curley wrote:

> Oddly enough, the sshd package does not provide sshd.service as a file
> at all, but may create it as part of the installation process. It does
> provide ssh.service. 

I haven't looked at the Debian unit files, but SSH and SSHD both seem to
be in the Raspian ssh.service file. I suspect I would have been OK
enabling the plain old SSH file.

> This leads me to wonder if something is not right
> with the rasbian package.

Not a big surprise to those who've spent some time fighting with the 4.

> Do you have both the server and the client installed? On Debian, you
> need openssh-client and openssh-server.

Yes. All is working as expected now.

-- 
Glenn English

Re: systemdq [Solved]

[ghe]

Trivial in retrospect.

There were several ssh* files in /lib/systemd/service. None named sshd*.
I copied the one named ssh.service to sshd.service, enabled it,
rebooted, and there is was.

An interesting question is why things are different in Raspian Stretch
on a 3+. For the time being, I'll just blame the RPi4 OS/motherboard. Or me.

Thanks all.

-- 
Glenn English

Re: systemdq

[Linux-Fan]

ghe writes:


>>Have you tried commands of this sort?

# systemctl enable sshd.service
# systemctl start sshd.service
# systemctl status sshd.service

>From asking it to start at boot:

Failed to save action : Systemd service ssh cannot be created unless a
command is given

Trying the suggested commands:

Failed to enable unit: Unit file sshd.service does not exist.

Failed to start sshd.service: Unit sshd.service not found.

Unit sshd.service could not be found.


Now that are some "good" error messages :)

My next step would be to check were the unit is gone (might save the time to
create one). On my system (not Rapsbian, but Debian 10.2 "Buster"), one can
use these commands:

$ systemctl | grep ssh
ssh.service loaded active running   OpenBSD Secure Shell server

If `ssh.service` is present in `systemctl` output, it might be interesting
to give the enable/start/status sequence another try with `sshd.service`
replaced by `ssh.service`?

$ dpkg -L openssh-server
[...]
/etc/init.d/ssh
[...]
/lib
/lib/systemd
/lib/systemd/system
/lib/systemd/system/rescue-ssh.target
/lib/systemd/system/ssh.service
/lib/systemd/system/ssh.socket
/lib/systemd/system/ssh@.service
[...]

This indicates that the actual unit name is `ssh.service` although on my
system, `systemctl status sshd.service` (with additional `d`) works just as
well :)

It would be interesting to see, if the files are also present on the system
which produces the error messages mentioned above. If no `.service` files
can be identified this way, it would be interesting to check the version and
origin of the `openssh-server` package like this (with the output from my
system included as an example):

$ apt-cache policy openssh-server
openssh-server:
  Installed: 1:7.9p1-10+deb10u1
  Candidate: 1:7.9p1-10+deb10u1
  Version table:
 *** 1:7.9p1-10+deb10u1 500
500 http://security.debian.org buster/updates/main amd64 
Packages
500 file:/fs/e01/normal/debianmirror/cnt buster/main amd64 
Packages
100 /var/lib/dpkg/status

HTH
Linux-Fan


pgpNaKqxO9sGT.pgp
Description: PGP signature

Re: systemdq

[Charles Curley]

On Sat, 28 Dec 2019 14:15:36 -0700
ghe  wrote:

> >>Have you tried commands of this sort?  
> 
> # systemctl enable sshd.service
> # systemctl start sshd.service
> # systemctl status sshd.service
> 
> >From asking it to start at boot:  
> 
> Failed to save action : Systemd service ssh cannot be created unless a
> command is given
> 
> 
> Trying the suggested commands:
> 
> Failed to enable unit: Unit file sshd.service does not exist.
> 
> Failed to start sshd.service: Unit sshd.service not found.
> 
> Unit sshd.service could not be found.

That seems pretty unambiguous to me. You don't have the file
sshd.service where systemd can find it.

> 
> > Have you tried removing openssh-server package and reinstalling it?
> > If you re using any version of Debian the default
> > installation comes with sane defaults and it leaves the service
> > enabled and running.  
> 
> Reinstalling (from an RPi mirror) did nothing. Trying to get it
> started at boot gave the same error message as before.

Debian (not rasbian) seems to put sshd into place at installation time.

charles@hawk:~$ locate sshd.service
/etc/systemd/system/sshd.service
/var/lib/systemd/deb-systemd-helper-enabled/sshd.service
charles@hawk:~$

The second one has to be there. The first is optional and overrides the
second.

Oddly enough, the sshd package does not provide sshd.service as a file
at all, but may create it as part of the installation process. It does
provide ssh.service. This leads me to wonder if something is not right
with the rasbian package.

Do you have both the server and the client installed? On Debian, you
need openssh-client and openssh-server.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: systemdq

[ghe]

>>Have you tried commands of this sort?

# systemctl enable sshd.service
# systemctl start sshd.service
# systemctl status sshd.service

>From asking it to start at boot:

Failed to save action : Systemd service ssh cannot be created unless a
command is given


Trying the suggested commands:

Failed to enable unit: Unit file sshd.service does not exist.

Failed to start sshd.service: Unit sshd.service not found.

Unit sshd.service could not be found.

> Have you tried removing openssh-server package and reinstalling it?
> If you re using any version of Debian the default
> installation comes with sane defaults and it leaves the service
> enabled and running.

Reinstalling (from an RPi mirror) did nothing. Trying to get it started
at boot gave the same error message as before.


My problem was the lame error message -- there are lots of commands on
my server. The suggestions from the list gave me enough info that I feel
I have some things to look after. Looks like creating an sshd.service
unit file would be a good idea.


I was also glad to see that Gene had gone back to Raspian -- my next
step was going to be installing Genuine Debian. Raspian on the RPi4 is,
IMHO, less than stable.

-- 
Glenn English

Re: systemdq

[Gene Heskett]

On Saturday 28 December 2019 12:47:16 Curt wrote:

> On 2019-12-28, Gene Heskett  wrote:
> > On Saturday 28 December 2019 11:08:20 ghe wrote:
> >> On 12/27/19 5:02 PM, Nektarios Katakis wrote:
> >> > Have you tried removing openssh-server package and reinstalling
> >> > it?
> >>
> >> Another hopefully good suggestion. Thanks, and I'll try it.
> >>
> >> > If you re using any version of Debian
> >>
> >> Raspian Buster.
> >
> > One problem, raspian buster is armhf, debian is arm64.
>
> I was going to say--but didn't!--that the OP had merely provided a
> bunch of prose ("try to set" etc.) and no genuine technical detail
> (viz. a cut-and-paste of input/output from a terminal session) in his
> problem presentation, so that even Carnac the Magnificent in his prime
> would fail to divine where the error might lie. Then he revealed
> (because the whole process should be like pulling teeth--if they don't
> fall out "naturally," if haphazardly, that is) he was using Raspian
> rather than Debian, and I thought it was the addition of insult to
> injury.
>
> Maybe 'sshd -t' would disclose some snafu in the config (a stray "-"
> without an argument)?
>
Your guess is as good as mine, but I do know of a combination of the 2, 
is in one case an instant pi crasher, that of installing the armhf 
version of the amanda client, on the debian buster arm64 install will 
crash the whole maryann about 2 seconds after the server asks the client 
for an estimate. And it does it without so much as a by-by in the logs. 
That same client, installed on a raspian (armhf) install has been 
running flawlessly for a couple weeks now.

Maybe not, but all the clues point to the debian repo's identical version 
of the amanda client not haveing been rebuilt with arm64 flags set when 
debian changed the architecture of the rpi4 to arm64 from armhf with the 
buster release.  This lets the debian-arm boot useing grub! debian-arm 
ran just as stably for me until I tried to add it to my backup here.

Once I discovered debian-arm was now an arm64 build, I switched back to 
the raspbian build because its smaller armhf stack frame=reduced 
latency, so I stepped up a few releases of the rt kernel, to make sure I 
had the latest video drivers, built it and installed it, worked 
reasonably well reporting glxgears at near 60 fps even when pulled to 
full screen, so I dd a git clone of linuxcnc, pulled in the missing deps 
as the make discovered them, and there was quite a list that 
dpkg-chkbuilddeps did not find, but eventually it did build linuxcnc as 
debs, I installed that and its running an 11x54 Sheldon lathe 
flawlessly, with video fps's right close to 55.  The pi3 only manages 
video fps's in the 1.5-2.5 range running build from the same code, so 
that is a huge diff.

All this of course took place on an SSD plugged into one of the usb-3 
ports of the rpi-4 once it was installed, no way was I going to subject 
the boot u-sd to that abuse.

The only niggle in the linuxcnc operation now is a slight stutter in jog 
motions from the keyboard arrow keys, which does NOT manifest itself 
running gcode or MDI driven moves. I can live with that.
 
You can get that kernel, and the linuxcnc debs from my web site, add 
lathe-stf to the link in the sig, you'll see a linuxcnc4rpi4 link, click 
on that and you can dl it all, but my uplink is slow.  Poor boy net 
connection. I can get gigabyte, for another $30 a month.

If you can't get to it, I have around 35 search bots blocked with 
iptables useing /24 syntax. Let me know your net address and I'll make 
sure your aren't blocked. Most of the bots didn't bother me, just 
indexing my site, till I put that up, then they downloaded my whole site 
repeatedly which was a DDOS because of my limited uplink bandwidth.

> > Cheers, Gene Heskett


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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: systemdq

[Curt]

On 2019-12-28, Gene Heskett  wrote:
> On Saturday 28 December 2019 11:08:20 ghe wrote:
>
>> On 12/27/19 5:02 PM, Nektarios Katakis wrote:
>> > Have you tried removing openssh-server package and reinstalling it?
>>
>> Another hopefully good suggestion. Thanks, and I'll try it.
>>
>> > If you re using any version of Debian
>>
>> Raspian Buster.
>
> One problem, raspian buster is armhf, debian is arm64.

I was going to say--but didn't!--that the OP had merely provided a bunch
of prose ("try to set" etc.) and no genuine technical detail (viz. a
cut-and-paste of input/output from a terminal session) in his problem
presentation, so that even Carnac the Magnificent in his prime would
fail to divine where the error might lie. Then he revealed (because the
whole process should be like pulling teeth--if they don't fall out
"naturally," if haphazardly, that is) he was using Raspian rather than
Debian, and I thought it was the addition of insult to injury.

Maybe 'sshd -t' would disclose some snafu in the config (a stray "-"
without an argument)?

> Cheers, Gene Heskett


-- 
"J'ai pour me guérir du jugement des autres toute la distance qui me sépare de
moi." Antonin Artaud

Re: systemdq

[Gene Heskett]

On Saturday 28 December 2019 11:08:20 ghe wrote:

> On 12/27/19 5:02 PM, Nektarios Katakis wrote:
> > Have you tried removing openssh-server package and reinstalling it?
>
> Another hopefully good suggestion. Thanks, and I'll try it.
>
> > If you re using any version of Debian
>
> Raspian Buster.

One problem, raspian buster is armhf, debian is arm64.

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: systemdq

[ghe]

On 12/27/19 5:02 PM, Nektarios Katakis wrote:

> Have you tried removing openssh-server package and reinstalling it?

Another hopefully good suggestion. Thanks, and I'll try it.

> If you re using any version of Debian 

Raspian Buster.

-- 
Glenn English

Re: systemdq

[ghe]

On 12/27/19 4:50 PM, Linux-Fan wrote:

> Have you tried commands of this sort?

Not yet, but I will in a few minutes. My problem was that the error
message was more of the "Oops" type rather than suggesting what I might
do about it.

> # systemctl enable sshd.service
> # systemctl start sshd.service
> # systemctl status sshd.service
> 
> Even if you already tried them without solving the issue, the commands'
> outputs would still be interesting.

I'll reply to the list.

-- 
Glenn English

Re: systemdq

[Nektarios Katakis]

On Fri, 27 Dec 2019 16:24:30 -0700
ghe  wrote:

> SSH isn't starting at boot on my server. When I try to set it to do
> that, systemd says it can't do that 'without a command.'
> 
> What kind of command makes it happy? Where does it need to be?
> 
> (I've futzed with the ssh file in /etc/default, even entered a
> command: (qwerty="42" -- it wasn't impressed). I looked around on the
> web (lots of info about systemd commands, but nothing about what I
> need.)
> 
> Help??
> 

Have you tried removing openssh-server package and reinstalling it?
If you re using any version of Debian the default
installation comes with sane defaults and it leaves the service
enabled and running.

Regards,
Nektarios Katakis

Re: systemdq

[Linux-Fan]

ghe writes:


SSH isn't starting at boot on my server. When I try to set it to do
that, systemd says it can't do that 'without a command.'

What kind of command makes it happy? Where does it need to be?

(I've futzed with the ssh file in /etc/default, even entered a command:
(qwerty="42" -- it wasn't impressed). I looked around on the web (lots
of info about systemd commands, but nothing about what I need.)

Help??


How exactly are you trying to enable it?

Have you tried commands of this sort?

# systemctl enable sshd.service
# systemctl start sshd.service
# systemctl status sshd.service

Even if you already tried them without solving the issue, the commands'
outputs would still be interesting.

HTH
Linux-Fan


pgp3e0t_Dqp2B.pgp
Description: PGP signature

systemdq

[ghe]

SSH isn't starting at boot on my server. When I try to set it to do
that, systemd says it can't do that 'without a command.'

What kind of command makes it happy? Where does it need to be?

(I've futzed with the ssh file in /etc/default, even entered a command:
(qwerty="42" -- it wasn't impressed). I looked around on the web (lots
of info about systemd commands, but nothing about what I need.)

Help??

-- 
Glenn English