| View previous topic :: View next topic |
| Author |
Message |
dewhite
Tux's lil' helper
Joined: 16 Mar 2003
Posts: 106
Location: Houston, Texas, USA
|
 Posted: Mon Oct 17, 2016 5:37 am Post subject: log spam: obexd_server_init failed |
 |
|
I just completed a new install earlier today and set about getting Plasma installed with all my favorite apps & utilities.
I was piddling around with filelight and noticed that before the end of day 1, my /var/log was already near 4gb. It turns out that two of the log files contained there were each passing 1.9gb, filled, entirely, with a repeating two-line spam about obexd failing to start.
The log files /var/log/daemon.log and /var/log/syslog are each overflowing with the following:
| Code: | Oct 17 00:30:25 localhost obexd[32385]: OBEX daemon 5.39
Oct 17 00:30:25 localhost obexd[32385]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32387]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32387]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32389]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32389]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32391]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32391]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32393]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32393]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32395]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32395]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32397]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32397]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32399]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32399]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32401]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32401]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32403]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32403]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32405]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32405]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32407]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32407]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32409]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32409]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32411]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32411]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32413]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32413]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32415]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32415]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32419]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32419]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32423]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32423]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32425]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32425]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32427]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32427]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32429]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32429]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32431]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32431]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32433]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32433]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32435]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32435]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32437]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32437]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32439]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32439]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32441]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32441]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32451]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32451]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32453]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32453]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32455]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32455]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32457]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32457]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32459]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32459]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32461]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32461]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32466]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32466]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32469]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32469]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32471]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32471]: obex_server_init failed
Oct 17 00:30:26 localhost obexd[32473]: OBEX daemon 5.39
Oct 17 00:30:26 localhost obexd[32473]: obex_server_init failed
Oct 17 00:30:27 localhost obexd[32475]: OBEX daemon 5.39
Oct 17 00:30:27 localhost obexd[32475]: obex_server_init failed |
As you can see, the message is being posted to each log several times each second.
| Code: | | ps -aux | grep obex |
gives no process for this daemon so I'm guessing it must be a function of some larger process. A google search indicates that obexd might have something to do with bluetooth - this is a desktop system with no bluetooth module attached.
Any ideas on what's run amok and how/where to see about shutting it up?
Happy to provide any additional details about system specs or configuration upon request - thanks!
_________________
Work FS: R7-5700g | 2x16Gb DDR4 | 500Gb NVMe LUKS root | 2x 8TB RAID1
Home FS: R7-1700x | 2x8Gb DDR4 | 275Gb M.2 SATA LUKS root | 2x 14TB RAID1
Last edited by dewhite on Mon Oct 17, 2016 6:00 am; edited 1 time in total |
|
| Back to top |
|
 |
dewhite
Tux's lil' helper
Joined: 16 Mar 2003
Posts: 106
Location: Houston, Texas, USA
|
| Posted: Mon Oct 17, 2016 5:57 am Post subject: |
|
|
Looking further at the output of filelight I also now see that the .xsession-errors file for my user is ridiculously huge at just over 800mb (again, just about 12 hours into the life of this young system). That file is filed with more complaints about obexd which must be a part of bluedevil:
| Code: | bluedevil: ObexManager operational changed false
bluedevil: ObexManager operational changed false
bluedevil: ObexManager operational changed false
bluedevil: ObexManager operational changed false
bluedevil: ObexManager operational changed false
|
I'm assuming that bluedevil was probably installed along with plasma-meta or kde-apps-meta?
_________________
Work FS: R7-5700g | 2x16Gb DDR4 | 500Gb NVMe LUKS root | 2x 8TB RAID1
Home FS: R7-1700x | 2x8Gb DDR4 | 275Gb M.2 SATA LUKS root | 2x 14TB RAID1 |
|
| Back to top |
|
|
dewhite
Tux's lil' helper
Joined: 16 Mar 2003
Posts: 106
Location: Houston, Texas, USA
|
| Posted: Mon Oct 17, 2016 6:30 am Post subject: |
|
|
Found a temporary fix to shut this unruly process up:
Within Plasma: Open System Settings. Go to "Startup and Shutdown" under "Workspace." Select "Background Services." Deselect use of Service called "Bluetooth." Apply Changes. Reboot system (or as I did) restart your xdm session.
This brings a stop to the spam to both log files and the .xsession-errors file.
I'm still curious what brings on this behavior - if it is a bug or something unique to the way that I installed my system. If this is a widespread bug, it should be messing up people's systems left & right...
_________________
Work FS: R7-5700g | 2x16Gb DDR4 | 500Gb NVMe LUKS root | 2x 8TB RAID1
Home FS: R7-1700x | 2x8Gb DDR4 | 275Gb M.2 SATA LUKS root | 2x 14TB RAID1 |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21631
|
| Posted: Tue Oct 18, 2016 1:41 am Post subject: |
|
|
| I would consider it a bug that the program spammed your log files like that. It may be a rare bug, but it should have required some very explicit action from you to put it into such an aggressive restart & report loop. Since you did not mention taking such an action, it is apparently looping like that without instruction from the user, which I consider to be poor practice. |
|
| Back to top |
|
|
dewhite
Tux's lil' helper
Joined: 16 Mar 2003
Posts: 106
Location: Houston, Texas, USA
|
| Posted: Tue Oct 18, 2016 7:44 pm Post subject: |
|
|
| Hu wrote: | | I would consider it a bug that the program spammed your log files like that. It may be a rare bug, but it should have required some very explicit action from you to put it into such an aggressive restart & report loop. Since you did not mention taking such an action, it is apparently looping like that without instruction from the user, which I consider to be poor practice. |
Exactly my concern. I can think of no deviant action during my install that should have allowed this behavior. Can you suggest the most appropriate action to take to escalate this concern? I often scan through bug submissions to solve my own problems, but I've never filed one myself related to Gentoo.
_________________
Work FS: R7-5700g | 2x16Gb DDR4 | 500Gb NVMe LUKS root | 2x 8TB RAID1
Home FS: R7-1700x | 2x8Gb DDR4 | 275Gb M.2 SATA LUKS root | 2x 14TB RAID1 |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21631
|
| Posted: Wed Oct 19, 2016 1:22 am Post subject: |
|
|
| You can file it with Gentoo at bugs.gentoo.org or you could try to escalate directly to upstream. Either way, you will likely be asked to provide debugging data. The respondent should be able to instruct you on how to collect this. The messages it spewed so far are unlikely to be helpful. |
|
| Back to top |
|
|
Ctp.Slow
n00b
Joined: 30 Oct 2016
Posts: 1
|
| Posted: Sun Oct 30, 2016 9:57 pm Post subject: |
|
|
Hey all,
I had the same problem today with a new installation. The problem was that the bluetooth service wasn't started. After this everything went to normal.
I agree that the behavior of spamming the logs is not the fine way to handle this situation. There should be some appropriate error handling.
Cheers  |
|
| Back to top |
|
|
trigggl
Apprentice
Joined: 26 Aug 2007
Posts: 250
Location: Arkansas
|
| Posted: Mon Jan 22, 2018 8:05 pm Post subject: |
|
|
This just helped me out with a recent plasma install.
_________________
Greg |
|
| Back to top |
|
|
guyuming
Apprentice
Joined: 19 Nov 2020
Posts: 235
|
| Posted: Sun Dec 06, 2020 6:11 am Post subject: |
|
|
| dewhite wrote: |
Within Plasma: Open System Settings. Go to "Startup and Shutdown" under "Workspace." Select "Background Services." Deselect use of Service called "Bluetooth." Apply Changes. Reboot system |
i could not find "Background Services" in Plasma.
I also have xfce desktop installed, i logout plasma and login with xfce, and can find something like kde settings in application start menus, in this kde setting, i can find the bluetooth setting dewhite mentioned.
Then i swith back to plasma, logs does not keeps growing now. |
|
| Back to top |
|
|
dewhite
Tux's lil' helper
Joined: 16 Mar 2003
Posts: 106
Location: Houston, Texas, USA
|
| Posted: Mon Jul 25, 2022 7:51 pm Post subject: |
|
|
| dewhite wrote: | Found a temporary fix to shut this unruly process up:
Within Plasma: Open System Settings. Go to "Startup and Shutdown" under "Workspace." Select "Background Services." Deselect use of Service called "Bluetooth." Apply Changes. Reboot system (or as I did) restart your xdm session.
This brings a stop to the spam to both log files and the .xsession-errors file.
I'm still curious what brings on this behavior - if it is a bug or something unique to the way that I installed my system. If this is a widespread bug, it should be messing up people's systems left & right... |
So . . . It's six years later and I have found this behavior to happen every time I stand up a new install and emerge plasma-meta. It only starts once I bring the UI up with "/etc/init.d/displaymanager start" after configuring it to use SDDM, and by that point I have usually forgotten about this problem and don't notice until later the next day that CPU is hovering at 30-40% and the size of /var/log/messages is now measured in Gibibytes...
Today, same as usual, however I thought a little more about the messages in the log and tried a different approach:
| Code: | zelda ~ # /etc/init.d/bluetooth start
* Starting bluetooth ... |
Which immediately stops the nonsense in the logs:
| Code: | Jul 25 14:28:21 zelda bluetoothd[32113]: Bluetooth daemon 5.64
bluetoothd[32113]: Starting SDP server
Bluetooth management interface 1.21 initialized |
If you want a quick way to retain what's in the logs while removing all the SPAM, consider trying this (with adjustments for your logs and logger, of course):
| Code: | | /etc/init.d/syslog-ng stop && grep -v "obex" /var/log/messages > /var/log/messages.tmp && mv /var/log/messages.tmp /var/log/messages && chmod 600 /var/log/messages && /etc/init.d/syslog-ng start |
_________________
Work FS: R7-5700g | 2x16Gb DDR4 | 500Gb NVMe LUKS root | 2x 8TB RAID1
Home FS: R7-1700x | 2x8Gb DDR4 | 275Gb M.2 SATA LUKS root | 2x 14TB RAID1 |
|
| Back to top |
|
|
|
Desktop Environments
