yesod devel always results in 'resource busy (Address already in use)'

[Christian Brink]

I've just upgraded to the latest yesod-platform and yesod-bin.  Now when I use `yesod devel` I get the following output:

    Yesod devel server. Press ENTER to quit

    Resolving dependencies...

    Configuring scafftest-0.0.0...

    Forcing recompile for ./Model.hs because of config/models

    Forcing recompile for ./Foundation.hs because of config/routes

    Forcing recompile for ./Foundation.hs because of messages/en.msg

    Forcing recompile for ./Foundation.hs because of templates/default-layout-wrapper.hamlet

    Forcing recompile for ./Foundation.hs because of templates/default-layout.hamlet

    Forcing recompile for ./Handler/Home.hs because of templates/homepage.hamlet

    Forcing recompile for ./Handler/Home.hs because of templates/homepage.julius

    Forcing recompile for ./Handler/Home.hs because of templates/homepage.lucius

    Rebuilding application... (using cabal)

    Starting development server...

    Starting devel application

    Devel application launched: http://localhost:3000

    devel.hs: bind: resource busy (Address already in use)

This happens every single time I run it, even when I've just restarted the VM it's running on.

If I do a build and run the binary directly, it works fine, binding to the same address and port.

If I run `watch -n 0 'sudo netstat -taupen | grep 3000'` and then run `yesod devel`, it shows that a `yesod` process has bound itself to port 3000 immediately when 

    Yesod devel server. Press ENTER to quit

appears on the screen.  As you can see in the output above, it's not until a good 10-15 seconds later that I see

    devel.hs: bind: resource busy (Address already in use)

which suggests to me that there's some kind of duplicate process launch being attempted.

Any ideas?

Thanks!

[Christian Brink]

By the way, this is happening with a brand-new, unmodified scaffolded site.

[Michael Snoyman]

I'm not able to reproduce this. Can you confirm:

* Version of GHC

* OS

* Version of yesod-bin and yesod-platform used

--
You received this message because you are subscribed to the Google Groups "Yesod Web Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to yesodweb+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Christian Brink]

I'm not at my computer til later today so I don't recall the exact exact yesod versions, but it's ghc 763 and Ubuntu 1204 -- will get the rest later. 1.9.2 for bin, is what I recall. 

You received this message because you are subscribed to a topic in the Google Groups "Yesod Web Framework" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/yesodweb/0AX2GbKqmIk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to yesodweb+u...@googlegroups.com.

[Christian Brink]

1.9.2 was of course way off :)

yesod-bin (output from `yesod version`): 1.2.9.1

yesod-platform (per `cabal info yesod-platform`): 1.2.10

Thanks as always Michael.  If your hunch is that this might be something environment-related, do you have any ideas about what I should be looking at?

[Michael Snoyman]

Hmm... I'm not sure *what* it could be. I just tried with the exact same setup, and it all worked correctly.

Are you certain that the scaffolding you generated was coming from yesod-bin version 1.2.9.1?

[Christian Brink]

I'm pretty sure.  I tried it several times, installing yesod-bin in a cabal sandbox and using that executable to generate a scaffolded site.

Since you've looked into it and can't reproduce it, I've got that "this is something I'm doing wrong" feeling pretty strongly.  But if you have any guesses about how someone could screw up to produce this behavior, please do let me know.  For the time being I'm just building manually with each change.

[Michael Snoyman]

Hmm... one more idea for debugging. Inside devel.hs, can you add an import of:

import System.Environment (getEnvironment)

and then at the top of main:

    getEnvironment >>= mapM_ print

And also print out the `port` value after the getApplicationDev call.

[Christian Brink]

Here's the output, minus a few obviously irrelevant lines that contained sensitive information:

("LESSOPEN","| /usr/bin/lesspipe %s")

("MAIL","/var/mail/vagrant")

("SSH_CLIENT","10.0.2.2 55426 22")

("USER","vagrant")

("SHLVL","1")

("PORT","3000")

("OLDPWD","/home/vagrant")

("HOME","/home/vagrant")

("SSH_TTY","/dev/pts/3")

("FB_APP_NAME","Gloss Localhost")

("PG_POOLSIZE","25")

("NVM_DIR","/home/vagrant/.nvm")

("DISPLAY_PORT","3000")

("LOGNAME","vagrant")

("_","/home/vagrant/.cabal/bin/yesod")

("TERM","xterm")

("PATH","/home/vagrant/.gem/ruby/1.9.1/bin:/home/vagrant:/home/vagrant/.cabal/bin:/usr/local/heroku/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/opt/vagrant_ruby/bin")

("TESTED_ENV","Development")

("LANG","en_US")

("LS_COLORS","rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:")

("SOLR_URL_ASSUMPTIONS","http://localhost:8080/solr/assumptions")

("SHELL","/bin/bash")

("LESSCLOSE","/usr/bin/lesspipe %s %s")

("PWD","/web/gloss")

("SOLR_URL_ELEMENTS","http://localhost:8080/solr/elements")

("SSH_CONNECTION","10.0.2.2 55426 10.0.2.15 22")

("EDITOR","vim")

Starting devel application

Devel application launched: http://localhost:3000

port from getAppDev: 3000

devel.hs: bind: resource busy (Address already in use)

[Christian Brink]

Ok, I found the problem.  The application was being served on port 3000 despite the need, with yesod devel, to reverse-proxy its requests to another port.

Thanks :)

[Christian Brink]

That is, this was happening because I had `export PORT=3000` in my ~/.profile.

I can't remember what problem I was encountering when it /wasn't/ set.  It was something.  In any case, I'll add a line to Devel.hs to unset/mask it if it's set.

[Michael Snoyman]

Aha! So it was a bug in yesod-bin after all. The fix is on Github[1] and Hackage.

Thanks for discovering this one. And let this be a lesson to everyone: always use proper datatypes, even if the library function you're calling doesn't.

[1] https://github.com/yesodweb/yesod/commit/cf20f159574c797ef94f7cfade555b0ac96f152c

[Christian Brink]

Glad my pain is the community's gain :)