Bug #5661
closedsms.db files not in proper directory / backtrace on old sms.db
100%
Description
osmo-msc writes his sms.db (and .wad etc) files in the 'working directory' which is not set and thus in /
this should be /var/lib/osmocom
i only noticed it by accident since a recent update broke it on restart:
Aug 24 16:17:22 nebula systemd[1]: Started Osmocom Mobile Switching Center (MSC). Aug 24 16:17:22 nebula osmo-msc[31967]: <0014> telnet_interface.c:100 Available via telnet 127.0.0.1 4254 Aug 24 16:17:22 nebula osmo-msc[31967]: <000d> smpp_smsc.c:1017 SMPP at 0.0.0.0 2775 Aug 24 16:17:22 nebula osmo-msc[31967]: <001b> control_if.c:1013 CTRL at 127.0.0.1 4255 Aug 24 16:17:22 nebula osmo-msc[31967]: <001e> gsup_client.c:75 GSUP connecting to 127.0.0.1:4222 Aug 24 16:17:22 nebula osmo-msc[31967]: <000a> db.c:522 Init database connection to 'sms.db' using SQLite3 lib version 3.16.2 Aug 24 16:17:22 nebula osmo-msc[31967]: <000a> db.c:318 SQLITE3: (283) recovered 224 frames from WAL file //sms.db-wal Aug 24 16:17:22 nebula osmo-msc[31967]: <000a> backtrace.c:43 backtrace() returned 21 addresses Aug 24 16:17:22 nebula osmo-msc[31967]: <000a> backtrace.c:53 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0(+0x45e10) [0x7f5d4ae7ee10] Aug 24 16:17:22 nebula osmo-msc[31967]: <000a> backtrace.c:53 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0(sqlite3_log+0x9e) [0x7f5d4ae7eede] Aug 24 16:17:22 nebula osmo-msc[31967]: <000a> backtrace.c:53 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0(+0x59bcb) [0x7f5d4ae92bcb] Aug 24 16:17:22 nebula osmo-msc[31967]: <000a> backtrace.c:53 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0(+0x5a00b) [0x7f5d4ae9300b] Aug 24 16:17:22 nebula osmo-msc[31967]: <000a> backtrace.c:53 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0(+0x64362) [0x7f5d4ae9d362] Aug 24 16:17:22 nebula osmo-msc[31967]: <000a> backtrace.c:53 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0(+0x67b6f) [0x7f5d4aea0b6f] Aug 24 16:17:22 nebula osmo-msc[31967]: <000a> backtrace.c:53 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0(+0x96cf2) [0x7f5d4aecfcf2] Aug 24 16:17:22 nebula osmo-msc[31967]: <000a> backtrace.c:53 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0(+0x96e5e) [0x7f5d4aecfe5e] Aug 24 16:17:22 nebula osmo-msc[31967]: <000a> backtrace.c:53 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0(+0x96f10) [0x7f5d4aecff10] Aug 24 16:17:22 nebula osmo-msc[31967]: <000a> backtrace.c:53 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0(+0xa7e5d) [0x7f5d4aee0e5d] Aug 24 16:17:22 nebula osmo-msc[31967]: <000a> backtrace.c:53 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0(+0xaaccd) [0x7f5d4aee3ccd] Aug 24 16:17:22 nebula osmo-msc[31967]: <000a> backtrace.c:53 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0(+0xaf4b1) [0x7f5d4aee84b1] Aug 24 16:17:22 nebula osmo-msc[31967]: <000a> backtrace.c:53 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0(+0xafa0a) [0x7f5d4aee8a0a] Aug 24 16:17:22 nebula osmo-msc[31967]: <000a> backtrace.c:53 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0(sqlite3_prepare_v2+0x16) [0x7f5d4aee8cf6] Aug 24 16:17:22 nebula osmo-msc[31967]: <000a> backtrace.c:53 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0(sqlite3_exec+0xc3) [0x7f5d4aecf3c3] Aug 24 16:17:22 nebula osmo-msc[31967]: <000a> backtrace.c:53 /usr/bin/osmo-msc(+0x1ba50) [0x559f14cb2a50] Aug 24 16:17:22 nebula osmo-msc[31967]: <000a> backtrace.c:53 /usr/bin/osmo-msc(+0x527ed) [0x559f14ce97ed] Aug 24 16:17:22 nebula osmo-msc[31967]: <000a> backtrace.c:53 /usr/bin/osmo-msc(+0x12dc5) [0x559f14ca9dc5] Aug 24 16:17:22 nebula osmo-msc[31967]: <000a> backtrace.c:53 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f5d4a69a2e1] Aug 24 16:17:22 nebula osmo-msc[31967]: <000a> backtrace.c:53 /usr/bin/osmo-msc(+0x1383a) [0x559f14caa83a] Aug 24 16:17:22 nebula osmo-msc[31967]: <000a> db.c:470 Detected DB Revision 5, expected 6 Aug 24 16:17:22 nebula osmo-msc[31967]: <000a> db.c:488 The storage format of BINARY data in the database has changed. In order to deliver any pending SMS in your database, you must manually convert your database from '5' to '6'. Alternatively you can use a fresh, blank database with this version of osmo-msc, sorry. Aug 24 16:17:22 nebula osmo-msc[31967]: <000a> db.c:634 Database schema revision invalid, please update your database schema Aug 24 16:17:22 nebula osmo-msc[31967]: <0007> sms_queue.c:519 DB: Failed to prepare database. Aug 24 16:17:22 nebula systemd[1]: osmo-msc.service: Main process exited, code=exited, status=255/n/a Aug 24 16:17:22 nebula osmo-hlr[30480]: 20220824161722609 DLINP ERROR 127.0.0.1:34331 lost connection with server (ipa.c:375) Aug 24 16:17:22 nebula systemd[1]: osmo-msc.service: Unit entered failed state. Aug 24 16:17:22 nebula systemd[1]: osmo-msc.service: Failed with result 'exit-code'. Aug 24 16:17:24 nebula systemd[1]: osmo-msc.service: Service hold-off time over, scheduling restart. Aug 24 16:17:24 nebula systemd[1]: Stopped Osmocom Mobile Switching Center (MSC).
since this is a testsetup i simply deleted the sms.db, but this should either error out properly or update the db file - the backtrace is not what i expect in any case.
same is true for the osmo-ggsn which adds a "gsn_restart" file.
Related issues
Updated by fixeria almost 2 years ago
- Related to Bug #4821: Update working dir in systemd unit files added
Updated by msuraev almost 2 years ago
- Status changed from New to In Progress
There's potential problem with directory ownership on Debian-based systemd with this: right now /var/lib/osmocom is created from osmo-hlr so if it's not install on the system osmo-msc (and others using it) will fail.
We can make the WorkingDirectory optional in systemd unit (and get the same backtrace as above) or make libosmocore.deb owner of /var/lib/osmocom since all our projects require libosmocore anyway. Perhaps there's another Debian-specific solution I'm not aware of?
Updated by msuraev almost 2 years ago
- % Done changed from 0 to 20
Nevermind, if we use StateDirectory= than it'll be automatically created if missing. So the only problem on Debian will appear if osmo-hlr is installed after osmo-msc (or alike) was run.
Updated by laforge almost 2 years ago
Can't two pacakges "share" ownership of a directory? After all, I think it's quite common
that multiple packages put files in the same directory. Just think of /etc. If I do a dokg -S etc
, I get tons of packages listed
Updated by msuraev almost 2 years ago
laforge wrote in #note-5:
Can't two pacakges "share" ownership of a directory?
Certainly. The easiest way would be to let systemd create it on-demand for us instead of making it during package install - see https://gerrit.osmocom.org/c/osmo-hlr/+/29225
Updated by msuraev almost 2 years ago
- % Done changed from 20 to 50
The fix is under review in https://gerrit.osmocom.org/c/osmo-msc/+/29242
Updated by msuraev almost 2 years ago
- Status changed from In Progress to Resolved
- % Done changed from 50 to 100