49

I am getting an error on bluetooth service status.

I need guidance to resolve this error.

    pi@raspberrypi:~ $ sudo service bluetooth status
* bluetooth.service - Bluetooth service
   Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled)
   Active: active (running) since Sat 2016-01-09 19:12:47 UTC; 1min 12s ago
     Docs: man:bluetoothd(8)
 Main PID: 370 (bluetoothd)
   Status: "Running"
   CGroup: /system.slice/bluetooth.service
           `-370 /usr/lib/bluetooth/bluetoothd

Jan 09 19:12:46 raspberrypi bluetoothd[370]: Bluetooth daemon 5.23
Jan 09 19:12:47 raspberrypi bluetoothd[370]: Starting SDP server
Jan 09 19:12:47 raspberrypi systemd[1]: Started Bluetooth service.
Jan 09 19:12:47 raspberrypi bluetoothd[370]: Bluetooth management interface 1.9 initialized
Jan 09 19:12:47 raspberrypi bluetoothd[370]: Sap driver initialization failed.
Jan 09 19:12:47 raspberrypi bluetoothd[370]: sap-server: Operation not permitted (1)
pi@raspberrypi:~ $
Patrick Cook
  • 6,365
  • 7
  • 37
  • 63
Jeeva
  • 603
  • 1
  • 5
  • 4
  • 1
    sap in this context seems to be SIM access protocol and thus is likely to be something to do with connecting to a mobile phone (and presumably internet data). Given that all the other messages are about a successful start-up of the bluetooth daemon I'm not entirely sure that is an error as such...? – SlySven Jan 10 '16 at 12:37
  • SAP is related to sim access, for more info on this https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1629632 – Pavan Nath Jan 07 '20 at 06:57

2 Answers2

64

NOTE:

This was a good answer at one time, but it appears that it may not work any longer. This is based on trying to cure the same problem posted in the OP's question - but on a bullseye system. The same is true for the answer below.

SAP stands for SIM Access Profile, so you have to disable it:

  • Open /etc/systemd/system/bluetooth.target.wants/bluetooth.service

  • Add "--noplugin=sap" at the end of the "ExecStart" Line: For example change-

      ExecStart=/usr/lib/bluetooth/bluetoothd

To

    ExecStart=/usr/lib/bluetooth/bluetoothd --noplugin=sap

Don't copy paste the above command directly! Just add "--noplugin=sap" at the end of the "ExecStart" line!

  • Reload the systemd:

      $ sudo systemctl daemon-reload

  • Restart the bluetooth:

      $ sudo service bluetooth restart

  • Get the bluetooth status:

      $ sudo service bluetooth status

    bluetooth.service - Bluetooth service
     Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled)
     Active: active (running) since Sat 2016-04-30 10:38:46 UTC; 6s ago
       Docs: man:bluetoothd(8)
   Main PID: 12775 (bluetoothd)
     Status: "Running"
     CGroup: /system.slice/bluetooth.service
             └─12775 /usr/lib/bluetooth/bluetoothd --noplugin=sap
Seamus
  • 21,900
  • 3
  • 33
  • 70
pylover
  • 740
  • 7
  • 9
  • 3
    If you like to stick with systemctl, it can also do systemctl restart bluetooth and systemctl status bluetooth. Those probably also need sudo. – XTL Sep 26 '16 at 19:42
  • 3
    In most of web tutorials and solutions, we do not write the sudo for safety. i assume the linux users are already knowing about privileges. but here is no problem, tanks, i'll add those sudo's. – pylover Sep 26 '16 at 21:12
  • Works ok, once, then I find out that the file that need to be addressed is (also) /lib/systemd/system/bluetooth.service – fcm Aug 12 '17 at 22:02
  • 2
    Why isn't this disabled by default? – Sawtaytoes Jul 06 '19 at 04:13
  • I don't know why. the Linux audio is so complicated. – pylover Jul 06 '19 at 17:52
  • 1
    Editing /etc/systemd/system/bluetooth.target.wants/bluetooth.service seems to have no effect for me.. had to edit /lib/systemd/system/bluetooth.service – Nickolay Nov 10 '23 at 22:18
20

NOTE:

This was a good answer at one time, but it appears that it may not work any longer. This is based on trying to cure the same problem posted in the OP's question - but on a bullseye system.

If you don't want to overwrite the system bluetooth.service file, it's a good place to use a .service.d override:

sudo mkdir  /etc/systemd/system/bluetooth.service.d/

Then place in this file:

/etc/systemd/system/bluetooth.service.d/01-disable-sap-plugin.conf

[Service]
ExecStart=
ExecStart=/usr/lib/bluetooth/bluetoothd --noplugin=sap

sudo systemctl daemon-reload
sudo systemctl restart bluetooth.service

Note: The double usage of ExecStart= in the SystemD bluetooth.service.d override file is important! The first line with empty assignment, "ExecStart=", clears out the value of ExecStart so we can override it later rather than append to it. This S.O. answer gives more detail. Some SystemD settings such as ExecStart behave as an appended list when specifying them multiple times. Many options that you want to override will apply to this use case when we use foo.service.d/*.conf files. So it's important to notice that an extra Foo= setting may be necessary to override a value rather than append to a list.

Seamus
  • 21,900
  • 3
  • 33
  • 70
TrinitronX
  • 301
  • 2
  • 6
  • 7
    I think it is better to use sudo systemctl edit bluetooth.service instead of fiddling direct with systemd directories and files. – Ingo Jun 25 '19 at 14:47
  • Yeah, good suggestion. It's a an easy way to do the same thing above. Sometimes it helps to rename the .d/ file snippet to clarify what it's doing. – TrinitronX Jun 26 '19 at 17:18
  • 1
    Mainly it's a safer way doing this under control of systemd? – Ingo Jun 26 '19 at 17:22
  • @Ingo: Yeah it's another feature of newer SystemD versions. There are some cases where you may not want to do this, like for example: editing a production .service file is risky. This blog post has more helpful info. One of the things mentioned there is "All successful editing converts into a service restart!" So it's not always "safer" as you say, but it could be more convenient. – TrinitronX Jun 27 '19 at 21:58
  • @TrinitronX Can you please explain inside your answer why there an empty argument for the ExecStart parameter ? – SebMa Feb 28 '20 at 12:26
  • 2
    @SebMa : Sure! The simplest explanation is that it clears out the value of ExecStart= so we can override it later rather than append to it. Some SystemD settings behave as an appended list when specifying them multiple times. This S.O. answer gives more detail – TrinitronX Feb 28 '20 at 22:01
  • 1
    @trinitronx Thanks. Can you please add this explanation into your answer so that other people don't have to go through all the comments to understand why the parameter was first set to blank ? – SebMa Feb 29 '20 at 08:22
  • 1
    @SebMa: Great idea! I've added the explanation to the answer. – TrinitronX Mar 04 '20 at 22:53