programs stop executing once agent.log fullfills /tmp

[MLope15]

Hi,

my Galileo programs stop execution once the agent.log fullfills the space in the /tmp filesystem. How can stop the writing in that file?

Regards

[Pablo_M_Intel]

Hi marco.lopez.trinidad@gmail.com,

Could you please be a bit more specific? Are you using tail –f to see what's going on with agent.log? What are you getting?

Did you try restarting the iotkit-agent?

systemctl restart iotkit-agent

Regards,

PabloM_Intel

[MLope15]

Hi Pablo,

I mean, the Galileo program starts running in normal way, agent.log file starts with no text at all, after sometime of the program execution (days), the program gets stopped which coincides with a huge agent.log file and /tmp at 100% use. In addition, the network communication gets closed by the Galileo.

I assume the filesystem gets overloaded and via an OS mechanism the program is stopped in order not writing more data in the agent.log file and also communications (transfer of reception of data) get closed.

With respect the tail -f command returns:

tail: warning: following standard input indefinitely is ineffective

[MLope15]

Kind Regards!

[Pablo_M_Intel]

Hi marco.lopez.trinidad@gmail.com,

Thank you for your answer. Could you please share some more information so we can replicate your issue?

• Which image are you using?
• Could you provide the code or script that you're running?
• Which IDE are you using to upload your program?
• For how long are you running the program without interruptions?
• Have you make any changes to the image before running your program? Image changes or library downloads.

Regards,

PabloM_Intel

[MLope15]

Hi Pablo,

1. Image: Linux version 3.8.7-yocto-standard (brendanl@iotd01) (gcc version 4.8.2))
2. Code:

# include

# include

# include

# include

# include

# include

# include

# include

# include "mraa/aio.h"

# define GP_LED 18 // PGI13 is the GP LED

# define GP_TEMP 37 // A0_MUX is temperature INPUT

# define GPIO_DIRECTION_IN 1

# define GPIO_DIRECTION_OUT 0

# define ERROR -1

# define ANALOG_PIN 0

# define LED_ON 1

# define LED_OFF 0

int sockfd, n;

struct sockaddr_in servaddr;

char json[256];

char buffer[256];

mraa_aio_context adc;

int fileHandleGPIO_LED;

int fileHandleGPIO_TEMP;

int ledState;

int B = 3975;

int openGPIO(int gpio, int direction) {

char buffer[256];

int fileHandle;

int fileMode;

fileHandle = open("/sys/class/gpio/export", O_WRONLY);

if(ERROR == fileHandle) {

puts("Unable to opening /sys/class/gpio/export");

return -1;

}

sprintf(buffer, "%d", gpio);

write(fileHandle, buffer, strlen(buffer));

close(fileHandle);

// Direction GPIO

sprintf(buffer, "/sys/class/gpio/gpio%d/direction", gpio);

fileHandle = open(buffer, O_WRONLY);

if(ERROR == fileHandle) {

puts("unable to open flie: ");

puts(buffer);

return -1;

}

if(direction == GPIO_DIRECTION_OUT) {

write(fileHandle, "out", 3);

fileMode = O_WRONLY;

}

else {

write(fileHandle, "in", 2);

fileMode = O_RDONLY;

}

close(fileHandle);

// Open GPIO for read/write

sprintf(buffer,"/sys/class/gpio/gpio%d/value", gpio);

fileHandle = open(buffer,fileMode);

if(ERROR == fileHandle) {

puts("Unable to open file: ");

puts(buffer);

return -1;

}

return fileHandle;

}

int closeGPIO(int gpio, int fileHandle) {

char buffer[256];

close(fileHandle);

fileHandle = open("/sys/class/gpio/unexport", O_WRONLY);

return fileHandle;

}

int writeGPIO(int fHandle, int val) {

if(val == 0) {

// set GPIO low status

write(fHandle, "0", 1);

}

else {

write(fHandle, "1", 1);

}

return 0;

}

int network_setup(void) {

puts("Network setup");

sockfd = socket(AF_INET, SOCK_DGRAM, 0);

bzero(&servaddr, sizeof(servaddr));

servaddr.sin_family = AF_INET;

servaddr.sin_addr.s_addr = inet_addr("127.0.0.1");

servaddr.sin_port = htons(41234);

return 0; // only to compile purposes.

}

int board_setup(){

ledState = LED_OFF;

puts("Board setup");

adc = mraa_aio_init(ANALOG_PIN);

if(NULL == adc) {

puts("Unable to init adc");

return(-1);

}

// LED handle used each time switching is required.

fileHandleGPIO_LED = openGPIO(GP_LED, GPIO_DIRECTION_OUT);

if(ERROR == fileHandleGPIO_LED) {

puts("unable to open LED port # 13");

return(-1);

}

writeGPIO(fileHandleGPIO_LED, ledState);

return 0;

}

int setup(void) {

network_setup();

board_setup(); ...

[Pablo_M_Intel]

Hi marco.lopez.trinidad@gmail.com,

Have you tried implementing a script that manages the amount of data in that file? If you are able to control how much is written in that file maybe you'll be able to prevent the program from stopping. If you're not sure how to proceed with this I suggest to check this tutorial https://www.linux.com/learn/tutorials/284789-writing-a-simple-bash-script- https://www.linux.com/learn/tutorials/284789-writing-a-simple-bash-script-.

Regards,

PabloM_Intel

[MLope15]

Hi Pablo,

no I didn't.

On the other hand, I found that not using the puts instruction nothing is written in the agent.log file. Rather the Galileo board after working few days unexpectedly anyway stops transmitting logs to the Dashboard, even if I restarted the iotkit-agent the Galileo board does not transmit anything.

cheers up!

--marco

[Pablo_M_Intel]

Hi marco.lopez.trinidad@gmail.com,

So, if you remove the puts command the agent.log file is not filled with data anymore, but the even after that the Galileo stops transmitting. Am I right? I apologize if I'm missing something.

Did you check if the program is still running? Because you can write a script that sees if the sketch is still running, if this is not the case you can then restart the sketch.

Regards,

PabloM_Intel

[MLope15]

Hi Pablo,

yes, the puts command writes in the console and also in the agent.log file, therefore removing the command the program continuous the execution, apparently with no problem.

Curiously, after the program stops logging data to the agent.log and the Dashboard, the program stills running.

Regards,

--marco

[Pablo_M_Intel]

Hi marco.lopez.trinidad@gmail.com,

That's very weird, so the problem is not the agent.log file being filled anymore, we can discard that. Still it would be necessary to find a way to avoid the program from stopping logging data. I can't think of a definitive solution because we don't know exactly what the root of the issue is, but a possible workaround would be to stop and restart the program every now and then and see if solves the problem.

Regards,

PabloM_Intel

[Pablo_M_Intel]

Hi marco.lopez.trinidad@gmail.com,

Do you have updates on this case?

Regards,

PabloM_Intel

[MLope15]

Hi,

no, I've not. It is still the same way.

regards!

--marco

[Pablo_M_Intel]

Hi marco.lopez.trinidad@gmail.com,

Did you try our suggestion? Writing a script that keeps this file empty so you can prevent the program from stopping.

Regards,

PabloM_Intel