[sqlite] SQLITE_CANTOPEN after days of operation
Yes I can see it now with lsof on the process. Ok non-sqlite issue, now to find where I'm not closing the file properly. Thanks for assistance all! Andy > errno 24 is EMFILE "Too many open files". You almost certainly have a ? file-descriptor leak. > > -scott On 14 October 2015 at 08:52, Andrew Miles 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 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 wrote: >> >>> On 10/5/15, Andrew Miles 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 >>> >> >> >
[sqlite] SQLITE_CANTOPEN after days of operation
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 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 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 wrote: >> >>> On 10/5/15, Andrew Miles 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 >>> >> >> >
[sqlite] SQLITE_CANTOPEN after days of operation
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 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 wrote: > >> On 10/5/15, Andrew Miles 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 >> > >
[sqlite] SQLITE_CANTOPEN after days of operation
errno 24 is EMFILE "Too many open files". You almost certainly have a file-descriptor leak. -scott On Wed, Oct 14, 2015 at 12:52 AM, Andrew Miles 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 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 wrote: > > > >> On 10/5/15, Andrew Miles 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 > >> > > > > > ___ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
[sqlite] SQLITE_CANTOPEN after days of operation
On 13 Oct 2015, at 6:32pm, Scott Hess wrote: > This implies that the process was previously able to open journal files in > that directory. Having access rights to the database files change for no > reason is concerning, but so is having them not change but it just doesn't > work! You might want to log access() and/or stat() results for the > directory when you see this error. Also, you might want to check the > rights up the directory tree, and whether you have interesting errors being > reported at the OS level. And check whether you have an anti-virus package running on that computer. Simon.
[sqlite] SQLITE_CANTOPEN after days of operation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/11/2015 12:56 PM, Andrew Miles wrote: >>> 5) I ran lsof on the db, only one process (this one) had the >>> file open Have you run lsof on your monitoring process? You may be running out of file descriptors that are accessing other files or network connection s. Roger -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlYdV58ACgkQmOOfHg372QSn8gCeMB+0Jcl+XtxDW8SsDHhifAQi SwwAoMQ09NZ2kDwcCV4QZlKjEPjTzIIP =mgxT -END PGP SIGNATURE-
[sqlite] SQLITE_CANTOPEN after days of operation
On Sun, Oct 11, 2015 at 12:56 PM, Andrew Miles wrote: > 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. This implies that the process was previously able to open journal files in that directory. Having access rights to the database files change for no reason is concerning, but so is having them not change but it just doesn't work! You might want to log access() and/or stat() results for the directory when you see this error. Also, you might want to check the rights up the directory tree, and whether you have interesting errors being reported at the OS level. Based on your statement that it happens after a few days, and the problem doesn't go away if you retry, but it _does_ go away if you restart the process, you might also run lsof against the process. Maybe the process has a file-descriptor leak or something of that sort. Only other things I can think of is to try PRAGMA journal_mode=TRUNCATE. This truncates the journal file rather than deleting it. Since the journal file sticks around between transactions, this may work around the issue. -scott
[sqlite] SQLITE_CANTOPEN after days of operation
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 wrote: > On 10/5/15, Andrew Miles 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 >
[sqlite] SQLITE_CANTOPEN after days of operation
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? Andy
[sqlite] SQLITE_CANTOPEN after days of operation
On 10/5/15, Andrew Miles 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
