Project

General

Profile

Actions

Bug #5661

closed

sms.db files not in proper directory / backtrace on old sms.db

Added by roh 3 months ago. Updated 3 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
08/24/2022
Due date:
% Done:

100%

Resolution:
Spec Reference:

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

Related to Cellular Network Infrastructure - Bug #4821: Update working dir in systemd unit files Resolvedmsuraev10/20/2020

Actions
Actions #1

Updated by laforge 3 months ago

  • Assignee set to msuraev
Actions #2

Updated by fixeria 3 months ago

  • Related to Bug #4821: Update working dir in systemd unit files added
Actions #3

Updated by msuraev 3 months 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?

Actions #4

Updated by msuraev 3 months 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.

Actions #5

Updated by laforge 3 months 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

Actions #6

Updated by msuraev 3 months 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

Actions #7

Updated by msuraev 3 months ago

  • % Done changed from 20 to 50
Actions #8

Updated by msuraev 3 months ago

  • Status changed from In Progress to Resolved
  • % Done changed from 50 to 100
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)