Jimbo.Automates Posted February 26, 2017 Posted February 26, 2017 try: sudo rm /tmp/myqtoken.json Then run again. Sent from my Nexus 6P using Tapatalk
xKing Posted February 26, 2017 Posted February 26, 2017 Yup, what Jimbo said Please don't run the script as root. BTW setting 755 vs 644 makes no sense since you just adding eXecutable bit on the file which is useless on text.
lsibarra Posted February 26, 2017 Posted February 26, 2017 Hi Jimbo and xKing, Deleting the myqtoken.json file worked as long as the myq-garage.log file is under pi ownership. I am not sure what is triggering this to change. This morning when i checked the ownership of the file, it is back to root again. Could you help explain what is causing this to keep reverting back to root? Also, could you explain how the myqtoken.json file got created if it is not needed? I just want to understand kinda understand this more. Thanks again for all your help. Larry
xKing Posted February 26, 2017 Posted February 26, 2017 Perhaps you invoking the script with dscServer which you run as root?... Make sure to run it as pi (you may need to change it's config.xml ownership to pi as well) I would recommend against running anything which is not a system service as root.
lsibarra Posted February 27, 2017 Posted February 27, 2017 Hi xKing, I checked it again since it stopped working again. The myq-garage.log seems like it is retaining the ownership as pi and NOT root. However, the myqtoken.json must be deleted each time when it stops working. I am not sure why this file is causing it to stop working. Any ideas?
xKing Posted February 27, 2017 Posted February 27, 2017 Is myqtoken.json getting root ownership? If yes - make sure you don't have script run as root anywhere. Crontab maybe (don't use /etc/crontab, run crontab -e as pi instead)? dscServer?
lsibarra Posted February 28, 2017 Posted February 28, 2017 Hi xKing, Yes you are right... the myqtoken.json is getting root ownership because the config.xml for Nodelink is set as root ownership. I just changed that to pi as well the myq-garage.log and now everytime the myqtoken.json is created.. it is being created as pi ownership. I will continue to monitor it. I disabled the cron job that I was running to delete the file and see how this one will go. Thanks again
xKing Posted February 28, 2017 Posted February 28, 2017 do the ps -ef | grep mono bet your dscServer is running as root
lsibarra Posted February 28, 2017 Posted February 28, 2017 Hi xKing, Here is the result pi@raspberrypi:~ $ ps -ef | grep mono root 978 1 5 Feb26 ? 01:44:16 mono /home/pi/node/NodeLink.exe pi 9439 9392 0 20:15 pts/0 00:00:00 grep --color=auto mono Looks like the NodeLink.exe is showing as root. how do I fix that. Larry
xKing Posted February 28, 2017 Posted February 28, 2017 yup, that's the cause. How do you start NodeLink ?
lsibarra Posted February 28, 2017 Posted February 28, 2017 Hi xKing, The Nodelink run on mono. The program is executed as follows: mono ~/node/NodeLink.exe However, I added this line on the rc.local so that when I reboot the raspberry pi, it will automatically launch the program. mono /home/pi/node/NodeLink.exe & Hope you can help me change the ownership from this info. Thanks again.
xKing Posted February 28, 2017 Posted February 28, 2017 change your line to look like su pi -c "mono /home/pi/node/NodeLink.exe" & make sure config.xml is pi owned so you won't prevent NodeLink from updating it of course.
lsibarra Posted February 28, 2017 Posted February 28, 2017 Thanks xKing. I will give this a try when I get home tonight. Thanks for your help. I've learned so much from you 1
lsibarra Posted March 2, 2017 Posted March 2, 2017 Hi xKing, I changed the line in my rc.local per your instructions. However, it is still not working. The file still needs to be deleted in order for the command to respond. Is it bad to run contab -e every 1 min to delete the file? Please advise. pi@raspberrypi:~ $ ps -ef | grep mono root 1237 1 0 Feb28 ? 00:00:00 su pi -c mono /home/pi/node/NodeLink.exe pi 1244 1237 5 Feb28 ? 01:11:12 mono /home/pi/node/NodeLink.exe pi 3283 3267 0 20:04 pts/0 00:00:00 grep --color=auto mono
xKing Posted March 2, 2017 Posted March 2, 2017 do you mean /tmp/myqtoken.json? Is it getting created as root? can you show ls -la /tmp at that time? do you call myq-garage from anywhere else except the nodeLink? maybe crontab or something? you'll need to find out what calls script as root.
lsibarra Posted March 4, 2017 Posted March 4, 2017 Hi xKing, Here is the result from the ls -la /tmp root@raspberrypi:~# ls -la /tmp total 624 drwxrwxrwt 14 root root 4096 Mar 3 18:28 . drwxr-xr-x 21 root root 4096 Oct 23 15:26 .. -rw-r--r-- 1 pi pi 566459 Mar 3 18:28 cloud-print-connector srwxr-xr-x 1 pi pi 0 Feb 28 21:33 cloud-print-connector-monitor.sock drwx------ 2 pi pi 4096 Feb 28 21:32 dhcpcd-(null) drwxrwxrwt 2 root root 4096 Feb 28 21:32 .font-unix drwxrwxrwt 2 root root 4096 Feb 28 21:32 .ICE-unix srwxr-xr-x 1 pi pi 0 Feb 28 21:32 .menu-cached-:0-pi -rw------- 1 pi pi 93 Mar 3 18:28 myqtoken.json srwxr-xr-x 1 pi pi 0 Feb 28 21:32 .pcmanfm-socket--0-pi drwx------ 2 root root 4096 Feb 28 21:32 pulse-PKdhtXMmr18n drwx------ 2 pi pi 4096 Feb 28 21:32 ssh-oqIsvg9tmD9E drwx------ 2 pi pi 4096 Feb 28 21:32 ssh-Yo2MOcnXwp3g drwx------ 3 root root 4096 Feb 28 21:32 systemd-private-f8bc8ad405b641e5a97c881569d15787-colord.service-Eihu69 drwx------ 3 root root 4096 Mar 3 07:35 systemd-private-f8bc8ad405b641e5a97c881569d15787-cups.service-gDB9XS drwx------ 3 root root 4096 Feb 28 21:32 systemd-private-f8bc8ad405b641e5a97c881569d15787-rtkit-daemon.service-B5pspF drwxrwxrwt 2 root root 4096 Feb 28 21:32 .Test-unix -r--r--r-- 1 root root 11 Feb 28 21:32 .X0-lock drwxrwxrwt 2 root root 4096 Feb 28 21:32 .X11-unix drwxrwxrwt 2 root root 4096 Feb 28 21:32 .XIM-unix it doesn't look like the file is getting created as root anymore. Another observation I noticed is that the myqtoken.json file only gets created as soon as I make a call to myq-garage.py from the ISY Network Resource. My Network Resource setting in ISY is as follows:Command Type: tcp Host: <isy_iip_address> Port: <nodelink_port_nbr> Mode: C Escaped When I run the network resource from ISY, it will communicate with the NodeLink Relay Server which will call the myq.garage.py to run with proper arguments [open/close/status] [doorname]. For now, I created this shell script #!/bin/sh file=/tmp/myqtoken.json if [ -f "$file" ] ; then rm -f "$file" fi and setup crontab -e to * * * * * /home/pi/node/del_myqtoken.sh to delete the file if it exist. This cron is running every minute to see if there is a file there. I know that this isn't really fixing a root cause, but for now, it is working. However, any guidance you may have to identify the root cause is greatly appreciated.
xKing Posted March 4, 2017 Posted March 4, 2017 hm... so what is the exact problem you experiencing when the file IS actually there like on the output above?... P.S. If you set TOKENTTL=0 in the config - it won't even create the file, but you loosing the token caching
lsibarra Posted March 4, 2017 Posted March 4, 2017 If the file exists, the garage door will not respond regardless if the command is run from the Terminal or Network Resource in ISY. I am basically getting this error message: 2017-03-01 18:21:50,377 ERROR Traceback (most recent call last): 2017-03-01 18:21:50,377 ERROR File "/home/pi/node/myq-garage.py", line 407, in <module> 2017-03-01 18:21:50,378 ERROR gdoor_main() 2017-03-01 18:21:50,378 ERROR File "/home/pi/node/myq-garage.py", line 396, in gdoor_main 2017-03-01 18:21:50,379 ERROR print(doorname + ' not found in available doors.') 2017-03-01 18:21:50,379 ERROR UnboundLocalError 2017-03-01 18:21:50,379 ERROR : 2017-03-01 18:21:50,379 ERROR local variable 'doorname' referenced before assignment
lsibarra Posted March 4, 2017 Posted March 4, 2017 Hi xKing, Please disregard that error message that i provided in the above comment. I just replicated the issue and actually the commands from the either the Terminal or Network Resource in ISY will not respond to the garage door. I just looked at the log and all it shows is this. Not sure what the means but in order for the garage door to respond to the commands, the token file must be deleted. Somehow the token seems to not able to get a new token when it expires. 2017-03-03 20:53:55,261 INFO ==================================STARTED================================== 2017-03-03 20:54:37,143 INFO ==================================STARTED================================== 2017-03-03 20:55:13,465 INFO ==================================STARTED==================================
xKing Posted March 4, 2017 Posted March 4, 2017 (edited) Hm... does it happen immediately or after some time? Like 30 minutes? Maybe TOKENTTL value of 60 is too big, try setting it to 30? I will look at the script again, may need to enhance it to re-fetch the token on 1st error with the saved one. Edited March 4, 2017 by xKing
lsibarra Posted March 4, 2017 Posted March 4, 2017 I noticed that it stops responding between 10 to 15 minutes after the myqtoken.json file was created. For sure its good at least 8 minutes.
xKing Posted March 4, 2017 Posted March 4, 2017 Interesting, thanks! Try setting TOKENTTL to 8 then Sent from my iPhone using Tapatalk
lsibarra Posted March 4, 2017 Posted March 4, 2017 OMG xKing... after changing the TOKENTTL to 8, it is now working without deleting the file. I've been checking it every minute to see where it will break.. but so far, its been 26 minutes since myqtoken.json file was created and still working. Just for my understanding, do you know why changing it to 8 made a difference?
xKing Posted March 4, 2017 Posted March 4, 2017 Well, if TOKENTTL is 8 minutes - it will save the auth token and only use it for 8 minutes, after that it will just fetch a new one. Since MyQ web site does not return token validity period - we could only assume how long it's good for... Apparently 60 is way too much. We'll need to correct token caching logic a bit.
xKing Posted March 5, 2017 Posted March 5, 2017 I've added a retry logic, script would try to re-authenticate once if saved token did not work. Waiting for Einstein.42's approval to merge.
Recommended Posts