Do not allow running two (or more) exporters under the same name.

[steelman]

I am new to labgrid and I am experimenting with it. We've got a production labgrid instance set up and running and to avoid issues I run a second labgrid-exporter instance. For an hour or so I've been trying to acquire a place containing resources exported by my instance to no avail. The coordinator said it can't find the resource

Nov 19 20:33:05 darkstar labgrid-coordinator[1300]: INFO:root:client connected: ipv4:127.0.0.1:50336
Nov 19 20:33:05 darkstar labgrid-coordinator[1300]: placename: "rpi4"
Nov 19 20:33:05 darkstar labgrid-exporter[293794]: WARNING:root:set_acquired_request failed: acquire request for unknown resource rpi4/USBSerialPort by rpi4
Nov 19 20:33:05 darkstar labgrid-coordinator[1300]: ERROR:root:failed to acquire ResourceImport(data={'cls': 'NetworkSerialPort', 'params': {'speed': 115200, 'port': None, 'host': 'darkstar', 'extra': {'proxy_required': False, 'proxy': 'darkstar.example.local', 'path': '/dev/ttyUSB0'}}, 'acquired': None, 'avail': True}, path=('darkstar', 'rpi4', 'NetworkSerialPort', 'USBSerialPort'), orphaned=False)
Nov 19 20:33:05 darkstar labgrid-coordinator[1300]: Traceback (most recent call last):
Nov 19 20:33:05 darkstar labgrid-coordinator[1300]:   File "/home/__srv__/labgrid/labgrid-venv/lib/python3.9/site-packages/labgrid/remote/coordinator.py", line 650, in _acquire_resources
Nov 19 20:33:05 darkstar labgrid-coordinator[1300]:     await self._acquire_resource(place, resource)
Nov 19 20:33:05 darkstar labgrid-coordinator[1300]:   File "/home/__srv__/labgrid/labgrid-venv/lib/python3.9/site-packages/labgrid/remote/coordinator.py", line 625, in _acquire_resource
Nov 19 20:33:05 darkstar labgrid-coordinator[1300]:     raise ExporterError(f"failed to acquire {resource} ({cmd.response.reason})")
Nov 19 20:33:05 darkstar labgrid-coordinator[1300]: labgrid.remote.coordinator.ExporterError: failed to acquire ResourceImport(data={'cls': 'NetworkSerialPort', 'params': {'speed': 115200, 'port': None, 'host': 'darkstar', 'extra': {'proxy_required': False, 'proxy': 'darkstar.example.local', 'path': '/dev/ttyUSB0'}}, 'acquired': None, 'avail': True}, path=('darkstar', 'rpi4', 'NetworkSerialPort', 'USBSerialPort'), orphaned=False) (acquire request for unknown resource rpi4/USBSerialPort by rpi4)

The resource was there:

$ labgrid-client r
darkstar/rpi/NetworkSerialPort     # <- this is exported by the production exporter
darkstar/rpi4/NetworkSerialPort    # <- this is me playing

thus I added a place

labgrid-client -p rpi4 add-match darkstar/rpi4/*

and it showed up

$ labgrid-client -p rpi4 show
Place 'rpi4':
  matches:
    darkstar/rpi4/*
  acquired: None
  acquired resources:
  created: 2025-11-19 16:19:45.142368
  changed: 2025-11-19 20:44:06.618351
Matching resource 'USBSerialPort' (darkstar/rpi4/NetworkSerialPort/USBSerialPort):
  {'acquired': None,
   'avail': True,
   'cls': 'NetworkSerialPort',
   'params': {'extra': {'path': '/dev/ttyUSB0',
                        'proxy': 'darkstar.example.local',
                        'proxy_required': False},
              'host': 'darkstar',
              'port': None,
              'speed': 115200}}

My mistake was running the second labgrid-client without --name darkstar-devel. I didn't read the documentation thoroughly enough and I didn't know it was a thing.

However, I believe the second exporter shouldn't be allowed to connect to the coordinator under the same name as the one that was already up and running.

[threexc]

I'm not sure this is the right thing to do. While many users choose to make an exporter handle a single DUT only, that may not be ideal for some and in such cases it may be desirable for them to run multiple instances of labgrid-exporter targeting different test setups from the same machine.

Maybe some sort of warning or informational print statement when an exporter is already running under the same name would be a good middle-ground to help others in cases like yours?

[steelman]

Yup, a warning (and an option to suppress it of sort --i-know-what-i-am-doing-and-i-take-full-responsibility) would also have helped me.

run multiple instances of labgrid-exporter targeting different test setups from the same machine

Do you mean running them at the same time, or restarting labgrid-exporter with different configs? If it's the former, how would it work? I believe, what I saw, was the coordinator accepting resources from two exporters named darkstar and then being confused which one to talk to about the rpi4 place. The way I understand, what I saw, is that there is no way to have a working environment with two exporters having the same name (and being connected to the same coordinator) even if they manage disjoint sets of resources.

[jluebbe]

Yes, this is a bug/regression. Only one exporter should be able to register resources under a given name.

You can have multiple exporters (with different names) registering resources with the same 'host': <hostname>' property just fine, but the should be clearly associated with a specific exporter.

[threexc]

Yup, a warning (and an option to suppress it of sort --i-know-what-i-am-doing-and-i-take-full-responsibility) would also have helped me.

run multiple instances of labgrid-exporter targeting different test setups from the same machine

Do you mean running them at the same time, or restarting labgrid-exporter with different configs? If it's the former, how would it work? I believe, what I saw, was the coordinator accepting resources from two exporters named darkstar and then being confused which one to talk to about the rpi4 place. The way I understand, what I saw, is that there is no way to have a working environment with two exporters having the same name (and being connected to the same coordinator) even if they manage disjoint sets of resources.

Jan's right, ignore me :)