Version 1.0.5 issue

[rmaster78]

I am having an odd issue after updating it to 1.0.5. Prior to the update, the gymnasticon would continue to run forever so I can just hop on my bike and start riding, but after the update it looks like the code "exits" if I don't pedal for a while and it never restarts. I've included the "status" log below and also the config file setting I am using right now. Let me know... thanks!

` pi@raspberrypi:~ $ sudo systemctl status gymnasticon ● gymnasticon.service - Gymnasticon Loaded: loaded (/etc/systemd/system/gymnasticon.service; enabled; vendor preset: enabled) Active: inactive (dead) since Fri 2020-09-25 22:03:15 PDT; 55s ago Process: 12177 ExecStart=/usr/local/bin/gymnasticon --server-ping-interval=6 --power-scale=0.9 (code=exited, status=0/SUCCESS) Main PID: 12177 (code=exited, status=0/SUCCESS)

Sep 25 22:02:55 raspberrypi gymnasticon[12177]: [2020-09-26T05:02:55.305Z] received stats from bike [power=0W cadence=0rpm] Sep 25 22:02:56 raspberrypi gymnasticon[12177]: [2020-09-26T05:02:56.279Z] received stats from bike [power=0W cadence=0rpm] Sep 25 22:02:57 raspberrypi gymnasticon[12177]: [2020-09-26T05:02:57.255Z] received stats from bike [power=0W cadence=0rpm] Sep 25 22:02:58 raspberrypi gymnasticon[12177]: [2020-09-26T05:02:58.379Z] received stats from bike [power=0W cadence=0rpm] Sep 25 22:02:58 raspberrypi gymnasticon[12177]: [2020-09-26T05:02:58.439Z] pinging app since no pedal strokes for 6s Sep 25 22:02:59 raspberrypi gymnasticon[12177]: [2020-09-26T05:02:59.279Z] received stats from bike [power=0W cadence=0rpm] Sep 25 22:03:04 raspberrypi gymnasticon[12177]: [2020-09-26T05:03:04.445Z] pinging app since no pedal strokes for 6s Sep 25 22:03:10 raspberrypi gymnasticon[12177]: [2020-09-26T05:03:10.454Z] pinging app since no pedal strokes for 6s Sep 25 22:03:15 raspberrypi gymnasticon[12177]: [2020-09-26T05:03:15.803Z] bike disconnected ec:00:a2:d3:49:a3 Sep 25 22:03:15 raspberrypi systemd[1]: gymnasticon.service: Succeeded. `

` [Unit] Description=Gymnasticon After=bluetooth.target Requires=bluetooth.target

[Service] Type=simple Environment= WorkingDirectory=/home/pi User=pi Group=pi ExecStart=/usr/local/bin/gymnasticon --server-ping-interval=6 --power-scale=0.9 RestartSec=1 Restart=on-failure AmbientCapabilities=CAP_NET_RAW CAP_NET_ADMIN NoNewPrivileges=true

[Install] WantedBy=multi-user.target `

[ptx2]

Hey, thanks for reporting this. Give this updated .service file a shot:

[Unit]
Description=Gymnasticon
After=bluetooth.target
Requires=bluetooth.target
StartLimitIntervalSec=0

[Service]
Type=simple
Environment=
WorkingDirectory=/home/pi
User=pi
Group=pi
ExecStart=/usr/local/bin/gymnasticon --server-ping-interval=6 --power-scale=0.9
RestartSec=1
Restart=always
AmbientCapabilities=CAP_NET_RAW CAP_NET_ADMIN
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

And then apply with:

sudo systemctl daemon-reload
sudo systemctl restart gymnasticon

(The change is that Restart=on-failure is changed to Restart=always and StartLimitIntervalSec=0 has been added to the [Unit] block.)

I think that should do it. Let me know if it works!

[rmaster78]

It looks like it is working as I rode last night and just tried to log in to Zwift and it still detects the bike! Thanks for the fix!

[rmaster78]

Reopening issue because after updating the .service file as instructed, it seemed like everything was perfect for about a day... but now all of a sudden, Pi would crash (ex. can't log in using SSH). I have to unplug and replug the power supply to get it to run again. This happened a few hours I updated you guys that everything was working, but I still kept he issue closed as I thought it was a one-off issue, but this issue is repeating itself every day now.

Do you know where I can pull the log files after I reboot the system so I can take a look and also share it with you guys?

I suspect this new problem has something to do with how many times it retries to restart the program or how often it retries? Before the StartLimitIntervalSec=0 and Restart=always was added, the gymansticon program would just "exit" but Pi would still be alive and I can log in, but now the entire system "dies" (ex. I can't login using SSH and zwift won't show powermeter even tho I am pedaling to wake up the bike) and I have to unplug and replug the pi to get everything working again.

Let me know what you guys think and if you need a log file let me know where I maybe able to find it. Thanks!

[ptx2]

Hey, sorry to hear about this issue! To look at all the gymnasticon logs on the system, with an interface similar to journalctl you can use this command:

sudo zcat /var/log/syslog* |less -XFRS

(Note that you'll get more than just gymnasticon logs in there. If you paste here make sure to redact anything you don't want to share. If it's just running Gymnasticon then there's probably not a lot of sensitive stuff in there, but you may want to redact names of Wi-Fi networks, ip/mac addresses, etc.)

Also, how many amps is the power supply / usb port that is powering the Pi?

Does downgrading to 1.0.4 and rolling back the changes to the .service file help? To downgrade npm install -g gymnasticon@1.0.4 should do it.

Also if you prefer not to paste all the logs here, feel free to email them.

[rmaster78]

I tried the sudo zcat /var/log/syslog* |less -XFRS command you mentioned but got an error stating

gzip: /var/log/syslog: not in gzip format gzip: /var/log/syslog.1: not in gzip format

So I just used sudo nano syslog and manually copy pasted the logs to a text file and started looking into it. There doesn't seem to be much clue... All I see is a time jump and I am guessing this is when I restarted the pi after it froze on me.

As for power supply, I was using apple USB plug which was supplying 1A to the Pi Zero W. The USB cable that I am using was some generic brand that came off of one of my kids toy so I just switched it out to another heavier cable that I used to install gymansticon to the pi. It is odd that with version 1.0.3 I never had any crashes with the original setup. We'll see how this goes...

It seems like the pi freezes after it's been idle for a long time. Pi is also sitting next to the AC vent without any case/container. Wondering if the cold AC air is doing something to the pi??? Anyways, I'll keep digging. Thanks for the help and continued support and improvements.

Oct 8 14:52:24 raspberrypi systemd[1]: gymnasticon.service: Scheduled restart job, restart counter is at 11. Oct 8 14:52:24 raspberrypi systemd[1]: Stopped Gymnasticon. Oct 8 14:52:25 raspberrypi systemd[1]: Started Gymnasticon. Oct 8 14:52:29 raspberrypi gymnasticon[16944]: [2020-10-08T21:52:29.295Z] connecting to bike... Oct 8 14:17:18 raspberrypi systemd-modules-load[65]: Inserted module 'dwc2' Oct 8 14:17:18 raspberrypi systemd-modules-load[65]: Inserted module 'g_ether' Oct 8 14:17:18 raspberrypi fake-hwclock[71]: Thu 8 Oct 21:17:01 UTC 2020 Oct 8 14:17:18 raspberrypi systemd-fsck[91]: e2fsck 1.44.5 (15-Dec-2018) Oct 8 14:17:18 raspberrypi systemd-fsck[91]: rootfs: clean, 60311/104624 files, 376662/416256 blocks Oct 8 14:17:18 raspberrypi systemd[1]: Started Set the console keyboard layout. Oct 8 14:17:18 raspberrypi systemd[1]: Started udev Coldplug all Devices. Oct 8 14:17:18 raspberrypi systemd[1]: Starting Helper to synchronize boot up for ifupdown... Oct 8 14:17:18 raspberrypi systemd[1]: Started Remount Root and Kernel File Systems. Oct 8 14:17:18 raspberrypi systemd[1]: Started Helper to synchronize boot up for ifupdown. Oct 8 14:17:18 raspberrypi systemd[1]: Starting Flush Journal to Persistent Storage... Oct 8 14:17:18 raspberrypi systemd[1]: Starting Create System Users...

[ptx2]

Ah, try adding -f to the zcat command. That should make it handle both compressed and uncompressed files:

sudo zcat -f /var/log/syslog* |less -XFRS

Note that syslog is the latest log file but if it doesn't go far enough back in time, there should be past log files in there too named like syslog.1, syslog.2.gz, syslog.3.gz, etc. the .gz ones are compressed. The above command should display all of those files.

It may also be useful to look at kern.log:

sudo zcat -f /var/log/kern* |less -XFRS

It'd be interesting to see all log lines from both those files (minus anything sensitive) between the time a successful ride ended and when you noticed the Pi was unreachable.

You can zip up that entire logs directory and copy it to your computer with SFTP/SCP (same user/pass as SSH) for easier browsing/editing. This will create a zip file at /tmp/logs.tgz:

sudo tar zcvf /tmp/logs.tgz /var/log

I'd guess 1A is plenty for a Pi Zero W with no peripherals but if you have a 1.2A or higher handy it couldn't hurt to try. I think the AC is probably fine, although I'd recommend a case for the Pi just to protect against shorting it out. If you have the equipment another thing to try is connect monitor/keyboard when it's unresponsive and see if there is anything on the screen.

Did you have a chance to try rolling back to an earlier version yet to see if that helps?

If you're comfortable sending the entire logs directory over email, I'm happy to take a look and see if anything stands out. Before you do make sure to eyeball them to see if there's anything you want to redact (names of WiFi networks, etc.)

[ptx2]

Hey, I tried but have not been able to reproduce this issue here with 1.0.5. I am running with some extra logging enabled in case it does occur. In the meantime, I also just released 1.1.0 so it might be worth giving that a try too.

[rmaster78]

After you mentioned that I should put a cover for the pi, I covered the pi with a toy cup. Since the pi is sitting right in front of the AC vent area, perhaps some particles float around and short the pi??? Not sure, but I figured it is probably safer with a cup over it. So far (1 day of cover it with with a cup) it hasn't had an issue with bluebooth disconnecting. But I am having issue with connecting SSH using ssh pi@raspberrypi.local command. I need to use IP address to connect now until I reboot. Not sure what that is all about, quick search yield something to do with DNS as when I type nslookup raspberrypi.local it can't find anything... anyways... I just updated it to 1.1.0 and monitor how things go. I'll keep this open for few days and report back if any issues arise!

Thanks for the continued support and development of the program! I am really enjoying Zwifting all thanks to you!

[ptx2]

Ah interesting. The service that publishes the raspberrypi.local hostname is called avahi. If you're not able to login using raspberrypi.local but can login with the IP, you could check if there are any error messages in the logs for avahi. I would guess this is a separate issue to the Bluetooth issue but they could be indirectly related somehow.

Glad to hear the cup seems to be working for now :-)

[rmaster78]

There are some avahi logs in the syslog, but nothing that I can tell as they all look the same. Mostly it contains... avahi-daemon[256]: Withdrawing address record for [mac address] avahi-daemon[256]: Leaving mDNS multicast group on interface wlan0.IPv6 with address [mac address] avahi-daemon[256]: Joining mDNS multicast group on interface wlan0.IPv6 with address [mac address] avahi-daemon[256]: Registering new address record for [mac address] on wlan0.*. avahi-daemon[256]: Registering new address record for [ip address] on wlan0.IPv4

I probably am not looking closely enough, but the odd thing is that I was able to log in to pi usingraspberrypi.local just now when I had to use IP address couple days ago. Didn't keep a close log of when I logged in etc, so hard to narrow it down on when it started working again... but I think this isn't an issue with gymnasticon so I'll end this discussion here.

As for the stability issue, it seems like this is resolved after updating it to 1.1.0 + using a different USB cable + cup over pi. It is hard to tell which one truly fixed it, but I don't want to narrow it down and cause problems when things are working well with this setup right now.

Closing the case (hopefully for good :)