| 01:03.18 | *** join/#asterisk paulgrmn (~paulgrmn@c-98-250-183-21.hsd1.mi.comcast.net) |
| 01:07.10 | *** join/#asterisk sponji (~i5@172.58.107.233) |
| 01:24.32 | *** join/#asterisk mahafyi (2d771cc2@45.119.28.194) |
| 02:08.47 | *** join/#asterisk tsal (~tsal@i59F4DEDE.versanet.de) |
| 05:55.38 | *** join/#asterisk gerhard7 (~gerhard7@86.87.238.48) |
| 06:27.53 | *** join/#asterisk gerhard7 (~gerhard7@86-87-238-48.fixed.kpn.net) |
| 06:52.03 | *** join/#asterisk gerhard7 (~gerhard7@86-87-238-48.fixed.kpn.net) |
| 08:17.28 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
| 09:04.44 | *** join/#asterisk jkroon (~jkroon@165.16.203.116) |
| 10:12.30 | *** join/#asterisk sethmhur (~AdiIRC@c-76-16-81-90.hsd1.in.comcast.net) |
| 10:12.49 | sethmhur | good morning |
| 10:14.16 | sethmhur | I was wondering how to make public voice mail boxes in a dial plan wear other users can record voice mails? |
| 10:57.00 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 12:52.35 | *** join/#asterisk beardy (~beardy@unaffiliated/beardy) |
| 13:25.04 | *** part/#asterisk sethmhur (~AdiIRC@c-76-16-81-90.hsd1.in.comcast.net) |
| 13:29.53 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 13:41.33 | *** join/#asterisk Riviera (Riviera@2a03:b0c0:1:d0::10:b001) |
| 13:51.21 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 14:06.37 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 15:04.41 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 15:44.50 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 16:40.52 | *** join/#asterisk fling (~fling@fsf/member/fling) |
| 17:18.38 | *** join/#asterisk opal (~wowaname@volatile/founder/wowaname) |
| 17:42.40 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 17:47.18 | *** join/#asterisk life_of_e (~life_of_e@108-95-189-245.lightspeed.irvnca.sbcglobal.net) |
| 17:52.03 | *** join/#asterisk paulgrmn (~paulgrmn@c-98-250-183-21.hsd1.mi.comcast.net) |
| 18:05.43 | *** join/#asterisk jkroon (~jkroon@165.16.204.100) |
| 18:12.02 | *** part/#asterisk zerocool (~muhGNUdoh@206.189.64.51) |
| 18:12.47 | *** join/#asterisk jkroon (~jkroon@165.16.204.100) |
| 18:38.52 | *** join/#asterisk Cyrillax (~Cyrillax@unaffiliated/cyrillax) |
| 18:41.21 | Cyrillax | So I have a client thats getting a lot of "db.c: Couldn't execute statement: not an error |
| 18:41.21 | Cyrillax | " Errors. database show returns nothing, and nothing can be read or set via asterisk. However, sqlite3 reads the db just fine, and no errors are detected. Restarting asterisk fixes the problem just fine, and it continues to work until it breaks again |
| 18:41.43 | Cyrillax | The error that triggers it is Couldn't execute statement: SQL logic error or missing databas |
| 18:42.07 | Cyrillax | it's like after it fails, the internal handle * uses to communicate is dead and no reconnect is attempted |
| 18:42.25 | Cyrillax | The customer uses AMi actions a lot to update the DB |
| 18:47.01 | jkroon | Cyrillax, do you perhaps have a version where it worked, and the version where it no longer does? |
| 18:53.47 | Cyrillax | Client says he 'thinks' its always happened even since *11. but at least on all the versions of *16. on 16.14.0 and 16.9.0 right now, both identical symptoms |
| 19:01.14 | Cyrillax | Does db.c use exclusively prepared statements, or can an AMI put/get use regular statements, that could be broken by something in the AMI action? |
| 19:01.23 | Cyrillax | like a username with an ' for example |
| 19:07.14 | igcewieling | make sure asterisk has write permission to /var/lib/asterisk and /var/lib/asterisk/astdb.sqlite3 |
| 19:12.07 | jkroon | Cyrillax, i've never encountered this, and to say I've hammered astdb is putting it mildly. both via AMI and in dialplan. |
| 19:13.31 | jkroon | is there a sequence of events? |
| 19:13.58 | jkroon | there are basically two places where that error can be logged, ast_db_put() and ast_db_deltree(). |
| 19:13.59 | Cyrillax | asterisk running as root and permissions are root-owned, 644 on the file, and 755 on directory |
| 19:14.27 | jkroon | however, looking at the code, once that error has triggered, astdb is screwed. |
| 19:14.57 | jkroon | ast_mutex_lock(&dblock) ... and then a few returns before ast_mutex_unlock(&dblock). I'll create a review for that at least. |
| 19:16.41 | jkroon | no wait, I'm wrong. |
| 19:16.53 | jkroon | res gets set to -1, but the cleanup code does get executed. |
| 19:19.49 | seanbright | yes, db.c exclusively uses prepared statements |
| 19:20.28 | jkroon | yes, and sqlite3 doesn't use an external daemon, so it's not like we can lose the connection to the database server. |
| 19:20.42 | jkroon | Cyrillax, is the client tampering with the astdb.sqlite3 file directly? |
| 19:20.57 | *** join/#asterisk imcdona (~imcdona@2602:41:642e:a610:f4f1:290b:b1e1:1a27) |
| 19:22.10 | Cyrillax | I don't believe so; only after asterisk starts erring. I will confirm that |
| 19:23.09 | jkroon | seanbright, looking at https://sqlite.org/c3ref/step.html - looks like sqlite3_errmsg() may only be valid after SQLITE_ERROR specifically, so wondering if _step is returning some "normal" error response perhaps which really isn't an error, but puts things in a wacky state. |
| 19:24.01 | seanbright | dunno |
| 19:24.04 | seanbright | haven't looked in forever |
| 19:24.22 | jkroon | yea, can't really imagine this code breaking, it's very simply. |
| 19:25.04 | jkroon | we can possibly avoid a pointless sync() in case of error, but I think that's pointless, since I really don't see how this can fail, like ever. unless you're tampering externally. |
| 19:27.08 | jkroon | Cyrillax, are you comfortable editing the code? |
| 19:27.25 | Cyrillax | yea |
| 19:27.42 | jkroon | to log the actual return value from the two calls to sqlite3_step functions that can cause that warning. |
| 19:28.17 | Cyrillax | yep can do know exactly where that is have db.c open |
| 19:28.22 | jkroon | https://sqlite.org/rescode.html#ok |
| 19:28.52 | jkroon | so I believe those are the raw values, so then at least you can report back what the code is that sqlite3 is returning, then we can consider corrective action. |
| 19:30.00 | Cyrillax | takes ~ week for it to recur, so won't have that for a good while |
| 19:30.14 | jkroon | yea, that's how it goes. |
| 19:31.22 | *** join/#asterisk lankanmon (~LKNnet@cpeb4fbe4e331bd-cm64777d632380.cpe.net.cable.rogers.com) |
| 20:32.34 | Cyrillax | jkroon dude was doing a vacuum of the sqlite db at periodic intervals and didnt feel that was relevant information |
| 20:37.49 | jkroon | ok, so you will likely find that the call is returning the _BUSY response code. |
| 20:38.00 | jkroon | which isn't an error, it's just saying, you can't use it now. |
| 20:38.13 | jkroon | don't think it's necessary to do a vacuum on astdb to be honest... |
| 20:39.42 | jkroon | https://sqlite.org/lang_vacuum.html if he really needs/wants vacuum, investigate that auto_vacuum option thing. |
| 21:29.29 | *** join/#asterisk john2gb (~john2gb@94-225-47-8.access.telenet.be) |
| 22:38.46 | *** join/#asterisk dakudos (~dakudos@c-73-229-175-50.hsd1.co.comcast.net) |
| 22:43.19 | *** join/#asterisk dakudos (~dakudos@c-73-229-175-50.hsd1.co.comcast.net) |
| 23:00.17 | *** join/#asterisk CatCow97 (~mine9@c-73-96-109-206.hsd1.or.comcast.net) |
| 23:02.52 | *** join/#asterisk dakudos (~dakudos@c-73-229-175-50.hsd1.co.comcast.net) |
| 23:26.46 | *** join/#asterisk dakudos (~dakudos@c-73-229-175-50.hsd1.co.comcast.net) |
| 23:59.41 | *** join/#asterisk akp55 (~akp55@c-73-148-15-158.hsd1.va.comcast.net) |