Project

General

Profile

Actions
Copy link

Bug #5661

closed

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

Added by roh over 1 year ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
msuraev
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
Copy link
 #1

Updated by laforge over 1 year ago

  • Assignee set to msuraev
Actions
Copy link
 #2

Updated by fixeria over 1 year ago

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

Updated by msuraev over 1 year 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
Copy link
 #4

Updated by msuraev over 1 year 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
Copy link
 #5

Updated by laforge over 1 year 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
Copy link
 #6

Updated by msuraev over 1 year 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
Copy link
 #7

Updated by msuraev over 1 year ago

  • % Done changed from 20 to 50
Actions
Copy link
 #8

Updated by msuraev over 1 year ago

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

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)