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

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

reboot stuff doesn't start

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

Contents

  reboot stuff doesn't start Gene Heskett <gheskett@shentel.net> - 2019-05-26 17:40 +0200
    Re: reboot stuff doesn't start john doe <johndoe65534@mail.com> - 2019-05-26 18:20 +0200
      Re: reboot stuff doesn't start Gene Heskett <gheskett@shentel.net> - 2019-05-26 23:50 +0200
        Re: reboot stuff doesn't start Curt <curty@free.fr> - 2019-05-27 11:00 +0200
          Re: reboot stuff doesn't start Gene Heskett <gheskett@shentel.net> - 2019-05-27 20:00 +0200
        Re: reboot stuff doesn't start Reco <recoverym4n@enotuniq.net> - 2019-05-27 11:20 +0200
          Re: reboot stuff doesn't start Gene Heskett <gheskett@shentel.net> - 2019-05-27 20:10 +0200
            Re: reboot stuff doesn't start Reco <recoverym4n@enotuniq.net> - 2019-05-27 21:40 +0200
              Re: reboot stuff doesn't start Gene Heskett <gheskett@shentel.net> - 2019-05-28 00:00 +0200
          Re: reboot stuff doesn't start Greg Wooledge <wooledg@eeg.ccf.org> - 2019-05-28 17:00 +0200
            Re: reboot stuff doesn't start Reco <recoverym4n@enotuniq.net> - 2019-05-28 18:00 +0200
              Re: reboot stuff doesn't start Gene Heskett <gheskett@shentel.net> - 2019-05-28 19:30 +0200
                Re: reboot stuff doesn't start Greg Wooledge <wooledg@eeg.ccf.org> - 2019-05-28 19:40 +0200
                  Re: reboot stuff doesn't start Reco <recoverym4n@enotuniq.net> - 2019-05-28 19:50 +0200
                    Re: reboot stuff doesn't start Greg Wooledge <wooledg@eeg.ccf.org> - 2019-05-28 20:00 +0200
                Re: reboot stuff doesn't start Greg Wooledge <wooledg@eeg.ccf.org> - 2019-05-28 19:40 +0200
                Re: reboot stuff doesn't start Reco <recoverym4n@enotuniq.net> - 2019-05-28 19:40 +0200
                  Re: reboot stuff doesn't start Gene Heskett <gheskett@shentel.net> - 2019-05-28 23:00 +0200
                    Re: reboot stuff doesn't start Reco <recoverym4n@enotuniq.net> - 2019-05-29 06:30 +0200
                      Re: reboot stuff doesn't start Gene Heskett <gheskett@shentel.net> - 2019-05-29 12:10 +0200
                        Re: reboot stuff doesn't start Reco <recoverym4n@enotuniq.net> - 2019-05-29 12:30 +0200
                      Re: reboot stuff doesn't start Gene Heskett <gheskett@shentel.net> - 2019-05-29 12:50 +0200
                        Re: reboot stuff doesn't start Reco <recoverym4n@enotuniq.net> - 2019-05-29 12:50 +0200
                          Re: reboot stuff doesn't start Gene Heskett <gheskett@shentel.net> - 2019-05-29 13:00 +0200
                            Re: reboot stuff doesn't start Brian <ad44@cityscape.co.uk> - 2019-05-29 20:00 +0200
                Re: reboot stuff doesn't start Gene Heskett <gheskett@shentel.net> - 2019-05-28 20:30 +0200
                  Re: reboot stuff doesn't start Brian <ad44@cityscape.co.uk> - 2019-05-28 21:40 +0200
                    Re: reboot stuff doesn't start Gene Heskett <gheskett@shentel.net> - 2019-05-29 03:50 +0200
                      Re: reboot stuff doesn't start Brian <ad44@cityscape.co.uk> - 2019-05-29 14:30 +0200
                        Re: reboot stuff doesn't start Gene Heskett <gheskett@shentel.net> - 2019-05-29 17:10 +0200
                          Re: reboot stuff doesn't start mick crane <mick.crane@gmail.com> - 2019-05-29 17:20 +0200
                            Re: reboot stuff doesn't start Roberto C. Sánchez <roberto@debian.org> - 2019-05-29 17:30 +0200
                            Re: reboot stuff doesn't start Greg Wooledge <wooledg@eeg.ccf.org> - 2019-05-29 17:30 +0200
    Re: reboot stuff doesn't start Brian <ad44@cityscape.co.uk> - 2019-05-26 21:40 +0200
      Re: reboot stuff doesn't start Gene Heskett <gheskett@shentel.net> - 2019-05-27 00:10 +0200
    Re: reboot stuff doesn't start Felix Miata <mrmazda@earthlink.net> - 2019-05-29 20:40 +0200

Page 1 of 2  [1] 2  Next page →

#209182 — reboot stuff doesn't start

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>

[toc] | [next] | [standalone]

#209183

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

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

#209191

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>

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

#209211

On 2019-05-26, Gene Heskett <gheskett@shentel.net> 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

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

#209249

On Monday 27 May 2019 04:50:22 am Curt wrote:

> On 2019-05-26, Gene Heskett <gheskett@shentel.net> 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>

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

#209214

	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

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

#209250

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>

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

#209258

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

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

#209263

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>

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

#209317

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.

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

#209322

	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

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

#209331

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>

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

#209332

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!

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

#209336

	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

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

#209338

On Tue, May 28, 2019 at 08:42:38PM +0300, Reco wrote:
> 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 ☺

No, this isn't a GNUism.  The definition of set -e *really is* that
complicated.  This is mandated by POSIX.  And the definition is fluid,
changing every few years as people bring up newly discovered special
cases where it doesn't do the right thing, or is ambiguous or unclear.
Then they debate for a few weeks (months, years) and publish a new
interpretation.

Here's an example from 2009-2012: <http://austingroupbugs.net/view.php?id=52>

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

#209333

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.

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

#209335

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

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

#209351

On Tuesday 28 May 2019 01:32:31 pm Reco wrote:

> 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
How about a daemon that never exits, but does report its pid on the next 
line when launched with a trailing &

I'm also seeing several can't connect to d-bus messages, only ID'd by the 
pid.  That means whatever its pid is, isn't working.

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

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

#209359

On Tue, May 28, 2019 at 04:52:52PM -0400, Gene Heskett wrote:
> On Tuesday 28 May 2019 01:32:31 pm Reco wrote:
> 
> > 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.
>
> How about a daemon that never exits, but does report its pid on the next 
> line when launched with a trailing &

They call such programs a curious perversion in IT usually.
Luckily it does not matter for the start-stop-daemon (it can derive pid more
straightforward way) nor it does matter to systemd (there are cgroups
for that).


> I'm also seeing several can't connect to d-bus messages, only ID'd by the 
> pid.  That means whatever its pid is, isn't working.

Like I wrote earlier - nothing that you put into rc.local belongs there.
I suppose that the thing is written to be launched from the inside the
user session, where you have dbus session already.

Reco

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

#209366

On Wednesday 29 May 2019 12:22:41 am Reco wrote:

> On Tue, May 28, 2019 at 04:52:52PM -0400, Gene Heskett wrote:
> > On Tuesday 28 May 2019 01:32:31 pm Reco wrote:
> > > 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.
> >
> > How about a daemon that never exits, but does report its pid on the
> > next line when launched with a trailing &
>
> They call such programs a curious perversion in IT usually.
> Luckily it does not matter for the start-stop-daemon (it can derive
> pid more straightforward way) nor it does matter to systemd (there are
> cgroups for that).
>
> > I'm also seeing several can't connect to d-bus messages, only ID'd
> > by the pid.  That means whatever its pid is, isn't working.
>
> Like I wrote earlier - nothing that you put into rc.local belongs
> there. I suppose that the thing is written to be launched from the
> inside the user session, where you have dbus session already.
>
> Reco
This is intended to be started after I login.  If d-bus isn't before I 
login, then obviously I need to move it to someplace thats run after 
I've logged in.

Where would that be? Someplace inside ~Desktop? but its empty now.

But I am using trinity, so maybe ~.trinity/Autostart?  Its also empty.

The point is that all this worked flawlessly on wheezy. d-bus was 
apparently running by the time the login popped up.

Thanks for any good ideas, 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>

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web