Opened 9 years ago

Closed 9 years ago

#4862 closed Bug (invalid)

Qt Client can make duplicate session

Reported by: orps Owned by: jordan
Priority: Normal Milestone: None Set
Component: Qt Client Version: 2.51
Severity: Normal Keywords:
Cc:

Description

Qt Client can make duplicate session on rhel 6.2 when launch twice.

And here is the patch to fix it.

(I just saw this place...)

Attachments (2)

fix-duplicate-session.patch (2.8 KB) - added by orps 9 years ago.
several_instances_with_different_config_dir.png (53.0 KB) - added by orps 9 years ago.

Download all attachments as: .zip

Change History (10)

Changed 9 years ago by orps

comment:1 Changed 9 years ago by rb07

There is no "duplicate session" problem when DBUS is working properly.

There can be only one application registered with the dbus session daemon, so the second can't be handling the "session" (in a DBUS session). There can be several additional instances of the application running (usually with a different configuration, for instance one local and one remote session), but those run w/o the DBUS connection (i.e. only the first one has, and handles the DBUS requests sent by other instances).

I think this ticket is invalid, and the reason is that it seems to be just a problem with one user's environment, not a real problem (i.e. it works fine for me, and all the users that have file and magnet association working fine).

comment:2 Changed 9 years ago by orps

Hi, rb07.

Are you using RHEL 6 or CENTOS 6 ? I have a real machine, a notebook, and two virtual machine in Virtualbox are setup CENTOS 6.2 32bit or 64bit, and in these four environment I can reproduce the problem. And if you saw the patch you will found transmission won't exit when the DBUS register failed,

transmission-2.51/qt/app.cc if( !bus.registerService( DBUS_SERVICE ) )

std::cerr << "couldn't register " << qPrintable(DBUS_SERVICE) << std::endl;

The second session will print this error but still launch continue. So just add

exit( 1 );

after std::endl;, just 10 byte then this problem will fixed.

The other part of the patch, just use to activate the window of the old session.

orps

comment:3 Changed 9 years ago by rb07

I know the code very well.

Before MyApp is created (where the registerService() call is made), look near the end of app.cc, in main():

    // try to delegate the work to an existing copy of Transmission
    // before starting ourselves...
    bool delegated = false;
    QDBusConnection bus = QDBusConnection::sessionBus();
...

The problem you are seeing is because that failed, for unknown(*) reasons in your systems, perhaps you should un-comment the output after the response.

Why? because that is the part used by the file and magnet association, and that is the part I said its working fine (for me, not for you). Your patch is just a band-aid to work around the earlier failure, but is wrong in that it will prevent several instances from existing when that is a perfectly valid option (as I said, you can run several instances with different configurations).

(*) Since Qt 4.8.0 there is a new complaint by the Qt startup, it says:

QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.

Perhaps that is causing your problem. So far it hasn't caused any problems for me.

comment:4 Changed 9 years ago by orps

@rb07

  1. What linux you are using ??? Because I found this problem always in other linux not just rhel.
  1. I should say "qt client can make duplicate instance" if you think "session" mean "dbus session".
  1. There no problem with gtk client,

gtk client only make duplicate instance when the config-dir different and won't print any error message.

  1. The "response" you said,
    bool delegated = false;
    QDBusConnection bus = QDBusConnection::sessionBus();
    for( int i=0, n=addme.size(); i<n; ++i )
    

Look third line, if addme.size() equal 0 (no args), then there no "response" anywhere can make delegated true.

  1. "run several instances with different configurations"

Right, this patch not thought of that. But in my test if transmission print "couldn't register com.transmissionbt.Transmission", then this instance can't get any peers so you still can't run several instances with different config-dir.

test process:
launch transmission-qt
add torrent a in this instance
launch transmission-qt -g ./123
add torrent a in this instance (of course, download to other folder)
launch transmission-qt
wait few minutes

comment:5 Changed 9 years ago by orps

There no "your" problem or "my" problem, are you think transmission is write for you ?

Should I say you could not report any thing because they won't caused any problems for me ?

The other 195 active tickets almost will not affect me, should I say those problem are just with their environment ?

Do something useful or GET OUT

comment:6 Changed 9 years ago by rb07

You shouldn't be rude if you want people to help.

Your reporting skills are going the wrong way, there is no use in saying anything about the GTK client, that's not relevant, there is also no use in running bogus tests like "run several instances with different configs" and your configurations are not really different, just a copy of each other (you can't use the same ports in different instances). My example was one local session, one remote.

To make things clear for people reading this thread, you are saying that your test case is run transmission-qt, with no parameters, several times. The result is that it does run several simultaneous instances, and you didn't expect that.

So, yes, we are talking about different scenarios. With one local, one remote session, only the first instance will handle file and magnet association, but it is a valid use of 2 instances. You want to make that use case invalid, if I understood your point.

Don't worry, I won't write to this ticket any more. I'm out (no bold, or yelling necessary).

comment:7 Changed 9 years ago by qwerty12

For anybody who wants to use orps' patch, the restoreExistSession( ) call should be moved to where delegated is checked - (restoreExistSession( )
delegated) should work. Otherwise you won't be able to add torrents through external means if a Transmission session is already running.

(Thanks to orps for the patch and thanks to rb07 for his explanations - I now understand why the Transmission Qt client works the way it does, and it makes sense, but for people like me and orps who don't use the Transmission Qt client as a remote it doesn't make sense for us)

Version 0, edited 9 years ago by qwerty12 (next)

comment:8 Changed 9 years ago by jordan

  • Resolution set to invalid
  • Status changed from new to closed

IMO the use case of having two instances of transmission-qt is very valid for viewing multiple remote sessions.

Note: See TracTickets for help on using tickets.