Skip to content
This repository has been archived by the owner on Dec 19, 2024. It is now read-only.

Watcher test issues in Linux #122

Closed
jonathanKingston opened this issue May 6, 2015 · 7 comments · Fixed by #238
Closed

Watcher test issues in Linux #122

jonathanKingston opened this issue May 6, 2015 · 7 comments · Fixed by #238

Comments

@jonathanKingston
Copy link
Contributor

So the tests don't run correctly for the watcher code in Linux, I'm either getting:

  • The code times out
  • The code never finishes

The test in issue is this: test/cli.watcher.js

Killing the processes using the method mentioned here solves the issues:
http://krasimirtsonev.com/blog/article/Nodejs-managing-child-processes-starting-stopping-exec-spawn

However this causes the following line of the test to fail (Which I can't actually see should ever reliably pass):

      if (err && !err.killed) { throw err }
@MoOx
Copy link
Owner

MoOx commented May 15, 2015

So what do you propose to enhance the tests ?

@jonathanKingston
Copy link
Contributor Author

Sorry for the delay with this; I'm going to paste the changes I made so they are not lost and a brain dump.

The regarding the following line, I know you mention you didn't write the test however I would be interested if you think a failed watcher should be killed? If that is the case then I think the code for that isn't working with Linux correctly.

      if (err && !err.killed) { throw err }

The changes I made mostly hang off just killing the listeners aggressively, however as I would like to get to the root of the problem I'm not sure the following are where cssnext should be doing:

+var psTree = require("ps-tree")
+var kill = function (pid, signal, callback) {
+  signal = signal || "SIGTERM"
+  callback = callback || function () {}
+  var killTree = true
+  if (killTree) {
+    psTree(pid, function (error, children) {
+      [pid].concat(
+        children.map(function (p) {
+          return p.PID
+        })
+      ).forEach(function (tpid) {
+        try { process.kill(tpid, signal) }
+        catch (ex) {
+          console.log(ex)
+        }
+      })
+      callback()
+    })
+  } else {
+    try { process.kill(pid, signal) }
+    catch (ex) {
+      console.log(ex)
+    }
+    callback()
+  }
+}

Killing in the name of:

-              watchImportProcess.kill()
+              kill(watchImportProcess.pid)
+              t.end()

Numbering plans:

+    t.plan(5)

Linux seemed to not wait around for file testing:

     // /**/ to get a content
     // yeah...
+    var fileTest = true
+
+    while (fileTest) {
+      try {
+        var me = fs.readFileSync(watchOut, {encoding: "utf8"})
+        if (me === "/**/") {
+          fileTest = false
+        }
+      } catch (e) {
+       // do something here
+      }
+    }

I'll await feedback and if you are ok with them, I can mop them up into a merge.

@MoOx
Copy link
Owner

MoOx commented May 22, 2015

This test if (err && !err.killed) { throw err } is just to allow ourselves to kill the process when tests are finished, otherwise I think the process will continue until someone kill it.

We already plan 5 tests from what I can read.

If your function helps to kill all childs, maybe it's the solution. Did you make some debug to see if we actually have other child process to kill ?

Also I am considering changing watcher because of #123, maybe that can helps to solve this issue ?

@MoOx
Copy link
Owner

MoOx commented Jun 15, 2015

up :)

@jonathanKingston
Copy link
Contributor Author

Whoops sorry, will look into this further soon.

Yup I wasn't certain if it was actually getting killed in the watcher code (Last time I checked I couldn't see the code that did that).

Yeah certainly as I think the issue is that there is no code killing it correctly, either linux is wrong or that test is.

@MoOx
Copy link
Owner

MoOx commented Aug 6, 2015

Any updates on this ? Otherwise I will end up by closing this issue (not even sure why...)

@MoOx MoOx mentioned this issue Dec 29, 2015
5 tasks
@MoOx MoOx closed this as completed in #238 Jan 4, 2016
@MoOx
Copy link
Owner

MoOx commented Jan 4, 2016

Not relevant anymore. cssnext is now postcss-cssnext. cssnext is deprecated. See postcss-cssnext migration guide http://cssnext.io/postcss/

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants