Tmds.DBus: Long running application sometimes stops to get watched DBUS changes

Hi

We are using the release 0.10 on a linux system to monitor the NetworkManager. During startup of our application we setup a Watch instance for changes on the wired network as seen in my code snippet below.

This works as expected normally, but we see cases that changes on the wired device or wired interface are never received in the handler methods. It seems as the connection to the DBUS is dead in that case.

What could cause to this behavior? Is there a connection loss that can happen (and detected)? Is there limitation we could be running into?

Regards Adrian

// create network manager
_networkManager = _dbusConnection.CreateProxy<INetworkManager>(networkManagerService, networkManagerObjectPath);

// create network manager settings
_networkManagerSettings = _dbusConnection.CreateProxy<ISettings>(networkManagerService, new ObjectPath("/org/freedesktop/NetworkManager/Settings"));

// search devices
var devices = await _networkManager.GetDevicesAsync();
foreach (var device in devices)
{
	// get device type
	// https://people.freedesktop.org/~lkundrak/nm-docs/nm-dbus-types.html#NMDeviceType
	var deviceType = await device.GetDeviceTypeAsync();

	if (deviceType == 1) // NM_DEVICE_TYPE_ETHERNET
	{
		_wiredDevice = device;
	}
}

// initialize devices
if (_wiredDevice != null)
{
	_wiredDeviceWatch = await _wiredDevice.WatchPropertiesAsync(WiredDevicePropertiesChangedHandler);

	_wiredInterface = _dbusConnection.CreateProxy<IWired>(networkManagerService, _wiredDevice.ObjectPath);
	_wiredInterfaceWatch =
		await _wiredInterface.WatchPropertiesAsync(WiredInterfacePropertiesChangedHandler);

	var wiredProperties = await _wiredInterface.GetAllAsync();
	Log.Info($"Ethernet Mac-Address: {wiredProperties.HwAddress}");
}

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 1
  • Comments: 19 (16 by maintainers)

Commits related to this issue

Most upvoted comments

The fix is part of 0.11.0 which was just published to nuget.org.

What could cause to this behavior? Is there a connection loss that can happen (and detected)? Is there limitation we could be running into?

You can add a Action<Exception> argument to a signal method that will be called when the connection is closed. The Connection class itself also emits state changes when it gets closed.

If you attach a debugger to your app and look at the Connection instance, probably it will give you an idea of its state and help debug the issue further.