Windows daemon process detection #2258

New issue

Closed

opened 2019-02-03 02:46:35 +01:00 by kicken · 4 comments

kicken commented

2019-02-03 02:46:35 +01:00

(Migrated from github.com)

The Issue

Detecting an existing daemon process on windows appears to be fragile and fails to work under some circumstances.

Steps to Reproduce

Create a shortcut to the daemon app with settings:
a. Target: "C:\Program Files\LBRY\resources\static\daemon\lbrynet.exe" start
b. Start In: "C:\Program Files\LBRY\resources\static\daemon"
Launch daemon process using shortcut
Launch desktop application

Expected Behavior

Desktop application uses existing daemon and launches successfully.

Actual Behavior

Desktop application fails to detect existing daemon and then fails to run.

System Configuration

LBRY Daemon version: lbrynet 0.30.4
LBRY App version: LBRY 0.28.0-rc.2
LBRY Installation ID: 4V4d9Ak5UMWhytVuYyxggyFx9V18TXboU8HaJC6CTmFeQ2e2UkszhhWi6kp7uZBoWa
Operating system: Windows 10 v1803 (build 17134.523)

Anything Else

Looking at the commit history I see there were a few attempts at fixes for this based on the output of WMIC. In my testing it appears as though the WMIC output can vary depending on how one launches the process. I tested a varity of ways to launch the daemon and looked at the WMIC output that find_process matches against.

When using a command prompt to launch the daemon WMIC has a double-space as well as path/quotes if present in the original command.
lbrynet start
"c:\Program Files\LBRY\resources\static\daemon\lbrynet.exe" start
"c:\Program Files\LBRY\resources\static\daemon\lbrynet" start

When using a shortcut as described above, you get a single space and full path:
"C:\Program Files\LBRY\resources\static\daemon\lbrynet.exe" start

When using a tool such as hstart to launch the daemon without a visible console window (what I've been doing previously) you get a single space and path/quotes depending on the original command.
lbrynet.exe start
"C:\Program Files\LBRY\resources\static\daemon\lbrynet.exe" start

## The Issue Detecting an existing daemon process on windows appears to be fragile and fails to work under some circumstances. ### Steps to Reproduce 1. Create a shortcut to the daemon app with settings: a. **Target:** "C:\Program Files\LBRY\resources\static\daemon\lbrynet.exe" start b. **Start In:** "C:\Program Files\LBRY\resources\static\daemon" 2. Launch daemon process using shortcut 3. Launch desktop application ### Expected Behavior Desktop application uses existing daemon and launches successfully. ### Actual Behavior Desktop application fails to detect existing daemon and then fails to run. ## System Configuration - LBRY Daemon version: lbrynet 0.30.4 - LBRY App version: LBRY 0.28.0-rc.2 - LBRY Installation ID: 4V4d9Ak5UMWhytVuYyxggyFx9V18TXboU8HaJC6CTmFeQ2e2UkszhhWi6kp7uZBoWa - Operating system: Windows 10 v1803 (build 17134.523) ## Anything Else Looking at the commit history I see there were a few attempts at fixes for this based on the output of WMIC. In my testing it appears as though the WMIC output can vary depending on how one launches the process. I tested a varity of ways to launch the daemon and looked at the WMIC output that find_process matches against. When using a command prompt to launch the daemon WMIC has a double-space as well as path/quotes if present in the original command. `lbrynet start` `"c:\Program Files\LBRY\resources\static\daemon\lbrynet.exe" start` `"c:\Program Files\LBRY\resources\static\daemon\lbrynet" start` When using a shortcut as described above, you get a single space and full path: `"C:\Program Files\LBRY\resources\static\daemon\lbrynet.exe" start` When using a tool such as hstart to launch the daemon without a visible console window (what I've been doing previously) you get a single space and path/quotes depending on the original command. `lbrynet.exe start` `"C:\Program Files\LBRY\resources\static\daemon\lbrynet.exe" start`

👍 1

neb-b commented

2019-02-03 02:51:30 +01:00

(Migrated from github.com)

Wow thank your for the very detailed issue!

We definitely didn't test these different ways to open the app but shouldn't this is very helpful. Shouldn't be to hard to fix. Thanks again. 🙂

Wow thank your for the very detailed issue! We definitely didn't test these different ways to open the app but shouldn't this is very helpful. Shouldn't be to hard to fix. Thanks again. 🙂

tzarebczan commented

2019-02-03 02:53:57 +01:00

(Migrated from github.com)

Thanks for the report. There's a known process parsing issue that prevents us from detecting it in a better way on Windows (most won't run into this problem). If you start lbrynet as just lbrynet start, without the exe, it should work. There is a guide here, we can make a note... https://lbry.io/faq/how-to-run-lbry

Not sure how to do this via a shortcut, will give it a shot.

Thanks for the report. There's a known process parsing issue that prevents us from detecting it in a better way on Windows (most won't run into this problem). If you start lbrynet as just ```lbrynet start```, without the exe, it should work. There is a guide here, we can make a note... https://lbry.io/faq/how-to-run-lbry Not sure how to do this via a shortcut, will give it a shot.

tzarebczan commented

2019-02-03 02:55:24 +01:00

(Migrated from github.com)

Can we show you some appreciation for opening the issue? Thanks again!!

Can we [show you some appreciation](https://LBRY.io/faq/appreciation) for opening the issue? Thanks again!!

tzarebczan commented

2019-02-18 18:30:47 +01:00

(Migrated from github.com)

Fixed in https://github.com/lbryio/lbry-desktop/pull/2283