reboot stuff doesn't start

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

reboot stuff doesn't start

Gene Heskett-4
Greetings all;

New stretch install about 2 weeks ago, cleaning up the remains.  Fresh
disk, so no leftovers. But lots of stuff has been copied over from the
wheezy disk since

I have spamassassin enabled in my rc5.d, and I start heyu engine and heyu
monitor in my rc.local for several years , but neither one is actually
being started now.

I can restart spamassassin once logged it, ditto for heyu and friends.

Why don't they start when they're supposed to?

Thanks all.

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

Reply | Threaded
Open this post in threaded view
|

Re: reboot stuff doesn't start

john doe-6
On 5/26/2019 5:32 PM, Gene Heskett wrote:

> Greetings all;
>
> New stretch install about 2 weeks ago, cleaning up the remains.  Fresh
> disk, so no leftovers. But lots of stuff has been copied over from the
> wheezy disk since
>
> I have spamassassin enabled in my rc5.d, and I start heyu engine and heyu
> monitor in my rc.local for several years , but neither one is actually
> being started now.
>
> I can restart spamassassin once logged it, ditto for heyu and friends.
>
> Why don't they start when they're supposed to?
>

Look at the service 'rc.local'.:

$ systemctl status/enable rc.local


The real question here is why the services that you use don't have a
service file.

--
John Doe

Reply | Threaded
Open this post in threaded view
|

Re: reboot stuff doesn't start

Brian
In reply to this post by Gene Heskett-4
On Sun 26 May 2019 at 11:32:11 -0400, Gene Heskett wrote:

> Greetings all;
>
> New stretch install about 2 weeks ago, cleaning up the remains.  Fresh
> disk, so no leftovers. But lots of stuff has been copied over from the
> wheezy disk since

All copied stuff is compatible with stretch? You checked beforehand?
You checked afterwards? You didn't check at all?

--
Brian.

Reply | Threaded
Open this post in threaded view
|

Re: reboot stuff doesn't start

Gene Heskett-4
In reply to this post by john doe-6
On Sunday 26 May 2019 12:13:38 pm john doe wrote:

> On 5/26/2019 5:32 PM, Gene Heskett wrote:
> > Greetings all;
> >
> > New stretch install about 2 weeks ago, cleaning up the remains.
> > Fresh disk, so no leftovers. But lots of stuff has been copied over
> > from the wheezy disk since
> >
> > I have spamassassin enabled in my rc5.d, and I start heyu engine and
> > heyu monitor in my rc.local for several years , but neither one is
> > actually being started now.
> >
> > I can restart spamassassin once logged it, ditto for heyu and
> > friends.
> >
> > Why don't they start when they're supposed to?
>
> Look at the service 'rc.local'.:
>
> $ systemctl status/enable rc.local

hummmmm....:
root@coyote:GenesAmandaHelper-0.61$ systemctl status rc.local
● rc-local.service - /etc/rc.local Compatibility
   Loaded: loaded (/lib/systemd/system/rc-local.service; static; vendor
preset: enabled)
  Drop-In: /lib/systemd/system/rc-local.service.d
           └─debian.conf
   Active: failed (Result: exit-code) since Sat 2019-05-25 12:03:03 EDT;
1 day 5h ago
  Process: 884 ExecStart=/etc/rc.local start (code=exited,
status=1/FAILURE)

May 25 12:03:03 coyote su[1224]: + ??? root:gene
May 25 12:03:03 coyote su[1224]: pam_unix(su:session): session opened for
user gene by (uid=0)
May 25 12:03:03 coyote su[1238]: Successful su for gene by root
May 25 12:03:03 coyote su[1238]: + ??? root:gene
May 25 12:03:03 coyote su[1238]: pam_unix(su:session): session opened for
user gene by (uid=0)
May 25 12:03:03 coyote rc.local[884]: read: Connection reset by peer
May 25 12:03:03 coyote systemd[1]: rc-local.service: Control process
exited, code=exited status=1
May 25 12:03:03 coyote systemd[1]: Failed to start /etc/rc.local
Compatibility.
May 25 12:03:03 coyote systemd[1]: rc-local.service: Unit entered failed
state.
May 25 12:03:03 coyote systemd[1]: rc-local.service: Failed with
result 'exit-code'.

None of which gives me the faintest clue whats wrong with it.  So:
root@coyote:GenesAmandaHelper-0.61$ cat /etc/rc.local
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
#

# mount the sshfs shares. Suggested way didn't work,
# so changed syntax to this, which does
su gene -c "sshfs gene@shop:/ /sshnet/shop"
su gene -c "sshfs gene@lathe:/ /sshnet/lathe"
su gene -c "sshfs gene@GO704:/ /sshnet/GO704"
#su gene -c "sshfs gene@Sheldon:/ /sshnet/Sheldon"
su gene -c "sshfs gene@rock64:/ /sshnet/rock64"
su gene -c "sshfs pi@picnc:/ /sshnet/picnc"

# Now, udev is being a cast iron bitch, so lets see if we can outwit udev
# and make heyu work. 0755 didn't work, Ed Dipold says 0666
chmod 0666 /dev/ttyUSB0
chown gene:gene /dev/ttyUSB0

# Now, need some heyu stuff run
su gene -c "/usr/local/bin/heyu engine &"
su gene -c "/usr/local/bin/heyu monitor &"
exit 0

>
>
> The real question here is why the services that you use don't have a
> service file.

Is there a template that can be filled in and moved to an active
location?

Spamassassin has the usual start,stop etc file in /e/init.d
and its a S04 in rc5.d.  So it should start ok.  It does ok later.

Thanks.
> --
> John Doe


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

Reply | Threaded
Open this post in threaded view
|

Re: reboot stuff doesn't start

Gene Heskett-4
In reply to this post by Brian
On Sunday 26 May 2019 03:34:52 pm Brian wrote:

> On Sun 26 May 2019 at 11:32:11 -0400, Gene Heskett wrote:
> > Greetings all;
> >
> > New stretch install about 2 weeks ago, cleaning up the remains.
> > Fresh disk, so no leftovers. But lots of stuff has been copied over
> > from the wheezy disk since
>
> All copied stuff is compatible with stretch? You checked beforehand?
> You checked afterwards? You didn't check at all?

Didn't check at all. Its 99.99999% data, old email corpus goes back about
23 years, several gigabytes of old pix and movies of weddings I had
shot. Half a terabyte of Downloads.  The contents of my /home/gene/bin
directory which is 99% bash helper scripts I've written over the last 20
years.

It appears that my rc.local has been broken by stretch so I've posted it
in a previous message for pithy comments, along with all the blather
from systemctl, very noisy but zero clues as to WTH is wrong.  No wonder
some hate systemd.

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

Reply | Threaded
Open this post in threaded view
|

Re: reboot stuff doesn't start

bw-2
In reply to this post by Gene Heskett-4
In-Reply-To: <[hidden email]>

>Greetings all;
>
>New stretch install about 2 weeks ago, cleaning up the remains.  Fresh
>disk, so no leftovers. But lots of stuff has been copied over from the
>wheezy disk since
>
>I have spamassassin enabled in my rc5.d, and I start heyu engine and heyu
>monitor in my rc.local for several years , but neither one is actually
>being started now.
>
>I can restart spamassassin once logged it, ditto for heyu and friends.
>
>Why don't they start when they're supposed to?
>
>Thanks all.
>
>Cheers, Gene Heskett
>--
>"There are four boxes to be used in defense of liberty:
> soap, ballot, jury, and ammo. Please use in that order."
>-Ed Howdershelt (Author)
>Genes Web page <http://geneslinuxbox.net:6309/gene>

Hii Gene, SInce you are going to a lot of trouble getting this stuff
setup, why not try and ditch use of rc.local for starting services
altogether?  It really never was a nice thing IMHO, and really might
simplify your life in the future to just stop doing it this way.

I found a few different suggestions about sshfs on a quick search, but
really couldn't recommend a way to solve it.
 
https://duckduckgo.com/html/?q=mount+sshfs+boot
https://www.halolinux.us/smart-home-automation/heyu.html

If heyu is configuring itself to run by altering /etc/rc.local, then IMO
it is not for stretch.  Service files for running it under systemd should
be available somewhere.  Maybe on the net if they are not in the
pkg/build archive, have you looked around?

Good Luck.

Reply | Threaded
Open this post in threaded view
|

Re: reboot stuff doesn't start

Gene Heskett-4
On Sunday 26 May 2019 08:29:27 pm bw wrote:

> In-Reply-To: <[hidden email]>
>
> >Greetings all;
> >
> >New stretch install about 2 weeks ago, cleaning up the remains.
> > Fresh disk, so no leftovers. But lots of stuff has been copied over
> > from the wheezy disk since
> >
> >I have spamassassin enabled in my rc5.d, and I start heyu engine and
> > heyu monitor in my rc.local for several years , but neither one is
> > actually being started now.
> >
> >I can restart spamassassin once logged it, ditto for heyu and
> > friends.
> >
> >Why don't they start when they're supposed to?
> >
> >Thanks all.
> >
> >Cheers, Gene Heskett
> >--
> >"There are four boxes to be used in defense of liberty:
> > soap, ballot, jury, and ammo. Please use in that order."
> >-Ed Howdershelt (Author)
> >Genes Web page <http://geneslinuxbox.net:6309/gene>
>
> Hii Gene, SInce you are going to a lot of trouble getting this stuff
> setup, why not try and ditch use of rc.local for starting services
> altogether?  It really never was a nice thing IMHO, and really might
> simplify your life in the future to just stop doing it this way.
>
Seems like an ideal place to put stuff you want running, without having
to do it manually after a reboot, sometimes tying up a terminal screen
for nothing.

Computers should save you work, not make it.

> I found a few different suggestions about sshfs on a quick search, but
> really couldn't recommend a way to solve it.

I've no clue why sshfs should be a problem, it Just Works, with a lot
less fuss than CIFS/SAMBA, doesn't throw away perms like they do and I
have yet to crash it mid copy like NFS is rather fond of doing.  So I
haven't setup an NFS share in quite a few years now.

Between a login shell and sshfs, I have the complete run of all 5
computers on my local net. From this keyboard.

> https://duckduckgo.com/html/?q=mount+sshfs+boot
> https://www.halolinux.us/smart-home-automation/heyu.html

But sshfs has nothing to do with heyu. heyu's problem that keeps it out
of the FOSS distributions is the license.  I'm not running a reactor
with it so it doesn't bother me a bit.

> If heyu is configuring itself to run by altering /etc/rc.local,

its not altering rc.local in any way other than my alterations edited
into rc.local to make it run.  In this case udev is the problem, as it
sets the perms so tight only root can use /dev/ttyUSB*.  Since I don't
have a phone modem plugged into the world, that lever of security it
pure paranoia, so I change it from an automatic root account named
rc.local.

> then
> IMO it is not for stretch.  Service files for running it under systemd
> should be available somewhere.  Maybe on the net if they are not in
> the pkg/build archive, have you looked around?

I could I suppose ask on the heyu list, but this did work for what, 5
years on wheezy and about as long on ubuntu.

> Good Luck.


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

Reply | Threaded
Open this post in threaded view
|

Re: reboot stuff doesn't start

Curt
In reply to this post by Gene Heskett-4
On 2019-05-26, Gene Heskett <[hidden email]> wrote:
> hummmmm....:
> root@coyote:GenesAmandaHelper-0.61$ systemctl status rc.local
> ● rc-local.service - /etc/rc.local Compatibility
>    Loaded: loaded (/lib/systemd/system/rc-local.service; static; vendor
> preset: enabled)

I found this (not sure if it's entirely applicable, or even entirely
wise, but there you go):

https://www.linuxbabe.com/linux-server/how-to-enable-etcrc-local-with-systemd



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

Reply | Threaded
Open this post in threaded view
|

Re: reboot stuff doesn't start

Reco
In reply to this post by Gene Heskett-4
        Hi.

On Sun, May 26, 2019 at 05:45:56PM -0400, Gene Heskett wrote:

> On Sunday 26 May 2019 12:13:38 pm john doe wrote:
>
> > On 5/26/2019 5:32 PM, Gene Heskett wrote:
> > > Greetings all;
> > >
> > > New stretch install about 2 weeks ago, cleaning up the remains.
> > > Fresh disk, so no leftovers. But lots of stuff has been copied over
> > > from the wheezy disk since
> > >
> > > I have spamassassin enabled in my rc5.d, and I start heyu engine and
> > > heyu monitor in my rc.local for several years , but neither one is
> > > actually being started now.
> > >
> > > I can restart spamassassin once logged it, ditto for heyu and
> > > friends.
> > >
> > > Why don't they start when they're supposed to?
> >
> > Look at the service 'rc.local'.:
> >
> > $ systemctl status/enable rc.local
>
> hummmmm....:
> root@coyote:GenesAmandaHelper-0.61$ systemctl status rc.local
...
> May 25 12:03:03 coyote rc.local[884]: read: Connection reset by peer
...

> None of which gives me the faintest clue whats wrong with it.

It does for me.

First,

> root@coyote:GenesAmandaHelper-0.61$ cat /etc/rc.local
> #!/bin/sh -e

Any execution error will terminate the script.


Second,

> # mount the sshfs shares. Suggested way didn't work,
> # so changed syntax to this, which does
> su gene -c "sshfs gene@shop:/ /sshnet/shop"

It fails here, or at any of the later sshfs invocations.
Either your resolver is broken or remote sshd does not function.

Note - you're doing it wrong by configuring per-user mounts at
systemwide level. They invented systemd user-level services just for
that.

Also,

> # Now, udev is being a cast iron bitch,

But overriding it this way will only work until the first 'udevadm
trigger' or USB device hotplug.
They invented 'dialout' group (and use it by default) to avoid such
kludges, consider using it.

And,

> # Now, need some heyu stuff run
> su gene -c "/usr/local/bin/heyu engine &"
> su gene -c "/usr/local/bin/heyu monitor &"

this just cries 'put me into systemd unit'.
Abusing shell's background in rc.local is good for all those enterprisey
"i-dont-know-what-im-doing" devopses. Don't be like them.


In short, everything in your rc.local does not belong there.

Reco

Reply | Threaded
Open this post in threaded view
|

Re: reboot stuff doesn't start

Gene Heskett-4
In reply to this post by Curt
On Monday 27 May 2019 04:50:22 am Curt wrote:

> On 2019-05-26, Gene Heskett <[hidden email]> wrote:
> > hummmmm....:
> > root@coyote:GenesAmandaHelper-0.61$ systemctl status rc.local
> > ● rc-local.service - /etc/rc.local Compatibility

And un-noticed 100 lines later in that same log is a report that the
compatibility had failed.

> >    Loaded: loaded (/lib/systemd/system/rc-local.service; static;
> > vendor preset: enabled)
>
> I found this (not sure if it's entirely applicable, or even entirely
> wise, but there you go):
>
> https://www.linuxbabe.com/linux-server/how-to-enable-etcrc-local-with-
>systemd

Here is the full trace of that command above:
root@coyote:~$ systemctl status rc.local
● rc-local.service - /etc/rc.local Compatibility
   Loaded: loaded (/lib/systemd/system/rc-local.service; static; vendor
preset: enabled)
  Drop-In: /lib/systemd/system/rc-local.service.d
           └─debian.conf
   Active: failed (Result: exit-code) since Mon 2019-05-27 09:04:59 EDT;
4h 42min ago

May 27 09:04:58 coyote su[1341]: + ??? root:gene
May 27 09:04:58 coyote su[1341]: pam_unix(su:session): session opened for
user gene by (uid=0)
May 27 09:04:58 coyote su[1357]: Successful su for gene by root
May 27 09:04:58 coyote su[1357]: + ??? root:gene
May 27 09:04:58 coyote su[1357]: pam_unix(su:session): session opened for
user gene by (uid=0)
May 27 09:04:59 coyote rc.local[921]: read: Connection reset by peer
May 27 09:04:59 coyote systemd[1]: rc-local.service: Control process
exited, code=exited status=1
May 27 09:04:59 coyote systemd[1]: Failed to start /etc/rc.local
Compatibility.
May 27 09:04:59 coyote systemd[1]: rc-local.service: Unit entered failed
state.
May 27 09:04:59 coyote systemd[1]: rc-local.service: Failed with
result 'exit-code'

Make of it what you will.

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)
Genes Web page <http://geneslinuxbox.net:6309/gene>

Reply | Threaded
Open this post in threaded view
|

Re: reboot stuff doesn't start

Gene Heskett-4
In reply to this post by Reco
On Monday 27 May 2019 05:11:29 am Reco wrote:

> Hi.
>
> On Sun, May 26, 2019 at 05:45:56PM -0400, Gene Heskett wrote:
> > On Sunday 26 May 2019 12:13:38 pm john doe wrote:
> > > On 5/26/2019 5:32 PM, Gene Heskett wrote:
> > > > Greetings all;
> > > >
> > > > New stretch install about 2 weeks ago, cleaning up the remains.
> > > > Fresh disk, so no leftovers. But lots of stuff has been copied
> > > > over from the wheezy disk since
> > > >
> > > > I have spamassassin enabled in my rc5.d, and I start heyu engine
> > > > and heyu monitor in my rc.local for several years , but neither
> > > > one is actually being started now.
> > > >
> > > > I can restart spamassassin once logged it, ditto for heyu and
> > > > friends.
> > > >
> > > > Why don't they start when they're supposed to?
> > >
> > > Look at the service 'rc.local'.:
> > >
> > > $ systemctl status/enable rc.local
> >
> > hummmmm....:
> > root@coyote:GenesAmandaHelper-0.61$ systemctl status rc.local
>
> ...
>
> > May 25 12:03:03 coyote rc.local[884]: read: Connection reset by peer
>
> ...
>
> > None of which gives me the faintest clue whats wrong with it.
>
> It does for me.
>
> First,
>
> > root@coyote:GenesAmandaHelper-0.61$ cat /etc/rc.local
> > #!/bin/sh -e
>
> Any execution error will terminate the script.
>
>
> Second,
>
> > # mount the sshfs shares. Suggested way didn't work,
> > # so changed syntax to this, which does
> > su gene -c "sshfs gene@shop:/ /sshnet/shop"
>
> It fails here, or at any of the later sshfs invocations.
> Either your resolver is broken or remote sshd does not function.
>
> Note - you're doing it wrong by configuring per-user mounts at
> systemwide level. They invented systemd user-level services just for
> that.
humm how about anls -l /sshnet/*
gene@coyote:~$ ls -l /sshnet/*
/sshnet/GO704:
total 96
drwxr-xr-x 1 root   root    4096 Jun  3  2018 bin
drwxr-xr-x 1 root   root    4096 Mar 23 17:51 boot
drwxr-xr-x 1 root   root    3400 Apr 28 16:22 dev
drwxr-xr-x 1 root   root   12288 May 23 22:29 etc
drwxr-xr-x 1 backup backup  4096 Oct  6  2015 GenesAmandaHelper-0.61
drwxr-xr-x 1 root   root    4096 Oct  5  2015 home
lrwxrwxrwx 1 root   root      35 Oct 27  2017
initrd.img -> /boot/initrd.img-3.4-9-rtai-686-pae
drwxr-xr-x 1 root   root    4096 Jun 20  2017 lib
drwx------ 1 root   root   16384 Oct 27  2017 lost+found
drwxr-xr-x 1 root   root    4096 Oct 27  2018 media
drwxr-xr-x 1 root   root    4096 Nov 10  2015 opt
dr-xr-xr-x 1 root   root       0 Mar 23 17:53 proc
drwx------ 1 root   root    4096 Sep 25  2017 root
drwxr-xr-x 1 root   root    1000 May 27 08:09 run
drwxr-xr-x 1 root   root    4096 Jun  3  2018 sbin
drwxr-xr-x 1 gene   gene    4096 Oct 27  2017 sshnet
dr-xr-xr-x 1 root   root       0 Mar 23 17:53 sys
drwxrwxrwt 1 root   root    4096 May 27 13:17 tmp
drwxr-xr-x 1 root   root    4096 Mar 23 17:48 usr
drwxr-xr-x 1 root   root    4096 Oct 28  2017 var
lrwxrwxrwx 1 root   root      32 Oct 27  2017
vmlinuz -> /boot/vmlinuz-3.4-9-rtai-686-pae

/sshnet/lathe:
total 108
drwxr-xr-x 1 root   root  4096 Jun  3  2018 bin
drwxr-xr-x 1 root   root  1024 Feb  5  2017 boot
drwxr-xr-x 1 root   root  3340 Apr 28 10:41 dev
drwxr-xr-x 1 root   root 12288 May 23 22:37 etc
drwxr-xr-x 1 backup disk  4096 May  6  2015 GenesAmandaHelper-0.61
drwxr-xr-x 1 root   root  4096 May  8  2015 home
lrwxrwxrwx 1 root   root    35 May  6  2015
initrd.img -> /boot/initrd.img-3.4-9-rtai-686-pae
drwxr-xr-x 1 root   root  4096 Jun 24  2017 lib
drwx------ 1 root   root 16384 May  6  2015 lost+found
drwxr-xr-x 1 root   root  4096 Jul  3  2014 media
drwxr-xr-x 1 root   root  4096 Apr 19  2014 mnt
drwxr-xr-x 1 root   root     0 Mar  7 16:38 net
drwxr-xr-x 1 root   root  4096 Jul  3  2014 opt
dr-xr-xr-x 1 root   root     0 Mar  7 16:38 proc
drwx------ 1 root   root  4096 May  7  2015 root
drwxr-xr-x 1 root   root   920 May 23 22:36 run
drwxr-xr-x 1 root   root  4096 Jun  3  2018 sbin
drwxr-xr-x 1 root   root  4096 Jun 10  2012 selinux
drwxr-xr-x 1 root   root  4096 Jul  3  2014 srv
drwxr-xr-x 1 gene   gene  4096 Sep 24  2015 sshnet
dr-xr-xr-x 1 root   root     0 Mar  7 16:38 sys
drwxrwxrwt 1 root   root  4096 May 27 13:34 tmp
drwxr-xr-x 1 root   root  4096 May  6  2015 usr
drwxr-xr-x 1 root   root  4096 May  6  2015 var
lrwxrwxrwx 1 root   root    31 May  6  2015 vmlinuz ->
boot/vmlinuz-3.4-9-rtai-686-pae

/sshnet/picnc:
total 100
drwxr-xr-x 1 root   root    4096 Apr 26 21:09 bin
drwxr-xr-x 1 root   root    3072 Dec 31  1969 boot
-rw-r--r-- 1 root   root       4 Nov 15  2016 debian-binary
drwxr-xr-x 1 root   root    3640 May 17 16:57 dev
drwxr-xr-x 1 root   root   12288 May 17 16:52 etc
drwxr-xr-x 1 backup backup  4096 Jun 17  2017 GenesAmandaHelper-0.61
drwxr-xr-x 1 root   root    4096 Apr 10  2017 home
drwxr-xr-x 1 root   root    4096 Sep  4  2017 lib
drwx------ 1 root   root   16384 Apr 10  2017 lost+found
drwxr-xr-x 1 root   root    4096 Aug  1  2018 media
drwxr-xr-x 1 root   root    4096 Apr 10  2017 mnt
drwxr-xr-x 1 root   root    4096 Jun  2  2017 opt
dr-xr-xr-x 1 root   root       0 Dec 31  1969 proc
drwx------ 1 root   root    4096 Nov 11  2018 root
drwxr-xr-x 1 root   root     720 May 17 16:52 run
drwxr-xr-x 1 root   root    4096 Apr 26 21:10 sbin
drwxr-xr-x 1 root   root    4096 Apr 10  2017 srv
drwxr-xr-x 1 gene   gene    4096 Jun  7  2017 sshnet
dr-xr-xr-x 1 root   root       0 Dec 31  1969 sys
drwxrwxrwt 1 root   root    4096 May 27 13:17 tmp
drwxr-xr-x 1 root   root    4096 Jun  2  2017 usr
drwxr-xr-x 1 root   root    4096 Sep 25  2018 var

/sshnet/redpitaya:
total 0

/sshnet/rock64:
total 88
drwxr-xr-x 1 root root  4096 May 18 15:48 bin
drwxr-xr-x 1 root root  4096 May 22 15:05 boot
drwxr-xr-x 1 root root  3800 May 22 15:05 dev
drwxr-xr-x 1 root root  4096 May 23 22:51 etc
drwxr-xr-x 1 root root  4096 May 18 15:40 home
drwxr-xr-x 1 root root  4096 May 18 15:47 lib
drwx------ 1 root root 16384 Feb 10 05:23 lost+found
drwxr-xr-x 1 root root  4096 Feb  7 10:24 media
drwxr-xr-x 1 root root  4096 Feb  7 10:24 mnt
drwxr-xr-x 1 root root  4096 Feb  7 10:24 opt
dr-xr-xr-x 1 root root     0 Dec 31  1969 proc
drwx------ 1 root root  4096 May 18 17:03 root
drwxr-xr-x 1 root root   720 May 27 09:46 run
drwxr-xr-x 1 root root  4096 May 18 15:50 sbin
drwxrwxr-x 1 root root  4096 Feb 10 05:19 selinux
drwxr-xr-x 1 root root  4096 Feb  7 10:24 srv
dr-xr-xr-x 1 root root     0 May 22 15:05 sys
drwxrwxrwt 1 root root   280 May 27 13:45 tmp
drwxr-xr-x 1 root root  4096 Feb  7 10:24 usr
drwxr-xr-x 1 root root  4096 Feb 10 05:19 var
drwxr-xr-x 1 gene gene  4096 Jan  7 16:27 workspace

/sshnet/Sheldon:
total 0

/sshnet/shop:
total 108
drwxr-xr-x 1 root root  4096 Jan 16 10:38 bin
drwxr-xr-x 1 root root  4096 Feb 22 19:57 boot
drwxr-xr-x 1 root root  3260 May 21 19:13 dev
drwxr-xr-x 1 root root 12288 May 23 22:39 etc
drwxr-xr-x 1 root root  4096 May 18  2015 GenesAmandaHelper-0.61
drwxr-xr-x 1 root root  4096 May 19  2015 home
lrwxrwxrwx 1 root root    35 May 18  2015
initrd.img -> /boot/initrd.img-3.4-9-rtai-686-pae
drwxr-xr-x 1 root root  4096 Jun 24  2017 lib
drwx------ 1 root root 16384 May 18  2015 lost+found
drwxr-xr-x 1 root root  4096 May  7  2018 media
drwxr-xr-x 1 root root  4096 Apr 19  2014 mnt
drwxr-xr-x 1 root root     0 Mar 16 19:45 net
drwxr-xr-x 1 root root  4096 Jul  3  2014 opt
dr-xr-xr-x 1 root root     0 Mar 16 19:44 proc
drwx------ 1 root root  4096 May  6  2018 root
drwxr-xr-x 1 root root   920 May 23 22:38 run
drwxr-xr-x 1 root root  4096 Jun  3  2018 sbin
drwxr-xr-x 1 root root  4096 Jun 10  2012 selinux
drwxr-xr-x 1 root root  4096 Jul  3  2014 srv
drwxr-xr-x 1 gene gene  4096 Sep 24  2015 sshnet
dr-xr-xr-x 1 root root     0 Mar 16 19:44 sys
drwxrwxrwt 1 root root  4096 May 27 13:17 tmp
drwxr-xr-x 1 root root  4096 May 19  2015 usr
drwxr-xr-x 1 root root  4096 May 21  2015 var
lrwxrwxrwx 1 root root    31 May 18  2015 vmlinuz ->
boot/vmlinuz-3.4-9-rtai-686-pae

/sshnet/vna:
total 0
===================
that part Just Works.

> Also,
>
> > # Now, udev is being a cast iron bitch,
>
> But overriding it this way will only work until the first 'udevadm
> trigger' or USB device hotplug.
> They invented 'dialout' group (and use it by default) to avoid such
> kludges, consider using it.

So I should make heyu a member of group dialout?  It is not now:
gene@coyote:~$ grep dialout /etc/group
dialout:x:20:gene

>
> And,
>
> > # Now, need some heyu stuff run
> > su gene -c "/usr/local/bin/heyu engine &"
> > su gene -c "/usr/local/bin/heyu monitor &"
>
> this just cries 'put me into systemd unit'.
> Abusing shell's background in rc.local is good for all those
> enterprisey "i-dont-know-what-im-doing" devopses. Don't be like them.

And the docs on how to do that are where?
>
> In short, everything in your rc.local does not belong there.
>
> Reco

Thanks Reco.

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

Reply | Threaded
Open this post in threaded view
|

Re: reboot stuff doesn't start

Reco
On Mon, May 27, 2019 at 02:00:49PM -0400, Gene Heskett wrote:

> > > May 25 12:03:03 coyote rc.local[884]: read: Connection reset by peer
> >
> > ...
> >
> > > None of which gives me the faintest clue whats wrong with it.
> >
> > It does for me.
> >
> > First,
> >
> > > root@coyote:GenesAmandaHelper-0.61$ cat /etc/rc.local
> > > #!/bin/sh -e
> >
> > Any execution error will terminate the script.
> >
> >
> > Second,
> >
> > > # mount the sshfs shares. Suggested way didn't work,
> > > # so changed syntax to this, which does
> > > su gene -c "sshfs gene@shop:/ /sshnet/shop"
> >
> > It fails here, or at any of the later sshfs invocations.
> > Either your resolver is broken or remote sshd does not function.
> >
> > Note - you're doing it wrong by configuring per-user mounts at
> > systemwide level. They invented systemd user-level services just for
> > that.
> humm how about anls -l /sshnet/*

And that's supposed to prove what exactly?
That sshfs works once you configured your NICs and have the resolver
working and run all this stuff by hand?
rc-local.service formally depends on network.target, but that does not
mean all your interfaces are configured by the time /etc/rc.local is
actually run.


> > Also,
> >
> > > # Now, udev is being a cast iron bitch,
> >
> > But overriding it this way will only work until the first 'udevadm
> > trigger' or USB device hotplug.
> > They invented 'dialout' group (and use it by default) to avoid such
> > kludges, consider using it.
>
> So I should make heyu a member of group dialout?  It is not now:
> gene@coyote:~$ grep dialout /etc/group
> dialout:x:20:gene

Your rc.local contents do not contain any hint on why would you need 0666
permission on /dev/ttyUSB0. Sure, you needed it for something. Maybe it
even solved some problem.
You do not name your problem so I cannot comment on whenever adding a
certain custom user to dialout group can solve it or not.


> > And,
> >
> > > # Now, need some heyu stuff run
> > > su gene -c "/usr/local/bin/heyu engine &"
> > > su gene -c "/usr/local/bin/heyu monitor &"
> >
> > this just cries 'put me into systemd unit'.
> > Abusing shell's background in rc.local is good for all those
> > enterprisey "i-dont-know-what-im-doing" devopses. Don't be like them.
>
> And the docs on how to do that are where?

Google. [1] may or may not be of help.
Any *service file at /lib/systemd/system can serve as a template.

Reco

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

Reply | Threaded
Open this post in threaded view
|

Re: reboot stuff doesn't start

Gene Heskett-4
On Monday 27 May 2019 03:31:42 pm Reco wrote:

> On Mon, May 27, 2019 at 02:00:49PM -0400, Gene Heskett wrote:
> > > > May 25 12:03:03 coyote rc.local[884]: read: Connection reset by
> > > > peer
> > >
> > > ...
> > >
> > > > None of which gives me the faintest clue whats wrong with it.
> > >
> > > It does for me.
> > >
> > > First,
> > >
> > > > root@coyote:GenesAmandaHelper-0.61$ cat /etc/rc.local
> > > > #!/bin/sh -e
> > >
> > > Any execution error will terminate the script.
> > >
> > >
> > > Second,
> > >
> > > > # mount the sshfs shares. Suggested way didn't work,
> > > > # so changed syntax to this, which does
> > > > su gene -c "sshfs gene@shop:/ /sshnet/shop"
> > >
> > > It fails here, or at any of the later sshfs invocations.
> > > Either your resolver is broken or remote sshd does not function.
> > >
> > > Note - you're doing it wrong by configuring per-user mounts at
> > > systemwide level. They invented systemd user-level services just
> > > for that.
> >
> > humm how about anls -l /sshnet/*
>
> And that's supposed to prove what exactly?
> That sshfs works once you configured your NICs and have the resolver
> working and run all this stuff by hand?
> rc-local.service formally depends on network.target, but that does not
> mean all your interfaces are configured by the time /etc/rc.local is
> actually run.
>
> > > Also,
> > >
> > > > # Now, udev is being a cast iron bitch,
> > >
> > > But overriding it this way will only work until the first 'udevadm
> > > trigger' or USB device hotplug.
> > > They invented 'dialout' group (and use it by default) to avoid
> > > such kludges, consider using it.
> >
> > So I should make heyu a member of group dialout?  It is not now:
> > gene@coyote:~$ grep dialout /etc/group
> > dialout:x:20:gene
>
> Your rc.local contents do not contain any hint on why would you need
> 0666 permission on /dev/ttyUSB0. Sure, you needed it for something.
> Maybe it even solved some problem.
> You do not name your problem so I cannot comment on whenever adding a
> certain custom user to dialout group can solve it or not.

heyu did not like the seriel ports default params, so I asked on the heyu
list, about 2 years ago, Ed Dipold, a regular on that list suggested I
try 0666 and chown it to me. Worked flawlessly UNTIL I bought a new 2T
drive and installed stretch 3 weeks ago.  And has worked only
intermittently since.

Right now its as if the cm-11a has died, and I note its not running more
than a degree or so over ambient, not as warm as before. If I get some
spare time tomorrow I'll open it and check for smoked parts. I hate to
do that as those things make even old radio shack stuff look like
Cadillac quality stuff.

FWIW, I have what used to be a 1st phone FCC license, and I am a C.E.T.
and I know which end of a soldering iron gets hot as I have several,
also a dual trace 1GHS/a sec scope and all the other tools of the trade.
I also sat in the CE's chair at the local cbs affiliate from 1984 to
2002.  The chair never got fully warmed up though, as I did it by myself
at least half of that time.

I'll shut my horn off now.

> > > And,
> > >
> > > > # Now, need some heyu stuff run
> > > > su gene -c "/usr/local/bin/heyu engine &"
> > > > su gene -c "/usr/local/bin/heyu monitor &"
> > >
> > > this just cries 'put me into systemd unit'.
> > > Abusing shell's background in rc.local is good for all those
> > > enterprisey "i-dont-know-what-im-doing" devopses. Don't be like
> > > them.
> >
> > And the docs on how to do that are where?
>
> Google. [1] may or may not be of help.

It wasn't.

> Any *service file at /lib/systemd/system can serve as a template.
>
> Reco

Buried under a pyramid, no wonder I couldn't find it. Thanks a bunch.

> [1] https://wiki.debian.org/systemd

That too.  Thanks Reco.

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

Reply | Threaded
Open this post in threaded view
|

Re: reboot stuff doesn't start

Greg Wooledge
In reply to this post by Reco
On Mon, May 27, 2019 at 12:11:29PM +0300, Reco wrote:
> On Sun, May 26, 2019 at 05:45:56PM -0400, Gene Heskett wrote:
> > root@coyote:GenesAmandaHelper-0.61$ cat /etc/rc.local
> > #!/bin/sh -e
>
> Any execution error will terminate the script.

The blame is on Debian for that one.  That's what Debian put in the
default /etc/rc.local file in every release up to jessie.  (They "fixed"
this in stretch by not having a default /etc/rc.local file at all, but
if you upgraded to stretch, you still have the old default file.)

Debian's policy for developers is to use -e with all shell scripts
(horrible!), but inflicting that same policy on end users is not wise.

Reply | Threaded
Open this post in threaded view
|

Re: reboot stuff doesn't start

Reco
        Hi.

On Tue, May 28, 2019 at 10:53:04AM -0400, Greg Wooledge wrote:

> On Mon, May 27, 2019 at 12:11:29PM +0300, Reco wrote:
> > On Sun, May 26, 2019 at 05:45:56PM -0400, Gene Heskett wrote:
> > > root@coyote:GenesAmandaHelper-0.61$ cat /etc/rc.local
> > > #!/bin/sh -e
> >
> > Any execution error will terminate the script.
>
> The blame is on Debian for that one.  That's what Debian put in the
> default /etc/rc.local file in every release up to jessie.  (They "fixed"
> this in stretch by not having a default /etc/rc.local file at all, but
> if you upgraded to stretch, you still have the old default file.)

I disagree. /etc/rc.local is a part of init (whenever it's sysvinit or
systemd or upstart), being run as root. If something goes wrong there -
it should fail as verbose as possible (yep, journald is worthless in
this regard). Helps with diagnostics and all that.


> Debian's policy for developers is to use -e with all shell scripts
> (horrible!),

On the contrary. Helps with error catching, limits the damage (all
package scripts are executed as root), promotes at least some kind of
code quality.
Side effects may include non-removing packages (failed prerm script), of
course, but they have bugs.debian.org for these cases.


> but inflicting that same policy on end users is not wise.

End users can remove that '-e' flag if they believe it's problematic.
rc.local is a simple shell script, open to all kinds of abuse including
this one.

Reco

Reply | Threaded
Open this post in threaded view
|

Re: reboot stuff doesn't start

Gene Heskett-4
On Tuesday 28 May 2019 11:53:26 am Reco wrote:

> Hi.
>
> On Tue, May 28, 2019 at 10:53:04AM -0400, Greg Wooledge wrote:
> > On Mon, May 27, 2019 at 12:11:29PM +0300, Reco wrote:
> > > On Sun, May 26, 2019 at 05:45:56PM -0400, Gene Heskett wrote:
> > > > root@coyote:GenesAmandaHelper-0.61$ cat /etc/rc.local
> > > > #!/bin/sh -e
> > >
> > > Any execution error will terminate the script.
> >
> > The blame is on Debian for that one.  That's what Debian put in the
> > default /etc/rc.local file in every release up to jessie.  (They
> > "fixed" this in stretch by not having a default /etc/rc.local file
> > at all, but if you upgraded to stretch, you still have the old
> > default file.)
>
> I disagree. /etc/rc.local is a part of init (whenever it's sysvinit or
> systemd or upstart), being run as root. If something goes wrong there
> - it should fail as verbose as possible (yep, journald is worthless in
> this regard). Helps with diagnostics and all that.
>
I'll sure as hell 2nd that. If anything, rc.local should stack the errors
and keep on trucking, and when its out of things to do, then spit out
the errors if any, in the order encountered, to the syslog.

> > Debian's policy for developers is to use -e with all shell scripts
> > (horrible!),
>
> On the contrary. Helps with error catching, limits the damage (all
> package scripts are executed as root), promotes at least some kind of
> code quality.
> Side effects may include non-removing packages (failed prerm script),
> of course, but they have bugs.debian.org for these cases.
>
> > but inflicting that same policy on end users is not wise.
>
> End users can remove that '-e' flag if they believe it's problematic.
> rc.local is a simple shell script, open to all kinds of abuse
> including this one.
>
I assume the -e is a bash option? I just rescanned the man page without
find a reference other than a test for file -e=exists filename.

It is in the shebang line, so what does that do when its in that
position.
> Reco


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

Reply | Threaded
Open this post in threaded view
|

Re: reboot stuff doesn't start

Reco
On Tue, May 28, 2019 at 01:23:45PM -0400, Gene Heskett wrote:
> > End users can remove that '-e' flag if they believe it's problematic.
> > rc.local is a simple shell script, open to all kinds of abuse
> > including this one.
> >
> I assume the -e is a bash option?

Any POSIX-compliant shell knows about '-e', bash included.
Your own rc.local has this shebang: #!/bin/sh -e

> I just rescanned the man page without
> find a reference other than a test for file -e=exists filename.

dash(1) references it. bash(1) lists '-e' as an option to "set" command.

> It is in the shebang line, so what does that do when its in that
> position.

Quoting bash(1):

  -e  Exit  immediately if a pipeline (which may consist of a single
simple command), a list, or a compound command (see SHELL GRAMMAR
above), exits with a non-zero status.

Reco

Reply | Threaded
Open this post in threaded view
|

Re: reboot stuff doesn't start

Greg Wooledge
In reply to this post by Gene Heskett-4
On Tue, May 28, 2019 at 01:23:45PM -0400, Gene Heskett wrote:
> I'll sure as hell 2nd that. If anything, rc.local should stack the errors
> and keep on trucking, and when its out of things to do, then spit out
> the errors if any, in the order encountered, to the syslog.

If you want that behavior, remove the -e option.  -e forces the shell
to terminate on the first "error", instead of trucking on.

> I assume the -e is a bash option? I just rescanned the man page without
> find a reference other than a test for file -e=exists filename.
>
> It is in the shebang line, so what does that do when its in that
> position.

Yes, it's a bash (or sh) option.  It turns on the "errexit" flag, which
means that the shell will terminate under various conditions that are
impossible to summarize cleanly, but all of which involve a command
exiting with a non-zero status.

<https://mywiki.wooledge.org/BashFAQ/105> has some explanations.

The relevant man page section is:

              -e      Exit  immediately  if a pipeline (which may consist of a
                      single simple command), a list, or  a  compound  command
                      (see SHELL GRAMMAR above), exits with a non-zero status.
                      The shell does not exit if the  command  that  fails  is
                      part  of  the command list immediately following a while
                      or until keyword, part of the test following the  if  or
                      elif  reserved  words, part of any command executed in a
                      && or || list except the command following the final  &&
                      or ||, any command in a pipeline but the last, or if the
                      command's return value is being inverted with !.   If  a
                      compound  command  other  than a subshell returns a non-
                      zero status because a command failed while -e was  being
                      ignored,  the  shell  does  not exit.  A trap on ERR, if
                      set, is executed before the shell  exits.   This  option
                      applies to the shell environment and each subshell envi‐
                      ronment separately (see  COMMAND  EXECUTION  ENVIRONMENT
                      above), and may cause subshells to exit before executing
                      all the commands in the subshell.

                      If a compound command or shell function  executes  in  a
                      context  where -e is being ignored, none of the commands
                      executed within the compound command  or  function  body
                      will  be  affected  by the -e setting, even if -e is set
                      and a command returns a failure status.  If  a  compound
                      command  or  shell function sets -e while executing in a
                      context where -e is ignored, that setting will not  have
                      any  effect  until  the  compound command or the command
                      containing the function call completes.

                [...]

              -o option-name
                      The option-name can be one of the following:
                [...]
                      errexit Same as -e.


The easiest way to find it is to search for "errexit" and then scroll
upward.  At least, that's how I did it.

Reply | Threaded
Open this post in threaded view
|

Re: reboot stuff doesn't start

Greg Wooledge
In reply to this post by Reco
On Tue, May 28, 2019 at 08:32:31PM +0300, Reco wrote:
> Quoting bash(1):
>
>   -e  Exit  immediately if a pipeline (which may consist of a single
> simple command), a list, or a compound command (see SHELL GRAMMAR
> above), exits with a non-zero status.

No fair snipping out the two paragraphs of exceptions and plot twists!

Reply | Threaded
Open this post in threaded view
|

Re: reboot stuff doesn't start

Reco
        Hi.

On Tue, May 28, 2019 at 01:37:48PM -0400, Greg Wooledge wrote:
> On Tue, May 28, 2019 at 08:32:31PM +0300, Reco wrote:
> > Quoting bash(1):
> >
> >   -e  Exit  immediately if a pipeline (which may consist of a single
> > simple command), a list, or a compound command (see SHELL GRAMMAR
> > above), exits with a non-zero status.
>
> No fair snipping out the two paragraphs of exceptions and plot twists!

IMO all GNU utilities provide complex and crossreference infested
manpages on purpose - so that the user could say "to hell with it", and
run "info <foo>" instead ☺

Reco

12