Open oliverschmidt opened 7 years ago
I'll have a look at this when I'm felling a little better (nasty virus thing). I think this has not been fixed, however the files on Ivan's website are no longer being updated, so you'll want to look at the sources on github going forward.
Thanks for your quick feedback. I looked at https://github.com/RasppleII/a2cloud/blob/master/setup/vsd.txt#L35 and I didn't see a relevant change.
I'm under the impression, perhaps mistaken, that xvfb-run's purpose is to start Xvfb with appropriate arguments, then kill it when the command completes, and in my tests it seems to be doing that. It doesn't always die immediately on RPi, but it does exit.
Ah, a thought: Do the extra Xvfbs disappear after 30 seconds?
https://github.com/RasppleII/a2cloud/blob/master/setup/adtpro.sh.txt#L143
I redid everything from scratch in order to reproduce:
#!/bin/bash
# don't do anything if ADTPro is already running
if [[ $(ps aux | grep [A]DTPro) ]]; then
1&>2 echo "ADTPro server is already running."
else
echo -n "Please wait..."
sudo nohup adtpro.sh headless ethernet &> /dev/null
echo "ok."
fi
adtpro-start
vsd1
several times to mount a new disk imageps -ef | grep --color=none vfb
and getroot 3076 1 0 10:20 pts/1 00:00:02 Xvfb :99 -screen 0 640x480x8 -nolisten tcp -auth /tmp/xvfb-run.TkBQRf/Xauthority
root 3186 1 0 10:32 pts/1 00:00:02 Xvfb :100 -screen 0 640x480x8 -nolisten tcp -auth /tmp/xvfb-run.fOhgCn/Xauthority
root 3265 1 0 10:33 pts/1 00:00:02 Xvfb :101 -screen 0 640x480x8 -nolisten tcp -auth /tmp/xvfb-run.SHREYc/Xauthority
root 3324 1 0 10:34 pts/1 00:00:00 /bin/sh /usr/bin/xvfb-run --auto-servernum java -Xms256m -Xmx512m -Djava.library.path=/usr/local/adtpro/lib/rxtx/rxtx-2.2pre2-local/arm -Dgnu.io.rxtx.SerialPorts=/dev/ -cp ../lib/ADTPro.jar:../lib/rxtx/rxtx-2.2pre2-local/arm/../RXTXcomm.jar:../lib/AppleCommander/AppleCommander-ac.jar org.adtpro.ADTPro ethernet
root 3337 3324 0 10:34 pts/1 00:00:01 Xvfb :102 -screen 0 640x480x8 -nolisten tcp -auth /tmp/xvfb-run.TKcqUv/Xauthority
pi 3376 2985 0 10:47 pts/1 00:00:00 grep --color=auto --color=none vfb
If they aren't dying after 30 seconds, that's definitely a bug. (They shouldn't need 30 seconds to die, but I've never really trusted that sleep as a means of keeping people from running ADTPro more than once on older Pis...) Still, if something's keeping Xvfb running, I'm not sure what it is--it's supposed to exit when the command does, and other clients do properly quit out. I wonder if java is just not exiting?
Perhaps there's some way, as a workaround for the time being, that we can identify the Xvfb process in need of killing and dispatch it ourselves? Might have to rewrite the xvfb-run script to do it, although that'd make our solution portable to non-Debian-based Linux systems which have Xvfb, but don't have Branden's xvfb-run script. That's a plus all on its own since, although I intend to make things be installed using Debian packages, part of the reason for doing it that way is to eventually divorce A2CLOUD and A2SERVER from specific dependency on Debian by moving the Debianisms to Debian package scripts.
I wonder if java is just not exiting?
No. Many Xvfb, but only one xvfb-run and only one java:
pi@raspberrypi /usr/local/adtpro/disks $ ps -ef
UID PID PPID C STIME TTY TIME CMD
root 1 0 3 15:03 ? 00:00:22 init [2]
root 2 0 0 15:03 ? 00:00:00 [kthreadd]
root 3 2 0 15:03 ? 00:00:00 [ksoftirqd/0]
root 5 2 0 15:03 ? 00:00:00 [kworker/0:0H]
root 6 2 0 15:03 ? 00:00:00 [kworker/u2:0]
root 7 2 0 15:03 ? 00:00:00 [rcu_preempt]
root 8 2 0 15:03 ? 00:00:00 [rcu_sched]
root 9 2 0 15:03 ? 00:00:00 [rcu_bh]
root 10 2 0 15:03 ? 00:00:00 [khelper]
root 11 2 0 15:03 ? 00:00:00 [kdevtmpfs]
root 12 2 0 15:03 ? 00:00:00 [netns]
root 13 2 0 15:03 ? 00:00:00 [perf]
root 14 2 0 15:03 ? 00:00:00 [khungtaskd]
root 15 2 0 15:03 ? 00:00:00 [writeback]
root 16 2 0 15:03 ? 00:00:00 [crypto]
root 17 2 0 15:03 ? 00:00:00 [bioset]
root 18 2 0 15:03 ? 00:00:00 [kblockd]
root 20 2 0 15:03 ? 00:00:00 [rpciod]
root 21 2 0 15:03 ? 00:00:00 [kswapd0]
root 22 2 0 15:03 ? 00:00:00 [fsnotify_mark]
root 23 2 0 15:03 ? 00:00:00 [nfsiod]
root 29 2 0 15:03 ? 00:00:00 [kthrotld]
root 30 2 0 15:03 ? 00:00:00 [VCHIQ-0]
root 31 2 0 15:03 ? 00:00:00 [VCHIQr-0]
root 32 2 0 15:03 ? 00:00:00 [VCHIQs-0]
root 33 2 0 15:03 ? 00:00:00 [iscsi_eh]
root 34 2 0 15:03 ? 00:00:00 [dwc_otg]
root 35 2 0 15:03 ? 00:00:00 [DWC Notificatio]
root 36 2 0 15:03 ? 00:00:00 [kworker/0:2]
root 37 2 0 15:03 ? 00:00:00 [kworker/u2:1]
root 38 2 0 15:03 ? 00:00:00 [mmcqd/0]
root 39 2 0 15:03 ? 00:00:00 [VCHIQka-0]
root 40 2 0 15:03 ? 00:00:00 [SMIO]
root 41 2 0 15:03 ? 00:00:00 [deferwq]
root 42 2 0 15:03 ? 00:00:00 [jbd2/mmcblk0p6-]
root 43 2 0 15:03 ? 00:00:00 [ext4-rsv-conver]
root 158 1 0 15:03 ? 00:00:00 udevd --daemon
root 1668 1 0 15:03 ? 00:00:00 /usr/sbin/ifplugd -i wlan0 -q -f -u0 -d10 -w -I
root 1696 1 0 15:04 ? 00:00:00 /usr/sbin/ifplugd -i lo -q -f -u0 -d10 -w -I
root 1717 1 0 15:04 ? 00:00:00 /usr/sbin/ifplugd -i eth0 -q -f -u0 -d10 -w -I
root 1731 2 0 15:04 ? 00:00:00 [RTW_CMD_THREAD]
root 1759 1 0 15:04 ? 00:00:00 /sbin/wpa_supplicant -s -B -P /var/run/wpa_supplicant.wlan0.pid -i wlan0 -W -D nl80211,wext -c /etc/wpa_supplicant/wpa_supplicant.conf
root 1899 1 0 15:04 ? 00:00:00 /sbin/wpa_cli -B -P /var/run/wpa_action.wlan0.pid -i wlan0 -p /var/run/wpa_supplicant -a /sbin/wpa_action
root 2025 1 0 15:04 ? 00:00:00 /sbin/a2pid --daemon
root 2043 158 0 15:04 ? 00:00:00 udevd --daemon
root 2045 158 0 15:04 ? 00:00:00 udevd --daemon
root 2124 1 0 15:04 ? 00:00:00 /usr/sbin/rsyslogd -c5
root 2185 1 0 15:04 ? 00:00:00 /usr/sbin/cron
root 2203 1 0 15:04 ? 00:00:00 /usr/sbin/nmbd -D
root 2211 1 0 15:04 ? 00:00:00 /usr/sbin/smbd -D
root 2234 2211 0 15:04 ? 00:00:00 /usr/sbin/smbd -D
104 2244 1 0 15:04 ? 00:00:00 /usr/bin/dbus-daemon --system
avahi 2284 1 0 15:04 ? 00:00:00 avahi-daemon: running [raspberrypi.local]
avahi 2286 2284 0 15:04 ? 00:00:00 avahi-daemon: chroot helper
nobody 2324 1 0 15:04 ? 00:00:00 /usr/bin/gdomap -I /var/run/gdomap.pid -p
root 2325 1 0 15:04 ? 00:00:00 startpar -f -- gdomap
root 2386 1 0 15:04 ? 00:00:00 /usr/local/sbin/atalkd
109 2711 1 0 15:04 ? 00:00:00 /usr/sbin/exim4 -bd -q30m
nobody 2775 1 0 15:04 ? 00:00:00 /usr/sbin/thd --daemon --triggers /etc/triggerhappy/triggers.d/ --socket /var/run/thd.socket --pidfile /var/run/thd.pid --user nobody /dev/input/e
xrdp 2785 1 0 15:04 ? 00:00:00 /usr/sbin/xrdp
root 2788 1 0 15:04 ? 00:00:00 /usr/sbin/xrdp-sesman
root 2826 1 0 15:04 tty1 00:00:00 /sbin/getty --noclear 38400 tty1
root 2827 1 0 15:04 tty2 00:00:00 /sbin/getty 38400 tty2
root 2828 1 0 15:04 tty3 00:00:00 /sbin/getty 38400 tty3
root 2829 1 0 15:04 tty4 00:00:00 /sbin/getty 38400 tty4
root 2830 1 0 15:04 tty5 00:00:00 /sbin/getty 38400 tty5
root 2831 1 0 15:04 tty6 00:00:00 /sbin/getty 38400 tty6
root 2832 1 0 15:04 ? 00:00:00 /bin/bash /usr/local/sbin/usbgetty -h -L -scanttyUSB 4800 vt100
ntp 2833 1 0 15:04 ? 00:00:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -c /var/lib/ntp/ntp.conf.dhcp -u 102:104
root 2837 1 0 15:04 ? 00:00:00 dhclient -v -pf /run/dhclient.wlan0.pid -lf /var/lib/dhcp/dhclient.wlan0.leases wlan0
root 2863 2832 0 15:04 ? 00:00:00 sleep 86399
root 2914 1 0 15:04 ? 00:00:00 /usr/sbin/sshd
root 2928 2914 0 15:04 ? 00:00:00 sshd: pi [priv]
pi 2934 2928 0 15:04 ? 00:00:00 sshd: pi@pts/1
pi 2935 2934 0 15:04 pts/1 00:00:02 -bash
root 2966 1 0 15:04 ? 00:00:00 /usr/local/sbin/cnid_metad -l log_note
root 2971 1 0 15:04 ? 00:00:00 /usr/local/sbin/afpd -U uams_dhx2.so -g pi -c 50 -n raspberrypi
root 2972 1 0 15:04 ? 00:00:00 /usr/local/sbin/a2boot
root 3061 1 0 15:06 pts/1 00:00:02 Xvfb :99 -screen 0 640x480x8 -nolisten tcp -auth /tmp/xvfb-run.PpOfIX/Xauthority
root 3129 1 0 15:07 pts/1 00:00:02 Xvfb :100 -screen 0 640x480x8 -nolisten tcp -auth /tmp/xvfb-run.vNVTIC/Xauthority
root 3151 2 0 15:08 ? 00:00:00 [kworker/0:0]
root 3207 1 0 15:09 pts/1 00:00:02 Xvfb :101 -screen 0 640x480x8 -nolisten tcp -auth /tmp/xvfb-run.ogV947/Xauthority
root 3263 1 0 15:10 pts/1 00:00:00 /bin/sh /usr/bin/xvfb-run --auto-servernum java -Xms256m -Xmx512m -Djava.library.path=/usr/local/adtpro/lib/rxtx/rxtx-2.2pre2-local/arm -Dgnu.io.r
root 3276 3263 0 15:10 pts/1 00:00:01 Xvfb :102 -screen 0 640x480x8 -nolisten tcp -auth /tmp/xvfb-run.OmeDId/Xauthority
root 3279 3263 5 15:10 pts/1 00:00:14 java -Xms256m -Xmx512m -Djava.library.path=/usr/local/adtpro/lib/rxtx/rxtx-2.2pre2-local/arm -Dgnu.io.rxtx.SerialPorts=/dev/ -cp ../lib/ADTPro.jar
root 3299 2 0 15:13 ? 00:00:00 [kworker/0:1]
pi 3301 2935 0 15:15 pts/1 00:00:00 ps -ef
This is interesting. Would you please compare the sha1sum of your xvfb-run script with e7de6023507d8944f61fe04d2d6c5ee29df636ee ?
It should be the same, and I've got no doubt that it is as I suspect that script has changed one one iota since 2004. Its manpage clearly says:
When the command exits, its status is saved, the Xvfb server
is killed (using the process ID stored earlier), the X
authority cookie removed, and the authority file deleted (if
the user did not specify one to use). xvfb-run then exits
with the exit status of command.
If it's not, we can try jessie's xvfb-run. Otherwise, we're going to have to modify things to save that PID and kill it off.
Joseph
On Tue, Oct 25, 2016 at 12:16:17PM -0700, Oliver Schmidt wrote:
I wonder if java is just not exiting?
No. Many Xvfb, but only one xvfb-run and only one java:
pi@raspberrypi /usr/local/adtpro/disks $ ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 3 15:03 ? 00:00:22 init [2] root 2 0 0 15:03 ? 00:00:00 [kthreadd] root 3 2 0 15:03 ? 00:00:00 [ksoftirqd/0] root 5 2 0 15:03 ? 00:00:00 [kworker/0:0H] root 6 2 0 15:03 ? 00:00:00 [kworker/u2:0] root 7 2 0 15:03 ? 00:00:00 [rcu_preempt] root 8 2 0 15:03 ? 00:00:00 [rcu_sched] root 9 2 0 15:03 ? 00:00:00 [rcu_bh] root 10 2 0 15:03 ? 00:00:00 [khelper] root 11 2 0 15:03 ? 00:00:00 [kdevtmpfs] root 12 2 0 15:03 ? 00:00:00 [netns] root 13 2 0 15:03 ? 00:00:00 [perf] root 14 2 0 15:03 ? 00:00:00 [khungtaskd] root 15 2 0 15:03 ? 00:00:00 [writeback] root 16 2 0 15:03 ? 00:00:00 [crypto] root 17 2 0 15:03 ? 00:00:00 [bioset] root 18 2 0 15:03 ? 00:00:00 [kblockd] root 20 2 0 15:03 ? 00:00:00 [rpciod] root 21 2 0 15:03 ? 00:00:00 [kswapd0] root 22 2 0 15:03 ? 00:00:00 [fsnotify_mark] root 23 2 0 15:03 ? 00:00:00 [nfsiod] root 29 2 0 15:03 ? 00:00:00 [kthrotld] root 30 2 0 15:03 ? 00:00:00 [VCHIQ-0] root 31 2 0 15:03 ? 00:00:00 [VCHIQr-0] root 32 2 0 15:03 ? 00:00:00 [VCHIQs-0] root 33 2 0 15:03 ? 00:00:00 [iscsi_eh] root 34 2 0 15:03 ? 00:00:00 [dwc_otg] root 35 2 0 15:03 ? 00:00:00 [DWC Notificatio] root 36 2 0 15:03 ? 00:00:00 [kworker/0:2] root 37 2 0 15:03 ? 00:00:00 [kworker/u2:1] root 38 2 0 15:03 ? 00:00:00 [mmcqd/0] root 39 2 0 15:03 ? 00:00:00 [VCHIQka-0] root 40 2 0 15:03 ? 00:00:00 [SMIO] root 41 2 0 15:03 ? 00:00:00 [deferwq] root 42 2 0 15:03 ? 00:00:00 [jbd2/mmcblk0p6-] root 43 2 0 15:03 ? 00:00:00 [ext4-rsv-conver] root 158 1 0 15:03 ? 00:00:00 udevd --daemon root 1668 1 0 15:03 ? 00:00:00 /usr/sbin/ifplugd -i wlan0 -q -f -u0 -d10 -w -I root 1696 1 0 15:04 ? 00:00:00 /usr/sbin/ifplugd -i lo -q -f -u0 -d10 -w -I root 1717 1 0 15:04 ? 00:00:00 /usr/sbin/ifplugd -i eth0 -q -f -u0 -d10 -w -I root 1731 2 0 15:04 ? 00:00:00 [RTW_CMD_THREAD] root 1759 1 0 15:04 ? 00:00:00 /sbin/wpa_supplicant -s -B -P /var/run/wpa_supplicant.wlan0.pid -i wlan0 -W -D nl80211,wext -c /etc/wpa_supplicant/wpa_supplicant.conf root 1899 1 0 15:04 ? 00:00:00 /sbin/wpa_cli -B -P /var/run/wpa_action.wlan0.pid -i wlan0 -p /var/run/wpa_supplicant -a /sbin/wpa_action root 2025 1 0 15:04 ? 00:00:00 /sbin/a2pid --daemon root 2043 158 0 15:04 ? 00:00:00 udevd --daemon root 2045 158 0 15:04 ? 00:00:00 udevd --daemon root 2124 1 0 15:04 ? 00:00:00 /usr/sbin/rsyslogd -c5 root 2185 1 0 15:04 ? 00:00:00 /usr/sbin/cron root 2203 1 0 15:04 ? 00:00:00 /usr/sbin/nmbd -D root 2211 1 0 15:04 ? 00:00:00 /usr/sbin/smbd -D root 2234 2211 0 15:04 ? 00:00:00 /usr/sbin/smbd -D 104 2244 1 0 15:04 ? 00:00:00 /usr/bin/dbus-daemon --system avahi 2284 1 0 15:04 ? 00:00:00 avahi-daemon: running [raspberrypi.local] avahi 2286 2284 0 15:04 ? 00:00:00 avahi-daemon: chroot helper nobody 2324 1 0 15:04 ? 00:00:00 /usr/bin/gdomap -I /var/run/gdomap.pid -p root 2325 1 0 15:04 ? 00:00:00 startpar -f -- gdomap root 2386 1 0 15:04 ? 00:00:00 /usr/local/sbin/atalkd 109 2711 1 0 15:04 ? 00:00:00 /usr/sbin/exim4 -bd -q30m nobody 2775 1 0 15:04 ? 00:00:00 /usr/sbin/thd --daemon --triggers /etc/triggerhappy/triggers.d/ --socket /var/run/thd.socket --pidfile /var/run/thd.pid --user nobody /dev/input/e xrdp 2785 1 0 15:04 ? 00:00:00 /usr/sbin/xrdp root 2788 1 0 15:04 ? 00:00:00 /usr/sbin/xrdp-sesman root 2826 1 0 15:04 tty1 00:00:00 /sbin/getty --noclear 38400 tty1 root 2827 1 0 15:04 tty2 00:00:00 /sbin/getty 38400 tty2 root 2828 1 0 15:04 tty3 00:00:00 /sbin/getty 38400 tty3 root 2829 1 0 15:04 tty4 00:00:00 /sbin/getty 38400 tty4 root 2830 1 0 15:04 tty5 00:00:00 /sbin/getty 38400 tty5 root 2831 1 0 15:04 tty6 00:00:00 /sbin/getty 38400 tty6 root 2832 1 0 15:04 ? 00:00:00 /bin/bash /usr/local/sbin/usbgetty -h -L -scanttyUSB 4800 vt100 ntp 2833 1 0 15:04 ? 00:00:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -c /var/lib/ntp/ntp.conf.dhcp -u 102:104 root 2837 1 0 15:04 ? 00:00:00 dhclient -v -pf /run/dhclient.wlan0.pid -lf /var/lib/dhcp/dhclient.wlan0.leases wlan0 root 2863 2832 0 15:04 ? 00:00:00 sleep 86399 root 2914 1 0 15:04 ? 00:00:00 /usr/sbin/sshd root 2928 2914 0 15:04 ? 00:00:00 sshd: pi [priv] pi 2934 2928 0 15:04 ? 00:00:00 sshd: pi@pts/1 pi 2935 2934 0 15:04 pts/1 00:00:02 -bash root 2966 1 0 15:04 ? 00:00:00 /usr/local/sbin/cnid_metad -l log_note root 2971 1 0 15:04 ? 00:00:00 /usr/local/sbin/afpd -U uams_dhx2.so -g pi -c 50 -n raspberrypi root 2972 1 0 15:04 ? 00:00:00 /usr/local/sbin/a2boot root 3061 1 0 15:06 pts/1 00:00:02 Xvfb :99 -screen 0 640x480x8 -nolisten tcp -auth /tmp/xvfb-run.PpOfIX/Xauthority root 3129 1 0 15:07 pts/1 00:00:02 Xvfb :100 -screen 0 640x480x8 -nolisten tcp -auth /tmp/xvfb-run.vNVTIC/Xauthority root 3151 2 0 15:08 ? 00:00:00 [kworker/0:0] root 3207 1 0 15:09 pts/1 00:00:02 Xvfb :101 -screen 0 640x480x8 -nolisten tcp -auth /tmp/xvfb-run.ogV947/Xauthority root 3263 1 0 15:10 pts/1 00:00:00 /bin/sh /usr/bin/xvfb-run --auto-servernum java -Xms256m -Xmx512m -Djava.library.path=/usr/local/adtpro/lib/rxtx/rxtx-2.2pre2-local/arm -Dgnu.io.r root 3276 3263 0 15:10 pts/1 00:00:01 Xvfb :102 -screen 0 640x480x8 -nolisten tcp -auth /tmp/xvfb-run.OmeDId/Xauthority root 3279 3263 5 15:10 pts/1 00:00:14 java -Xms256m -Xmx512m -Djava.library.path=/usr/local/adtpro/lib/rxtx/rxtx-2.2pre2-local/arm -Dgnu.io.rxtx.SerialPorts=/dev/ -cp ../lib/ADTPro.jar root 3299 2 0 15:13 ? 00:00:00 [kworker/0:1] pi 3301 2935 0 15:15 pts/1 00:00:00 ps -ef
You are receiving this because you were assigned. Reply to this email directly or view it on GitHub: https://github.com/RasppleII/a2cloud/issues/30#issuecomment-256147103
Stupid question: Have you tried to reproduce the issue?
Yes, but not in the strictest sense. I've tested it on my Raspbian jessie beta briefly and it looks like it works. I tested it a little more extensively on my amd64 Debian sid development machine and again it appears to work fine. But I haven't tested Ivan's 2015 release at all, in part because I haven't got another microSD card at the moment and because I've never been able to actually build it, so patches are difficult.
This is somewhat less than ideal. It was supposed to be a nice, easy transition. Ivan had ported his build system to jessie which was supposed to be released for KFest. I was going to take the next six months and come up with a clean way to reproduce his release using something approximating standard build tools and get it right so that others can help develop it.
In September, with no release for jessie and no actually building codebase, I got handed the whole thing, except I can't actually edit anything on Ivan's website, and I didn't even have a functioning beta. In October, I released a beta to not one single report of success or failure, so I have no idea whether it works for anyone besides me even a little bit. Yours is the first feedback I've got, and it's for a bug I don't have against a version I can't test without basically backing up and wiping the "hard drive" of my test system for the year-overdue release I've been frantically trying to finish while dodging viruses, a fiancee who spent a week in the hospital, and there are still things I need to be able to do here that I just don't know how to do by myself.
I'm really trying to solve the problem here, but I'm grasping at straws. The manpage says Xvfb is supposed to be killed. I see that on my system, it is killed with a variety of clients, including ADTPro. But I'm not using the same OS version, the same JRE, or the same CPU architecture for the majority of my testing. Hopefully when there is an actual jessie release, that'll begin to change more. At the very least I hope to invest in another Pi 3 kit in the next several months so that I can go through the entire process end-to-end with the kit a new user would likely buy, on video.
First of all thanks for the detailed answer :-)
I can't actually edit anything on Ivan's website
Reminds me on the situation with cc65: The domain cc65.org is still not mine to present day and it took many months until the former maintainer of cc65 put a link on his site pointing to my site.
Yours is the first feedback I've got
Maybe I misunderstand things but as long as http://ivanx.com/rasppleii/ is the site coming up on Googling 'raspple 2' or and that site only links Ivan's 2015 release this likely won't change much.
Working hard for the community and not getting feedback at all sucks ! I know...
I'm really trying to solve the problem here
That doesn't make sense from my perspective! I only reported that issue to make you aware of it and help avoiding it in further releases. Now you are aware of it and likely will check for Xvfb proccesses now and then when testing upcoming releases.
And in case (although I don't think so) that it only happens when going for Ethernet instead of serial then that's okay too as you plan to support Ethernet in the future and will therefore likely test it.
So from my perspective everything is fine and there's no need for you to invest any more of your scarce time into this legacy release.
PS: Best wishes for a speedy recovery to your fiancee !
FWIW, if I came across sounding critical there, that's not intentional at all. I may letting my frustration peek through a little at not having an actual release out the door yet.
Right now I'm trying to pick apart some weirdness with A2SERVER and have had to go and have done a few things I intended to hold off on that'll be pushing toward a 1.6.0 in the Jessie release to fix. I've gotta come back to A2CLOUD afterward and likely do much the same thing.
This issue doesn't appear to be happening on sid, and a quick look didn't show it on jessie, but technically we still do support wheezy, and you're seeing it there. I just can't currently test it there. So it seems that leaving this issue open is a good idea--I'm just limited in my ability to come up with an immediate fix until I rustle up another microSD card, or figure out how to get the Pi 3 to boot off of one of the myriad USB sticks I have laying around. And fixing it is something I'd like to do.
I actually bought two of Glenn's Uthernet II cards, and I had yet to actually use one of them--but you know what I have in mind for the future of Ethernet on the Apple //. Actually, I'd like to go a step further and see things go in a wifi direction at some point--with Apple //c support. I don't know if the issue you're seeing only happens with Ethernet, but I doubt it.
Once I have a release out the door, I'm reminded that I need to bring up CC65. Cross development for the Apple // and IIgs is high on my priority list.
FWIW, if I came across sounding critical there, that's not intentional at all. I may letting my frustration peek through a little at not having an actual release out the door yet.
Not a t all. I hoped my reaction made clear that I rather appreciated your open words!
I actually bought two of Glenn's Uthernet II cards
That's great so you can actually test the new Uthernet II support in the upcoming ADTPro 2.0.2 :-)
but you know what I have in mind for the future of Ethernet on the Apple //
As you know I have plans here too - which I don't want to publish at this point. So before investing time I suggest to get in touch with me in order to coordinate / avoid double work...
Once I have a release out the door, I'm reminded that I need to bring up CC65.
You may have noticed that it becomes sort of popular to use the RPi as common ground for cross development tools in the embedded space. One might think about installing cc65 on the RPi (it doesn't have a GUI anyway so a terminal / Telnet / SSH with any editor is just fine). ADTPro includes AppleCommander already which is great to push a binary into a disk image. So all together would allow to write some C code on the RPi and have the result served to the A2 via a virtual disk. Doing this via ProTERM from the A2 would turn the cross development into (sort of) a native development ;-))
I haven't updated this issue, but I think I've figured out what's going on here. When xvfb-run starts ADTPro, it doesn't really have a good way of knowing that it has exited cleanly. When you run the vsd scripts, it seems that ADTPro is being terminated but, before the Xvfb process is shut down, it's being restarted. The xvfb-run script will then start a new server, seeing that the display it has been using is occupied.
The best solution I can see to this is to stop starting multiple Xvfb servers. What I'm working on going forward is for an /etc/init.d/adtpro-xvfb
script to run first as a dependency to create the X server context (on display :6502 because, ...well, you're not using it already are you?) Then we'll start up /etc/init.d/adtpro
which is the normal Java program after that using the Xvfb we just started.
These two init scripts would easily make two systemd services which would be easy to write. They could be implemented a single init script, however the result would NOT be an easy single systemd service. Essentially, it's quite easy to make how it works for sysvinit or upstart the same as how it works for systemd. We currently only really try to support systemd and sysvinit, the defaults of Debian 8+ and 7 respectively, but one of my goals is to eventually have this stuff be distribution-agnostic. You just can't write a portable init script sadly (LSB fails to provide some essential tools for that), but the one I've got is easily ported from Debian style (start-stop-daemon) to Red Hat style (daemon) should someone ever care to do it.
In fact, I see no reason why A2CLOUD could not at some point be used on a Mac or even a carefully curated Windows UNIX-like cygin/msys2 environment. Either install the tools you need or write a shell function that runs the method of installing programs on your system.
A2SERVER with netatalk ... is a harder sell on non-Linux systems. (I think FreeBSD may have the option of AppleTalk networking support? I don't know.) But that's a whole different issue.
The vsd script (http://appleii.ivanx.com/prnumber6/a2cloud-insert-a-disk-image/) kills the ADTPro process but it doesn't kill the xvfb process. So every disk image change leaves you with another unused xvfb.