• Delayed access via VNC

    From Chris B@3:770/3 to All on Fri Jun 11 19:25:48 2021
    I have done a couple of temperature measuring projects with different
    PIs (a Pi3 and a Pi Zero W) and am quite familiar with running them
    headless via VNC.

    I thought I would try my hand with a camera on a PI zero W and having
    got the basics sorted have installed the "motion" package and was
    starting to play with that.

    but now when running headless initial attempts to access the machine via
    VNC result in

    VNC Server is not currently listening for cloud connections

    I discovered by chance that if I leave it long enough it does eventually
    come up and having done some testing by trying to access every 30
    seconds from boot I can not get access at 11 minutes but can at 11
    minutes 30 seconds.


    If I connect the pi to a display via the HDMI port and keyboard/mouse
    via USB, the machine boots in about a minute or two, VNC starts and I
    can log in from my remote machine, straight away.

    I have done quite a bit of googling and did find this page https://www.raspberrypi.org/documentation/configuration/screensaver.md

    but setting consoleblank to 60 did not improve matters.

    I have tried @reboot vncserver start in crontab with no effect.

    I have uninstalled the motion package but still no improvement

    Does anyone have any idea where I should look?

    Thanks

    --
    Chris B (News)

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From NY@3:770/3 to Chris B on Fri Jun 11 21:22:05 2021
    "Chris B" <news@salis.co.uk> wrote in message news:sa09rd$i6d$1@dont-email.me...
    I have done a couple of temperature measuring projects with different PIs
    (a Pi3 and a Pi Zero W) and am quite familiar with running them headless
    via VNC.

    I thought I would try my hand with a camera on a PI zero W and having got
    the basics sorted have installed the "motion" package and was starting to play with that.

    but now when running headless initial attempts to access the machine via
    VNC result in

    VNC Server is not currently listening for cloud connections

    I discovered by chance that if I leave it long enough it does eventually
    come up and having done some testing by trying to access every 30 seconds from boot I can not get access at 11 minutes but can at 11 minutes 30 seconds.


    If I connect the pi to a display via the HDMI port and keyboard/mouse via USB, the machine boots in about a minute or two, VNC starts and I can log
    in from my remote machine, straight away.

    I have done quite a bit of googling and did find this page https://www.raspberrypi.org/documentation/configuration/screensaver.md

    but setting consoleblank to 60 did not improve matters.

    I have tried @reboot vncserver start in crontab with no effect.

    I have uninstalled the motion package but still no improvement

    Does anyone have any idea where I should look?


    Ah, the "headless Pi4 problem". I hit this when I migrated from a Pi3 to a
    Pi4.

    I found that the following lines in /boot/config.txt solved it for me:

    hdmi_force_hotplug=1 # allow Pi to boot with no monitor connected
    hdmi_group=2
    hdmi_mode=82 # force 1920x1080x60 even though monitor can’t be
    auto-detected

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris B@3:770/3 to All on Sat Jun 12 08:20:15 2021
    On 11/06/2021 21:22, NY wrote:
    "Chris B" <news@salis.co.uk> wrote in message news:sa09rd$i6d$1@dont-email.me...
    I have done a couple of temperature measuring projects with different
    PIs (a Pi3 and a Pi Zero W) and am quite familiar with running them
    headless via VNC.

    I thought I would try my hand with a camera on a PI zero W and having
    got the basics sorted have installed the "motion" package and was
    starting to play with that.

    but now when running headless initial attempts to access the machine
    via VNC result in

    VNC Server is not currently listening for cloud connections

    I discovered by chance that if I leave it long enough it does
    eventually come up and having done some testing by trying to access
    every 30 seconds from boot I can not get access at 11 minutes but can
    at 11 minutes 30 seconds.


    If I connect the pi to a display via the HDMI port and keyboard/mouse
    via USB, the machine boots in about a minute or two, VNC starts and I
    can log in from my remote machine, straight away.

    I have done quite a bit of googling and did find this page
    https://www.raspberrypi.org/documentation/configuration/screensaver.md

    but setting consoleblank to 60 did not improve matters.

    I have tried @reboot vncserver start in crontab with no effect.

    I have uninstalled the motion package but still no improvement

    Does anyone have any idea where I should look?


    Ah, the "headless Pi4 problem". I hit this when I migrated from a Pi3 to
    a Pi4.

    I found that the following lines in /boot/config.txt solved it for me:

        hdmi_force_hotplug=1    # allow Pi to boot with no monitor connected
        hdmi_group=2
        hdmi_mode=82        # force 1920x1080x60 even though monitor can’t
    be auto-detected


    Thanks for the suggestions which I have now had time to look into.
    The first two lines were already set in my /boot/config.txt

    The third line was hdmi_mode=16. I changed it to 82 and although this
    had a major effect on the VNC display it did not reduce the VNC access
    time which remains at in excess of 10 minutes from reboot

    Regards

    --
    Chris B (News)
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From NY@3:770/3 to me@privacy.invalid on Sat Jun 12 11:14:45 2021
    "NY" <me@privacy.invalid> wrote in message
    news:sa20ke$2kp$1@dont-email.me...
    "Chris B" <news@salis.co.uk> wrote in message news:sa1n7f$fol$1@dont-email.me...

    Ah, the "headless Pi4 problem". I hit this when I migrated from a Pi3 to >>> a Pi4.

    I found that the following lines in /boot/config.txt solved it for me:

    hdmi_force_hotplug=1 # allow Pi to boot with no monitor
    connected
    hdmi_group=2
    hdmi_mode=82 # force 1920x1080x60 even though monitor can’t >>> be auto-detected


    Thanks for the suggestions which I have now had time to look into.
    The first two lines were already set in my /boot/config.txt

    The third line was hdmi_mode=16. I changed it to 82 and although this
    had a major effect on the VNC display it did not reduce the VNC access
    time which remains at in excess of 10 minutes from reboot

    Hmmm. I wonder what it different about your setup. In my case the Pi
    refused to boot, and stuck as a solid (not flickering) green LED. I never thought to leave it to see if it would eventually boot. VNC may be a
    slight red herring here, because a Pi ought to be able to boot without any remote connection. What happens if you set up a recurring ping to the Pi: does that start responding any sooner than the > 10 mins that you've found for VNC.

    As far as I am aware, the hdmi_force_hotplug=1 is the only parameter which matters as regards ability to boot; the hdmi_mode=82 is there just to make sure what VNC sees a full-resolution display when it connects, rather than defaulting to 640x480 or giving a white-writing-on-black-background error message.


    Thinking about this a bit more, I can't see that any software which
    auto-starts on your Pi (but which I don't have on mine) would be started
    early enough to cause a no/go-go on the booting process. So I wonder if the reason your Pi doesn't respond to VNC is different to the reason mine didn't boot until I added hdmi_force_hotplug=1. Maybe your Pi is booting OK but
    Real VNC server isn't starting until after a long timeout. There is probably
    a log file somewhere which contains details of all the processes and their time-since-boot (it will be a fictitious time because the Pi will boot with
    a semi-random time because it has no real-time clock hardware, and the time will only be corrected when the Pi then syncs with an NTP server),

    If you can ping the Pi from long before VNC responds, you could try enabling SSH on the Pi and connecting to it by PuTTY (Windows) or JuiceSSH
    (Android) - get those working when the Pi is booted and responding via VNC
    (or connected to a monitor) so you know that they normally work, before rebooting and trying with the Pi headless. Those are diagnostic rather than solutions, but at least they help diagnose how far the Pi is getting in its boot process - ie whether it is even leaving the starting blocks.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From NY@3:770/3 to Andy Burns on Sat Jun 12 11:15:45 2021
    "Andy Burns" <usenet@andyburns.uk> wrote in message news:iijfffFm6ihU1@mid.individual.net...
    NY wrote:

    As far as I am aware, the hdmi_force_hotplug=1 is the only parameter
    which matters as regards ability to boot; the hdmi_mode=82 is there just
    to make sure what VNC sees a full-resolution display when it connects,
    rather than defaulting to 640x480 or giving a
    white-writing-on-black-background error message.

    If the config.txt option isn't doing the trick, maybe try a physical hdmi dummy?

    <https://thepihut.com/products/hdmi-dummy-plug>

    I nearly suggested something like that...

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From NY@3:770/3 to Chris B on Sat Jun 12 11:00:42 2021
    "Chris B" <news@salis.co.uk> wrote in message news:sa1n7f$fol$1@dont-email.me...

    Ah, the "headless Pi4 problem". I hit this when I migrated from a Pi3 to
    a Pi4.

    I found that the following lines in /boot/config.txt solved it for me:

    hdmi_force_hotplug=1 # allow Pi to boot with no monitor connected
    hdmi_group=2
    hdmi_mode=82 # force 1920x1080x60 even though monitor can’t
    be auto-detected


    Thanks for the suggestions which I have now had time to look into.
    The first two lines were already set in my /boot/config.txt

    The third line was hdmi_mode=16. I changed it to 82 and although this had
    a major effect on the VNC display it did not reduce the VNC access time
    which remains at in excess of 10 minutes from reboot

    Hmmm. I wonder what it different about your setup. In my case the Pi refused
    to boot, and stuck as a solid (not flickering) green LED. I never thought to leave it to see if it would eventually boot. VNC may be a slight red herring here, because a Pi ought to be able to boot without any remote connection.
    What happens if you set up a recurring ping to the Pi: does that start responding any sooner than the > 10 mins that you've found for VNC.

    As far as I am aware, the hdmi_force_hotplug=1 is the only parameter which matters as regards ability to boot; the hdmi_mode=82 is there just to make
    sure what VNC sees a full-resolution display when it connects, rather than defaulting to 640x480 or giving a white-writing-on-black-background error message.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Andy Burns@3:770/3 to Chris B on Sat Jun 12 11:13:51 2021
    Chris B wrote:

    Does anyone have any idea where I should look?

    does SSH access become available before VNC access?

    if so, can you see the VNC process, is anything listening on the VNC port?

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Andy Burns@3:770/3 to All on Sat Jun 12 11:09:51 2021
    NY wrote:

    As far as I am aware, the hdmi_force_hotplug=1 is the only parameter
    which matters as regards ability to boot; the hdmi_mode=82 is there just
    to make sure what VNC sees a full-resolution display when it connects,
    rather than defaulting to 640x480 or giving a white-writing-on-black-background error message.

    If the config.txt option isn't doing the trick, maybe try a physical
    hdmi dummy?

    <https://thepihut.com/products/hdmi-dummy-plug>

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From A. Dumas@3:770/3 to Chris B on Sat Jun 12 12:53:42 2021
    On 11-06-2021 20:25, Chris B wrote:
    I have tried @reboot vncserver start in crontab with no effect.

    Use 'sudo raspi-config' to configure VNC, that should be enough. Do not
    add another 'vncserver start' somewhere.

    I have uninstalled the motion package but still no improvement

    Desktop + Motion + VNC sounds a bit much (by which I mean a LOT) for a
    Pi Zero.

    Does anyone have any idea where I should look?

    Start over from scratch: download a fresh image of the latest 32-bit
    RaspiOS, burn it to SD card and connect to that.

    If running headless, you do need those config.txt settings. Group 1 mode
    16 is the same as group 2 mode 82. CEA (group 1) was originally for TV compatible hdmi, DMT (group 2) is for DVI over hdmi to a computer
    monitor, but effectively they're the same. If you want sound output over
    the physical cable, use a CEA mode. This makes no difference for VNC. I
    have this:

    hdmi_force_hotplug=1
    # 1/16 = CEA 1920x1080 @ 60 Hz
    # 1/31 = CEA 1920x1080 @ 50 Hz
    # 1/95 = CEA 3840x2160 @ 30 Hz (only for Pi 4)
    # 2/69 = DMT 1920x1200 @ 60 Hz
    # 2/82 = DMT 1920x1080 @ 60 Hz
    hdmi_group=1
    hdmi_mode=16

    More modes available at https://www.raspberrypi.org/documentation/configuration/config-txt/video.md (scroll down to "hdmi_mode" where they have two enormous tables for CEA
    and DMT).

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to All on Sat Jun 12 12:59:17 2021
    On 12/06/2021 11:14, NY wrote:
    Maybe your Pi is booting OK but Real VNC server isn't starting until
    after a long timeout.

    The timeout is reasonably consistent with a tcp connect failure time


    --
    In a Time of Universal Deceit, Telling the Truth Is a Revolutionary Act.

    - George Orwell
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From NY@3:770/3 to A. Dumas on Sat Jun 12 12:29:48 2021
    "A. Dumas" <alexandre@dumas.fr.invalid> wrote in message news:60c49236$0$22704$e4fe514c@news.xs4all.nl...
    If running headless, you do need those config.txt settings. Group 1 mode
    16 is the same as group 2 mode 82. CEA (group 1) was originally for TV compatible hdmi, DMT (group 2) is for DVI over hdmi to a computer monitor, but effectively they're the same.


    If you want sound output over the physical cable, use a CEA mode. This
    makes no difference for VNC. I have this:

    Ah!!!!!!!!!

    This explains why when I was using 2/82 = DMT 1920x1080 @ 60 Hz, I couldn't
    get any sound if I connected the Pi by HDMI cable, having set the Pi to boot headless with

    hdmi_force_hotplug=1
    hdmi_group=2
    hdmi_mode=82

    I'll change it to

    hdmi_force_hotplug=1
    hdmi_group=1
    hdmi_mode=31

    Which are the parameters I have for my Pi3 which doesn't need the hdmi_force_hotplug=1 to allow it to boot headlessly. I Couldn't find any reference to the CEA modes or 50 Hz rather than 60 Hz when I was researching for the Pi4 - maybe it is that 50 Hz modes are not offered by raspi_config.


    hdmi_force_hotplug=1
    # 1/16 = CEA 1920x1080 @ 60 Hz
    # 1/31 = CEA 1920x1080 @ 50 Hz
    # 1/95 = CEA 3840x2160 @ 30 Hz (only for Pi 4)
    # 2/69 = DMT 1920x1200 @ 60 Hz
    # 2/82 = DMT 1920x1080 @ 60 Hz
    hdmi_group=1
    hdmi_mode=16

    More modes available at https://www.raspberrypi.org/documentation/configuration/config-txt/video.md (scroll down to "hdmi_mode" where they have two enormous tables for CEA
    and DMT).
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris B (News)@3:770/3 to Andy Burns on Sat Jun 12 07:20:36 2021
    On Saturday, 12 June 2021 at 11:13:53 UTC+1, Andy Burns wrote:
    Chris B wrote:

    Does anyone have any idea where I should look?
    does SSH access become available before VNC access?

    if so, can you see the VNC process, is anything listening on the VNC port?

    Apologies if this formats incorrectly but I am away from home at the moment using Google Groups
    rather than the more familiar T Bird

    I have uninstalled the "motion" package

    I rebooted and tried to ping immeadiately

    chris@Johns-iMac ~ % ping 192.168.1.22
    PING 192.168.1.22 (192.168.1.22): 56 data bytes
    Request timeout for icmp_seq 0
    Request timeout for icmp_seq 1
    Request timeout for icmp_seq 2
    Request timeout for icmp_seq 3
    Request timeout for icmp_seq 4
    Request timeout for icmp_seq 5
    Request timeout for icmp_seq 6
    ping: sendto: No route to host

    {lots of similar lines deleted}

    Request timeout for icmp_seq 43
    64 bytes from 192.168.1.22: icmp_seq=44 ttl=64 time=8.094 ms
    64 bytes from 192.168.1.22: icmp_seq=45 ttl=64 time=4.997 ms
    64 bytes from 192.168.1.22: icmp_seq=46 ttl=64 time=7.650 ms
    64 bytes from 192.168.1.22: icmp_seq=47 ttl=64 time=5.090 ms
    64 bytes from 192.168.1.22: icmp_seq=48 ttl=64 time=6.026 ms
    64 bytes from 192.168.1.22: icmp_seq=49 ttl=64 time=5.279 ms
    64 bytes from 192.168.1.22: icmp_seq=50 ttl=64 time=5.696 ms
    64 bytes from 192.168.1.22: icmp_seq=51 ttl=64 time=5.697 ms
    64 bytes from 192.168.1.22: icmp_seq=52 ttl=64 time=2.083 ms
    64 bytes from 192.168.1.22: icmp_seq=53 ttl=64 time=7.380 ms
    ^C
    --- 192.168.1.22 ping statistics ---
    54 packets transmitted, 10 packets received, 81.5% packet loss
    round-trip min/avg/max/stddev = 2.083/5.799/8.094/1.628 ms

    So then I tried to SSH and do a ps aux (results below)

    chris@Johns-iMac ~ % ssh pi@192.168.1.22
    pi@192.168.1.22's password:
    Linux pizero2 4.19.66+ #1253 Thu Aug 15 11:37:30 BST 2019 armv6l

    The programs included with the Debian GNU/Linux system are free software;
    the exact distribution terms for each program are described in the
    individual files in /usr/share/doc/*/copyright.

    Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
    permitted by applicable law.
    Last login: Sat Jun 12 14:55:11 2021
    pi@pizero2:~ $ ps aux
    USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
    root 1 5.0 1.6 27024 6052 ? Ss 15:02 0:04 /sbin/init splash
    root 2 0.0 0.0 0 0 ? S 15:02 0:00 [kthreadd] root 3 0.0 0.0 0 0 ? I 15:02 0:00 [kworker/0:
  • From NY@3:770/3 to All on Sat Jun 12 15:44:14 2021
    "Chris B (News)" <cjb200@gmail.com> wrote in message news:a833b994-8d62-490f-9c37-707cfa38a5cdn@googlegroups.com...
    On Saturday, 12 June 2021 at 11:13:53 UTC+1, Andy Burns wrote:
    Chris B wrote:

    Does anyone have any idea where I should look?
    does SSH access become available before VNC access?

    if so, can you see the VNC process, is anything listening on the VNC
    port?

    Apologies if this formats incorrectly but I am away from home at the
    moment using Google Groups
    rather than the more familiar T Bird

    I have uninstalled the "motion" package

    I rebooted and tried to ping immeadiately

    chris@Johns-iMac ~ % ping 192.168.1.22
    PING 192.168.1.22 (192.168.1.22): 56 data bytes
    Request timeout for icmp_seq 0
    Request timeout for icmp_seq 1
    Request timeout for icmp_seq 2
    Request timeout for icmp_seq 3
    Request timeout for icmp_seq 4
    Request timeout for icmp_seq 5
    Request timeout for icmp_seq 6
    ping: sendto: No route to host

    {lots of similar lines deleted}

    Request timeout for icmp_seq 43
    64 bytes from 192.168.1.22: icmp_seq=44 ttl=64 time=8.094 ms
    64 bytes from 192.168.1.22: icmp_seq=45 ttl=64 time=4.997 ms

    ...

    So then I tried to SSH and do a ps aux (results below)

    ...

    All of this time VNC viewer is responding with
    VNC Server is not currently listening for Cloud connections.




    Ok. so we've established that the Pi *is* booting - and taking about 43
    seconds to start responding to pings - assuming that you started the ping command as you applied power to the Pi to start it booting, and that your
    pings are once a second.

    And SSH is working OK: its listener process must be starting long before
    VNC's starts.


    So it's not the failure-to-boot problem of not having an HDMI monitor to detect. But something else is preventing the VNC listener starting when
    there's no HDMI device present.



    Ah, a thought has just occurred to me. That word "cloud" in "VNC Server is
    not currently listening for Cloud connections". There are two ways of establishing a VNC connection. One involves referring to the computer (in
    your case, the Pi) by its name, and goes via a central cloud server. The
    other is a direct connection by IP address and does not rely on a cloud
    server. The default is to use the cloud server: it works for RealVNC server
    on *any* platform, even if you have the free rather than paid-for
    subscription version of VNC.

    The VNC server component that is built into Raspian/RasPiOS is a special
    case: even without a paid-for subscription, clients can connect to it
    directly by IP address.

    At your VNC Viewer client (on your non-Pi computer), try configuring a
    direct connection. For the Windows version, to the right of the "VNC
    Connect" logo there is a box with the default wording "Enter a VNC Server address of search". Hopefully it's similar for your Mac client. In this box, type the IP address of the Pi. And see whether you can connect any sooner
    this way than via the cloud.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Andy Burns@3:770/3 to All on Sat Jun 12 17:00:59 2021
    NY wrote:

    That word "cloud" in "VNC Server is not currently listening for Cloud connections". There are two ways of establishing a VNC connection.

    VNC was always direct (either forward on TCP/5900 or reverse on
    TCP/5500) when I was using it, having a rendezvous with a 3rd party
    server in the cloud was the teamviewer or anydesk way of doing it (with
    pros and cons).

    How long does the Pi take to register with this VNC cloud?

    <https://help.realvnc.com/hc/en-us/articles/360003474692-Why-is-VNC-Server-not-currently-listening-for-Cloud-connections->
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From NY@3:770/3 to Andy Burns on Sat Jun 12 19:16:46 2021
    "Andy Burns" <usenet@andyburns.uk> wrote in message news:iik41rFq5upU1@mid.individual.net...
    NY wrote:

    That word "cloud" in "VNC Server is not currently listening for Cloud
    connections". There are two ways of establishing a VNC connection.

    VNC was always direct (either forward on TCP/5900 or reverse on TCP/5500) when I was using it, having a rendezvous with a 3rd party server in the
    cloud was the teamviewer or anydesk way of doing it (with pros and cons).

    In my RealVNC address book I have two entries for my Pis - one using the
    normal cloud method (*) and the other using direct connection. And the connection speed reported by VNC is very different: the cloud one is capped
    at roughly the upstream (slower) speed of my broadband connection. That does rather suggest that a cloud connection routes data out onto the WAN and then back in again.

    I've just connected directly from my Windows PC to one of my Pis, where both computers and the router are Gigabit compatible. In the pull-down menu at
    the top of the remote desktop, there is an "i" icon. It reports Connection
    Type = Direct TCP and Line speed estimate = 750110 kbits/sec. Having closed that connection and opened one via the cloud to the same Pi, results are Connection Type = Cloud connection to [LAN IP}:50556 and Line speed
    estimate = 10560.kbits/sec - and Ookla Speedtest gives my current speed as 29.18 Mbps D and 9.78 Mbps (ie 9780 kbps) U. That suggests that a direct connection is almost full Gigabit speed and cloud speed is similar to
    upstream WAN speed.


    (*) I only use this if I need to access the Pi from outside my LAN - eg from
    my phone or laptop when away from home.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris B@3:770/3 to All on Sun Jun 13 09:05:26 2021
    On 12/06/2021 15:44, NY wrote:
    "Chris B (News)" <cjb200@gmail.com> wrote in message news:a833b994-8d62-490f-9c37-707cfa38a5cdn@googlegroups.com...
    On Saturday, 12 June 2021 at 11:13:53 UTC+1, Andy Burns wrote:
    Chris B wrote:

    Does anyone have any idea where I should look?
    does SSH access become available before VNC access?

    if so, can you see the VNC process, is anything listening on the VNC
    port?

    Apologies if this formats incorrectly but I am away from home at the
    moment using Google Groups
    rather than the more familiar T Bird

    I have uninstalled the "motion" package

    I rebooted and tried to ping immeadiately

    chris@Johns-iMac ~ % ping 192.168.1.22
    PING 192.168.1.22 (192.168.1.22): 56 data bytes
    Request timeout for icmp_seq 0
    Request timeout for icmp_seq 1
    Request timeout for icmp_seq 2
    Request timeout for icmp_seq 3
    Request timeout for icmp_seq 4
    Request timeout for icmp_seq 5
    Request timeout for icmp_seq 6
    ping: sendto: No route to host

    {lots of similar lines deleted}

    Request timeout for icmp_seq 43
    64 bytes from 192.168.1.22: icmp_seq=44 ttl=64 time=8.094 ms
    64 bytes from 192.168.1.22: icmp_seq=45 ttl=64 time=4.997 ms

    ...

    So then I tried to SSH and do a ps aux (results below)

    ...

    All of this time VNC viewer is responding with
    VNC Server is not currently listening for Cloud connections.




    Ok. so we've established that the Pi *is* booting - and taking about 43 seconds to start responding to pings - assuming that you started the
    ping command as you applied power to the Pi to start it booting, and
    that your pings are once a second.

    And SSH is working OK: its listener process must be starting long before VNC's starts.


    So it's not the failure-to-boot problem of not having an HDMI monitor to detect. But something else is preventing the VNC listener starting when there's no HDMI device present.



    Ah, a thought has just occurred to me. That word "cloud" in "VNC Server
    is not currently listening for Cloud connections". There are two ways of establishing a VNC connection. One involves referring to the computer
    (in your case, the Pi) by its name, and goes via a central cloud server.
    The other is a direct connection by IP address and does not rely on a
    cloud server. The default is to use the cloud server: it works for
    RealVNC server on *any* platform, even if you have the free rather than paid-for subscription version of VNC.

    The VNC server component that is built into Raspian/RasPiOS is a special case: even without a paid-for subscription, clients can connect to it directly by IP address.

    At your VNC Viewer client (on your non-Pi computer), try configuring a
    direct connection. For the Windows version, to the right of the "VNC
    Connect" logo there is a box with the default wording "Enter a VNC
    Server address of search". Hopefully it's similar for your Mac client.
    In this box, type the IP address of the Pi. And see whether you can
    connect any sooner this way than via the cloud.


    Just tried that and in the period when the cloud connection is
    "VNC Server is not currently listening for Cloud connections."

    the direct connection method you suggest gives
    "Timed out waiting for a response from the computer"

    as soon as the cloud connection is up and running so is the direct method.

    Once up and running the CPU usage is very low - usually well below 5%
    with the odd spike to 20% or so, so its not as if something else is
    using all of the processing power.

    I asked myself what is different about this machine and my other 2.
    1) This one has the camera interface enabled
    2) This one has had the motion package installed and removed.

    So I have disabled the camera interface - no change.
    Perhaps 2 has corrupted something somewhere.

    It looks like this isn't a quick and easy fix that lots of people know
    but I don't so perhaps it is time for the SD card reformat option and
    start again from scratch. This time play with the camera without
    trying motion. Its all part of the learning experience :-)




    --
    Chris B (News)
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to All on Sun Jun 13 10:10:34 2021
    On 12/06/2021 11:14, NY wrote:
    Thinking about this a bit more, I can't see that any software which auto-starts on your Pi (but which I don't have on mine) would be started early enough to cause a no/go-go on the booting process.

    Could be an excessive amount of time to obtain a DHCP lease. If you use raspi-config to set wait for network at boot, you should see this
    happening with an attached display.

    ---druck

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to druck on Sun Jun 13 10:12:29 2021
    On 13/06/2021 10:10, druck wrote:
    On 12/06/2021 11:14, NY wrote:
    Thinking about this a bit more, I can't see that any software which
    auto-starts on your Pi (but which I don't have on mine) would be
    started early enough to cause a no/go-go on the booting process.

    Could be an excessive amount of time to obtain a DHCP lease. If you use raspi-config to set wait for network at boot, you should see this
    happening with an attached display.

    Ignore that, just read other branch of thread and it seems networking is
    up fairly quickly.

    ---druck

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From NY@3:770/3 to Chris B on Sun Jun 13 11:00:00 2021
    "Chris B" <news@salis.co.uk> wrote in message news:sa4e87$5d1$1@dont-email.me...

    It looks like this isn't a quick and easy fix that lots of people know but
    I don't so perhaps it is time for the SD card reformat option and start
    again from scratch. This time play with the camera without trying
    motion. Its all part of the learning experience :-)

    Yes, that's how I rationalised it when I had to reinstall my Pi: once
    because something catastrophic happened between a clean shutdown and a clean startup (no power cuts at that time), so the Pi failed very early in the
    boot process; secondly when I bought a Pi4 and migrated software from the
    Pi3; thirdly because an update on the Pi4 invoked by sudo apt update
    followed by sudo apt full-upgrade caused a program (or a device driver) to misbehave (the Pi was running TVHeadend as a video recorder; after the
    upgrade recordings from the satellite decoder started intermittently experiencing massive numbers of data errors, as if the satellite signal had become badly degraded by noise). I will not be installing any updates on the
    Pi - especially ones which update the kernel.

    Luckily I made detailed notes of all the customisations I made as I was
    doing the first reinstallation (Pi wouldn't boot) and was able to refer to those to make sure I carried out the same stages (with appropriate modifications when going from Pi3 to Pi4) for initial installation and then
    the reinstallation (duff satellite tuner driver).


    In your case, I'd get VNC server working early in the build process, and
    prove that it works, and then retry it periodically as new software is installed, to find out what provokes it. Maybe also take an image of the SD card before each significant new installation so you can roll back to just before, rather than having to go right back to the beginning.

    That reminds me: it's probably about time I updated the SD images of my Pis
    as rollback insurance, so I roll back to as late a state as possible rather than to how they were several months ago.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From NY@3:770/3 to druck on Sun Jun 13 11:02:24 2021
    "druck" <news@druck.org.uk> wrote in message
    news:sa4i5t$prj$2@dont-email.me...
    On 13/06/2021 10:10, druck wrote:
    On 12/06/2021 11:14, NY wrote:
    Thinking about this a bit more, I can't see that any software which
    auto-starts on your Pi (but which I don't have on mine) would be started >>> early enough to cause a no/go-go on the booting process.

    Could be an excessive amount of time to obtain a DHCP lease. If you use
    raspi-config to set wait for network at boot, you should see this
    happening with an attached display.

    Ignore that, just read other branch of thread and it seems networking is
    up fairly quickly.

    LOL. I was just about to point that out, but you got there first.

    Another off-the-wall suggestion to the OP (you may already have tried this). What happens if you boot up headless and then some time in the expected 10 minute delay plug the monitor in? Does that immediately allow VNC to accept connections?
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris B@3:770/3 to All on Mon Jun 14 09:55:43 2021
    On 13/06/2021 11:00, NY wrote:
    "Chris B" <news@salis.co.uk> wrote in message news:sa4e87$5d1$1@dont-email.me...

    It looks like this isn't a quick and easy fix that lots of people know
    but I don't so perhaps it is time for the SD card reformat option and
    start again from scratch.   This time play with the camera without
    trying motion.   Its all part of the learning experience  :-)



    That reminds me: it's probably about time I updated the SD images of my
    Pis as rollback insurance, so I roll back to as late a state as possible rather than to how they were several months ago.

    Thanks to you (and others) for suggestions and help, it is much
    appreciated. I have now returned to a fully serviceable PiZero with a
    camera connection.

    The comment about SD card backups is noted and from now forwards will be carried out before major changes.




    --
    Chris B (News)

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Martin Gregorie@3:770/3 to Chris B on Mon Jun 14 14:09:53 2021
    On Mon, 14 Jun 2021 09:55:43 +0100, Chris B wrote:

    The comment about SD card backups is noted and from now forwards will be carried out before major changes.

    You may like to take a look at the 'rsync' backup package if you're not
    already using it. Its fast because, rather than taking a full backup, it
    brings the backup into line with the current state of play on your live
    system, adding/deleting/replacing files and directories as needed to
    capture each current machine state.

    I have a pair of 1GB WD Essential USB drives which are kept offline and
    used alternatively to do a weekly backup of all my systems (3x Linux x86
    and (currently) one RPi), so I always have last week's set of backups
    offline in a fire safe while the two week old backup disk is being
    updated to capture the current system states.


    --
    Martin | martin at
    Gregorie | gregorie dot org

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)