Night_prowler
Night_prowler

Reputation: 63

Redirecting output of bluez btmgmt to file from systemd service

I try to have separate ssp modes during connection using Bluetooth btmgmt utility. Basic idea is scan current device OUI and select ssp on/off modes. But I can't get any answer from neither btmgmt con or btmgmt info commands when I put them into .service files. My system is Arch Linux arm 32-bit and bluez stack version is 5.55-1. I tried

[Unit]
Description=check Bluetooth address

[Service]
Type=oneshot
ExecStart=/usr/bin/bash -c '/usr/bin/btmgmt info >> /usr/local/lib/mac 2>&1'

without any success: it just puts nothing in output file. Some tricks like add

User=root
Group=root

or substitute ExecStart with

ExecStart=/bin/bash -c 'echo -e "$(btmgmt con)" >> /usr/local/lib/mac 2>&1

did nothing. I tried changed thing by putting btmgmt stuff in different bash script instead of start them right from service file, i.e.

ExecStart=/usr/local/lib/test1

to no avail. I'm confused completely, because of:

  1. It doesn't seem to be general btmgmt thing problem, because I can set ssp mode from service files in very simple manner, just using

    ExecStart=btmgmt off

or

ExecStart=btmgmt off

even without full path.

  1. It doesn't seem to be redirecting command error as well, because if I add

    ExecStartPre=/usr/bin/bash -c '/usr/bin/fdisk -l > /usr/local/lib/mac 2>&1'

it does work without any problem and I see fdisk info in file (I use fdisk because it requires elevated rights same as btmgmt one). Moreover, btmgmt info works in the same way, i.e. shows nothing in out file. It makes me think something is wrong in output of btmgmt. I talk about output because input parameters work fine in btmgmt ssp on/of commands and journalctl and systemct don't show any errors in btmgmt con/info cases, so it seems to like output generating successfully but then sending somewhere to outer space, but I'm not sure completely. Thanks for any help in advance

Upvotes: 2

Views: 793

Answers (3)

user70931
user70931

Reputation: 11

using script might also be a valid option to fake the TTY.

Upvotes: 1

Peter Willemsen
Peter Willemsen

Reputation: 379

I know this is an old question, but I had the same problem, and managed to fix it after hours and hours of trying.

I don't know why in the world this happens to be so hard with btmgmt but here's the fix:

[Unit]
After=bluetooth.service
Description=Bluetooth service

[Service]
ExecStart=<your-process>
Group=root
StandardInput=tty
TTYPath=/dev/tty2
TTYReset=yes
TTYVHangup=yes
Type=simple
User=root

Basically, by occupying a TTY, btmgmt will think it's running in an interactive terminal, and will output as usual.

Hope this saves anyone the hell I've been through!

Upvotes: 3

Night_prowler
Night_prowler

Reputation: 63

Well, I make a statement: btmgmt is quite intended to be used for output at any manner, but they tried make a zillion variants of output which directed to exact result it should be: bug is buried somewhere deep inside of bt_shell_printf and struct data. I'm not ready run through all that disgusting documented code (I mean total absence of comments or more-or-less satisfactory mans), so I ended up with a liitte bit hacked version of utility downgraded to simple fprintf in output, leaving only commands I need: con, ssp, power and simplified until only current setting printing info. Everything works fine, and I can use that kind of btmgmt not with systemd only, but even with udev rules (indirectly, of course)

Upvotes: 2

Related Questions