Description of problem: Despite applying the function Quit, the application inconsistently may achieve or not that state. Version-Release number of selected component (if applicable): 5.0.1-3.fc26 Actual results: When it does’t achieve the state Quit, its related process jumps without ending from status Sleeping to status Running. On System Monitor, even applying the function End to that unresponsive process remains without any effect. Only applying the function Kill is effective. Expected results: To effectively quit on demand.
Thanks for opening the bugzilla report. Can you please add if the problem is reproducible, or how many times this takes place? Also, can you please share the relevant ps output before and after quitting the application when the bug takes place?
It took place about four times out of five last time. Tested now, because there is no traffic received neither sent the application managed repeatedly to quit properly.
Also when at least Ktorrent is running, its representative icon is not displayed by the tool located on the left side at the bottom of the screen that may be hidden or shown and when shown displays some of the applications's icons that run in the background.
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'.
Hi Ricky, I am very sorry for not responding earlier, that was not intentional. To better understand the bug, can you please add the ps output of before and after you've send the quit signal? Also, you mentioned in comment #3 that and icon is not displayed. Can you add a quick screenshot highlighting what you mean?
Don’t be sorry; Coders of your type are Work-machines, who very often make the job as they were two and even in rare cases three persons of an other type. Since the material to be download and in a same measure sent was fully achieved, I had no use anymore of Ktorrent for a while and uninstalled it a while ago. I just newly installed it now in conjunction with the previous comment. As far as I can tell, the icon, symbol of the application is today displayed as I expected at the time of the issue. Since I have no material anymore today regarding traffic to be handled by Ktorrent, which is a sine qua non condition for testing the quit (Ctrl+Q) function, ps function's outputs are not here relevant regarding current issue. For now the three reports of snapshots of the current processes –before Ktorrent is launched, while Ktorrent is running, and after the quit signal have been sent– are the same: $ ps -l F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD 0 S 1000 6284 6278 0 80 0 - 6338 wait pts/0 00:00:00 bash 0 R 1000 6973 6284 0 80 0 - 9106 - pts/0 00:00:00 ps
Hi Ricky, thanks for the quick reply. So I take it that right now the bug cannot be reproduced, am I right? How about we close the bug for now, but you open up as soon as it appears again? In the meantime I searched the KDE bug database for related bugs, but wasn't able to spot something similar. However, I nevertheless will aim for an update of Ktorrent in the future to 5.1 since there were a lot of updates of the underlying foundation (KF5) which might have an effect on improved process management.
It seems wise to close the report at any moment; it will be duly reopened on purpose if the issue still occurs with effects I noticed, as I might have use for Ktorrent in the future. Active and passive materials that might be involved in the same issue will be kept since now in Ktorrent four months.
Hi Ricky, thanks for the feedback. =) For reference: this bug will be closed as WONTFIX, since we currently do not have sufficient data to reproduce the described behavior.