Requesting autoconnect for interfaces in Pigmeat (process-control & home)

@emilsayahi - can you participate in the upstream dotnet bug? With some small changes the application should be able to run without process-control. I’d like to hear from upstream dotnet before casting my vote.

Apologies if I sound a little stupid when I say this, I’m not entirely sure what to contribute to the issue? C# is a high-level, managed language—I’m not sure if there’s anything I could do on my end to resolve this problem. If it’s a bug with dotnet, and it’s not going to be resolved on their end anytime soon, then I would say connecting the interface would be the only option.
You certainly know a lot more than I do; I have very little experience in software development or the Linux ecosystem. I’m not seeing what ‘small changes’ could be made as a result.
I really appreciate your help so far. Sorry if I’m being a little tricky to work with, haha.

You are right that there isn’t anything you can do, but I’d like to hear what the dotnet folks have to say before we vote (there might be alternatives to explore, they might just fix dotnet, etc).

1 Like

Not to be a bother, it’s just that it’s been a while … since very little activity is occurring on the side of .NET, can this be revisited? I’ve had two people go so far as to leave negative reviews on the Snap Store as a result of this bug, and I’m growing a bit concerned that this autoconnect situation is harming users’ experiences and damaging the little reputation my app has:
Screenshot%20from%202020-07-03%2015-39-11

I’ve done a bit of digging, and think I found their offending code. I commented on the issue explaining my theory…

https://github.com/dotnet/runtime/blob/master/src/coreclr/src/pal/src/thread/thread.cpp#L760

1 Like

You’re the best, man. Seriously, the internet needs more people like you. Thanks for getting the ball rolling again.

Thanks @lucyllewy! I responded in the upstream bug and also suggested as a possible workaround to use LD_PRELOAD for sched_setaffinity until the issue is sorted out in dotnet proper. @lucyllewy - I can’t recall, do you have an example of this (perhaps it should be added to snapcraft-preload)?

For your future snaps, some snap publishers wait to promote their snaps to stable until auto-connections are established. Also, I believe you may be able to use an LD_PRELOAD to fix your snap now that @lucyllewy has triaged the issue.

@emilsayahi - it looks like upstream targeted fixing dotnet for this for 6.0.0. Were you able to do anything with LD_PRELOAD to work around this?

Nope, unfortunately. Thank you for your continued help, seriously. It’s unfortunate that this will take so long to fix upstream, but I’m also glad that we finally caught their attention. Hopefully, .NET Core will become more useable with Snapcraft. Currently, with .NET Core 3.1, I’ve been using a modified dotnet plugin that someone wrote in a Launchpad issue a while back, to build with snap, as the official dotnet plugin has been known to be broken (unless this has changed quite recently). I’m afraid that by the time 5.0, or even 6.0 come out, this modified plugin will itself become incompatible, creating yet another issue. Maybe I should learn Python to fix it myself, if this happens :woozy_face:?

EDIT: Here’s where I found the custom plugin: https://bugs.launchpad.net/snapcraft/+bug/1857705. The bug with the official plugin was marked as triaged and of high importance, yet was not resolved back in June when I first looked into publishing on Snapcraft. If this has been fixed it hasn’t been marked as such. If it has not, I suggest accepting ed10vi’s patch, which was written toward the end of May, ASAP and then looking into ensuring the dotnet plugin continues to work with future releases. .NET 5 releases rather soon, November 2020 (release previews are out now), with 6.0 being targeted for November 2021 (source).

+1 for auto-connection of process-control for now. When dotnet is updated, we can consider migrating your snap away from it.

@reviewers - can others please vote?

1 Like

@advocacy, @leecow - perhaps dotnet could consider backporting the fix for https://github.com/dotnet/runtime/issues/1634 (currently milestoned for 6) to .NET 5 once it is applied to 6? We could probably handle the developer friction until 5 is released (ie, dotnet runtime consumers having to plugs and ask for auto-connect of process-control) until November, but waiting more than a year for the fix would be suboptimal.

Also see:

1 Like

+1 for auto-connect of process-control to pigmeat as a stop-gap.

+2 votes for, 0 votes against, this is now live.

1 Like

FYI, progress is being made on https://github.com/dotnet/runtime/issues/1634 and it looks like they are considering backporting as far back as dotnet runtime 3.1.