How can I troubleshoot broken SMS?
-
@ezst036 said in How can I troubleshoot broken SMS?:
How can I basically clear this file?
the simplest way is to 'rm' the file (using sudo), do a 'sudo systemctl daemon-reload', and restart the ofono daemon. Extra logging will then stop. You can attach the log file here if you save it as a .txt file.
@ezst036 said in How can I troubleshoot broken SMS?:
If there was any other troubleshooting that could be done I suspect someone else would've mentioned it.
there are probably other steps, but the first one is usually the logging.
-
@wally said in How can I troubleshoot broken SMS?:
I was excited to try the two terminal commands you referenced
Huh, I missed your post; if by these 'two terminal commands' you are writing about the ones I posted, these commands are just commands to try to debug what could happen on a hardware that I don't have in my hands. Not intended to fix anything.
-
@ezst036 MMS always mostly worked for me though, and then both MMS and SMS stopped at once. Plus the other strange stuff with the flickering. I think my weirdo problem is separate.
I do recommend tryingsystemctl --user restart nuntiumthough, just in case. It's quick to try at least. I don't really understand why that would fix things when a reboot doesn't, but it always did for me when I'd see no sign of an incoming MMS, and it has worked for others on the forum too.@gpatel-fr Thanks for the reply, but I meant the daemon-reload and restart ofono commands that ezst036 mentioned.
-
@wally said in How can I troubleshoot broken SMS?:
trying systemctl --user restart nuntium
well, that could point to a bug in this service. Logs, logs !
@wally said in How can I troubleshoot broken SMS?:
I meant the daemon-reload and restart ofono
part of the commands necessary to enable debug log output of ofono. It will not and can not fix a problem.
-
@gpatel-fr Thanks for the help! I don't have the MMS issue anymore, so can't provide logs. There's history of this in the forum, going back to when it was an initctl command under 16.04. In another thread Lionel theorized that perhaps nuntium was being started too early in the boot process, but again nobody provided logs. I tried to recreate the issue on a broken old phone just for the logs, but failed.
Thanks for the clarification on the other commands. The reason I was hopeful it might fix my situation was having read:
@ezst036 said in How can I troubleshoot broken SMS?:Interesting. As soon as I restarted the daemon with 'sudo systemctl daemon-reload' and 'sudo systemctl restart ofono', a flood of plain text messages instantly came in.
I really appreciate people looking for the root of an issue like you are, and recognize that even if the restart-nuntium command works, it's a quick fix that doesn't help anyone solve any underlying bugs unless logs can be provided.
-
I think that the 'flood' can be explained because the debug output is really noisy. That's why it's not enabled by default
-
@gpatel-fr Ah, I understand your interpretation, but I think the flood of "plain text messages" to which they're referring is not logs, but a bunch of undelivered SMS which suddenly were all delivered at once after the daemon and ofono restarted.
They go on to talk about the dating of the messages and reference "text messages", which generally means SMS.
I think they're saying that the SMS timestamps were all from right then, when the SMS were delivered, which is how UT lists timestamps in Messages (although under Notifications one can see the time at which an SMS was actually sent).@ezst036 Can you clarify whether by flood of plain text messages you mean logs or SMS?
-
@wally said in How can I troubleshoot broken SMS?:
undelivered SMS which suddenly were all delivered at once after the daemon and ofono restarted.
that is possible indeed.
In this case it's just the restarting of ofono, because what systemctl daemon-reload is doing is explaining to systemd that the configuration files have changed. If one does not do it, the restart of affected services is denied because systemd will detect that change and refuse to change the service state as long as the user has not expressed their wish to actually change the system configuration. I presume that there are security considerations here.If you have the good interpretation, it just mean that ofono was in a bad state. Just restarting it without enabling the debug log would have worked just as well.
-
@gpatel-fr Thank you for the explanation. Slowly, very slowly, I learn more about the technical end of things.
If indeed it was SMS that came flooding in after ofono was restarted, it makes me wonder if they had tried rebooting the phone prior to that, during the three days that they were unable to receive SMS. -
What I meant by flood was that I all of a sudden had many text messages from like 6 people all in the same one moment and I do not believe all of them sent their messages exactly at the same time.
Since my text messaging was clearly broken, these text messages were waiting around as if my phone had been shut off and I had a several days worth accumulation of new text messages I had never seen while the text messaging was broken. Restarting ofono fixed at least the text side of my text messaging.
-
@gpatel-fr said in How can I troubleshoot broken SMS?:
@ezst036 said in How can I troubleshoot broken SMS?:
How can I basically clear this file?
the simplest way is to 'rm' the file (using sudo), do a 'sudo systemctl daemon-reload', and restart the ofono daemon. Extra logging will then stop. You can attach the log file here if you save it as a .txt file.
Thank you. I ran into a probably much more simple problem. What is the name of the file and where does it live? And what program on a desktop do you use to read them if not a regular text editor like Kate or Vim?
I had assumed I could find it in /var/log or even var/log/journal or if nothing else I could press CTRL+S from the terminal program that was opening and reading them and save the file as I pleased with whatever name I wanted. The files I have are not text file readable so I can't view them first, but then I wouldn't send this to anybody else either.
Most of the files in /var/log/journal appear to have GUIDs in the file names. user-1001@GUID, system@GUID, and user-2011@GUID. There's also a system.journal file here. But none are seemingly plain text readable.
Thank you for sticking with me.
-
@ezst036 said in How can I troubleshoot broken SMS?:
the text side of my text messaging.
as I understand it, if ofono is working and sms is configured, sms get in; mms have another, distinct configuration. Also, I have understood recently that UT has a lack in the media configuration that could explain that files are not played correctly (nothing related to MMS per se, just that MMS have sometimes very particular formats), and of course UT don't receive MMS behind Wifi. Quite a few wrinckles.