Atom silently dismisses some serious (though non-critical) startup errors

[anatoli26]

I had configured (via /etc/environment) the TMP var (which specifies the temporary directory on most GNU/Linux) to point to ~/.tmp, but as I already know, node-based apps don't recognize it (though other apps, like Thunderbird, do).

This dir is where node-based apps store a temporary unix socket for IPC. What I see as a problem (I understand this is not a bug, but a implementation decision, though IMO it would be better to change it) is that when Atom is not able to create an IPC socket (or on any other significant, though not critical error), it silently ignores the error and continues as if everything was OK. Then we observe a degradation in user experience without understanding the real cause. In my case it was that Atom was not detecting correctly that there was already a running instance so it was creating a new window for each new file opened externally (via shell/cli). Though, it does create an error file ~/.atom/nohup.out with the following content:

Application server failed { Error: listen EACCES ~/.tmp/atom-1.12.3-userx.sock
    at Object.exports._errnoException (util.js:1008:11)
    at exports._exceptionWithHostPort (util.js:1031:20)
    at Server._listen2 (net.js:1240:19)
    at listen (net.js:1289:10)
    at Server.listen (net.js:1378:5)
    at AtomApplication.module.exports.AtomApplication.listenForArgumentsFromNewProcess (/opt/atom/resources/app.asar/src/main-process/atom-application.js:282:14)
    at AtomApplication.module.exports.AtomApplication.initialize (/opt/atom/resources/app.asar/src/main-process/atom-application.js:120:12)
    at Function.module.exports.AtomApplication.open (/opt/atom/resources/app.asar/src/main-process/atom-application.js:59:38)
    at App.<anonymous> (/opt/atom/resources/app.asar/src/main-process/start.js:68:21)
    at emitTwo (events.js:111:20)
    at App.emit (events.js:191:7)
  code: 'EACCES',
  errno: 'EACCES',
  syscall: 'listen',
  address: '~/.tmp/atom-1.12.3-userx.sock',
  port: -1 }

For a comparison (and this is how the error was discovered) Visual Studio Code (which is also node-based) reports the error on initialization and fails to start.

[lee-dohm]

I'm not sure I understand what the bug is here. According to your first paragraph, you say that you configured the TMP variable to point to ~/.tmp and that Atom doesn't recognize that. But according to the error message, the socket is being written in ~/.tmp seemingly as you configured. What exactly is it you want done?

[anatoli26]

The underlying layer (Electron) is not recognizing ~ as home dir (doesn't perform filename expansion), so it tries to create a temp socket in the path ~/.tmp/atom-1.12.3-userx.sock interpreted literally (instead of /home/userX/.tmp/atom-1.12.3-userx.sock), which doesn't exist.

The problem in itself is not so important actually, as almost nobody sets this var to something that specific, but the problem of this issue is that Atom ignores this error, so the user doesn't know something is not working. For comparison, VS.Code also uses Electron, also fails to recognize the path, but it warns the user about the problem.

[lee-dohm]

Do you happen to know where in the code this socket is being created?

[anatoli26]

Mm no, but it's not part of Atom code base, it's in Electron initialization.

[stale]

Thanks for your contribution!

This issue has been automatically marked as stale because it has not had recent activity. Because the Atom team treats their issues as their backlog, stale issues are closed. If you would like this issue to remain open:

1. Verify that you can still reproduce the issue in the latest version of Atom
2. Comment that the issue is still reproducible and include:
   • What version of Atom you reproduced the issue on
   • What OS and version you reproduced the issue on
   • What steps you followed to reproduce the issue

Issues that are labeled as triaged will not be automatically marked as stale.

[lock]

This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks!