errors related to udevd after upgrade to weewx 5.0.0

[Joseph Verreau]

 My upgrade from 4.10 to 5.0 on my laptop, i.e. not connected to a real weather station thus running with the simulator device, has actually gone very nicely but for one puzzling report. I thought installing on my laptop would better prepare me for installing on my desktop that is actually connected to my weather station.

Jan 23 12:06:12 xps13-9305 systemd-udevd[632]: /usr/lib/udev/rules.d/60-weewx.rules:4 Unknown group '{weewx}', ignoring.

The reports occur in sets of ten once daily, so far.

installation history:

initially installed on this server running fedora in 2014 via the setup.py method. In 2020 I switched to the dnf repo method. When I first ran this upgrade to ver 5.0 using dnf upgrade I noticed that I ended up with the application using root:root for user:group assignments of directories and files. Reading the installation guide some more I noted there was a transition to weewx:weewx for those assignments. So I erased the application then ran dnf install weewx following along the instructions for fedora versions 34+. That seemed to correct the issue of ownership by creating the missing user and group.

I don’t observe anything else out of place. My install starts against the simulator device, and enters the main loop where it updates the database as I would expect.

Question: does the error reported above as in the journal imply a mis-configuration? Why is the group weewx identified as unknown?

- - - - - - - - - - -

Context:

{journal entries for ten minutes following reboot in attached text file}

Jan 22 11:55:05 xps13-9305 weewxd[872]: INFO __main__: Initializing weewxd version 5.0.0

Jan 22 11:55:05 xps13-9305 weewxd[872]: INFO __main__: Command line: /usr/share/weewx/weewxd.py /etc/weewx/weewx.conf

Jan 22 11:55:05 xps13-9305 weewxd[872]: INFO __main__: Using Python 3.12.1 (main, Dec 18 2023, 00:00:00) [GCC 13.2.1 20231205 (Red Hat 13.2.1-6)]

Jan 22 11:55:05 xps13-9305 weewxd[872]: INFO __main__: Located at /usr/bin/python3

Jan 22 11:55:05 xps13-9305 weewxd[872]: INFO __main__: Platform Linux-6.6.12-200.fc39.x86_64-x86_64-with-glibc2.38

Jan 22 11:55:05 xps13-9305 weewxd[872]: INFO __main__: Locale: 'en_US.UTF-8'

Jan 22 11:55:05 xps13-9305 weewxd[872]: INFO __main__: Entry path: /usr/share/weewx/weewxd.py

Jan 22 11:55:05 xps13-9305 weewxd[872]: INFO __main__: WEEWX_ROOT: /etc/weewx

Jan 22 11:55:05 xps13-9305 weewxd[872]: INFO __main__: Configuration file: /etc/weewx/weewx.conf

Jan 22 11:55:05 xps13-9305 weewxd[872]: INFO __main__: User module: /etc/weewx/bin/user

Jan 22 11:55:05 xps13-9305 weewxd[872]: INFO __main__: Debug: 1

Jan 22 11:55:05 xps13-9305 weewxd[872]: INFO weewx.engine: Loading station type Simulator (weewx.drivers.simulator)

Jan 22 11:55:05 xps13-9305 weewxd[872]: INFO weewx.engine: StdConvert target unit is 0x1

Jan 22 11:55:05 xps13-9305 weewxd[872]: INFO weewx.wxservices: StdWXCalculate will use data binding wx_binding

Jan 22 11:55:05 xps13-9305 weewxd[872]: INFO weewx.engine: Archive will use data binding wx_binding

Jan 22 11:55:05 xps13-9305 weewxd[872]: INFO weewx.engine: Record generation will be attempted in 'hardware'

Jan 22 11:55:05 xps13-9305 weewxd[872]: INFO weewx.engine: Using archive interval of 300 seconds (specified in weewx configuration)

- - - - - - - - - - -

[vince]

Too many lines to go through for my brain but if you added a weewx group and added a weewx user to it, I would reboot and see if the problem persisted.

[matthew wall]

On Tuesday, January 23, 2024 at 10:49:43 PM UTC-5 joev...@gmail.com wrote:

 My upgrade from 4.10 to 5.0 on my laptop, i.e. not connected to a real weather station thus running with the simulator device, has actually gone very nicely but for one puzzling report. I thought installing on my laptop would better prepare me for installing on my desktop that is actually connected to my weather station.

Jan 23 12:06:12 xps13-9305 systemd-udevd[632]: /usr/lib/udev/rules.d/60-weewx.rules:4 Unknown group '{weewx}', ignoring.

1) what is User and Group in /usr/lib/systemd/system/weewx.service?

2) do any of these files exist on your system:

/etc/systemd/system/weewx.service

/etc/init.d/weewx

/etc/init.d/weewx-multi

 

3) what do you see when you do this: 

grep weewx /etc/passwd

4) please post the contents of the file

/usr/lib/udev/rules.d/60-weewx.rules

installation history:

initially installed on this server running fedora in 2014 via the setup.py method. In 2020 I switched to the dnf repo method. When I first ran this upgrade to ver 5.0 using dnf upgrade I noticed that I ended up with the application using root:root for user:group assignments of directories and files. Reading the installation guide some more I noted there was a transition to weewx:weewx for those assignments. So I erased the application then ran dnf install weewx following along the instructions for fedora versions 34+. That seemed to correct the issue of ownership by creating the missing user and group.

I don’t observe anything else out of place. My install starts against the simulator device, and enters the main loop where it updates the database as I would expect.

Question: does the error reported above as in the journal imply a mis-configuration? Why is the group weewx identified as unknown?

when you upgrade from v4 to v5 using dnf, weewxd should run as root:root.  this is because the installer will try to respect your previous installation, and continue to run with the same user and permissions as the previous install.

when you do a new install of v5 using dnf, weewxd should run as weewx:weewx.

note that when you 'erase' an installation with dnf, the database, located in /var/lib/weewx, will not be deleted.  so if you were to run the v5 installer at this point, even though it is technically a new install, because of the /var/lib/weewx with root:root ownership, the 'new' install will run as root:root.

if you saw that v5 was running as root:root, that means you must have deleted /var/lib/weewx, or changed its permissions.  could you verify this?

m

[matthew wall]

On Wednesday, January 24, 2024 at 7:20:47 AM UTC-5 matthew wall wrote:

if you saw that v5 was running as root:root, that means you must have deleted /var/lib/weewx, or changed its permissions.  could you verify this?

i mistyped.  that line should have said:

if you saw that v5 was running as weewx:weewx, that means you must have deleted /var/lib/weewx or changed its permissions.

could you verify whether you deleted the database and /var/lib/weewx before you did the new install to v5?

m

[Joseph Verreau]

Matthew,

   answers to above:

1) located in /usr/lib/systemd/system I have these two:

 -rw-r--r--. 1 root root  368 Jan 21 12:18  weewx.service
-rw-r--r--. 1 root root  876 Jan 21 12:18  weewx@.service

2) located in xps13-9305:/etc/systemd/system/multi-user.target.wants/ I have the following but no weewx files in /etc/init.d or /etc/sysetmd/system

lrwxrwxrwx. 1 root root   37 Jan 21 12:18 weewx.service -> /usr/lib/systemd/system/weewx.service

3) xps13-9305:/etc/init.d# grep weewx /etc/passwd
weewx:x:971:960::/home/weewx:/sbin/nologin

4) 60-weewx.rules attached

and thank you for your response.

joev.mi

_ _ _ _ _ _ _ _ _ _

On Wednesday, January 24, 2024 at 7:20:47 AM UTC-5 matthew wall wrote:

[Joseph Verreau]

Matthew,

    I might have included this information:

drwxr-xr-x. 1 weewx weewx   578 Jan 23 18:15 .
drwxr-xr-x. 1 root  root   6320 Jan 23 12:06 ..
drwxr-xr-x. 1 weewx weewx     8 Jan 19 18:36 bin
drwxr-xr-x. 1 weewx weewx   160 Jan 21 12:18 examples
drwxr-xr-x. 1 weewx weewx   178 Jan 21 12:18 import
drwxr-xr-x. 1 weewx weewx    10 Jan 21 12:18 logrotate.d
drwxr-xr-x. 1 weewx weewx    22 Jan 21 12:18 logwatch
drwxr-xr-x. 1 weewx weewx    20 Jan 21 12:18 rsyslog.d
drwxr-xr-x. 1 weewx weewx    78 Jan 21 12:18 skins
drwxr-xr-x. 1 weewx weewx    54 Jan 21 12:18 systemd
drwxr-xr-x. 1 weewx weewx    22 Jan 21 12:18 udev
-rw-r--r--. 1 weewx weewx 19474 Jan 23 18:15 weewx.conf
-rw-r--r--. 1 weewx weewx 23138 Jan 30  2023 weewx.conf-4.10.1
-rw-r--r--. 1 weewx weewx 23146 Jan 19 18:36 weewx.conf-4.10.2-5.0.0
-rw-r--r--. 1 weewx weewx 23142 Jun  8  2021 weewx.conf-4.5.1
-rw-r--r--. 1 weewx weewx 23137 Feb  6  2022 weewx.conf-4.6.0
-rw-r--r--. 1 weewx weewx 23137 Feb 11  2022 weewx.conf-4.6.1
-rw-r--r--. 1 weewx weewx 23137 Feb 11  2022 weewx.conf-4.6.2
-rw-r--r--. 1 weewx weewx 23137 Mar  5  2022 weewx.conf-4.7.0
-rw-r--r--. 1 weewx weewx 23137 Apr 24  2022 weewx.conf-4.8.0
-rw-r--r--. 1 weewx weewx 23220 Oct 25  2022 weewx.conf-4.9.1
-rw-r--r--. 1 weewx weewx 19474 Jan 14 12:01 weewx.conf-5.0.0
-rw-r--r--. 1 weewx weewx 23138 Feb 23  2023 weewx.conf.prev
-rw-r--r--. 1 weewx weewx 19474 Jan 14 12:01 weewx.conf.rpmnew
-rw-r--r--. 1 weewx weewx 23138 Feb 23  2023 weewx.conf.rpmsave

joev.mi

_ _ _ _ _ _ _ _ _ _

[Joseph Verreau]

Matthew,

    Ooops, i neglected my other response:

   I neglected that detail, I did delete the directory /var/lib/weewx and the database therein.  I did not change the directory /etc/weewx and I noticed that when I ran dnf install weewx it updated the ownership and group of that directory and files therein.  I was tempted to conclude from that change that the install would update the ownership and group of the directory /var/lib/weewx if I hadn't deleted it.  I was tempted to merely add user:group of weewx:weewx and assign them to /var/lib/weewx and the database but I wasn't sure if there were special requirements for that user and group.  

   I have rebooted since I ran the install.  Since then I get the error about weewx group being unknown in sets of ten once per day.

[Joseph Verreau]

I see I didn't reference the container of the list of files above; the directory is /etc/weewx/

[matthew wall]

On Wednesday, January 24, 2024 at 2:38:38 PM UTC-5 joev...@gmail.com wrote:

3) xps13-9305:/etc/init.d# grep weewx /etc/passwd
weewx:x:971:960::/home/weewx:/sbin/nologin

it looks like your 'weewx' user has uid 971, and it is in group '960'.  it also has home directory '/home/weewx', which tells me that this weewx user was not created by the weewx v5 installer and dnf.

what do you get from this:

grep weewx /etc/group

 

[Joseph Verreau]

Matthew,

    actually I was afraid to create either user or group manually as I was not confident about whether there might be specifications I was not familiar with thus both the user and group resulted when I first deleted the directory /var/lib/weewx then ran dnf install weewx following the install instructions for fedora 34+.  I had checked both passwd and group prior to running the install and the user and group were not present.

    from grep weewx /etc/group I get:

xps13-9305:~$ grep weewx /etc/group
weewx:x:960:

@xps13-9305:~$ ll /etc/group
-rw-r--r--. 1 root root 1296 Jan 21 12:18 /etc/group
@xps13-9305:~$ ll /etc/passwd
-rw-r--r--. 1 root root 3400 Jan 21 12:18 /etc/passwd
@xps13-9305:~$ sudo dnf history list weewx
ID     | Command line                                                                                           | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------------------------------------------------------------------------------------
   668 | install weewx                                                                                          | 2024-01-21 12:18 | Install        |    5   

joev.mi

_ _ _ _ _ _ _ _ _ _

[Joseph Verreau]

... none of that is to say I didn't get something else wrong in the install.  

joev.mi

_ _ _ _ _ _ _ _ _ _

[Joseph Verreau]

... are you suggesting my plan to delete /var/lib/weewx and then erase weewx 4.10 then following the instructions to install v5 should work?  I believe I can save the database and re-add it after installing.  

[matthew wall]

i think i was mistaken about dnf not creating the weewx user.  i thought we had implemented useradd so that the HOME for a new weewx user is /var/lib/weewx, but apparently we did that for debian, but not for redhat/suse.  i will fix that. however, that is not relevant to your problem.

anyway, i am an idiot.

if you look at the rules file, you will see that it is incorrect.  instead of this:

GROUP="weewx"

we see this:

GROUP="{weewx}"

that is because there is a bug in the suse and redhat scriptlets that does an incorrect substitution.

fixed at commit b32ca406, to appear real-soon-now in 5.0.1

meanwhile, you can fix it by editing /usr/lib/udev/rules.d/60-weewx.rules

replace "{weewx}" with "weewx"

[Joseph Verreau]

Matthew,

    that I can do.  thank you for your time and very prompt responses.

joev.mi

_ _ _ _ _ _ _ _ _ _