Fails to create tmp directory on WSL

[villasv]

Provide the steps to reproduce

1. Run LH inside WSL2

What is the current behavior?

Runtime error encountered: EACCES: permission denied, mkdir '/mnt/undefined'
Error: EACCES: permission denied, mkdir '/mnt/undefined'
    at Object.mkdirSync (fs.js:750:3)
    at sync (/home/villasv/.nvm/versions/node/v10.14.1/lib/node_modules/lighthouse/node_modules/mkdirp/index.js:71:13)
    at sync (/home/villasv/.nvm/versions/node/v10.14.1/lib/node_modules/lighthouse/node_modules/mkdirp/index.js:77:24)
    at sync (/home/villasv/.nvm/versions/node/v10.14.1/lib/node_modules/lighthouse/node_modules/mkdirp/index.js:77:24)
    at sync (/home/villasv/.nvm/versions/node/v10.14.1/lib/node_modules/lighthouse/node_modules/mkdirp/index.js:77:24)
    at sync (/home/villasv/.nvm/versions/node/v10.14.1/lib/node_modules/lighthouse/node_modules/mkdirp/index.js:77:24)
    at Function.sync (/home/villasv/.nvm/versions/node/v10.14.1/lib/node_modules/lighthouse/node_modules/mkdirp/index.js:77:24)
    at makeWin32TmpDir (/home/villasv/.nvm/versions/node/v10.14.1/lib/node_modules/lighthouse/node_modules/chrome-launcher/dist/utils.js:115:12)
    at Object.makeTmpDir (/home/villasv/.nvm/versions/node/v10.14.1/lib/node_modules/lighthouse/node_modules/chrome-launcher/dist/utils.js:85:20)
    at Launcher.makeTmpDir (/home/villasv/.nvm/versions/node/v10.14.1/lib/node_modules/lighthouse/node_modules/chrome-launcher/dist/chrome-launcher.js:115:24)

What is the expected behavior?

No error.

Environment Information

• Affected Channels: CLI
• Lighthouse version: 5.6.0
• Chrome version:
• Node.js version: 10.14.1
• Operating System: Ubuntu on Windows 10 WSL2

[paulirish]

ah wsl2.

this was fixed in is-wsl: sindresorhus/is-wsl#3

but we have to pull it into chrome-launcher and then roll deps.

thanks for the heads up!

[paulirish]

Ah @patrickhulce pointed out we already have that fix in chrome-launcher/LH that you're using..

the relevant lines are

chrome-launcher/src/utils.ts

Lines 57 to 70 in d39af59

	export function getPlatform() {
	return isWsl ? 'wsl' : process.platform;
	}
	export function makeTmpDir() {
	switch (getPlatform()) {
	case 'darwin':
	case 'linux':
	return makeUnixTmpDir();
	case 'wsl':
	// We populate the user's Windows temp dir so the folder is correctly created later
	process.env.TEMP = getLocalAppDataPath(`${process.env.PATH}`);
	case 'win32':
	return makeWin32TmpDir();

so this isn't as straightforward as I was hoping..

---

it appears it's falling through to the win32 case which means is-wsl module is returning false on your system.

so.. reading the is-wsl source, I'm wondering what require('os').release in node and /proc/version are on your machine, @villasv

cc @KyivJunta since you solved this last time.

[villasv]

It shows up as Linux

$ nvm --version
0.35.1
$ node --version
v10.14.1
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.3 LTS
Release:        18.04
Codename:       bionic
$ node
> require('os').release()
'4.19.84-microsoft-standard'
> %
$ cat /proc/version
Linux version 4.19.84-microsoft-standard (oe-user@oe-host) (gcc version 8.2.0 (GCC)) GoogleChrome/lighthouse#1 SMP Wed Nov 13 11:44:37 UTC 2019

[villasv]

I had a problem once with some Python packages failing to identify the system as Linux (even though the OS said so) because they tried to guess from the file system, which is NTFS. Maybe this is a similar situation.

[villasv]

Looking at the code you highlighted, I think it's something else. I don't have my Windows PATH appended, so very likely process.env.TEMP = getLocalAppDataPath(`${process.env.PATH}`); is yielding TEMP = undefined.

It's pretty common nowadays to configure WSL not to append the Windows PATH to the Linux PATH because it slows everything down SO MUCH. My suggestion is to rely on the usual linux tooling for tmp directories.

Should I close this and copy the bug report on chrome-launcher?

[patrickhulce]

Ah great find @villasv! No need to copy we can transfer the issue over :)

[michaelchiche]

I am also having a problem with lighthouse inside WSL2.

It opens the chrome browser but then hangs with:

It looks like lighthouse succeeds to open chrome but cant seem to connect and manage it

[G-Rath]

It's pretty common nowadays to configure WSL not to append the Windows PATH to the Linux PATH because it slows everything down SO MUCH

I don't know about that, but in my case I get this issue because I have my C:\ mounts in /c/ instead of /mnt/c/, which is required due a bug in docker.

Ultimately the most stable fix is probably to call wslpath "C:\" at the top level once you know it's WSL.

[G-Rath]

@paulirish @patrickhulce I'm now very interested in getting this fixed in chrome-launcher ideally asap so it can get into lighthouse asap.

I've confirmed that chrome-launcher successfully launches a new "blank slate" Chrome without issue in WSL after I remove all the /mnt/s (since my C is mounted in /c/), so I think this is the only thing missing for WSL right now.

I'm happy to do PRs, but wanted to get some input on what solution you'd be happy with.

The ideal solution would be to use a utility function like this:

const wslPath = str => child_process.execSync(`wslpath -u ${str}`).toString().trim();

(overall, this should be taken a step further by refactoring the existing toWinDirFormat and then calling it in a few more places)

I think this solution is good: it's a very fast command, and saves a bunch of edge-case support.
The downside is there's not a particularly nice way to test it, if that matters for you.

I'll open a PR for this soon, but posting here in case you have initial thoughts.

[patrickhulce]

SGTM @G-Rath thanks for your help! We should avoid any string interpolation from string commands though, opting for execFile and passing as arguments instead. (#199 mistakenly believes we do this already but we certainly shouldn't start 😄)

FWIW there shouldn't be any sequencing issues with Lighthouse dependency here, publishing a fix should be enough for new installs and folks to be able to update their lockfiles since it uses a loose ^0.13.2 dependency.

[G-Rath]

since it uses a loose ^0.13.2 dependency

So long as it's a bug release yeah - if its a minor release it won't be allowed because it's 0.x.x,

Good point about the execFile.