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)

"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

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)

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

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>

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?

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

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

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

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

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

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:0-eve]
root 4 0.0 0.0 0 0 ? I< 15:02 0:00 [kworker/0:0H-kb]
root 5 0.0 0.0 0 0 ? I 15:02 0:00 [kworker/u2:0-ev]
root 6 0.0 0.0 0 0 ? I< 15:02 0:00 [mm_percpu_wq]
root 7 0.4 0.0 0 0 ? S 15:02 0:00 [ksoftirqd/0]
root 8 0.0 0.0 0 0 ? S 15:02 0:00 [kdevtmpfs]
root 9 0.0 0.0 0 0 ? I< 15:02 0:00 [netns]
root 10 0.2 0.0 0 0 ? I 15:02 0:00 [kworker/0:1-eve]
root 11 0.0 0.0 0 0 ? S 15:02 0:00 [khungtaskd]
root 12 0.0 0.0 0 0 ? S 15:02 0:00 [oom_reaper]
root 13 0.0 0.0 0 0 ? I< 15:02 0:00 [writeback]
root 14 0.0 0.0 0 0 ? S 15:02 0:00 [kcompactd0]
root 15 0.0 0.0 0 0 ? I< 15:02 0:00 [crypto]
root 16 0.0 0.0 0 0 ? I< 15:02 0:00 [kblockd]
root 17 0.0 0.0 0 0 ? S 15:02 0:00 [watchdogd]
root 18 0.0 0.0 0 0 ? I< 15:02 0:00 [rpciod]
root 19 0.0 0.0 0 0 ? I< 15:02 0:00 [kworker/u3:0-hc]
root 20 0.0 0.0 0 0 ? I< 15:02 0:00 [xprtiod]
root 21 0.1 0.0 0 0 ? I 15:02 0:00 [kworker/u2:1-br]
root 23 0.0 0.0 0 0 ? S 15:02 0:00 [kswapd0]
root 24 0.0 0.0 0 0 ? I< 15:02 0:00 [nfsiod]
root 35 0.0 0.0 0 0 ? I< 15:02 0:00 [kthrotld]
root 36 0.0 0.0 0 0 ? I< 15:02 0:00 [iscsi_eh]
root 37 0.0 0.0 0 0 ? I< 15:02 0:00 [dwc_otg]
root 38 0.0 0.0 0 0 ? I< 15:02 0:00 [DWC Notificatio]
root 39 0.0 0.0 0 0 ? S< 15:02 0:00 [vchiq-slot/0]
root 40 0.0 0.0 0 0 ? S< 15:02 0:00 [vchiq-recy/0]
root 41 0.0 0.0 0 0 ? S< 15:02 0:00 [vchiq-sync/0]
root 42 0.0 0.0 0 0 ? S 15:02 0:00 [vchiq-keep/0]
root 43 0.0 0.0 0 0 ? S< 15:02 0:00 [SMIO]
root 44 0.0 0.0 0 0 ? S 15:02 0:00 [irq/86-mmc1]
root 45 0.0 0.0 0 0 ? I 15:02 0:00 [kworker/0:2-eve]
root 46 0.0 0.0 0 0 ? I 15:02 0:00 [kworker/0:3-eve]
root 47 0.0 0.0 0 0 ? I< 15:02 0:00 [mmc_complete]
root 48 1.9 0.0 0 0 ? I< 15:02 0:01 [kworker/0:1H-mm]
root 49 0.0 0.0 0 0 ? I< 15:02 0:00 [kworker/0:2H]
root 50 0.0 0.0 0 0 ? S 15:02 0:00 [jbd2/mmcblk0p7-]
root 51 0.0 0.0 0 0 ? I< 15:02 0:00 [ext4-rsv-conver]
root 52 0.0 0.0 0 0 ? I< 15:02 0:00 [ipv6_addrconf]
root 69 1.8 1.1 9200 4308 ? Ss 15:02 0:01 /lib/systemd/systemd-journald
root 103 1.4 0.8 14716 3212 ? Ss 15:02 0:01 /lib/systemd/systemd-udevd
root 113 0.1 0.0 0 0 ? I 15:02 0:00 [kworker/u2:2-br]
root 133 8.0 0.0 0 0 ? S 15:02 0:05 [w1_bus_master1]
root 134 0.0 0.0 0 0 ? S< 15:02 0:00 [SMIO]
root 142 0.0 0.0 0 0 ? I< 15:02 0:00 [mmal-vchiq]
root 143 0.0 0.0 0 0 ? I< 15:02 0:00 [mmal-vchiq]
root 151 0.0 0.0 0 0 ? I< 15:02 0:00 [mmal-vchiq]
root 152 0.0 0.0 0 0 ? I< 15:02 0:00 [mmal-vchiq]
root 153 0.0 0.0 0 0 ? I< 15:02 0:00 [mmal-vchiq]
root 163 0.0 0.0 0 0 ? I< 15:02 0:00 [cfg80211]
root 167 0.0 0.0 0 0 ? I< 15:02 0:00 [brcmf_wq/mmc1:0]
root 168 0.0 0.0 0 0 ? S 15:02 0:00 [brcmf_wdog/mmc1]
root 171 0.0 0.0 0 0 ? I 15:02 0:00 [kworker/0:4-eve]
systemd+ 196 0.4 1.0 17264 4024 ? Ssl 15:02 0:00 /lib/systemd/systemd-timesyncd
root 224 0.0 0.6 5284 2364 ? Ss 15:02 0:00 /usr/sbin/cron -f
nobody 230 0.0 0.6 5276 2536 ? Ss 15:02 0:00 /usr/sbin/thd --triggers /etc/triggerhappy/triggers.d/ --socket /run/thd.socket --user nobody --deviceglob /dev/input/event
root 232 0.0 0.6 6880 2536 ? S 15:02 0:00 /usr/sbin/CRON -f
message+ 242 1.4 0.9 6644 3716 ? Ss 15:02 0:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
pi 258 0.0 0.3 1880 1228 ? Ss 15:02 0:00 /bin/sh -c vncserver start
pi 262 0.1 0.8 6648 3176 ? S 15:02 0:00 vncserver start
pi 265 0.2 1.8 16020 7096 ? S 15:02 0:00 /usr/bin/Xvnc-core :1 -auth /home/pi/.Xauthority -pn -fp /usr/share/fonts/X11/100dpi/:unscaled,/usr/share/fonts/X11/100dpi,
root 266 0.1 1.0 9988 3944 ? Ss 15:02 0:00 /sbin/wpa_supplicant -u -s -O /run/wpa_supplicant
root 268 0.0 0.9 7784 3608 ? S 15:02 0:00 /usr/bin/Xvnc -rootHelper 1000 4
root 269 0.7 2.0 50844 7628 ? Ssl 15:02 0:00 /usr/sbin/ModemManager
avahi 273 0.2 0.8 6384 3192 ? Ss 15:02 0:00 avahi-daemon: running [pizero2.local]
root 277 0.4 1.1 7368 4300 ? Ss 15:02 0:00 /lib/systemd/systemd-logind
root 278 0.3 0.7 22856 2996 ? Ssl 15:02 0:00 /usr/sbin/rsyslogd -n
avahi 281 0.0 0.3 6384 1504 ? S 15:02 0:00 avahi-daemon: chroot helper
root 293 0.7 1.9 37880 7216 ? Ssl 15:02 0:00 /usr/lib/policykit-1/polkitd --no-debug
root 305 0.0 0.0 0 0 ? I< 15:02 0:00 [kworker/u3:1-hc]
root 306 0.0 0.1 2076 664 ? S 15:02 0:00 /usr/bin/hciattach /dev/serial1 bcm43xx 3000000 flow - b8:27:eb:a7:8d:fc
root 307 0.0 0.0 0 0 ? I< 15:02 0:00 [kworker/u3:2-hc]
root 318 0.2 1.0 7260 4104 ? Ss 15:02 0:00 /usr/lib/bluetooth/bluetoothd
root 320 0.1 1.2 35028 4780 ? Ssl 15:02 0:00 /usr/bin/bluealsa
root 336 0.0 0.0 0 0 ? S< 15:02 0:00 [krfcommd]
root 396 0.0 0.7 5692 2736 ? Ss 15:02 0:00 /usr/bin/vncserver-x11-serviced -fg
root 399 0.1 1.7 11568 6508 ? S 15:02 0:00 /usr/bin/vncserver-x11-core -service
root 408 0.3 1.5 44568 5692 ? Ssl 15:02 0:00 /usr/sbin/lightdm
root 409 0.0 1.0 10572 3972 ? Ss 15:02 0:00 /sbin/wpa_supplicant -s -B -P /run/wpa_supplicant.wlan0.pid -i wlan0 -W -D nl80211,wext -c /etc/wpa_supplicant/wpa_supplica
root 413 0.5 1.3 10196 5252 ? Ss 15:02 0:00 /usr/sbin/sshd -D
root 421 0.1 0.7 5972 2944 tty1 Ss 15:02 0:00 /bin/login -f
root 423 3.2 10.2 124572 38568 tty7 Ssl+ 15:02 0:01 /usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
pi 453 0.9 1.5 9744 5896 ? Ss 15:02 0:00 /lib/systemd/systemd --user
pi 461 0.0 0.7 11376 2868 ? S 15:02 0:00 (sd-pam)
root 480 0.0 0.3 2628 1416 ? Ss 15:02 0:00 /sbin/wpa_cli -B -P /run/wpa_action.wlan0.pid -i wlan0 -p /var/run/wpa_supplicant -a /sbin/wpa_action
pi 486 1.3 1.0 6080 4004 tty1 S+ 15:02 0:00 -bash
root 570 0.4 1.6 29704 6400 ? Sl 15:02 0:00 lightdm --session-child 14 17
root 589 0.0 0.5 6640 2032 ? Ss 15:02 0:00 /sbin/dhclient -4 -v -pf /run/dhclient.wlan0.pid -lf /var/lib/dhcp/dhclient.wlan0.leases -I -df /var/lib/dhcp/dhclient6.wla
pi 610 0.9 3.0 49980 11716 ? Ssl 15:02 0:00 /usr/bin/lxsession -s LXDE-pi -e LXDE
pi 619 0.7 0.9 6500 3584 ? Ss 15:02 0:00 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation
pi 658 0.0 0.2 3784 1028 ? Ss 15:02 0:00 /usr/bin/ssh-agent x-session-manager
pi 665 0.4 1.5 38620 5836 ? Ssl 15:02 0:00 /usr/lib/gvfs/gvfsd
pi 670 0.2 1.4 51180 5376 ? Sl 15:02 0:00 /usr/lib/gvfs/gvfsd-fuse /run/user/1000/gvfs -f -o big_writes
pi 685 2.1 3.7 53024 14088 ? S 15:02 0:00 openbox --config-file /home/pi/.config/openbox/lxde-pi-rc.xml
pi 688 0.5 2.8 43316 10824 ? Sl 15:02 0:00 lxpolkit
pi 691 7.5 6.3 126712 24084 ? Sl 15:02 0:02 lxpanel --profile LXDE-pi
pi 694 8.6 5.7 97632 21748 ? Sl 15:02 0:03 pcmanfm --desktop --profile LXDE-pi
pi 724 0.0 0.2 3784 1052 ? Ss 15:02 0:00 /usr/bin/ssh-agent -s
pi 745 0.1 1.3 26192 4984 ? Ssl 15:02 0:00 /usr/lib/menu-cache/menu-cached /run/user/1000/menu-cached-:0
pi 752 0.0 0.0 0 0 ? Z 15:02 0:00 [sh] <defunct>
pi 757 1.6 2.9 73404 11044 ? Ssl 15:02 0:00 /usr/lib/gvfs/gvfs-udisks2-volume-monitor
root 760 1.7 2.0 54748 7852 ? Ssl 15:02 0:00 /usr/lib/udisks2/udisksd --no-debug
pi 767 0.2 1.4 37800 5596 ? Ssl 15:03 0:00 /usr/lib/gvfs/gvfs-gphoto2-volume-monitor
pi 772 0.3 1.8 48928 7060 ? Ssl 15:03 0:00 /usr/lib/gvfs/gvfs-afc-volume-monitor
pi 779 0.2 1.4 36316 5308 ? Ssl 15:03 0:00 /usr/lib/gvfs/gvfs-goa-volume-monitor
pi 783 0.2 1.4 36236 5316 ? Ssl 15:03 0:00 /usr/lib/gvfs/gvfs-mtp-volume-monitor
pi 819 0.7 1.7 47056 6684 ? Sl 15:03 0:00 /usr/lib/gvfs/gvfsd-trash --spawner :1.4 /org/gtk/gvfs/exec_spaw/0
root 830 0.0 0.0 0 0 ? S 15:03 0:00 [jbd2/mmcblk0p5-]
root 831 0.0 0.0 0 0 ? I< 15:03 0:00 [ext4-rsv-conver]
root 833 2.7 1.5 11620 5776 ? Ss 15:03 0:00 sshd: pi [priv]
pi 845 1.5 1.0 11620 3788 ? S 15:03 0:00 sshd: pi@pts/0
pi 848 10.2 1.0 6072 4020 pts/0 Ss 15:03 0:00 -bash
pi 867 0.0 0.7 7728 2848 pts/0 R+ 15:03 0:00 ps aux
pi@pizero2:~ $

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

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

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

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)

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

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

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

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

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)

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