Sorry didn't see previous replies before sending. I'll try next: 1) When the error occurs to create a new file in the directory 2) Check lsof of main and monitoring process to see if either is leaking files
Get back to you in a few days.... Thanks Andy On 14 October 2015 at 08:52, Andrew Miles <andy at blandsrow.com> wrote: > Fully opening the directory failed to fix the issue. So in summary the > program works for days then dies with this in the log: > > (14) cannot open file at line 28488 of [f5b5a13f73] > (14) os_unix.c:28488: (24) open(/usr/share/cm160) - > (14) cannot open file at line 28488 of [f5b5a13f73] > (14) os_unix.c:28488: (24) open(/usr/share/cm160) - > (14) cannot open file at line 30285 of [f5b5a13f73] > (14) os_unix.c:30285: (24) open(/usr/share/cm160/eagleowl_stat.db-journal) > - > (14) statement aborts at 29: [UPDATE energy_hour_stat SET status = 1 WHERE > record_count = 60] > > Any advice on what could be causing this? > > Andy > > On 11 October 2015 at 20:56, Andrew Miles <andy at blandsrow.com> wrote: > >> Thanks >> >> Log showed it unable to open the directory and then unable to write the >> journal file. The directory is root writable and the process is run as >> root so I didn't expect a problem here. I've now modified the directory >> access to be writable by all to see if that changes things. >> >> Andy >> >> On 5 October 2015 at 11:39, Richard Hipp <drh at sqlite.org> wrote: >> >>> On 10/5/15, Andrew Miles <andy at blandsrow.com> wrote: >>> > Hi >>> > >>> > I have a strange issue with a piece of C code using sqlite3. The code >>> runs >>> > for days and then stops on an SQL insert into db with the error code >>> > SQLITE_CANTOPEN. >>> > >>> > Further info: >>> > >>> > 1) The program is a status monitoring app - it writes values into the >>> SQL >>> > db once every 60 seconds. Average duration is about 2 days before >>> dying so >>> > roughly 3000 successful writes before failure. >>> > 2) The SQL db is kept open for the entire time i.e. I don't open/close >>> on >>> > every transaction. >>> > 3) There is another process accessing the same db but read only >>> > 4) I tried waiting 5 secs on the first CANTOPEN and trying again in >>> case >>> > the other process had locked the db but same message. Even closing >>> the db >>> > and reopening won't free the error. The only method is to stop the >>> program >>> > and restart, then it works again every time. >>> > 5) I ran lsof on the db, only one process (this one) had the file open >>> > 6) The extended error code reported is 14 i.e. no further information >>> > 7) Disk has 5GB free >>> > >>> > Any advice on how to debug further? >>> > >>> >>> Activate the error and warning log. https://www.sqlite.org/errlog.html >>> >>> -- >>> D. Richard Hipp >>> drh at sqlite.org >>> _______________________________________________ >>> sqlite-users mailing list >>> sqlite-users at mailinglists.sqlite.org >>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >>> >> >> >
