Rather than put the PID file in /var/run (which could have permission problems), put it somewhere else where your user has write permissions. See steps #3 and #4 in *Run as a non-root user <https://github.com/weewx/weewx/wiki/Run-as-a-non-root-user>*. In that example, /home/weewx/run is used as a writable directory for user 'weewx'.
-tk On Tue, May 7, 2019 at 5:25 PM Steve Chiz <[email protected]> wrote: > I've tried a dozen things since then, all to no avail. I found an old post > from Tom regarding commenting out the username lines to run as root again, > and that is what I did to get the weewx.service to start. > > Running the chown returned a file not found, so I assume one or more hard > reboots (shutdown -r) deleted that file. I removed the commenting on the > user name and this is the result. Oh, for a troubleshooting guide... > > I did not make any database owner changes as I use mariadb. > > May 7 20:18:47 WeeWx1 weewx[773]: engine: Locale is 'en_GB.UTF-8' > May 7 20:18:47 WeeWx1 weewx[773]: engine: pid file is /var/run/weewx.pid > May 7 20:18:47 WeeWx1 weewxd[773]: Traceback (most recent call last): > May 7 20:18:47 WeeWx1 weewxd[773]: File "/usr/bin/weewxd", line 64, in > <module> > May 7 20:18:47 WeeWx1 weewxd[773]: weewx.engine.main(options, args) > May 7 20:18:47 WeeWx1 weewxd[773]: File > "/usr/share/weewx/weewx/engine.py", line 841, in main > May 7 20:18:47 WeeWx1 weewxd[773]: > daemon.daemonize(pidfile=options.pidfile) > May 7 20:18:47 WeeWx1 weewxd[773]: File "/usr/share/weewx/daemon.py", > line 77, in daemonize > May 7 20:18:47 WeeWx1 weewxd[773]: if pidfile: > file(pidfile,'w+').write("%s\n" % pid) > May 7 20:18:47 WeeWx1 weewxd[773]: IOError: [Errno 13] Permission denied: > '/var/run/weewx.pid' > > I am changing permissions back to root/ftp and calling it a day. Thanks > for your help. > > On Tuesday, May 7, 2019 at 6:46:51 PM UTC-4, Leon Shaner wrote: >> >> Steve, >> >> Probably a leftover. >> I expect this should do it: >> >> $ sudo chown weewx /var/run/weewx.pid >> >> I would expect that file to be deleted on host reboot, except of course >> it is pronounced reboot, but spelled: >> >> $ sudo shutdown -r now >> >> If you use actual "reboot" then it skips shutdown scripts, so it's a big >> no-no. >> >> What about the other files, did you change their owner, too, such as for >> the DB? >> >> Regards, >> \Leon >> -- >> Leon Shaner :: Dearborn, Michigan (iPad Pro) >> >> On May 7, 2019, at 5:42 PM, Steve Chiz <[email protected]> wrote: >> >> Guess I spoke too soon. After a reboot, weewx won't start. IOError: >> [Errno 13] Permission denied: '/var/run/weewx.pid' >> >> On Tuesday, May 7, 2019 at 4:37:44 PM UTC-4, Steve Chiz wrote: >>> >>> Basically, it was my lack of understanding on how the .rules files work. >>> I appreciate the explanation of the granular permissions as it helped me >>> understand the 'why'. I am not worried about others plugging USB devices >>> into the pi, so I went ahead and edited the 99-usb.rules and added my newly >>> created weewx user to the plugdev group. I am successfully running weewx as >>> non-root, thanks again! WeeWx still complains that my key verification >>> fails, but I can directly ssh successfully to my remote host as the weewx >>> user without a password, so I'm close. >>> >>> Oh, and thanks for updating the wiki. I had run the "lsusb", I just >>> wasn't entirely sure what to do with the output. The edit makes it more >>> clear. >>> >>> On Tuesday, May 7, 2019 at 11:28:35 AM UTC-4, Leon Shaner wrote: >>>> >>>> Steve, >>>> Hope it works! =D >>>> >>>> I just updated the wiki. That section now reads: >>>> >>>> First find the idVendor and idProduct of your weatherstation with lsusb >>>> command >>>> then add a rules file in /etc/udev/rules.d/ with this content: >>>> >>>> SUBSYSTEM=="usb", ATTR{idVendor}=="your_value", >>>> ATTR{idProduct}=="your_value", ACTION=="add", GROUP="weewx", MODE="0664" >>>> >>>> Name the udev rules file something descriptive, such as an abbreviation >>>> of your weatherstation model or just weewx.rules, a la >>>> /etc/udev/rules.d/weewx.rules (extension must be .rules and filename >>>> should be simple, no spaces or special characters other than '-' and/or '_' >>>> and should not contain more than one period '.'). >>>> >>>> Regards, >>>> \Leon >>>> -- >>>> Leon Shaner :: Dearborn, Michigan (iPad Pro) >>>> >>>> On May 7, 2019, at 10:39 AM, Leon Shaner <[email protected]> wrote: >>>> >>>> Steve, >>>> >>>> In my first reply, I failed to answer your first question. >>>> >>>> Yes, if you use the first form with idVendor, idProduct explicitly >>>> filled in, you can call the UDEV rules file anything you like, as long as >>>> the extension is .rules and you place it in the /etc/udev/rules.d >>>> directory. >>>> >>>> I used a more generic /etc/udev/rules.d/99-usb.rules in my example, >>>> because my example is very generic, not tied to weewx, but would work for >>>> weewx provided weewx user is in the plugdev group. >>>> >>>> The (optional) number prefixes on the UDEV .rules files establish an >>>> order of precedence with later rules overriding earlier rules. Really it's >>>> ordered lexicographically, so files that start with letters, such as >>>> weewx.rules will be evaluated after (take precedence over) the files that >>>> do start with numbers. >>>> >>>> Regards, >>>> \Leon >>>> -- >>>> Leon Shaner :: Dearborn, Michigan (iPad Pro) >>>> >>>> On May 7, 2019, at 10:31 AM, Leon Shaner <[email protected]> wrote: >>>> >>>> Hey, Steve, >>>> >>>> That first wiki looks pretty complete. >>>> Did you in fact try the "lsusb" command to get the values you need for >>>> the first form of the udev rules? >>>> Using the first form with the idVendor and idProduct for your weather >>>> station is preferred. >>>> >>>> As an alternative, and if it's just you with physical access to the >>>> host and USB devices, e.g. you aren't too worried about other people >>>> connecting USB devices and accessing them as non-root, you can also just do >>>> this: >>>> >>>> File: /etc/udev/rules.d/99-usb.rules >>>> Contents: >>>> SUBSYSTEM=="usb", GROUP="plugdev", MODE="0660" >>>> >>>> Then be sure to put the wxuser and any other users in the "plugdev" >>>> group in /etc/group, a la: >>>> >>>> plugdev:x:46:steve,pi,weewx >>>> >>>> (Or whatever usernames you care to be allowed to access USB ports). >>>> (Your GID may differ from 46)... >>>> >>>> Notice that for perms, above, I put 0660. I can't think why "others" / >>>> "nobody" should even need to read the USB ports. Anybody that needs to >>>> read(or write) USB ports should be in the "plugdev" group. >>>> >>>> You could of course put GROUP="weewx" in my example above, but then any >>>> user would need to be in the weewx port to use any USB device, even those >>>> unrelated to weewx. The "plugdev" group is commonly used for other >>>> USB devices, such as auto-mounting removable media, so that is why I chose >>>> it in my example. If you used my example and put GROUP="weewx" it would >>>> likely break auto-mounting of removable media (maybe you don't care; maybe >>>> you don't use the usbmount service, etc.). >>>> >>>> Note that changes in /etc/group take a log out / log in to take effect. >>>> Check group membership via "id -a" ... >>>> >>>> Of course the explicit method, per the wiki, using the idVendor and >>>> idProduct values for your specific USB device avoids any conflict, because >>>> then assigning group weewx would only ever happen to that one device that >>>> exactly matches the idVendor and idProduct values from "lsusb" output. >>>> >>>> Hope that helps! =D >>>> >>>> Regards, >>>> \Leon >>>> -- >>>> Leon Shaner :: Dearborn, Michigan (iPad Pro) >>>> >>>> On May 7, 2019, at 9:37 AM, Steve Chiz <[email protected]> wrote: >>>> >>>> I've been trying to use the wiki to resolve this on my own, but can't >>>> seem to sort it out. This page suggests I create a rules file, but no >>>> indication on what that file should be named... weewx.rules? >>>> https://github.com/weewx/weewx/wiki/systemd >>>> >>>> I hunted up an older page >>>> https://github.com/weewx/weewx/wiki/Run-as-a-non-root-user that cites >>>> an example for Vantage (name the file vpro.rules) but what about other >>>> devices? In any event, the contents of the rules file is different than the >>>> more recently edited page. Which should I use? >>>> >>>> SUBSYSTEM=="usb", ATTR{idVendor}=="your_value", >>>> ATTR{idProduct}=="your_value", ACTION=="add", GROUP="weewx", MODE="0664" >>>> or >>>> SUBSYSTEM=="usb", ATTRS{interface}=="CP2102 USB to UART Bridge >>>> Controller", MODE: = "664", GROUP = "wxuser" >>>> >>>> I get that one page is about systemd specifically, which I am using, but >>>> both address the need to run weewx as a non-root user. If someone could >>>> point me to some documentation on how to switch from running weewx as root >>>> to a non-root user, that would be great! I probably should have set it up >>>> that way initially, regardless of rsync, as running as root always seems >>>> like a risky idea. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "weewx-user" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/weewx-user/aaab2dd1-376f-4f89-82a6-8ff03d032c9e%40googlegroups.com >>>> <https://groups.google.com/d/msgid/weewx-user/aaab2dd1-376f-4f89-82a6-8ff03d032c9e%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "weewx-user" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/weewx-user/0130621D-4F28-4F79-8036-1EF1743D9A95%40isylum.org >>>> <https://groups.google.com/d/msgid/weewx-user/0130621D-4F28-4F79-8036-1EF1743D9A95%40isylum.org?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> -- >> You received this message because you are subscribed to the Google Groups >> "weewx-user" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/weewx-user/d5d19e8c-4052-4cff-a28e-0c1935167fd9%40googlegroups.com >> <https://groups.google.com/d/msgid/weewx-user/d5d19e8c-4052-4cff-a28e-0c1935167fd9%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> >> -- > You received this message because you are subscribed to the Google Groups > "weewx-user" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/weewx-user/a7d1904a-8a0b-432a-94c0-0dbfd26f7abb%40googlegroups.com > <https://groups.google.com/d/msgid/weewx-user/a7d1904a-8a0b-432a-94c0-0dbfd26f7abb%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/CAPq0zEAfiTxK_YafWzYA0%3DhR4xVah3jL1hTnAkLuszgQC3fT7Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
