The web in a box - a next generation web framework for the Perl programming language

IRC log for #mojo, 2015-01-25

| Channels | #mojo index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:00 good_news_everyon joined #mojo
00:00 good_news_everyon [mojo] kraih pushed 1 new commit to xml_tags: http://git.io/XqIHxg
00:00 good_news_everyon mojo/xml_tags ee38a39 Sebastian Riedel: made tag helper faster again
00:00 good_news_everyon left #mojo
00:01 sri that's how it would look with $_XML
00:01 sri not pretty
00:01 sri https://github.com/kraih/mojo/compare/xml_tags
00:01 sri same performance as before, and 2 lines of code
00:06 Adura joined #mojo
00:06 sri it's not horrible...but...
00:28 jberger but ...
00:37 sri but
00:38 nicomen what what?
00:41 jberger I'm surprised that purl didn't have a YouTube link for what what
00:42 tempire thank goodness
00:42 tempire That may have even started in this channel
00:44 jberger pink fluffy unicorns?
00:44 jberger tempire: fix that ^^
00:46 tempire purl: mojoconf is https://www.youtube.com/watch?v=eWM2joNb9NE
00:46 purl ...but mojoconf is not officially announced yet...
00:46 sri purl knows what's up
00:46 purl sri: i haven't a clue
00:46 sri -.-
00:47 tempire speaking of old school
00:47 tempire https://www.youtube.com/watch?v=9UrKcfh43zM
00:48 sri "...not available in your country..."
00:48 tempire :(
00:50 Adura https://www.youtube.com/watch?v=7NPdVpx5CgE You'll have to settle for this.
00:50 Adura (hopefully)
00:50 jberger they're was an interview with him when that became popular
00:50 jberger he was basically just confused
00:51 tempire there many who don't understand the lulz
00:53 jberger purl: no, mojoconf is https://www.youtube.com/watch?v=eWM2joNb9NE
00:53 purl okay, jberger.
00:54 jberger fixed
00:56 mishantil Is there a way for mojo to call Foo::Bar when a route '/foo/bar' is hit?
00:57 sri jberger, tempire, marcus, batman, crab: i'm still on the edge about the xml helper... lets vote https://github.com/kraih/mojo/compare/xml_tags
00:57 mishantil Like auto-match routes instead of always providing ->to('foo#bar')
00:57 tempire what is your concern?
00:58 sri lack of use cases, and the use of our()
00:58 tempire Someone mentioned rss earlier, that's reasonable.
00:58 * sri really doesn't like our()
00:59 tempire No one likes our
00:59 * sri mentioned rss ;p
00:59 tempire I support it for that and atom feeds.
01:00 tempire And the features use of our is easily identifiable, and not very complex.
01:01 sri i guess it's also valuable as an example
01:07 jberger I don't hate our. it's a much better language feature than wantarray
01:08 pink_mist our is still better than local too .. that one is freaky
01:15 jberger pink_mist: local is the only reason to use our
01:20 jberger I prefer local as a scope guard rather than an object too personally
01:21 jberger then again, "with" from python might be preferable to either
01:21 jberger and it's rare for me to say that about python
01:21 pink_mist local  has very weird scoping though... not even sure you could call it scoping in the usual sense
01:21 mishantil Ok, so to answer my own question; if I do `sub Mojolicious::Routes::Route::auto { ... }` it works as I want it to.
01:22 mishantil Can't shake the feeling that mojo already have something for this already.
01:22 mishantil And that's one too many already.
01:44 jberger pink_mist: it's called dynamic scope
01:44 jberger find an article called "coping with scoping"
01:45 pink_mist I know what it's called. I know how it works. I just don't quite agree that it's actually scoped
01:45 pink_mist scope is simply the wrong word to use to describe its effects
01:49 jberger sorry, I never know the knowledge level of people on here
01:50 jberger I disagree though, it sets the global state for a time duration of the execution of that scope
01:51 jberger then again sri that would be the only way I would vote against an our implementation
01:52 jberger do we ever think that we would ever offer Nonblocking calls inside of a rendering template?
01:57 jberger I can't imagine that that would ever be encouraged though
01:58 pink_mist hmm, thinking about it, I guess I could conceded that the /value/ is scoped with local, but not the variable
02:19 klapperl joined #mojo
02:24 firnsy joined #mojo
02:31 jberger pink_mist: right, the variable is not  attached to a pad like a lexical is
03:43 cpan_mojo XML-Loy 0.34 by Nils Diewald - http://metacpan.org/release/AKRON/XML-Loy-0.34 (depends on Mojolicious)
03:50 noganex_ joined #mojo
04:07 jberger would be nice to get akron's opinion
04:07 jberger he does a bunch of xml
04:09 davido_ joined #mojo
05:41 sh4 joined #mojo
06:20 cpan_mojo Statocles 0.034 by Doug Bell - http://metacpan.org/release/PREACTION/Statocles-0.034 (depends on Mojolicious)
06:31 preaction hooray!
06:49 rem_lex| joined #mojo
06:54 dotandimet joined #mojo
07:32 Vandal joined #mojo
07:38 jzawodn joined #mojo
07:46 sri jberger: i don't see that happening, although someone might call Mojo::IOLoop->one_tick from a template and cause weird shit to happen
07:48 reneeb joined #mojo
08:05 trone joined #mojo
08:11 dotandimet joined #mojo
08:17 reneeb joined #mojo
08:40 dotandimet joined #mojo
08:46 Lee joined #mojo
08:47 marmez joined #mojo
08:59 irq joined #mojo
09:05 cpan_mojo Mojolicious-Plugin-FormFieldsFromJSON 0.25 by Renee Baecker - http://metacpan.org/release/RENEEB/Mojolicious-Plugin-FormFieldsFromJSON-0.25
09:19 sri jberger: actually, non-blocking operations in templates does seem pretty much impossible
09:19 sri you'd have to use Coro, which should keep the xml helper working properly
09:20 sri which reminds me that i've never actually built a flush helper with Coro
09:26 amon joined #mojo
09:43 sri neat, postgres 9.5 will get better at concurrency http://amitkapila16.blogspot.de/2015/01/read-scalability-in-postgresql-95.html
09:45 cpan_mojo MojoX-Dispatcher-Qooxdoo-Jsonrpc 0.96 by Tobias Oetiker - http://metacpan.org/release/OETIKER/MojoX-Dispatcher-Qooxdoo-Jsonrpc-0.96
10:19 nathanael joined #mojo
10:32 sri hmmm
10:32 sri interesting race condition in Mojo::Server::Prefork
10:32 sri MOJO_LOG_LEVEL=debug perl -Ilib -Mojo -E 'Mojo::IOLoop->next_tick(sub { exit 1 }); app->start' prefork
10:32 sri that one never stops on its own
10:34 sri because SIGCHLD is caught too early after the fork()
10:38 sri i hate this untestable stuff
10:47 batman sri: i'm not sure about the xml() helper. i like the use of local(). almost makes it tempting to simply expost that variable, instead of the actual helper ;)
10:47 batman but i'm pretty sure that will be down voted.
10:48 good_news_everyon joined #mojo
10:48 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/XMcKeQ
10:48 good_news_everyon mojo/master b90200a Sebastian Riedel: fixed race condition in Mojo::Server::Prefork
10:48 good_news_everyon left #mojo
10:48 sri batman: no chance in hell that would get my vote
10:48 batman if we are adding the xml() helper, then i'm +1 on your patch
10:48 batman sri: exactly :D
10:49 sri batman: the big question is *if* we add it
10:49 sri i think it lacks good use cases
10:50 batman yeah. i'm still not sure. i'm +1 on adding it when requested, but i doubt it will be demanded...
10:50 sri i hate hate hate that race condition patch :(
10:50 batman i agree. i do xml directly in the template. the important thing is that the tag helpers in HTML-space didn't act like xml
10:51 sri but at least it allows you to ctrl+c the one-liner above
10:52 sri it still goes bonkers with respawns though
10:52 batman i'm not feeling well, so i'm in no position to comment on that race condition patch :(
10:52 batman it makes my head spin...
10:53 batman but again... is it the use of local() that bugs you, or simply that it's hard to test?
10:53 sri the manager calls fork(), the child exits right away, so fast that the manager didn't even have time to create $self->{pool}{$pid} yet
10:53 sri impossible to test
10:54 sri so the manager receives SIGCHLD, reaps the child, and then goes back to creating $self->{pool}{$pid}
10:55 sri and so it looks like we still manage the dead child
10:55 sri and wait forever
10:59 sri aha, i have a better solution :)
11:05 good_news_everyon joined #mojo
11:05 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/9dMxyQ
11:05 good_news_everyon mojo/master 6faad94 Sebastian Riedel: just make sure signals are delivered
11:05 good_news_everyon left #mojo
11:05 sri for the record, i have absolutely nothing against local()
11:05 sri it's a great tool
11:06 sri i do hate global state though, and therefore package globals created with our()
11:07 sri they also make for shitty looking apis
11:07 sri local $Test::Builder::Level = $Test::Builder::Level + 2;
11:09 batman :)
11:09 sri i can accept stuff like our $VERSION, that's good global state
11:10 sri although i prefer the "package Foo 1.0" variant
11:10 sri and Foo->VERSION
11:19 cpan_mojo Mojolicious-Plugin-Prove 0.06 by Renee Baecker - http://metacpan.org/release/RENEEB/Mojolicious-Plugin-Prove-0.06
11:24 dod joined #mojo
11:29 dod joined #mojo
12:03 reneeb jberger, batman: to get the results of mojolicious 5.72 vs. 5.74 for your modules, you can use http://mojo.perl-services.de/#jberger,5-72,5-74
12:06 nicomen the other day I wanted to search metacpan for template toolkit plugins, and apparently there is no tagging system for packages, it would have made sense since namespaces are messy and change, and there is no rdepends search either (that would also have helped to find mojo plugins) I guess?
12:07 reneeb Not everything that has a dependency on Mojolicious is a plugin. Some dists only use the UserAgent to request some websites/apis.
12:08 reneeb If you want to get all modules that depend on a specific module, you could use MetaCPAN::Client that has a reverse_dependency method
12:15 nicomen true, I would've circumvented that by being able to tag modules with categories or similar
12:16 nicomen probably on top, as a metacpan task
12:19 nicomen similar similar to what debian does:
12:19 nicomen $ apt-cache show vim | ack-grep "(Section|Tag)"
12:19 nicomen Tag: devel::editor, implemented-in::c, interface::commandline,
12:19 nicomen Section: editors
12:23 sh4 joined #mojo
12:27 pink_mist nicomen: https://metacpan.org/requires/distribution/Mojolicious?sort=[[2,1]] <-- it's not that hard to find things that depend on Mojolicious =)
12:28 pink_mist nicomen: same thing can be applied to template::toolkit I expect =)
13:03 good_news_everyon joined #mojo
13:03 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/1ktwHw
13:03 good_news_everyon mojo/master 3bb278d Sebastian Riedel: removed -g and -u options from daemon command
13:03 good_news_everyon left #mojo
13:03 sri makes no sense as a feature
13:06 Oleg joined #mojo
13:07 Oleg sri: Oh nooo, I was user of -u option for a daemon :D
13:07 sri what did you use it for?
13:08 Oleg in the init script to switch from root to normal user
13:08 sri hmm
13:09 Oleg Of course I can make this with su -c "..."
13:09 pink_mist why not use hypnotoad?
13:09 stephan48 they are indeed usefull if you want to drop previlegies after binding to ports <1024 without a frontend webserver... no clue how common this usecase is
13:10 Oleg pink_mist: 1 process is enough for some tasks
13:10 pink_mist Oleg: can you? wouldn't think you'd be able to bind to port 80 with that
13:10 good_news_everyon joined #mojo
13:10 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/Yk0qrw
13:10 good_news_everyon mojo/master ce6a046 Sebastian Riedel: bring back -g and -u options...
13:10 good_news_everyon left #mojo
13:11 sri i guess it makes sense
13:11 Oleg thanks, sri
13:14 Oleg pink_mist: no I don't want to bind to 80 port. At system boot time scripts from /etc/init.d starts from root user. So I use -u option to switch to normal user
13:14 pink_mist ah I see
13:14 pink_mist still, that is also a valid usecase =)
13:16 sri i so hate it when untestable features have security implications
13:17 nicomen like?
13:17 sri like the one i just tried to remove
13:18 nicomen I don't understand the security implications that are untestable about that
13:19 sri how do you test group and user assignment portably?
13:20 sri and especially secondary groups?
13:21 stephan joined #mojo
13:21 nicomen are you only using Posix, then it could be mocked, no?
13:22 stephan hey. i'm just starting with mojo. i could not find out how i would match a route with name /foo?val=1?val=2. i tried post '/foo/*' {} but that did not work.
13:24 Oleg stephan: try "/foo"
13:25 stephan ok
13:26 stephan but then i won't get the ?val=1?val=2 values anymore
13:27 pink_mist those are parameters
13:27 Oleg did you mean "?val=1&val=2"
13:28 Oleg this will be in $self->param('val')
13:28 stephan yes, how would i get them? i used shift->param("val") but it wont return to me anything.
13:29 good_news_everyon joined #mojo
13:29 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/J-Ft6w
13:29 good_news_everyon mojo/master d63c4af Sebastian Riedel: mention that routes only match the path part of the request URL
13:29 good_news_everyon left #mojo
13:29 Oleg stephan: shift->param("val") should work
13:32 sri btw. i'm still looking for use cases for the xml helper
13:32 sri https://github.com/kraih/mojo/compare/xml_tags#diff-ab8c5553c5f71a9d70038dac95d4d07dR764
13:32 sri if anyone can think of something please speak up
13:33 pink_mist didn't marcus suggest rss feeds?
13:33 sri i did
13:33 sri but it's not really a good use case
13:33 sri which part of an rss feed would you generate with tag helpers?
13:35 sri i think tempire mentioned atom, but that's just the same
13:35 nicomen SOAP?
13:35 purl SOAP is Snakes on a @($*&@ Plane!~ or something you don't drop in prison or HTTP when you actually read the spec or XML-RPC + the kitchen sink or a pain for customers to use or all just evil corporate wankery that makes you just  want to slash your wrists or XML::Compile::SOAP or WebSource or W3C::SOAP
13:36 sri please try to stay serious
13:37 Oleg somebody may want to write API which will respond with XML
13:37 sri but why would you want to use tag helpers there?
13:37 nicomen lol, well, any serious developer to create results in an xml format probably would probably use some specialized modules for it. In my case we generate RSS, NewsML and ATOM using templates and writing out the xml in its entirety with some loops here and there
13:38 nicomen I have never used tag helpers actually. The only time I think I would need it would be for very dynamic forms perhaps, and that would be HTML.
13:38 Oleg I used XML::Writer for this :)
13:38 nicomen So when do you need HTML tag helpers?
13:49 good_news_everyon joined #mojo
13:49 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/IAKW4w
13:49 good_news_everyon mojo/master 2516f52 Sebastian Riedel: more response header examples
13:49 good_news_everyon left #mojo
13:57 asarch joined #mojo
14:05 stephan joined #mojo
14:17 jberger if I was writing an api for small records, using content negotiation and I wanted to have xml output, I would probably just template it given the small records size and it's status as only a small part of the system as a whole
14:17 jberger xml being only one choice out of many
14:19 jberger reneeb++ I will get to these today, thanks again
14:20 jberger preaction++ # statocles
14:33 jkramer left #mojo
14:42 jkramer joined #mojo
14:44 zivester joined #mojo
14:44 jkramer sri: When I do Mango->new->db('asd')->collection('qwe')->insert..., $self->mango inside Mango::Database returns undef. If I do my $mango = Mango->new; $mango->db... it works fine
14:45 jkramer Not sure if I should create a bug report for this
14:45 sri jkramer: i do not support Mango anymore
14:46 sri https://github.com/kraih/mango#moved
14:46 sri the new maintainer was supposed to make a new release for a few months now...
14:49 jkramer Ah ok, I'll post a bug on github then
14:50 stephan okay, not it works, somehow i used the POST method, but with GET it works.
14:56 jkramer sri: Just out of curiosity, why did you stop maintaining it? Did you find/write a better module for the job? :)
15:00 sri jkramer: wrong repo
15:00 sri that issue will get ignored
15:01 sri also https://groups.google.com/d/msg/mojolicious/GFsXFQF3t-k/Tchin2EhJqgJ
15:02 cpan_mojo Mojolicious-Plugin-FormFieldsFromJSON 0.26 by Renee Baecker - http://metacpan.org/release/RENEEB/Mojolicious-Plugin-FormFieldsFromJSON-0.26
15:03 jkramer Awww, damn
15:32 sri for discussion https://github.com/kraih/mojo/pull/734
15:52 dotan jkramer: I commented on your issue, basically, it's not a bug, it's a side-effect of a feature ;)
15:55 cpan_mojo Mojolicious-Plugin-InstallablePaths 0.04 by Joel Berger - http://metacpan.org/release/JBERGER/Mojolicious-Plugin-InstallablePaths-0.04
15:59 punter joined #mojo
16:27 cpan_mojo Mojolicious-Plugin-PPI 0.07 by Joel Berger - http://metacpan.org/release/JBERGER/Mojolicious-Plugin-PPI-0.07
16:43 stephan joined #mojo
16:50 cpan_mojo Mojolicious-Plugin-Memorize 0.02 by Joel Berger - http://metacpan.org/release/JBERGER/Mojolicious-Plugin-Memorize-0.02
17:03 stephan joined #mojo
17:06 stephan joined #mojo
17:13 stephan joined #mojo
17:15 good_news_everyon joined #mojo
17:15 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/AC89eg
17:15 good_news_everyon mojo/master 3490887 Sebastian Riedel: fixed typo in Mojo::Log
17:15 good_news_everyon left #mojo
17:15 stephan joined #mojo
17:15 Stephan joined #mojo
17:17 stephan joined #mojo
17:18 stephan joined #mojo
17:52 dod joined #mojo
18:04 good_news_everyon joined #mojo
18:04 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/Q2I1iQ
18:04 good_news_everyon mojo/master da28997 Sebastian Riedel: fix memory leak in Mojo::Server::Prefork
18:04 good_news_everyon left #mojo
18:07 skaji joined #mojo
18:09 cpan_mojo Galileo 0.038 by Joel Berger - http://metacpan.org/release/JBERGER/Galileo-0.038 (depends on Mojolicious::Plugin::Memorize)
18:10 jberger ok, with the exception of Mojo::Autobox failing in dev perls (which I believe is due to autobox problems there) I think I'm caught up
18:10 jberger reneeb++
18:12 mst jberger: yeah, she be brok
18:14 jberger I thought I had seen that, thanks for saving me the investigation
18:19 zivester joined #mojo
18:34 * tempire hasn't used anything with xml in quite a while
18:35 tempire What happened to marcus?
18:43 * sri wonders if we should do something about this one-liner
18:43 sri MOJO_LOG_LEVEL=debug perl -Ilib -Mojo -E 'Mojo::IOLoop->next_tick(sub { exit 1 }); app->start' prefork
18:45 sri ever since convos marcus has been a lot less active on irc
18:49 Oleg sri: What do you think about restart with some delay? But looks like this is not so easy to do
18:54 cpan_mojo Mojolicious-Plugin-MozPersona 0.05 by Heiko Jansen - http://metacpan.org/release/HJANSEN/Mojolicious-Plugin-MozPersona-0.05
18:57 sri Oleg: yea, anything too complex is out of the question
18:59 sri and of course it can't affect performance
18:59 jberger sri what should that example do?
18:59 * jberger misses marcus
18:59 sri jberger: eat cpu like crazy
19:00 sri note that with 5.74 you can't ctrl+c it, that was fixed in master
19:00 Oleg and disc space with laaarge log file :)
19:01 jberger I have 5.74 installed and I ctrl+c ed it
19:01 sri Oleg: to be fair, it's an unlikely edge case
19:01 mst sri: yeah, well, I'm trying to convince people to un-K-line it
19:01 mst sri: the problem is that they fucked it up badly enough repeatedly enough that it's not an easy sell
19:02 sri Oleg: most worker that die will die a little later when a request arrives
19:02 sri *+s
19:03 sri jberger: you shouldn't be able to, unless the box is really slow
19:04 jberger I doubt my 2 mo old mbp would qualify as really slow
19:04 sri jberger: anyway, the quick restarts you see before the ctrl+c are the problem i was referring to
19:04 jberger right
19:05 jberger so what would the expected (desired) result be?
19:05 sri you tell me ;p
19:05 jberger not forking new workers?
19:06 jberger I mean, its kinda like trying to fix a fork bomb
19:06 Oleg do not restart if no one heartbeat received?
19:06 sri workers will die and we need to restart them
19:06 jberger I'm not actually suggesting that btw
19:07 jberger I'm saying I doubt there is much we can do
19:07 sri Oleg: we don't keep track of old workers
19:07 sri that would be a whole new can of worms
19:09 jberger could you tilt the race odds in your favor by making the worker sleep 0.1 as its first thing?
19:09 sri there is no race condition anymore
19:10 sri it's just workers exiting and getting restarted really fast
19:10 jberger then, unfortunately, I could argue that that is what it is supposed to do :-/
19:11 jberger I'm not sure how you would detect otherwise
19:11 * sri shrugs
19:11 sri whole thing has come up because of this issue https://github.com/kraih/mojo/issues/733#issuecomment-71370784
19:12 sri some folks want hypnotoad/prefork to die if user/group assignment fails
19:12 sri which happens in the worker process, and is totally untestable
19:12 jberger ok, I see the problem in that case
19:13 Oleg {pool}{$pid} has info about heartbeat?
19:13 sri well, i don't think it's a big problem, so i'm not going to force the issue
19:13 sri anyone who cares and has an idea can send a pull request
19:13 Oleg so, may be checked inside SIGCHLD handler
19:13 jberger does the child have a mechanism to signal the parent?
19:14 sri note that everything you add will be untestable code as well
19:14 Oleg with pipe
19:14 * jberger tries to remember some stuff he learned when writing forkcall
19:14 sri so there's a limit on complexity you can add
19:16 jberger this was the line I remember reading, I'm not sure it's useful to us
19:16 jberger https://metacpan.org/source/MLEHMANN/AnyEvent-7.08/lib/AnyEvent/Util.pm#L307
19:18 preaction if the child exits with a specific exit code, that's another way to inform the parent of things
19:23 Oleg the idea is simple :) https://gist.github.com/olegwtf/849334dbc0499d41d1ee
19:29 sri Oleg: and then you're slowly losing all your workers in production
19:31 sri oh, i misread
19:31 sri you're decreasing the number of workers if there has been no heartbeat
19:32 basiliscos joined #mojo
19:33 sri that's actually the best solution yet
19:34 sri but there is a problem all solutions will have a hard time with
19:34 sri hypnotoad hot deployment
19:35 sri the case where you have a running hypnotoad, and change the user/group in the config file, before triggering hot deployment
19:36 sri the new manager starts fine, and kills the old one, but now your new manager notices the problem and shuts down too
19:37 sri hot deployment can only detect problems if the new manager process dies *before* spawning children
19:45 Oleg same as with fresh start. Man will check is his web page works, will notice that it doesn't. Check logs, found problem. So, I think this is not a problem of hot deployment
19:46 sri it is a very big problem
19:47 sri the whole point of hot deployment is to make it really hard for servers to go down
19:48 Oleg a, yeah, this point may be delayed
19:51 jberger ok but I still don't get it, if workers fail to come up, the server is going to be down anyway? no?
19:53 jberger is it possible to have the servers exit 255 if something goes wrong prior to ->start (like failing to setguid) and have the manager check for 255 and deal with it there?
19:54 Oleg In the current implementation they will not fail to start after fail of changing group. But we want they to fail like this: https://github.com/kraih/mojo/issues/733#issuecomment-71363819
19:55 jberger I probably should just not worry about this anymore, I'm way out of my league?
19:56 preaction you don't want 255, that assumes it was given a signal of 127. also, i think die() defaults to something weird like that. best to use <128 for that kind of thing
19:56 preaction i mean, if you're shutting down normally, you get sigterm, and you can check for that. anything else is probably abnormal
19:57 jberger ok I thought 255 was the highest, but yeah, something like what preaction said
19:58 preaction it is the highest. but if that last bit is set, it means "killed by signal", then you mask off that highest bit and you get the signal number that was sent
19:59 preaction so you'll see things like if ( $? & 128 ) { say "Killed by signal: " . $? << 1 } # i probably screwed that up, but we see if the 8th bit is set, then we shift off the 8th bit to find the signal number
19:59 Oleg this will not help with hot deployment issue
20:01 preaction when hot deploying, you want to ensure that the workers come up before switching over to the new manager. give it a few seconds, and if it can't keep a worker up, you failed?
20:04 sri or we just stick with what we have now
20:04 sri and don't make failures to switch group/user fatal
20:05 sri preaction: if you have an idea for how to do it reliably, please send a pull request
20:06 sri https://github.com/kraih/mojo/blob/master/lib/Mojo/Server/Hypnotoad.pm
20:06 sri it's all in there
20:06 sri although, i suspect you'd have to add one or two new methods to Mojo::Server::Prefork too
20:11 preaction so, just thinking out loud: you're allowed to trap all but the untrappable signals (sigkill, for example), which means you can exit 0; on those if it's "normal operation" to be killed by that signal. so any non-zero exit status in a worker should be considered abnormal. if it happens during startup, we've failed our hot deployment. or, really, if it happens before the worker sends its first heartbeat (which it could send when it's completely done
20:11 preaction initializing itself)
20:17 dotandimet joined #mojo
20:25 Grinnz well to me, it is always potentially a security issue, but it only becomes a real serious issue if root can fail to set user
20:26 Grinnz which i dunno, may happen with selinux
20:28 sri Grinnz: that's not relevant as long as there's no solution
20:28 Grinnz i know, but i don't know how to help with that part
20:29 Grinnz but i think having the workers send a "success" before hot deployment is considered successful is sane, not just for this case
20:29 sri or rather... the solution we have makes hot deployment unreliable
20:30 sri I'M WAITING FOR PATCHES!
20:33 mst maybe just do "if different user, screw it, refuse to hot restart" ?
20:33 Grinnz that too, i don't think changing user/group on hot deployment is a good idea
20:33 Grinnz its not something that should be expected
20:34 sri i disagree
20:34 Grinnz its not a hot deployment anymore, you're changing the parameters of the processes
20:35 Grinnz they may or may not be able to respond to requests anymore
20:35 jberger Grinnz: that's allowed of course, because that's how you change secrets
20:35 Grinnz i mean the unix parameters
20:35 mst jberger: er, lol? we're talking about uid/gid here
20:36 mst which basically can't work unless you have an extra launcher process that's setuid
20:36 sri "parameters of the processes" is about as vague as it gets
20:36 jberger yeah, I really don't have any idea what I'm talking about
20:36 purl i heard talking about was "Yeah, you're alway talking and talking and talking. Shut up and code."
20:36 jberger thanks purl, will do
20:37 sri mst: you're misunderstanding, the manager process is root, we fork workers and those workers do setuid/gid
20:37 Grinnz sri, let me put it this way. what if the user is changed to a user that is not allowed to fork processes?
20:37 Grinnz oh, its done in the worker
20:37 sri we hot deploy the manager process as root
20:38 sri which web server does it differently?
20:39 Grinnz i've never tried to change user/group for apache or nginx
20:39 mst sri: oh. sorry. then ... why would the uid/gid set fail?
20:39 mst which I thought was the original question?
20:39 Grinnz if it's not started as root, for one
20:39 sri lack of permissions or user/group does not exist
20:40 mst right, so would we have the same problem if the child process e.g. crashed trying to open a file or create a database connection?
20:40 sri http://nginx.org/en/docs/ngx_core_module.html#user
20:42 sri mst: very different problem (not actually a problem)
20:43 sri this is exhausting
20:43 sri https://github.com/kraih/mojo/issues/733
20:43 mst sri: sorry, I don't think I understand why this problem specifically is one rather than an entire class of problems
20:43 mst I'll shut up for the moment
20:43 sri one last time, that issue is the original problem
20:44 Grinnz i just tried to change to an invalid user in my nginx config, it sent an [emerg] error message and didn't restart the worker
20:44 sri i'm done with the topic too now, i've tried, nobody really solved the problem, and i'm ok with how it works now
20:45 sri nginx has it much easier, it can assume every dead worker was a fatal error, we are an app server and have to deal with shitty apps
20:45 Grinnz right
20:46 mst for this particular case, wouldn't simply checking if you're already the right group and skipping the set work?
20:46 sri i'm actually close to ripping out use/group support completely :)
20:46 sri s/use/user/
20:47 Grinnz no difference to me, i'm setting user before starting hypnotoad atm
20:47 sri how do you bind to a privileged port?
20:47 Grinnz i'm not, but i can see how that would be an issue
20:48 sri hmmm... actually ripping out setuidgid and daemonize might not be the worst idea
20:49 sri you can change the user/group from your app too, even make it a plugin
20:49 sri and daemonize is used so rarely anymore
20:49 Grinnz is it?
20:49 purl it's it!
20:50 sri maybe there are others like Grinnz that consider it a security issue
20:51 Grinnz i would think anything that leads to people runnign servers as root is worse
20:51 preaction if users want to daemonize, they can use the bsd daemontools
20:51 Grinnz i mean, the workers
20:51 sri not that it matters much, without tests both methods are fair game, but it's the argument that's pushing me over the edge right now
20:53 sri i don't actually use the feature myself either... switched to capabilities and non-root users
21:04 sri patch is pretty straight forward
21:05 sri https://gist.github.com/anonymous/c8a8a7130b78c7373f40
21:07 pink_mist oh no :( time to never update Mojolicious on my production server then :/
21:08 sri but security!
21:08 purl antonym: convenience
21:08 * sri pats purl
21:08 purl how condescending
21:08 mst actually, letting Daemon::Control do that part if you don't already have something else to do so is probably no bad thing
21:09 pink_mist sri: you're forcing me to run it as root if I upgrade :/ that's the opposite of security :/
21:09 sri pink_mist: i'm doing no such thing
21:09 mst pink_mist: no, he's forcing you to setuid/gid first, then start hypnotoad
21:10 pink_mist I only have /opt/perl/bin/hypnotoad in my sudo line
21:10 Grinnz what about privileged ports as mentioned before?
21:10 mst sri: I assume hypnotoad works with server_starter ?
21:11 sri i'm forcing you to a) run as root *and* deal with setuid/gid yourself in the app, b) bind to an unprivileged port and let a reverse proxy deal with the outside world (you should have one of those anyway), or c) use linux capabilities
21:11 jberger b++
21:12 * jberger shuts up again
21:13 pink_mist too old kernel for capabilities on this box :/
21:13 jberger then again, the harder to make it (appear) to be to not run as root, the more people will do so
21:14 jberger same lesson that's driving Test::Mojo::Phantom, the harder people believe it is to test javascript, the fewer people will do so
21:14 mst I quoted this conversation to a sysadmin friend of mine
21:14 mst the reply I got was "/ctcp tazer"
21:14 mst I'm inclined to concur that the feature should continue to exist in some form
21:14 sri but security
21:14 purl antonym: convenience
21:14 pink_mist and for describing how to deploy your app to someone else, being able to say "just edit the user/group in the config and sudo hypnotoad app.pl" was great :/ now they'll need to jump through hoops and hoops =/
21:16 sri this is me forcing the issue, since security has been invoked
21:16 sri if you want the feature to stay make the problems go away
21:17 mst as I said before, a small patch would kill the specific crash in question
21:17 mst and if they specify a user that doesn't exist and try and hot restart, sucks to be them
21:17 sri mst: that's not the problem at all
21:18 mst that's what the issue you told me to read leads me to believe
21:19 sri any user/group assignment failure triggers the same issue
21:20 mst sure. but the specific crash shouldn't need to happen
21:20 mst any -other- user/group assignment problem, well, your config is broken and your hot restart won't, live with it
21:21 sri your hot restarts will work just fine, but show an error in the log and keep running as root
21:21 mst uh, what?
21:21 mst I'm not proposing skipping if the set fails
21:21 mst I am proposing that it is possible to tell if you already have a particular group, and then if you do, you can skip trying to setgid entirely
21:21 mst because you're already done
21:21 sri aaaaaaaaargh
21:22 mst and then for any *other* setuid/setgid failure
21:22 mst "log an error, the hot restart is going to break" is acceptable
21:22 sri THAT'S THE PROBLEM!!!
21:22 sri we can't break the hot restart
21:22 mst if a user specifies a user that doesn't exist, that's their problem
21:22 mst that would presumably break restarting it any other way too
21:23 mst just document it next to the user and group options
21:23 sri the worker process does the setuid/gid change, which is to late to be caught by hot deployment, it's already successful by then
21:23 sri your server would go down
21:23 panzana` joined #mojo
21:23 stryx` joined #mojo
21:23 mst yes. and it would be your fault.
21:23 mst deleting the feature entirely is not an improvement over this
21:24 mst screwing up a username in most supervisor program configs will take your service down
21:24 mst so you're not actually making things any better for your users
21:24 sri we can bring the feature back once there's a proper patch
21:24 sri right now there is only garbage
21:24 sri and nobody to work on it
21:25 mst the code your gist deleted seemed basically reasonable to me
21:25 sri actually, you're arguing for removal
21:25 mst just needs a couple tweaks and some better error logging
21:26 sri jberger, marcus, batman, crab, tempire: now would be a good time to chime in
21:27 mst pink_mist: gimme a shout if you decide to work on a PR and get stuck; I'm pretty sure this is fixable, but I'm unlikely to try it myself given the response I just got
21:27 * mst shrugs and goes for a beer instead
21:27 jberger can I try to see if I understand by restating the issue as I see it?
21:27 jberger process forks worker
21:28 jberger worker fails for some reason (this might be one of two things, fails before or after starting the app)
21:28 jberger manager process needs to know what to do next
21:28 jberger is that about right?
21:29 sri that was the case i originally cared about... everybody else just wants the server to go down on setuid/gid failures
21:30 jberger well, as you mention, if your app is just exit 1, the app is already going to be in a wonky state
21:30 sri how is that relevant?
21:30 jberger I see that you are most worried about the server not going down, correct?
21:30 sri yes
21:31 jberger ok, so lets consider that your app has changed from 'do good stuff' to 'exit 1'
21:31 sri everybody else is cool with hypnotoad being able to shut down during a hot deploy... as opposed to keeping the original manager process running if the new one fails
21:31 jberger on hot restart, is there any way to prevent it from going down?
21:31 preaction yes. if the new one can't start, don't kill the old one
21:31 sri preaction: THAT'S THE PROBLEM!
21:32 preaction yes
21:32 sri we have no way to do that
21:32 jberger right, I can only think of one way around that, the child's exit value
21:32 sri jberger: i don't think you're grasping the whole situation yet
21:32 jberger check that the child exit value isn't non zero before the first heart beat
21:32 sri it's not about detecting something
21:32 jberger probably not, seeing as I just use nginx and port 8080
21:33 sri exit values, heartbeat messages... we have it all
21:34 jberger if the old manager has to go away, and the new manager is trying to run an app that cannot work (for any reason), there is nothing that can be done
21:35 sri of course there is
21:35 sri what we do now
21:35 sri keep the old one running
21:35 jberger "if the old manager has to go away"
21:36 jberger if it doesn't, then I guess I still don't see the issue
21:36 sri the old one goes away once the new one has loaded the app and spawned its workers (which may or may not need more time at this point to start/fail/whatever)
21:36 jberger you just told preaction that it has to go away
21:36 jberger ok so there is a race to see if the new one can exist
21:37 jberger before the old one goes away
21:37 sri the new one kills the old one
21:37 sri https://github.com/kraih/mojo/blob/master/lib/Mojo/Server/Hypnotoad.pm#L96
21:38 jberger so in a perfect world, where the new one could keep the old one around forever, just in case, then we would be fine?
21:39 sri no, you'd have a gazillion old processes
21:39 jberger it was a hypothetical, meant to avoid that very reality, I'm still narrowing the problem
21:40 jberger is the following then a possibility:
21:40 jberger "the old one goes away once the new one has loaded the app and spawned its workers and they have each successfully sent a heartbeat"
21:41 sri we don't do the last part
21:41 jberger I know, I'm asking
21:41 sri there was no question mark
21:41 jberger is the following then a possibility:
21:41 jberger ^^ implied question mark
21:42 rem_lex|pivo joined #mojo
21:42 sri then you have another problem
21:42 sri the old one also has a timeout, after which it kills the new one
21:43 sri i don't know how you'd make sure all your workers have a heartbeat
21:43 jberger and I suppose it would be over complicated for there to be a heartbeat between those two
21:43 sri under heavy load they might already have been restarted
21:43 jberger ok, even receive one heartbeat from a worker, that should usually suffice
21:43 sri heartbeats happen only like every 5 seconds
21:44 pink_mist can't the workers send their first heartbeat once they've initialised?
21:44 sri you can also set the number of requests after which to cycle workers very low
21:45 jberger sri: I'm curious about pink_mist's last
21:58 sri this patch may work https://gist.github.com/anonymous/faf1202ba0235fb4d39d
22:18 jberger I think that looks something like what I would have expected
22:18 jberger admittedly I am still getting lost a bit because a lot of this is foreign to me
22:18 jberger but it looks good so far
22:19 sri actually it's wrong
22:19 sri ;p
22:19 jberger hahaha, my point
22:22 skittles_ joined #mojo
22:22 phillipadsmith joined #mojo
22:25 chansen joined #mojo
22:42 sri this one might actually work though https://gist.github.com/anonymous/e4d53f59cdb73a8b8d1d
22:44 sri it does send a heartbeat right away (on the first reactor tick)
23:07 kaare joined #mojo
23:08 good_news_everyon joined #mojo
23:08 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/14Sx_w
23:08 good_news_everyon mojo/master ce7a188 Sebastian Riedel: make Hypnotoad a little more resilient to exceptions
23:08 good_news_everyon left #mojo
23:13 alnewkirk joined #mojo
23:24 good_news_everyon joined #mojo
23:24 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/scU8JA
23:24 good_news_everyon mojo/master 0ed85b1 Sebastian Riedel: slightly more consistent use of flags
23:24 good_news_everyon left #mojo
23:26 sri i think the complexity of Mojo::Server::Prefork might be a bit of a problem
23:26 sri and i still hate setuidgid/daemonize :(
23:29 Grinnz regardless of that, i think it is good (and expected) to have that check before hot deployment succeeds

| Channels | #mojo index | Today | | Search | Google Search | Plain-Text | summary