similar to: Detecting unicorn / defining after_fork after master startup

Hi all, I''m having issues with Unicorn and connecting to RabbitMQ using the tmm1-amqp gem. I''ve tried lots of approaches. The classic initializer with Thread.new { EM.run } for the Rails app and even tried using the Qusion library. (https://github.com/danielsdeleo/qusion) I''ve made a simple mod to Qusion for it to monkey patch unicorn too. The code looks

On 6/22/20 10:49 AM, Richard W.M. Jones wrote: > If you have a plugin which either creates background threads itself or > uses a library that creates background threads, it turns out you > cannot create these in .get_ready (or earlier). The reason is that > nbdkit forks when either daemonizing itself or using the --run option, > and fork cancels all the background threads in the

VDDK creates background threads. fork kills these, resulting in the library hanging or failing completely in certain configurations. --- plugins/vddk/vddk.c | 28 ++++++++++++++++++++++------ 1 file changed, 22 insertions(+), 6 deletions(-) diff --git a/plugins/vddk/vddk.c b/plugins/vddk/vddk.c index e6639b4d..a481e8bf 100644 --- a/plugins/vddk/vddk.c +++ b/plugins/vddk/vddk.c @@ -431,12

On 6/22/20 10:49 AM, Richard W.M. Jones wrote: > VDDK creates background threads. fork kills these, resulting in the s/kills/strands/ > library hanging or failing completely in certain configurations. > --- > plugins/vddk/vddk.c | 28 ++++++++++++++++++++++------ > 1 file changed, 22 insertions(+), 6 deletions(-) > ACK. Should we also modify our tests/libvixDiskLib.so

Hi all, I''m fighting with the after_fork hook and my sinatra application. The Sinatra app is using active_record, In my unciron.rb file I''m using preload_app true after_fork do |server, worker| ? defined?(ActiveRecord::Base) and ??? ActiveRecord::Base.establish_connection End but I always get the error: ERROR -- : ActiveRecord::AdapterNotSpecified

If you have a plugin which either creates background threads itself or uses a library that creates background threads, it turns out you cannot create these in .get_ready (or earlier). The reason is that nbdkit forks when either daemonizing itself or using the --run option, and fork cancels all the background threads in the child process (the daemonized or captive nbdkit). The only good solution

So, I''ve been following the recommendations for controller specs here: http://blog.davidchelimsky.net/articles/2006/11/09/tutorial-rspec-stubs-and-mocks Most notably: a single expectation per specify block; the setup block contains only stubs; mock expectations each get their own specify block. (I''m still using 0.8, so I haven''t gotten the describe/it goodness yet.) I

Hello, I hope this mailing list is correct. I've a cluster pacemaker with a clone resource ocfs2 with ocfs2-tools-1.4.1-25.6.x86_64 ocfs2-tools-o2cb-1.4.1-25.6.x86_64 on Opensuse 11.2 After some network problem on my switch I receive on one of 4 nodes of my cluster the following messages Aug 18 13:12:28 nodo1 openais[8462]: [TOTEM] The token was lost in the OPERATIONAL state. Aug 18 13:12:28

Greetings, I''m getting this - ActiveModel::MissingAttributeError: missing attribute: some_attr - on a random basis under a unicorn server, running rails 3.2 and ruby 1.9.3 As the case of the last poster in the following thread - https://github.com/rails/rails/issues/1906 - I too am able to resolve this issue by settingpreload_app to false. However, this is not the behaviour I want to

We''re using unicornctl restart with the default before/after hook behavior, which is to reap old Unicorn workers via SIGQUIT after the new one has finished booting. Unfortunately, while the new workers are forking and begin processing requests, we''re still seeing significant spikes in our haproxy request queue. It seems as if after we restart, the unwarmed workers get swamped by

Fairly straightforward. I'd love for type export to be a bit more flexible to make description optional, but could not figure out how to decode that from the C side of things, so for now this just requires the caller to supply a description for all exports during .list_exports. Signed-off-by: Eric Blake <eblake at redhat.com> --- plugins/ocaml/NBDKit.mli | 9 ++++

Fairly straightforward. A user can supply { "name"; None } or { "name"; Some "description" } as desired. Signed-off-by: Eric Blake <eblake@redhat.com> --- plugins/ocaml/NBDKit.mli | 9 ++++ plugins/ocaml/NBDKit.ml | 17 ++++++++ plugins/ocaml/example.ml | 33 +++++++++----- plugins/ocaml/ocaml.c | 92 +++++++++++++++++++++++++++++++++++++++- 4 files

On 7/22/20 7:42 AM, Richard W.M. Jones wrote: > See also: > https://www.redhat.com/archives/libguestfs/2020-July/msg00090.html > --- > docs/nbdkit-plugin.pod | 57 +++++++++++++++++++++++++++++++++++++--- > docs/nbdkit-protocol.pod | 7 +++-- > 2 files changed, 58 insertions(+), 6 deletions(-) I'm playing with code for an initial implementation of this, and quickly

Unicorn is a HTTP server for Rack applications designed to only serve fast clients on low-latency, high-bandwidth connections and take advantage of features in Unix/Unix-like kernels. Slow clients should only be served by placing a reverse proxy capable of fully buffering both the the request and response in between Unicorn and slow clients. * http://unicorn.bogomips.org/ * mongrel-unicorn at

I'm about to add an 'exportname' filter, and in the process, I noticed a few shortcomings in our API. Time to fix those before the 1.22 release locks our API in stone. Overloading .list_exports in order to determine a canonical export name at .open time is awkward; the two uses (answering NBD_OPT_LIST for a full list, vs. remapping a client's "" into a canonical name

This happened on s390 in Koji, once. The key lines from the log are: + start_t=0 nbdkit: sh[1]: debug: retry 1: waiting 1 seconds before retrying nbdkit: sh[1]: debug: retry 1: waiting 1 seconds before retrying + end_t=1 Somehow nbdkit did wait 2 seconds (or at least, nbdkit_nanosleep (1, 0) was called twice by the retry filter). But in the bash script, time (as measured by $SECONDS) advanced

Hi, I''m wondering why SIGINT and SIGTERM both were chosen for the quick shutdown? I agree with SIGINT but not with SIGTERM. A lot of unix tools send SIGTERM as default (kill, runit among some) and it seems to be the standard way of telling a process to quit gracefully but not among Ruby people (there are a few other ruby processes behaving the same way). I just think it''s weird

Mainly small fixes, improvements, and workarounds for fork() issues with pseudo-random number generators shipped with Ruby (Kernel#rand, OpenSSL::Random (used by SecureRandom and also by Rails). If there are any other fixes/improvements that could be useful let us know. I think this is nearing the end of the line for the 3.x series which will then go into maintenance mode. I''m looking

We now give an example of how a before_fork hook can be used to incrementally migrate off the old code base without hitting a thundering herd (especially in the "preload_app false") case. Also comment on the per-worker listen usage in the RDoc, not just a hidden comment. --- I just pushed this out earlier, this example was inspired by Chris Wanstrath''s before_fork hook but

This option didn't work except when using --foreground (or using another option that implies this). This is because it creates a background reader thread, but that thread is invalidated if nbdkit forks, resulting in deadlocks because the worker threads are fruitlessly sending notifications to a background thread that no longer exists. The fix is to move this work to .after_fork. ---