Welcome to the Cumulus Support forum.

Latest Cumulus MX V3 release 3.28.6 (build 3283) - 21 March 2024

Cumulus MX V4 beta test release 4.0.0 (build 4018) - 28 March 2024

Legacy Cumulus 1 release v1.9.4 (build 1099) - 28 November 2014 (a patch is available for 1.9.4 build 1099 that extends the date range of drop-down menus to 2030)

Download the Software (Cumulus MX / Cumulus 1 and other related items) from the Wiki

RESOLVED BY REBOOT: Issue when attempted running as service

From build 3044 the development baton passed to Mark Crossley. Mark has been responsible for all the Builds since. He has made the code available on GitHub. It is Mark's hope that others will join in this development, but at the very least he welcomes your ideas for future developments (see Cumulus MX Development suggestions).

Moderator: mcrossley

Post Reply
sfws
Posts: 1183
Joined: Fri 27 Jul 2012 11:29 am
Weather Station: Chas O, Maplin N96FY, N25FR
Operating System: rPi 3B+ with Buster (full)

RESOLVED BY REBOOT: Issue when attempted running as service

Post by sfws »

Post Edits: changing subject for the topic as progress made in resolving..

After the expected entries in the log (prior to the attempt to connect to weather station) comes:

Code: Select all

2021-07-29 17:54:46.628 Looking for Fine Offset station, VendorID=0x1941 ProductID=0x8021
2021-07-29 17:54:46.792 Fine Offset station found
2021-07-29 17:54:46.829 Stream open failed
2021-07-29 17:56:06.891 Looking for Fine Offset station, VendorID=0x1941 ProductID=0x8021
2021-07-29 17:56:06.898 Fine Offset station found
2021-07-29 17:56:06.900 Stream open failed
Cumulus has shutdown
The above failure came when I tried to run a "new installation" of MX as a service on my RPi. I had previously been running MX as a service with no issues for months.

As the move from 3.11.4 to 3.12.0 was a major upgrade, instead of just overwriting my existing installation with the whole release distribution, I decided to create a new CumulusMX folder (to make any regress easy), in turn I overwrote my old file defining the service as part of reference to new MX location which may have caused the problem.

The text above suggests that the problem has some connection with the Fine Offset code in MX. and the context suggests it is some action relating to what is in the service file.

Incidentally, since "updates.log" is now included in utilities too, it is time that file is renamed to a unique name, so you can't do what I nearly did (overwrite MX's updates.log with CreateMissings's update log).
Last edited by sfws on Fri 30 Jul 2021 1:53 pm, edited 3 times in total.
User avatar
mcrossley
Posts: 12695
Joined: Thu 07 Jan 2010 9:44 pm
Weather Station: Davis VP2/WLL
Operating System: Bullseye Lite rPi
Location: Wilmslow, Cheshire, UK
Contact:

Re: Release 3.12.0 shutdowns for Fine Offset station

Post by mcrossley »

Nothing has changed in the FineOffset code other than adding the extra log messages.

I tested against my old WH1080 and 3.12.0 connects OK and reads the data. :?
sfws
Posts: 1183
Joined: Fri 27 Jul 2012 11:29 am
Weather Station: Chas O, Maplin N96FY, N25FR
Operating System: rPi 3B+ with Buster (full)

Issue when attempted running as service

Post by sfws »

Thank you, that reassures me that MX is okay, now I know I have done something wrong.

On further investigation, 3.12.0 starts okay in interactive mode, but gives that issue when I start MX as a service.

I was running as a service before, for weeks without any issues, somehow in installing 3.12.0 my service must have been accidentally corrupted? When I have spare time, I will delete my service and start afresh. Meanwhile I can use interactive mode for now.

(post edited to change subject, matching change of subject in my first post, text above not updated)
Last edited by sfws on Fri 30 Jul 2021 5:16 am, edited 1 time in total.
User avatar
mcrossley
Posts: 12695
Joined: Thu 07 Jan 2010 9:44 pm
Weather Station: Davis VP2/WLL
Operating System: Bullseye Lite rPi
Location: Wilmslow, Cheshire, UK
Contact:

Re: Release 3.12.0 initially had issue, Okay now

Post by mcrossley »

Hmm, I'll do a bit more digging. The extra messages in history catch-up use the service flag to determine where they write, perhaps there is an issue in there. But your log snippet above shows it was aborting before it started reading the history data.

I have only tested interactive mode.
water01
Posts: 3215
Joined: Sat 13 Aug 2011 9:33 am
Weather Station: Ecowitt HP2551
Operating System: Windows 10 64bit
Location: Burnham-on-Sea
Contact:

Re: Release 3.12.0 initially had issue, Okay now

Post by water01 »

I am running my Fine Offset in CumulusMX as a service and I upgraded with no problems. Windows 10 Version 20H2. Everything running AOK.
David
Image
sfws
Posts: 1183
Joined: Fri 27 Jul 2012 11:29 am
Weather Station: Chas O, Maplin N96FY, N25FR
Operating System: rPi 3B+ with Buster (full)

Re: Issue when attempted running as service

Post by sfws »

water01 wrote: Thu 29 Jul 2021 7:41 pm I am running my Fine Offset in CumulusMX as a service and I upgraded with no problems. Windows 10 Version 20H2. Everything running AOK.
Good for you, and that is also useful to narrow down what might be problem. However, my post was about running MX as a service on a Raspberry Pi.

The coding in MX will be different between the CumulusMX -install that installs a Microsoft service to run MX, and CumulusMX.exe -service that runs MX inside a Linux service.

This morning with fresh eyes, I realise that multiple items have changed since May's 3.11.4 release, never the best for resolving issues, and I am now wondering if an upgrade of some other module on my RPi could be culprit:
1) My 3.11.4 service was left running as a service from when it was released (2 months ago!), as far as I can recall. I mention that because the problem occurs when starting the service, so any change on my RPi since May could be the culprit, and I can't recall everything I have done on the RPi in those 2 months.
2) A new folder was created for my 3.12.0 install, everything I added is owned by user "Pi", but the ".tmp" files MX has created while running interactively overnight are owned by root, but that is what I expected "sudo mono CumulusMX.exe" to do!
3) My /etc/systemd/system/cumulusmx.service was copied in again yesterday after editing the file in the MX release 3.12.0 distribution, but today I reinstated the file I had before as a test, that made no difference, the problem in my first post happens when I try to start the service, so I am staying with MX running interactively.
4) I can't retrospectively check the file ownerships that existed when I last successfully started MX as a service last May.
5) I rebooted my RPi during the MX upgrade process, this may have changed something about the environment in which the service is now trying to start.
6) Earlier this month, I upgraded my RPi using "sudo apt full-upgrade", the main impact of that for me was gaining the new PHP released at start of this month. It is possible that upgrade affected some module that a MX service uses when starting. Anyway, my MX service was not stopped during that apt upgrade.
7) The upgrade to MX 3.12.0 may be irrelevant, I would need to regress to 3.11.4 to check whether that still runs as a service after the reboot.
User avatar
mcrossley
Posts: 12695
Joined: Thu 07 Jan 2010 9:44 pm
Weather Station: Davis VP2/WLL
Operating System: Bullseye Lite rPi
Location: Wilmslow, Cheshire, UK
Contact:

Re: Issue when attempted running as service

Post by mcrossley »

Not much help as I run against a Davis WLL station. But my "live" station runs as a service on rPi 4 and did not encounter any issues when I updated to b3141.
I also have another test Pi Zero running against a Davis VP2 as a service, and that continued OK as well.
freddie
Posts: 2434
Joined: Wed 08 Jun 2011 11:19 am
Weather Station: Davis Vantage Pro 2 + Ecowitt
Operating System: GNU/Linux Ubuntu 22.04 LXC
Location: Alcaston, Shropshire, UK
Contact:

Re: Issue when attempted running as service

Post by freddie »

@sfws: could you share your MX service file, please? Also, any messages in /var/log/syslog around the time when you attempt to start as a service.
Freddie
Image
sfws
Posts: 1183
Joined: Fri 27 Jul 2012 11:29 am
Weather Station: Chas O, Maplin N96FY, N25FR
Operating System: rPi 3B+ with Buster (full)

Re: Issue when attempted running as service

Post by sfws »

Freddie, this might be a significant clue, there was something in the forum recently about how MX connects to USB HID by doing a search, maybe that code works differently within a service?

Syslog: I suspect these are the key entries from today, (the log was rotated so syslog1 shows what happened yesterday and I have preserved a copy of that on my RPi).

Code: Select all

Jul 30 08:37:46 tinyComputer systemd[1]: Starting CumulusMX service...
Jul 30 08:37:46 tinyComputer systemd[1]: Started CumulusMX service.
Jul 30 08:46:21 tinyComputer systemd[1]: cumulusmx.service: Couldn't add UID/GID reference to unit, proceeding without: Device or resource busy
Jul 30 08:46:21 tinyComputer systemd[1]: cumulusmx.service: Failed with result 'timeout'.
Jul 30 08:46:21 tinyComputer systemd[1]: Stopped CumulusMX service.
The MX service file attached is only changed for the location of MX folder from that in distribution. I know you in an earlier post in the forum were talking about changing the user entry, but I have left that at root as per distribution.
cumulusmx.service.zip
My Cumulus.ini file contains:

Code: Select all

VendorID=-1
ProductID=-1
as I have never considered changing the defaults.
You do not have the required permissions to view the files attached to this post.
freddie
Posts: 2434
Joined: Wed 08 Jun 2011 11:19 am
Weather Station: Davis Vantage Pro 2 + Ecowitt
Operating System: GNU/Linux Ubuntu 22.04 LXC
Location: Alcaston, Shropshire, UK
Contact:

Re: Issue when attempted running as service

Post by freddie »

This is quite telling:

Code: Select all

Jul 30 08:46:21 tinyComputer systemd[1]: cumulusmx.service: Couldn't add UID/GID reference to unit, proceeding without: Device or resource busy
Was there anything else accessing the device at the time?
Freddie
Image
sfws
Posts: 1183
Joined: Fri 27 Jul 2012 11:29 am
Weather Station: Chas O, Maplin N96FY, N25FR
Operating System: rPi 3B+ with Buster (full)

Re: Issue when attempted running as service

Post by sfws »

sfws wrote: Fri 30 Jul 2021 10:14 am Freddie, this might be a significant clue, there was something in the forum recently about how MX connects to USB HID by doing a search, maybe that code works differently within a service?
freddie wrote: Fri 30 Jul 2021 10:29 am This is quite telling:
You have picked up what I meant by significant clue!

Only MX software can access my weather station (and the interactive MX was stopped before I tried to run as a service).

Whatever the code does, and that is for Mark to answer, running as a MX service is generating a new request that overlaps, or conflicts with, the previous one.
mcrossley wrote: Thu 29 Jul 2021 7:38 pm your log snippet above shows it was aborting before it started reading the history data.
I was thinking perhaps the USB HID search (it looks like it is repeating?) and the attempt to read data, are somehow causing conflicts, in the service code.
water01
Posts: 3215
Joined: Sat 13 Aug 2011 9:33 am
Weather Station: Ecowitt HP2551
Operating System: Windows 10 64bit
Location: Burnham-on-Sea
Contact:

Re: Issue when attempted running as service

Post by water01 »

Good for you, and that is also useful to narrow down what might be problem. However, my post was about running MX as a service on a Raspberry Pi.
Apologies missed the Pi bit in your profile.
David
Image
freddie
Posts: 2434
Joined: Wed 08 Jun 2011 11:19 am
Weather Station: Davis Vantage Pro 2 + Ecowitt
Operating System: GNU/Linux Ubuntu 22.04 LXC
Location: Alcaston, Shropshire, UK
Contact:

Re: Issue when attempted running as service

Post by freddie »

Doing a bit of Googling, and see that your error message doesn't refer to your HID device - it is to do with a user (hence UID/GID). Hopefully further in your syslog you will have seen a message like this:

Code: Select all

systemd-resolved.service: User lookup succeeded: uid=* gid=*
where * is the uid/gid for the root user on your system. So ... a bit of a red herring.

Anything relating to HID in syslog?
Freddie
Image
sfws
Posts: 1183
Joined: Fri 27 Jul 2012 11:29 am
Weather Station: Chas O, Maplin N96FY, N25FR
Operating System: rPi 3B+ with Buster (full)

Re: RESOLVED BY REBOOT: Issue when attempted running as service

Post by sfws »

freddie wrote: Fri 30 Jul 2021 12:02 pm Doing a bit of Googling, and see that your error message doesn't refer to your HID device - it is to do with a user (hence UID/GID).
Many thanks, Freddie, for your persistence on this while I was taking advantage of the gap in rain showers to dig up more unwanted tree saplings in the middle of shrubs in my garden.

The first response is to confirm my syslog had no other messages (apart from the ones I posted) related to the issue.

Thank you for telling me that HID was a red herring. (My mind was far too focussed on trying to relate what I had done, to what MX might be doing, despite in an earlier post trying to list all I had done).

Now you have explained UID, that is something my computer should define. I believe it usually sets root UID to 1000. If it has not done that, then I will try a reboot. Perhaps the last reboot caused the problem, and the next reboot will clear it?

POST SCRIPT: I just rebooted my RPi again, MX 3.12.0 is now happily running as a service (and the syslog does indeed show after the reboot UID was set to 1000).

Mark, thank you for your replies, you can relax now, nothing whatsoever to do with MX nor the service definition!
Freddie, return to dreaming of extending your recording to include grass temperatures!

I said "I hate computers" when I first met paper tapes and a mainframe, and it seems, all these decades on, I still hate them for messing up what I try to do on them!
Post Reply