xpra icon
Bug tracker and wiki

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#1047 closed defect (invalid)

xpra sound does not work for "identical user environment"

Reported by: Jiang Owned by: Antoine Martin
Priority: major Milestone: 0.16
Component: client Version: trunk
Keywords: Cc:

Description

After migrating to a new client, I tried to connect to the same host. Both the host and the client run 0.15.9 on 64 bit ubuntu 14.04.

When enabling sound forwarding, it does not work. Server log complains:
cannot start sound: identical user environment as the server (loop).

What specifically is the problem? Is it because the username on both server and client are the same? But I have used the same setup, the only difference being the client was 32-bit, the server 64-bit.

It would be extremely helpful if the debugging information is slightly more informative. Please let me know how to proceed to debug the situation! I assume this may be helpful for others to be included in the wiki!

Thanks a lot in advance.

Change History (6)

comment:1 Changed 5 years ago by Jiang

I circumvent the problem by passing the argument XPRA_ALLOW_SOUND_LOOP=1 in the server start up.

And admittedly, I have a very peculiar set up: I just transfer the content of my server to a new disk, and is using the old disk on my client. The way I transfer the disk is actually ddrescue, so the new disk is a carbon copy of the old, with the same uuid for disk partitions, for example. Of course, I changed the hostname on the client

So, though this is not urgent, I am very curious to know how xpra identify the server and clients? By UUID? By hostname? What do I need to change?

comment:2 Changed 5 years ago by Antoine Martin

Resolution: invalid
Status: newclosed

And admittedly, I have a very peculiar set up: I just transfer the content of my server to a new disk, and is using the old disk on my client. The way I transfer the disk is actually ddrescue, so the new disk is a carbon copy of the old, with the same uuid for disk partitions, for example.


Your machines end up with the same unique ID.
Don't do that, or at least ensure you change it afterwards.
See /etc/machine-id and /var/lib/dbus/machine-id.

comment:3 Changed 5 years ago by Jiang

I'm sorry about this novice problem. Unfortunately, ubuntu does not seem to create a file named /etc/machine-id at all. There is no such file, and when I create it by touch, the empty file is not recreated.

/var/lib/dbus/machine-id is indeed there and is unfortunately copied. It looks like a formidable random number. How do I generate it? Can I simply change this, at random, by a single digit?

I know these are not your problem, but rather due to the irregularity in ubuntu. But I searched around the internet and could not find a place where I can regenerate machine-id when it is not generated during boot time. I haven't encountered machine-id in my years as linux user.

If you happen to know this, please give me a few hints. Otherwise I'll just use the workaround I found. Thank you!

comment:4 Changed 5 years ago by Antoine Martin

Did you even google it?
The first hit is dbus-uuidgen.

comment:5 Changed 5 years ago by Antoine Martin

It also clearly states: If you try to change an existing machine-id on a running system, it will probably result in bad things happening. Don't try to change this file. Also, don't make it the same on two different systems; it needs to be different anytime there are two different kernels running.

comment:6 Changed 5 years ago by Jiang

I did see this. "Bad things happening" is precisely why I was hesitant just use dbus-uuidgen to create a new ID and put it into /var/lib/dbus/machine-id. I was also confused why ubuntu does not have /etc/machine-id

However, now I simply generate a new uuid and rebooted. And now xpra works without workaround. Thank you for pointing this out to me!

Note: See TracTickets for help on using tickets.