merb silently fails with doubly specified 'port' config option.
Reported by Slurry | March 27th, 2008 @ 05:57 AM | in 0.9.4
I think there is some wonkiness when specifying:
c[:port] = whatever in config/environments/production.rb
Which will then cause most invocations like:
merb -a thin -c 3
merb -a thin -e production
merb -a thin -p 8000
merb -p 8000 -c 5
merb -p 8000
To silently fail and only spawn a single instance of merb running on whatever port is specified in the config file, and not on the command line.
Looking closer, it actually seems impossible to specify any options if c[:port] is present in the config files.
Comments and changes to this ticket
-
Slurry March 27th, 2008 @ 06:05 AM
To clarify, silently failing means `merb` will report that all instances were started and create their respective log files. It does not create the PID files or actually start the processes.
-
Martin Grund March 31st, 2008 @ 08:17 PM
It looks like you did not install thin or are not on the trunk.
Pls make sure you have thin installed.
The failing require is not shown ( but can be seen if you check for the line "Using Thin adapter" during startup)
Cheers,
Martin
-
Slurry April 2nd, 2008 @ 04:00 PM
Hi Martin,
I don't think that's it.. I have thin installed and can successfully start Merb using thin in all configurations above, as long as c[:port] isn't specified in the config file.
I haven't looked at this in a few days.. but the problem is somewhere in: merb-core/lib/merb-core/server.rb#daemonize(port).
After the call to fork(), the call to: "Merb::Config[:port] = port" (~line 107) then fails to change the port, which means all of the daemons to end up trying to start on the original port. (ie. whatever gets specified in Server#start)
-
Michael Klishin (antares) May 2nd, 2008 @ 10:06 AM
We try to clean up obsolete tickets. Can you still reproduce it? Thanks.
-
Slurry May 6th, 2008 @ 08:34 AM
Michael, I don't have any production Merb environments configured right now and am unable to verify/reproduce.
-
Michael Klishin (antares) May 6th, 2008 @ 11:17 PM
what is the case when you need to both specify port in configuration file and on command line?
-
Slurry May 7th, 2008 @ 12:45 AM
Although having `merb` work as expected would be swell, I don't think there are anything but edge cases for specifying the port in both places.
Personally, I found this problem while profiling the performance of different web servers. ie. The original app had instances running on a 400x range while I tested different servers/configurations on the 8000 range.
HTH
-
Michael Klishin (antares) May 7th, 2008 @ 11:24 AM
- → State changed from “new” to “open”
- → Assigned user changed from “” to “Michael Klishin (antares)”
Ok, sounds reasonable. Anyway, the way server boots now is a bit messy for me. So it probably needs some love => this should be open.
-
Michael Klishin (antares) May 11th, 2008 @ 02:26 PM
- → Milestone changed from “” to “0.9.4”
-
Michael Klishin (antares) May 11th, 2008 @ 10:15 PM
On run cmd line params are parsed and server is started. It drops pid early in boostrap process (see Merb::BootLoader::DropPid). BootLoader subclasses run in order they are defined (unless position is explicitly given).
Init file is read by Merb::BootLoader::Dependencies bootloader later.
What do you think should be the order of load, init first then server start? Does it matter so much we should be reordering boot process? It won't be very easy but is not impossible as well.
WDYT?
-
Michael Klishin (antares) May 11th, 2008 @ 10:29 PM
I moved DropPid bootloader to run later in the process and things work fine. But now init file configurations override those from command line.
It is not committed yet and I think cmd options should override init file, not vice versa. Any opinions?
-
jack dempsey (jackdempsey) May 11th, 2008 @ 10:54 PM
"It is not committed yet and I think cmd options should override init file, not vice versa. Any opinions?"
Definitely agree here. Default options are in files, options from cmd line almost always overwrite those in most any program I've used
-
Michael Klishin (antares) May 11th, 2008 @ 10:57 PM
- → State changed from “open” to “invalid”
After discussion at #merb it was decided to give cmd options higher priority.
So boot process stays the same. if you have a case when the opposite is absolutely needed, feel free to comment and reopen.
-
Slurry May 12th, 2008 @ 08:40 AM
Hi Michael, sorry to re-open this but.. the original scenario and problem are exactly as you describe:
The app was deployed with options specified in the configuration files. I then attempted to launch several other instances of the app on different ports by overriding the config file options with command line equivalents.
These other instances failed to launch with the specified command line params, and instead, only a single instance was spawned, and even it was started with options from the configuration files, not the command line.
Despite these two failures, `merb` incorrectly reported that all of the secondary instances were successfully started using the options specified from the command line.
Pardon my confuzzlement, has this been fixed? :-)
-
Michael Klishin (antares) May 12th, 2008 @ 03:51 PM
- → State changed from “invalid” to “open”
Reproduced. Something happens after daemonization it seems.
-
Michael Klishin (antares) May 12th, 2008 @ 04:33 PM
- → State changed from “open” to “invalid”
On boot Merb is checking pid file to figure out if it can start. No init file is loaded at this point, all options you have are either default or come from command line.
Once you specified port in config, on server start Merb actually uses default port 4000 (and pidfile merb.4000.pid unless explicitly given). Then on next start it sees pid file having id of running process and raises an exception. When daemonized, you cannot see it.
I've added some extra output information to server.rb methods because it probably would be easier for developers to understand what exactly is going on. On failure Merb now prints not just port, but actual pid file it uses (it may be overriden from command line) and process id stored in pid file.
In your case I suggest kill-ing first Merb instance and cleaning pid file manually. If you have any suggestions after this explaination, on what Merb could do in such cases, drop a comment here. But remember, at the point of Rack adapter start init files are far from being loaded.
-
Michael Klishin (antares) May 12th, 2008 @ 05:26 PM
- → State changed from “invalid” to “resolved”
-
Slurry May 12th, 2008 @ 08:20 PM
Michael, thanks for looking at this but after reading your comments, however, I don't think you're getting it:
"As #229 in merb-core shows, people try to set all of configuration options in Merb init file. This caused a hell of a lot of confusion."
There was no confusion and I didn't try to set "all configuration options" in the init.rb file. If you take another look at the second line of this very bug report, I only tried to set a single :port option, and it was in: config/environments/production.rb................
Your solution seems to be to remove the logger output and add a note alerting me to not set options in the init file (which again, never happened) yet we're still left with a broken Merb startup.. idk..
With a working boot process, I would think you should be able to set any available option in the config/environments/*.rb files while also then being able to override it on the command line.
My apologies for not being able to work on this, but don't you agree that is how it should work?
-
Michael Klishin (antares) May 12th, 2008 @ 09:07 PM
Read this.
I do not think it should be working, I said why a couple of times.
There is no way to execute code in init files at the moment when pid files are dropped / checked for alive instances. So you have to use command line options.
If you cannot understand why, read how bootloader works and see order of DropPid bootloader, Dependencies bootloader and when pid file operations are done in the process.
-
Michael Klishin (antares) May 12th, 2008 @ 09:10 PM
If you wonder why your instances fail to run I can explain one more time.
First time you relied on init file config option it actually did use port 4000 from defaults and default pid file name. Now on run Merb sees active process with pid from pid file and raises an exception.
Configuration of port in init file never worked and probably never will because it is an issue minor enough to not change bootloaders order.
if you for some reason really want it, write a plugin that hooks into bootloaders chain and reads init files very upfront. But this seems to be kind of work no worth doing just to get what you want.
-
-
Michael Klishin (antares) May 12th, 2008 @ 09:34 PM
Slurry,
This story ends here. If you want to have init files loaded as early as pid files drop, fork merb, do it and convince Ezra or Yehuda or Michael Ivey to merge it into wycats tree.
I won't be saying anything here any more.
Please Login or create a free account to add a new comment.
You can update this ticket by sending an email to from your email client. (help)
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
Peter