[Bug 46272] New: Create TaskList and MAP linux PID to wine windows PID
https://bugs.winehq.org/show_bug.cgi?id=46272 Bug ID: 46272 Summary: Create TaskList and MAP linux PID to wine windows PID Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: tools Assignee: wine-bugs(a)winehq.org Reporter: roberto(a)spadim.com.br Distribution: --- Starting with 2 metatrader issues, i went to IRC and talked with zf and ken, resume: I need to kill a wine process, but don't hard kill it. The windows solution is "taskkill /im <windows pid>" The problem: we don't know what <windows pid> should be used Workaround to get windows pid: each wine process should use WINE_DEBUG=+process,+pid. and pattern match the stdout from wine command, lines containing "__wine_kernel_init starting process" and "<imagename.exe>", if you have more than one line get the last one it's ugly (a lot) we should resolve this writing a tasklist.exe to wine... that's the best of both worlds wine windows and linux unix ideas: 1) from winedbg --command 'info proc', we have a tasklist with only windows pid 2) somewhere in wineserver we have linux-windows pid 3) create a tool like windows tasklist.exe with a new column "wine host PID" somework done here: https://github.com/wine-mirror/wine/blob/6d801377055911d914226a3c6af8d8637a6... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46272 --- Comment #1 from roberto(a)spadim.com.br --- more information at wineserver: parent_id (windows PID): https://github.com/wine-mirror/wine/blob/6d801377055911d914226a3c6af8d8637a6... unix pid: https://github.com/wine-mirror/wine/blob/6d801377055911d914226a3c6af8d8637a6... get process from id (parent_id_t): https://github.com/wine-mirror/wine/blob/6d801377055911d914226a3c6af8d8637a6... https://github.com/wine-mirror/wine/blob/6d801377055911d914226a3c6af8d8637a6... dump process information: (what we need - id and unix_id) https://github.com/wine-mirror/wine/blob/6d801377055911d914226a3c6af8d8637a6... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46272 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish(a)gmail.com Version|unspecified |4.0-rc1 Component|tools |programs -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46272 --- Comment #2 from Hans Leidekker <hans(a)meelstraat.net> --- Note that the create_snapshot/next_process server call returns both the Windows and Unix pid. See dlls/iphlpapi/ipstats.c:get_pid_map for an example. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46272 --- Comment #3 from Hans Leidekker <hans(a)meelstraat.net> --- Obviously we can't do server calls in programs. Maybe it would be acceptable to use an unused field from SYSTEM_PROCESS_INFORMATION for this purpose, e.g. dwUnknown4. Then we could retrieve the Unix pid with a call to NtQuerySystemInformation(SystemProcessInformation). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46272 --- Comment #4 from roberto(a)spadim.com.br --- well, that's a nice solution and user friendly, if os=wine and dwunknown4 !=0 we have the unix pid i think it's ok -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46272 --- Comment #5 from roberto(a)spadim.com.br --- just to append the link to get_pid_map: https://github.com/wine-mirror/wine/blob/a1e0a029b0ce80e6561e0656ae4530fb1a8... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46272 roberto(a)spadim.com.br changed: What |Removed |Added ---------------------------------------------------------------------------- Component|programs |tools Version|4.0-rc1 |unspecified --- Comment #6 from roberto(a)spadim.com.br --- Link to GIST output of WINE_DEBUG=+process,+pid "wine64 terminal64.exe /portable" at line with pattern match from stdout https://gist.github.com/rspadim/bed9f357dfef4bf0c6207a4b9217ccef#file-wine64... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46272 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |4.0-rc1 Component|tools |programs CC| |z.figura12(a)gmail.com --- Comment #7 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to Hans Leidekker from comment #3)
Obviously we can't do server calls in programs. Maybe it would be acceptable to use an unused field from SYSTEM_PROCESS_INFORMATION for this purpose, e.g. dwUnknown4. Then we could retrieve the Unix pid with a call to NtQuerySystemInformation(SystemProcessInformation).
I think it would make more sense to use an unused value instead, something like NtQueryInformationProcess(ProcessUnixPID); what do you think? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46272 --- Comment #8 from roberto(a)spadim.com.br --- well it will only works on wine, windows don't use it, and reactos too maybe WineProcessUnixPID ? just to make sure the developer know what he want after this we need to do the tasklist too (just output wine pid, unix pid, image name, is ok, maybe after dump others things? but for v1.0 is ok just it) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46272 --- Comment #9 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Zebediah Figura from comment #7)
(In reply to Hans Leidekker from comment #3)
Obviously we can't do server calls in programs. Maybe it would be acceptable to use an unused field from SYSTEM_PROCESS_INFORMATION for this purpose, e.g. dwUnknown4. Then we could retrieve the Unix pid with a call to NtQuerySystemInformation(SystemProcessInformation).
I think it would make more sense to use an unused value instead, something like NtQueryInformationProcess(ProcessUnixPID); what do you think?
For the taskkill case I think it would be better to have it in SYSTEM_PROCESS_INFORMATION. We're already walking the list of processes so it requires no extra calls to retrieve the Unix pid. This way we are also guaranteed to get consistent data because it's all in the same snapshot. A separate call would open up a race, albeit very unlikely to hit. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46272 --- Comment #10 from roberto(a)spadim.com.br --- another thing, instead of only tasklist, we could implement taskkill too "taskkill /unixpid <unixpid>" -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46272 --- Comment #11 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to Hans Leidekker from comment #9)
(In reply to Zebediah Figura from comment #7)
(In reply to Hans Leidekker from comment #3)
Obviously we can't do server calls in programs. Maybe it would be acceptable to use an unused field from SYSTEM_PROCESS_INFORMATION for this purpose, e.g. dwUnknown4. Then we could retrieve the Unix pid with a call to NtQuerySystemInformation(SystemProcessInformation).
I think it would make more sense to use an unused value instead, something like NtQueryInformationProcess(ProcessUnixPID); what do you think?
For the taskkill case I think it would be better to have it in SYSTEM_PROCESS_INFORMATION. We're already walking the list of processes so it requires no extra calls to retrieve the Unix pid. This way we are also guaranteed to get consistent data because it's all in the same snapshot. A separate call would open up a race, albeit very unlikely to hit.
Eh, I guess. I'm just concerned about abusing reserved fields that might be meaningful, and I'm not sure how worthwhile avoiding that kind of a race would actually be. Not to mention that our current implementation of SystemProcessInformation is already racy (though I guess this could be fixed by moving it all to the server). Besides which trying to avoid races may be a moot point, as it seems that tasklist.exe is supposed to return/filter by some things (username, "service information") that aren't available in SYSTEM_PROCESS_INFORMATION anyway. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46272 --- Comment #12 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Zebediah Figura from comment #11)
For the taskkill case I think it would be better to have it in SYSTEM_PROCESS_INFORMATION. We're already walking the list of processes so it requires no extra calls to retrieve the Unix pid. This way we are also guaranteed to get consistent data because it's all in the same snapshot. A separate call would open up a race, albeit very unlikely to hit.
Eh, I guess. I'm just concerned about abusing reserved fields that might be meaningful, and I'm not sure how worthwhile avoiding that kind of a race would actually be. Not to mention that our current implementation of SystemProcessInformation is already racy (though I guess this could be fixed by moving it all to the server).
There are 6 more unused DWORD fields, so we may have some wiggle room here.
Besides which trying to avoid races may be a moot point, as it seems that tasklist.exe is supposed to return/filter by some things (username, "service information") that aren't available in SYSTEM_PROCESS_INFORMATION anyway.
Why do we need this in tasklist? Isn't the use case that one should be able to gracefully close a Wine process using its Unix pid? If so, I think a taskkill /unixpid option would suffice. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46272 --- Comment #13 from roberto(a)spadim.com.br --- i think both should be ok, the priority of doing one or another is the point, i think taskkill have higher priority tasklist is something like ps ax taskkill is something like kill when you see htop at linux or other monitor you know the unix pid at wine side we have windows pid, something to show what's each one is ok (tasklist), maybe in future integrate this information at htop and others monitor tools should be interesting in worst scenario we need to close programs, kill at unix execute a hard kill to wine process (in my case terminal64.exe don't flush writes to disk and all writes are lost), even with sigterm or other "gracefull" signal (sighup etc) taskkill execute a "graceful" program close ("X" button at window manager), in this case taskkil /unixpid is the only solution. the today problem is: what pid to kill with taskkill if we don't know what wine pid is a unix pid, and we get back to tasklist idea -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org