Archived Forum

On my system, I've got PHPFIWA, PHPFINA, PHPTIMESTORE and MYSQL they all appear to be working fine. Just tried creating a new TIMESTORE feed that also works fine with data displaying in the realtime graph as I post datapoints. Could it be settings file related?

I'll take a look. The MYSQL feed I'm using for my daily gas pulses was rendering fine. I wonder if it could be the timestore key or something - but when I refreshed the feed sizes, the timestore feeds were definitely getting bigger.

A puzzler!

[edit: unless the settings.php file has the timestore key knocked out of it but I haven't restarted rfm12piphp recently. That would account for it continuing to log to feed, but be undisplayable?]

OK, I have a diagnosis but I'm a little stuck with it.

After I got my dev pi set up last night, I cleaned a lot of dev stuff out of my "live" pi and this included a timestore directory in the homedir (I can see this from history - no idea what was in it).

Surely timestore doesn't run out of one particular user's homedir... right? If so, what was there and how do I reinstate it?

It looks like the timestore feeds haven't updated since I booted that pi last night to pick up some hostname changes. Not a disaster, but a bit disappointing that there's no indication it was merrily logging 7 nodes to nothing (I take this on the chin and will look at how this might be advised on the feed page in some way).

Sigh... more trouble in paradise!

I decided to limit the damage I'd create PHPFIWA feeds and worry about transferring the old data later. However, these don't seem to work either - they get created with root/root ownership and rw-r-r permissions only... chmodding them has not resulted in any data suddenly being logged (at the same time, no problem at all with my previous PHPFIWA feeds).

Hmm, what's the permissions on the PHPFIWA folder itself? that needs to be set with:

sudo chown -R www-data:root /var/lib/phpfiwa

OK, so just to update, the mechanism I have to follow to get PHPFIWA feeds working is:

- create the feed

- chmod the permissions since they are created pretty strict:

-rw-r--r--  1 root     root        40 Mar 27 18:58 87_0.dat
-rw-r--r--  1 root     root         8 Mar 27 18:58 87_1.dat
-rw-r--r--  1 root     root         4 Mar 27 18:58 87_2.dat
-rw-r--r--  1 www-data www-data    36 Mar 27 18:58 87.meta
-rw-r--r--  1 root     root         4 Mar 27 18:58 88_0.dat
-rw-r--r--  1 root     root         4 Mar 27 18:58 88_1.dat
-rw-r--r--  1 root     root         4 Mar 27 18:58 88_2.dat
-rw-rw-r--  1 www-data www-data    36 Mar 27 18:58 88.meta

- restart rfm12piphp

Only then do I get recorded data.

Crikey!

@Trystan - you mean chown, right? Here's the current permission:

ls -al /var/lib | grep php
drwx-wx-wt  2 root      root       4096 Mar 27 18:39 php5
drwxrwxrwx  2 www-data  root       4096 Mar 27 18:25 phpfina
drwxrwxrwx  2 www-data  root       4096 Mar 27 18:58 phpfiwa
drwxrwxrwx  2 www-data  root       4096 Mar 18 00:46 phptimeseries

I tried altering the apache user's umask, but that's only helped with the meta files, not the dat ones.

What is it that creates the dat files? Clearly not apache. Is it something that I should be running as a different account, but is actually running as root?

just to confirm, chowning the dat files allows them to record (without restarting rfm12piphp... bizarrely)

aha! I've missed something here havent I! because Im running my home system through a modification to the raspberrypi_run.php script that then does a http request to the new node interface. Which means that the feeds are being created by the www-data user..

One solution would be to switch to Jerome's oem_gateway which does this as standard, the other is probably to get the feed engine to set the file ownership on creation to www-data

We could use this just after fopen i guess, http://www.php.net/manual/en/function.chown.php

Actually maybe it should work, Im testing it here running not the raspberrypi_run.php script but the input_queue_processor as root and that works ok, the data is being inserted and I can view it, the permissions are:

-rw-r--r-- 1 root     root         12 Mar 27 19:18 7_0.dat
-rw-r--r-- 1 root     root          8 Mar 27 19:18 7_1.dat
-rw-r--r-- 1 root     root          4 Mar 27 19:18 7_2.dat
-rw-r--r-- 1 root     root          4 Mar 27 19:18 7_3.dat
-rw-r--r-- 1 www-data www-data     44 Mar 27 19:18 7.meta

But then if I then try and add a value via the http interface of course, it fails. So chown is probably needed.

I'm chowning them (in PHP) to www-data but that still wasn't sufficient - I had to chmod g+w on the command line before they would update. Which is odd, because it seems to be heading back to where we started...

If I add the following lines to PHPFiwa.php at line 74 (inside the create method)

            $fh = fopen($this->dir.$meta->id."_0.dat", 'c+');
            fclose($fh);
            chown($this->dir.$meta->id."_0.dat","www-data");
           
            $fh = fopen($this->dir.$meta->id."_1.dat", 'c+');
            fclose($fh);
            chown($this->dir.$meta->id."_1.dat","www-data");
           
            $fh = fopen($this->dir.$meta->id."_2.dat", 'c+');
            fclose($fh);
            chown($this->dir.$meta->id."_2.dat","www-data");
           
            $fh = fopen($this->dir.$meta->id."_3.dat", 'c+');
            fclose($fh);
            chown($this->dir.$meta->id."_3.dat","www-data");

It then creates the data files with the correct ownership. We could bring the user out as a setting to the settings.php file.

The result of which is:

-rw-r--r-- 1 www-data www-data      4 Mar 27 19:30 8_0.dat
-rw-r--r-- 1 www-data www-data      4 Mar 27 19:30 8_1.dat
-rw-r--r-- 1 www-data www-data      4 Mar 27 19:30 8_2.dat
-rw-r--r-- 1 www-data www-data      4 Mar 27 19:30 8_3.dat
-rw-r--r-- 1 www-data www-data     44 Mar 27 19:30 8.meta

[cross post]

OK - that makes sense.

Ah I dont even need the chown bit in there as the initial creation is done via the web interface.. :) good thing because im pretty sure chown would create an error on windows

I've updated the master branch with the fix for this:

https://github.com/emoncms/emoncms/commit/55d2419b44f0a74459bb4f3dd03632...

Phew - thanks. I've pushed 8.0.7 up to the apt repo so people can pick that up (yikes)

I now need a way of reading the values from my original timestore feeds and injecting them into my new PHPFIWA feeds. Do you have anything like that yet, or any pointers if not?

cheers for the quick fix... I should probably not delete things from the homedir again without due caution!