Atom: 100% CPU usage when started in the home folder

[JamesTheAwesomeDude]

When editing a file, after the editor was open for a little while, it started to consume all the CPU and steadily consume more RAM (until all the available RAM is consumed).

The command line of the runaway process was:

/usr/share/atom/atom --eval require('/usr/share/atom/resources/app/node_modules/coffee-cash/lib/coffee-cash.js').setCacheDirectory('/home/james/.atom/compile-cache/coffee'); require('/usr/share/atom/resources/app/node_modules/coffee-cash/lib/coffee-cash.js').register(); require('/usr/share/atom/resources/app/node_modules/coffeestack/index.js').setCacheDirectory('/home/james/.atom/compile-cache/coffee/source-maps'); require('/usr/share/atom/resources/app/src/task-bootstrap.js');

This behavior seems to have just emerged after I updated it to 0.192.0 this morning.

[thomasjo]

Are you able to reproduce this in safe mode? I suspect this is caused by a misbehaving community package. Most likely a linter (if you have one that is).

[50Wliu]

Refs #5566.

[JamesTheAwesomeDude]

@thomasjo I have not installed any packages (beyond what came with the default installation).

I just now ran atom --safe, however, and the issue began within seconds of launch. The guilty process had basically the same command-line as last time, so I won't re-post it here.

[JamesTheAwesomeDude]

Are there any logs or anything like that than I can provide to help this issue get resolved quicky?

Atom is a very useful editor, and this issue is a blocker.

[maxbrunsfeld]

There were some changes to the indexing task for the fuzzy-finder package, relating to symbolic links. @JamesTheAwesomeDude what OS are you using? Does this happen regardless of what folder you open, or only in certain folders? If it is affected by the folder, could provide some information about any symlinks in the folder? Are they broken? Are there any circular symlink paths?

[JamesTheAwesomeDude]

@maxbrunsfeld I currently have no projects which involve symlinks.

Just now, I ran mkdir foo;cd foo;atom&htop and the issue did not seem to occur. I then ran it again from my home folder, and the issue persisted. Running it from the foo folder again did not cause the issue.

I then ran find -H ~ -xtype l to see if there were any symlinks that might be causing problems, but there was nothing interesting.

I am running Linux Mint 17.1 64-Bit (XFCE edition).

[maxbrunsfeld]

Does it happen on other non-empty folders, or just when you open your entire home directory?

[JamesTheAwesomeDude]

@maxbrunsfeld I just ran it in a directory with many gigabytes of MKVs, AVIs, and MP4s in subfolders, and it did not have the problem.

I also ran it directly in a directory with many AVI files in the working directory (not subfolders), and the problem did not occur. It seems to only happen in my home folder, which is odd.

Just for kicks, I did cd /;atom and the problem, surprisingly, did _not_ seem to manifest itself. The directory tree on the right appeared, and using it to navigate to my home directory did NOT trigger the issue, even more surprisingly.

[Calinou]

I can reproduce this; I have to kill Atom so that it stops doing that. Running latest Atom Git (0.195.0-07f80bc) on Debian jessie 64-bit. I just ran atom from the command line, so the default path is used.

Community packages used:

atom-color-highlight  language-glsl    merge-conflicts
atom-html-preview     language-lua     minifier
autocomplete-plus     language-svg     minimap
bezier-curve-editor   linter           monokai
color-picker          linter-csslint   project-palette-finder
emmet                 linter-htmlhint  sass-watch
git-plus              linter-jshint    seti-syntax
highlight-line        linter-lua       seti-ui
language-cmake        linter-php       todo-show
language-gdscript     linter-xmllint   web-browser

[JamesTheAwesomeDude]

@maxbrunsfeld It seems we can remove the needs-reproduction tag.. also, is there any more information you need about the error?

[50Wliu]

@Calinou running atom from the command line will start Atom in the folder that your terminal is currently in, so could you please give us some info about that folder? Thanks.

[Calinou]

I open it using Alt+F2 then typing atom which opens it in the home folder. Apparently, opening Atom using FileZilla does not trigger that excessive CPU usage.

[JamesTheAwesomeDude]

So it seems that both @Calinou and I only have this problem when running it from the home folder..

[v3ss0n]

Home folder usually have many subfolders , which contain source files yes it will index every source files (source code files that indexable by fuzzy package) .

[50Wliu]

Continuing on the question of symlinks: Does this still occur if you turn off the "Search through symlinks" (or whatever it is) option?

[Calinou]

Continuing on the question of symlinks: Does this still occur if you turn off the "Search through symlinks" (or whatever it is) option?

Yes, it still occurs regardless of the option's status (and restarted Atom after the setting change).

[blvz]

Can you guys confirm this? I did a simple:

$ mkdir project
$ atom project

CPU started at 30%, then increased to ~60%. On this process:

/Applications/Atom.app/Contents/Frameworks/Atom Helper.app/Contents/MacOS/Atom Helper --eval require('/Applications/Atom.app/Contents/Resources/app.asar/node_modules/coffee-cash/lib/coffee-cash.js').setCacheDirectory('/Users/blvdr/.atom/compile-cache/coffee');^Jrequire('/Applications/Atom.app/Contents/Resources/app.asar/node_modules/coffee-cash/lib/coffee-cash.js').register();^Jrequire('/Applications/Atom.app/Contents/Resources/app.asar/node_modules/coffeestack/index.js').setCacheDirectory('/Users/blvdr/.atom/compile-cache/coffee/source-maps');^Jrequire('/Applications/Atom.app/Contents/Resources/app.asar/src/task-bootstrap.js');

Waiting about 30 seconds, CPU dropped to 0.5% on that process, but immediately peaked at 100% on this one:

/Applications/Atom.app/Contents/Frameworks/Atom Helper.app/Contents/MacOS/Atom Helper --type=renderer --js-flags=--harmony --no-sandbox --enable-deferred-image-decoding --lang=English --node-integration=true --subpixel-font-scaling=false --enable-pinch-virtual-viewport --enable-delegated-renderer --num-raster-threads=1 --disable-accelerated-video-decode --channel=48444.7.71229215

Closing the window for the project directory (no need to quit Atom), made the CPU drop back to < 4%. It's the same problem I've had in the past, so I've tried the same fix, which fixed it.

$ git init project
$ atom project

Reading through all of this again, @50Wliu finally shed me some light:

Continuing on the question of symlinks: Does this still occur if you turn off the "Search through symlinks" (or whatever it is) option?

So actually the problem wasn't caused by a .gitignore in the root of the project, but from adding some files from home ~/ to git and forgetting to ignore everything else. :facepunch: :dizzy_face:

$ echo '*' >>  ~/.gitignore
$ atom project

Fixed. :open_mouth: :boom: :octocat: :sparkles:

Hope this fixes for you guys as well.

Edit:

Actually, $ echo '*' >> ~/.gitignore ignored all files from all projects. I've done this as a temporary fix:

$ mv ~/.git ~/.git_

[JamesTheAwesomeDude]

@blvz's solution (echo '*' > ~/.gitignore) did not fix the problem for me.

[blvz]

I've updated my answer, because it actually ignored all files, when creating a new window.

@JamesTheAwesomeDude Can you reproduce the problem with mkdir project && atom project and fix it with a git init project && atom project?

[JamesTheAwesomeDude]

@blvz Yes, running atom on a new folder does not trigger the problem.

I just ran git init project && atom project&htop and the problem did not occur. However, it did not fix the problem - running Atom in the home folder still triggers the problem.

[ohnnyj]

This may or may not be the same issue I am seeing.

Running Atom 0.196.0 is ok.

Running latest from github, 0.197.0-1d69d83, the editor freezes when I attempt to close an HTML tag (only when document type is set as HTML, if set as Plain Text this behavior will not occur).

1. Open new window.
2. Create new document.
3. Set document as HTML.
4. Then...

<span>

Everything is ok until I type another opening bracket:

<span><

The < will not display, the editor will lock up.

If I make a newline, everything is ok:

<span>
</span>

Also when I add text in between the span begin/end tags, everything is ok:

<span>text</span>

[JamesTheAwesomeDude]

@ohnnyj What does htop (or your task manager) show when you sort processes by CPU usage while Atom is doing that?

[ohnnyj]

@JamesTheAwesomeDude I see 100% for Atom Helper and ~500MB memory usage.

[benogle]

@ohnnyj your issue is because of https://github.com/atom/language-html/commit/4aaf3993b0d06086c5a0cfac2db1d7e9c317bb2e

Sorry about that, looking into it now.

[ohnnyj]

@benogle Thanks. Man, you guys are responsive. Can't complain, it's free, and sans this issue, a pretty awesome editor.

[benogle]

@ohnnyj master should have a fix. Please let me know if you get this behavior in any other way; open another issue and cc me.

[JamesTheAwesomeDude]

So it seems that @ohnnyj's issue was a separate one from this one? (His being related to HTML tag parsing locking up the editor and this one being about a runaway process which starts whenever Atom is run in a home folder)

[benogle]

Yes, it is a different issue.

[Yajo]

I just wanted to state that after installing atom-0.198.0-0.1.fc21.x86_64 I have not experienced this bug.

[mensinda]

I can reproduce this bug when somewhere in the project is one or more WINEPREFIX.

Steps to reproduce:

mkdir tmp
cd tmp

WINEPREFIX=$PWD/W1; winecfg # Create WINEPREFIX 1
WINEPREFIX=$PWD/W2; winecfg # Create WINEPREFIX 2
WINEPREFIX=$PWD/W3; winecfg # Create WINEPREFIX 3
WINEPREFIX=$PWD/W4; winecfg # Create WINEPREFIX 4

atom .  # 100% CPU and 3.5GB RAM usage after 1min with 4 WINEPREFIX

Removing every symlink in every WINEPREFIX 'fixed' the problem for me, so it should be a symlink issue.

A simple ln -s $HOME homeLink does not cause any problems.

Atom Version: 0.200.0-6431807
WINE: wine-1.7.42
OS: Arch Llinux

[mensinda]

I managed to reproduce the bug with a simpler setup:

mkdir -p cpuBug/projectRoot/d1
cd cpuBug
ln -s $PWD projectRoot/d1/root
cd projectRoot
ln -s /path/to/something/without/symlinks source
mkdir d2
ln -s $PWD/d1 d2/d1
atom

The final structure should look like this:

/cpuBug/projectRoot/source  -> /path/to/something/without/symlinks
/cpuBug/projectRoot/d1/root -> /cpuBug
/cpuBug/projectRoot/d2/d1   -> /cpuBug/projectRoot/d1

This is roughly what WINE does in a WINEPREFIX. Because most WINE users have the WINEPREFIX .wine in $HOME this bug is mostly triggerd there.

[winnieXY]

in #6844 it was suggested that disablling the fuzzy-finder will help - however this is not the case. I've an project folder with only latex code inside, no symlinks at all. Starting atom on the cmd in this folder still results after several minutes in a massive consumption of ram (~2-3G) and CPU (100-120%) (quad-core).
I'm running atom on Debian Unstable amd64. Switching back to 0.193 resolves this issue btw.

[pgkos]

It seems that the issue can be reproduced (on Atom v0.199.0) by simply opening the /proc directory on Linux (right click from file manager -> open with Atom), while the fuzzy-finder package is enabled.

The RAM consumption is even higher when opening a folder which contains a subfolder with symlink to /proc (which happened to me, I had a subfolder with symlink to /proc inside my ~/.config folder). Then the fuzzy-finder package traverses all the /proc subfolders and symlinks, including /proc/[pid]/cwd symlinks and that often causes a traversal of the whole filesystem for each pid.

Perhaps we should somehow prevent the fuzzy-finder package from traversing the /proc folder?

[JamesTheAwesomeDude]

Issue does not occur on Atom 0.198.0 and newer. Feel free to keep discussing the problem, but just make sure you've updated Atom before you spend/waste time on further speculation.

Thanks, devs, for getting this fixed!

[winnieXY]

Excuse me - but I was able to reproduce this error with the latest version available on website. So this is reproduceable, even with the git build from yesterday.
BTW - just yesterday a dupe of this bug was closed called: Atom v0.199 leaks memory and uses CPU #6844
So indeed this is reproduceable with Versions > 0.198.
Please reopen.

[mensinda]

I am using the latest Atom version (commit 254e3f3be2091e08083c6b2eef38f91637787ae1) and the issue still occurs on my symlink (/ WINE) setup and with /proc.

(fuzzy-finder version 0.87.0)

Could you please reopen the issue?

[JamesTheAwesomeDude]

@winnieXY I just double-checked version 0.198.0 and completely confirmed that the bug does _not_ occur. You might want to downgrade to that version for now as a stop-gap fix for this bug: https://github.com/atom/atom/releases/tag/v0.198.0

I'm now testing version 0.199.0 and will re-open in just a moment when I confirm the bug.

..yep, it's confirmed. Re-opening.

[winnieXY]

Thanks. I've upraded from 0.193 to 0.198 for now. Hope that this will be fixed soon.

[JamesTheAwesomeDude]

So this problem started occuring some time around version 0.192.0, was fixed with version 0.198.0, and regressed with version 0.199.0

Hopefully that will shed some light on this for the devs?

[winnieXY]

I can also confirm that 0.198.0 is not affected by this bug.

[winnieXY]

I'm trying to find a hint when the editor starts to hang. As preliminary information: I'm currently writing a quite huge .tex project. Sometimes it takes ~10 seconds until my words appear in the editor window. I've the subjective impression that this is related to autocompletion popping up . Disabling fuzzy-finder and autocompletion+ doesn't fix the performance problems (as still one core is at 80-90%) but the editor is not all the time lagging.

[nathansobo]

@winnieXY could you run a CPU profile from the developer tools while you're doing slow stuff and send me the output? Here's an animated gif of the basic procedure. You basically hit record, do the slow thing, then hit stop. After that you can save the profile to a file.

[number21]

v0.201 have this problem too. I run Atom from left-side menu. Fedora 21 Gnome 3

[lee-dohm]

@number21 Please run a CPU profile as described in @nathansobo's comment and post the results.

[number21]

Hello, I try to save profile, but Atom create file 0 byte size. It doesn't have to be like that, right?
I can kill this task, and continue work in Atom without crash or something else.

[winnieXY]

@nathansobo Yes, I'll do later today. I was in holidays for the last 4 day, hence my late answer.

[JamesTheAwesomeDude]

@winnieXY and @number21 Consider creating separate issues for your problems? It'll be easier on the devs if we keep things sorted

[50Wliu]

@JamesTheAwesomeDude: It seems to me that both their comments have to do with this issue, so I think it's fine if we keep this in one place.

@number21: That's a known bug on Linux (not sure if it originates from Atom, Electron, or Chromium though).

[bilderbuchi]

This is still happening when starting atom 1.2.4 in the home directory of Ubuntu 15.04. --safe does not fix the issue. The CPU profile shows nearly no activity in the chart, just one or two shrot peaks. (It's a 500kB file, so I didn't attach here)

[mishak87]

For me this happens when I open single files (bash scripts, I have shellcheck linter) in same window that are outside of project directory.

[ulrichSchreiner]

When working with a horizontally split pane to edit multiple files this happens _very often_ in my case. Sometimes it is 100% reproducable until i close the split-pane so i can open the file i want.

My atom versin is 1.3.1, it runs inside of docker (atocker). Any chance to enable logging or something to see what is consuming the CPU?

[50Wliu]

@ulrichSchreiner I believe your issue has already been fixed in 1.4.0-beta0.

[ulrichSchreiner]

let's hope so :-)

[ricpelo]

This bug is still fully reproducible with atom 1.4.0-beta3. Open atom from my home folder freeze my computer after a while. Open it from another folder works as expected.

[joshaber]

Resolved by ##10249.

[bilderbuchi]

@joshaber I can't confirm the fix. I'm running Atom 1.4.0, and when I do atom --safe . in my home directory, it immediately starts to fully load about 1 CPU, and doesn't stop.
edit: this is on a current Ubuntu .

[50Wliu]

@bilderbuchi The fix is only in the 1.5.0 betas, and not 1.4.0.

[JAlexoid]

Version 1.5.3 on Ubuntu 15.10 still exibits the same issue.
CPU usage ~100%(one core full utilisation) when openning home directory.

[darthrevan13]

Can confirm this is happening with version 1.5.3 on Ubuntu 15.10. I have to remove the project folder from the left pane in order for this to stop.

Also there is no problem when opening it from any other directory.

Edit:

Here is my CPU profile:

CPU-20160228T102038.cpuprofile.txt

Also, please reopen the issue!

[pgkos]

@darthrevan13, @JAlexoid does this issue still happen if you disable the fuzzy-finder package (disable it and then restart Atom in the home directory)?

[darthrevan13]

@pgkos I can confirm that this is no longer an issue if I deactivate the fuzzy-finder package.

[nathansobo]

@lee-dohm do you know if we're still having issues with fuzzy-finder maxing out CPU on 1.5.3?

[lee-dohm]

@nathansobo Not that I've heard of. I'll look into it though.

[lee-dohm]

I played around with launching Atom v1.5.3 on Mac OS X 10.11.3 on both my quad-core desktop with 32GB of RAM and my old dual-core laptop with 8GB of RAM. I couldn't reproduce what @darthrevan13 is seeing. @darthrevan13 please open a new Issue as I don't believe yours is related to the original problem.

[pgkos]

@lee-dohm steps to reproduce on a Mac:

1. Create a symbolic link to the root directory inside, for example, Desktop ln -s / rootdir
2. Open Atom and add Desktop as a project folder.
3. Activate fuzzy-finder (Ctrl+T)
4. CPU usage is very high and after a minute all RAM gets used up.

This is in fact a libuv/node.js issue - when reading lots of directories asynchronously, it hangs and uses all available memory. I assume the Node's event queue gets overfilled with directories while reading them.

The only fix is to read everything synchronously, which I did in atom/fuzzy-finder#103.

[lee-dohm]

@pgkos Can you quantify "lots of directories"? I tested this on my machine using my home directory which has 151,435 directories underneath it. I would think that would be sufficient for overloading the event queue if such a limit exists.

[pgkos]

I think that the issue occurs only in case when there is a symbolic link to a parent folder (forming a symlink loop), but I cannot rule out the possibility that it occurs also if there is just a huge number of directories to traverse.

My fuzzy-finder fork (atom/fuzzy-finder#103) reads all directories synchronously and keeps track of already visited directories, which prevents endlessly adding them inside symlink loops. I'm not sure if it is entirely compliant with the original, but it works (even inside /proc on Linux), runs very fast and prevents all problems with high CPU and RAM usage.

The reason I'm using synchronous reading is that I'm not entirely convinced of the reliability/performance of Node/libuv in this case (see nodejs/node#1741).

[lee-dohm]

@pgkos The symbolic link loop problem has been addressed in master.

[pgkos]

No, this (atom/fuzzy-finder#178) is unrelated to the symlink loop problem.

Version 1.0.2 still hangs (e.g. inside /proc on Linux).

[Zireael07]

@pgkos: Atom 1.0.2? We're at 1.5.3 now!

[pgkos]

@Zireael07 I meant fuzzy-finder 1.0.2, I've installed it over the (older) version shipped with Atom using apm install fuzzy-finder.

[bilderbuchi]

I can confirm that this is still an issue with Atom 1.5.3 on Ubuntu 15.10, and goes away if I deactivate the fuzzy-finder package, which is at 0.94.0

[dustinblackman]

Can confirm same issue on Atom 1.5.4 and OSX 10.10. Disabling fuzzy-finder fixes both CPU and RAM.

[averissimo]

Confirm the issue in:

• Atom: 1.9.0-dev-9466438
• Ubuntu 16.04

Disabling fuzzy-finder fixes both CPU _(after loading period where it is at 100% ~1min)_ and RAM

ps. I noticed this because I was using Atom to open all plain/text files, and it became unusable for this purpose, otherwise on all projects it is working like a charm!

[stanier]

Confirming issue for:

• Atom: 1.5.4
• Distro: Ubuntu 15.04

Sadly I was unable to do any useful investigation on the issue, being that atom was clocking in at 137% CPU and it took ten minutes just to load a tty and kill it...

[50Wliu]

@stanier The latest release is currently Atom 1.7.4.

[TheGistGuy]

I can confirm this issue on Atom 1.8.0.

The following process consumes all RAM in a few minutes after starting Atom:
/usr/share/atom/atom --eval require('/usr/share/atom/resources/app.asar/src/compile-cache.js').setCacheDirectory('/home/myuser/.atom/compile-cache'); require('/usr/share/atom/resources/app.asar/src/task-bootstrap.js');

Disabling fuzzy-finder solves the issue.

[cialu]

Confirm the issue in:

• Atom: 1.7.4
• Distro: Fedora 24 Beta

Disabling fuzzy-finder fixes both CPU and RAM issues.

[yusiwen]

Confirmed. v1.8.0, on windows 10 x64, disabling 'fuzzy-finder' package will drop CPU usage from 60% to normal.

[mhow2]

v1.9.0 I can confirm the above @yusiwen said too.

[thiagobraga]

Confirmed the issue too:

• Atom 1.9.9
• Windows 7 x64

Tried to disable fuzzy-finder, but it did not solve. It consumes 100% of 4 CPU cores and lasts about 15 seconds when starting Atom.

[v3ss0n]

This is happening again after v1.5 again. It was getting better before.
Not just one processes , there are 4 processing causing 100% io generating Compile cache.
For rotational harddrives , multi-core File IO is a BIG NO NO. It may be fine for SSD but my laptop is with Rotational drives. It even kills X11 and WM , and restarting case it again.

please , this need to be reopened

atom : v1.11.1
happens on default install without any plugin
linux 4.7.0
ext4 file system

[anotherbugmaster]

Removing home folder from a project is the temporary workaround for now

[v3ss0n]

Bump again , please reopen this.

[50Wliu]

@v3ss0n Please open a new issue.

[13rac1]

@v3ss0n https://github.com/atom/atom/issues/13084 Current discussion on this issue.

[anotherbugmaster]

@eosrei I don't think that these issues are related. This one occurs only if Atom has been started in home folder or, I presume, in any folder that contains large amount of files. Issue #13084 has something to do with a shell environment and occurs regardless of project folder.

[anotherbugmaster]

@50Wliu, Excuse me, but what is the point of opening the same issue again? Wouldn't it be better to just reopen this one?

[Ben3eeE]

@anotherbugmaster The point of opening a new issue is that this issue has already been resolved and because of this what you experience might be caused by a different bug. There are also questions in the default issue template that help us diagnose the problem.

[anotherbugmaster]

Alright, turning off Fuzzy-Finder solved the problem with large folders for me, so I will post new issue there.

[quinob]

Same for me ,using Atom 1.12.6 . Turning off Fuzzy-Finder keeps troubles away.

[marmistrz]

I have this problem bud I don't have fuzzy finder installed. Running in safe mode doesn't fix anything.

Atom : 1.14.4
Electron: 1.3.13
Chrome : 52.0.2743.82
Node : 6.5.0

[Zireael07]

@marmistrz fuzzy finder is a built in package.

[FallingSnow]

Disabling fuzzy finder resolved this issue for me as well.

[mboratko]

I can reproduce this issue with a vanilla Atom install on Arch Linux. I deleted my .atom directory, so it is essentially a fresh install (i.e. only core plugins and default settings). I opened Atom and then added the home directory as a project folder, the Electron process started rapidly using high CPU and spawned additional processes, which each consumed more and more RAM. Disabling fuzzy finder did not fix the problem, nor did running in safe mode. Removing the home folder from the project pane immediately fixed the problem.

Atom : 1.21.1
Electron: 1.6.15
Chrome : 56.0.2924.87
Node : 7.4.0

[kartongsaft]

I can also reproduce this issue under Arch Linux. Disabling fuzzy-finder or remove the home folder from project pane/Tree View fix the problem.

Atom: 1.21.1
Electron: 1.6.15

[flesniak]

Same problem here on Ubuntu 16.04.1. It seems to be another bug, or at least a regression - downgrading from 1.21.1 to 1.21.0 fixes the problem for me.

[vtempest]

My entire computer freezes every 2 hours when Atom is open because of this two-year obvious bug about home-folder indexing. Dell i7-6700k Ubuntu 17.10 and Atom 1.21 and 1.22. Opening any file in the ~ folder with atom automatically causes ~ to be added and it starts searching thru all the .folders to index them, CPU and mem and swap are all used up. No wonder so many people are complaining about how slow Node.js apps run.

Contact me if interested making a fork of the Atom editor that avoids some of the design decisions made here and making it run as a web app.

[Ben3eeE]

@maxbrunsfeld Can this be a regression from your recent changes to git-utils? Is there some other change in 1.21.1 that could cause this? The reports mention that downgrading to 1.21.0 fixes the issue.

/cc: @nathansobo

[maxbrunsfeld]

@Ben3eeE I believe this has to do with the new file watcher API. There was another issue about this that mentioned a “massive memory leak”. The problem is that nsfw is very inefficient on Linux; a fix is already in the works.

[Ben3eeE]

@maxbrunsfeld Oh file watcher makes sense. Thank you :bowing_man:

Everyone reporting this in a recent version of Atom may want to subscribe to https://github.com/atom/atom/issues/15966 for updates.

[smashwilson]

Everyone reporting this in a recent version of Atom may want to subscribe to #15966 for updates.

If changing this setting in your settings-view makes the problem go away:

Then #15966 is the problem you're experiencing.

[lock[bot]]

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!