I'm running a sharded MongoDB instance and as per the instructions, the config servers are a replica set. I'm unable to upgrade from v4.2.9 to 4.4.0. Per the upgrade instructions, I need to upgrade the config servers first, starting with a secondary. It already failed there. I shut down the secondary's instance, replaced the binaries, and restarted it. But it didn't start up again. The logs say the following (I removed the timestamps for clarity):
"msg":"The size storer reports that the oplog contains","attr":{"numRecords":53890848,"dataSize":13618131721}}
"msg":"Sampling the oplog to determine where to place markers for truncation"}
"msg":"Sampling from the oplog to determine where to place markers for truncation","attr":{"from":{"$timestamp":{"t":1494750837,"i":1}},"to":{"$timestamp":{"t":1598687615,"i":1}}}}
"msg":"Taking samples and assuming each oplog section contains","attr":{"numSamples":253,"containsNumRecords":2124552,"containsNumBytes":536870917}}
"msg":"User assertion","attr":{"error":"Location13111: field not found, expected type date","file":"src/mongo/bson/bsonelement.h","line":810}}
"msg":"WiredTiger record store oplog processing finished","attr":{"durationMillis":21}}
"msg":"~WiredTigerRecordStore for: {ns}","attr":{"ns":"local.oplog.rs"}}
"msg":"Invariant failure","attr":{"expr":"_oplogManagerCount > 0","file":"src/mongo/db/storage/wiredtiger/wiredtiger_kv_engine.cpp","line":2467}}
"msg":"\n\n***aborting after invariant() failure\n\n"}
"msg":"Writing fatal message","attr":{"message":"Got signal: 6 (Aborted).\n"}}
"msg":"BACKTRACE: {bt}","attr":{"bt":{"backtrace":[{"a":"55C91A79E621","b":"55C917AE3000","o":"2CBB621","s":"_ZN5mongo18stack_trace_detail12_GLOBAL__N_119printStackTraceImplERKNS1_7OptionsEPNS_14StackTraceSinkE.constprop.606","s+":"1E1"},{"a":"55C91A79FCC9","b":"55C917AE3000","o":"2CBCCC9","s":"_ZN5mongo15printStackTraceEv","s+":"29"},{"a":"55C91A79D4B6","b":"55C917AE3000","o":"2CBA4B6","s":"_ZN5mongo12_GLOBAL__N_116abruptQuitActionEiP9siginfo_tPv","s+":"66"},{"a":"7FAF200070E0","b":"7FAF1FFF6000","o":"110E0","s":"funlockfile","s+":"50"},{"a":"7FAF1FC89FFF","b":"7FAF1FC57000","o":"32FFF","s":"gsignal","s+":"CF"},{"a":"7FAF1FC8B42A","b":"7FAF1FC57000","o":"3442A","s":"abort","s+":"16A"},{"a":"55C9189E6C5F","b":"55C917AE3000","o":"F03C5F","s":"_ZN5mongo15invariantFailedEPKcS1_j","s+":"12C"},{"a":"55C9186CE4B6","b":"55C917AE3000","o":"BEB4B6","s":"_ZN5mongo18WiredTigerKVEngine16haltOplogManagerEv.cold.1904","s+":"18"},{"a":"55C918B0711C","b":"55C917AE3000","o":"102411C","s":"_ZN5mongo21WiredTigerRecordStoreD1Ev","s+":"2FC"},{"a":"55C918B0D68B","b":"55C917AE3000","o":"102A68B","s":"_ZN5mongo29StandardWiredTigerRecordStoreD0Ev","s+":"1B"},{"a":"55C9186CEC5B","b":"55C917AE3000","o":"BEBC5B","s":"_ZN5mongo18WiredTigerKVEngine21getGroupedRecordStoreEPNS_16OperationContextENS_10StringDataES3_RKNS_17CollectionOptionsENS_8KVPrefixE.cold.1921","s+":"57"},{"a":"55C919378A76","b":"55C917AE3000","o":"1895A76","s":"_ZN5mongo17StorageEngineImpl15_initCollectionEPNS_16OperationContextENS_8RecordIdERKNS_15NamespaceStringEb","s+":"316"},{"a":"55C91937A7BD","b":"55C917AE3000","o":"18977BD","s":"_ZN5mongo17StorageEngineImpl11loadCatalogEPNS_16OperationContextE","s+":"90D"},{"a":"55C91937E3D0","b":"55C917AE3000","o":"189B3D0","s":"_ZN5mongo17StorageEngineImplC1EPNS_8KVEngineENS_20StorageEngineOptionsE","s+":"270"},{"a":"55C918AC8005","b":"55C917AE3000","o":"FE5005","s":"_ZNK5mongo12_GLOBAL__N_117WiredTigerFactory6createERKNS_19StorageGlobalParamsEPKNS_21StorageEngineLockFileE","s+":"1A5"},{"a":"55C9193889EE","b":"55C917AE3000","o":"18A59EE","s":"_ZN5mongo23initializeStorageEngineEPNS_14ServiceContextENS_22StorageEngineInitFlagsE","s+":"4CE"},{"a":"55C918A84587","b":"55C917AE3000","o":"FA1587","s":"_ZN5mongo12_GLOBAL__N_114_initAndListenEPNS_14ServiceContextEi.isra.1409","s+":"3F7"},{"a":"55C918A88610","b":"55C917AE3000","o":"FA5610","s":"_ZN5mongo12_GLOBAL__N_111mongoDbMainEiPPcS2_","s+":"650"},{"a":"55C9189F7849","b":"55C917AE3000","o":"F14849","s":"main","s+":"9"},{"a":"7FAF1FC772E1","b":"7FAF1FC57000","o":"202E1","s":"__libc_start_main","s+":"F1"},{"a":"55C918A83A3A","b":"55C917AE3000","o":"FA0A3A","s":"_start","s+":"2A"}],"processInfo":{"mongodbVersion":"4.4.0","gitVersion":"563487e100c4215e2dce98d0af2a6a5a2d67c5cf","compiledModules":[],"uname":{"sysname":"Linux","release":"4.9.0-7-amd64","version":"#1 SMP Debian 4.9.110-3+deb9u2 (2018-08-13)","machine":"x86_64"},"somap":[{"b":"55C917AE3000","elfType":3,"buildId":"D7866CAA7FFAC402345915854064CD98A5B60C27"},{"b":"7FAF1FFF6000","path":"/lib/x86_64-linux-gnu/libpthread.so.0","elfType":3,"buildId":"16D609487BCC4ACBAC29A4EAA2DDA0D2F56211EC"},{"b":"7FAF1FC57000","path":"/lib/x86_64-linux-gnu/libc.so.6","elfType":3,"buildId":"775143E680FF0CD4CD51CCE1CE8CA216E635A1D6"}]}}}}
It appears to boil down to the following error message:
Location13111: field not found, expected type date.
src/mongo/bson/bsonelement.h:810
Googling didn't turn up anything useful. I didn't proceed after that but had to revert to v4.2.9. (I wanted to keep the damage to the config secondary and not get the same issue with the shards.)
I'm on Debian 9.13 and I tried both apt to install MongoDB 4.4.0 and directly installing the Debian 9.2 binaries. The error was the same both times.
Any ideas what to do about this one?
Here is my error. Comes with a stacktrace but guessing this will be good enough. This project worked fine before the patches.
[2020-07-28T10:20:45,262] WARN services.ProjectManagerService - Discovered filesystem project RossNapOISOperations, importing...
[2020-07-28T10:20:45,824] ERROR boot.SpringApplication - Application run failed
grails.validation.ValidationException: Validation Error(s) occurred during save():
Field error in object 'rundeck.Project' on field 'description': rejected value [Build/Deploy/Maintenance on ROSS, NAP, and OIS Projects]; codes [rundeck.Project.description.matches.error.rundeck.Project.description,rundeck.Project.description.matches.error.description,rundeck.Project.description.matches.error.java.lang.String,rundeck.Project.description.matches.error,project.description.matches.error.rundeck.Project.description,project.description.matches.error.description,project.description.matches.error.java.lang.String,project.description.matches.error,rundeck.Project.description.matches.invalid.rundeck.Project.description,rundeck.Project.description.matches.invalid.description,rundeck.Project.description.matches.invalid.java.lang.String,rundeck.Project.description.matches.invalid,project.description.matches.invalid.rundeck.Project.description,project.description.matches.invalid.description,project.description.matches.invalid.java.lang.String,project.description.matches.invalid,matches.invalid.rundeck.Project.description,matches.invalid.description,matches.invalid.java.lang.String,matches.invalid]; arguments [description,class rundeck.Project,Build/Deploy/Maintenance on ROSS, NAP, and OIS Projects,^[a-zA-Z0-9\p{L}\p{M}\s.,()_-]+$]; default message [Property [{0}] of class [{1}] with value [{2}] does not match the required pattern [{3}]]
That's related to how Rundeck 3.3.X interprets the project description after an instance upgrade, a good way to solve it is back to rundeck 3.2.X, edit the projects descriptions without "special characters" and update to Rundeck 3.3.1 again. You can add your issue to this GitHub thread.
I'm trying to run meteor from a checkout following the instructions on the main README: https://github.com/meteor/meteor (under Slow Start.) I'm trying to run the devel branch.
When running normal meteor, it starts up a mongo instance using the database stored in the .meteor directory of the current project. However, the checked out version throws the following error:
W20130729-16:18:46.369(-4)?(STDERR) /home/mao/projects/CrowdMapper/.meteor/local/build/programs/server/boot.js:184
W20130729-16:18:46.370(-4)?(STDERR) }).run();
W20130729-16:18:46.371(-4)?(STDERR) ^
W20130729-16:18:46.393(-4)?(STDERR) Error: MONGO_URL must be set in environment
W20130729-16:18:46.395(-4)?(STDERR) at packages/mongo-livedata/remote_collection_driver.js:32
W20130729-16:18:46.395(-4)?(STDERR) at _.once (packages/underscore/underscore.js:704)
W20130729-16:18:46.396(-4)?(STDERR) at new Meteor.Collection (packages/mongo-livedata/collection.js:65)
W20130729-16:18:46.396(-4)?(STDERR) at packages/service-configuration/service_configuration_common.js:8
W20130729-16:18:46.397(-4)?(STDERR) at packages/service-configuration.js:42:4
W20130729-16:18:46.397(-4)?(STDERR) at packages/service-configuration.js:51:3
W20130729-16:18:46.397(-4)?(STDERR) at mains (/home/mao/projects/CrowdMapper/.meteor/local/build/programs/server/boot.js:153:10)
W20130729-16:18:46.399(-4)?(STDERR) at Array.forEach (native)
W20130729-16:18:46.400(-4)?(STDERR) at Function._.each._.forEach (/home/mao/projects/meteor/dev_bundle/lib/node_modules/underscore/underscore.js:79:11)
W20130729-16:18:46.400(-4)?(STDERR) at /home/mao/projects/CrowdMapper/.meteor/local/build/programs/server/boot.js:80:5
How can I tell this version to use the project-local mongo database and start its own mongo instance as before?
This was caused by a breaking change in the devel branch as documented here:
https://groups.google.com/forum/#!topic/meteor-core/xtTlpFqp4to
This is because Meteor 0.6.5-rc's and later don't automatically include core dependencies that were listed for free before. It can be fixed with
meteor add standard-app-packages
or
meteor run-upgrader app-packages
I am getting a trouble, trying to use CarrierWave for a file upload Rest API developed in Rails 3, with a MongoDB database.
What I would like to do is storing some files (not only images but every file format) with the MongoDB system GridFS.
I read many documentations that recommend my to use the CarrierWave gem.
But I have an error when I try to configure it.
My development environment :
The Gemfile :
source 'https://rubygems.org'
gem 'rails', '3.2.8'
# MongoDB
gem 'mongoid', :git => 'git://github.com/mongoid/mongoid.git'
gem 'carrierwave', :git => "git://github.com/jnicklas/carrierwave.git"
# gem 'carrierwave-mongoid', :require => 'carrierwave/mongoid'
gem 'mini_magick', :git => 'git://github.com/probablycorey/mini_magick.git'
gem 'bson_ext'
gem 'json'
The application.rb :
require File.expand_path('../boot', __FILE__)
# ActiveRecord will not be use with MongoDB
# require 'rails/all'
require "action_controller/railtie"
require "action_mailer/railtie"
require "active_resource/railtie"
require "rails/test_unit/railtie"
require "sprockets/railtie"
require "mongoid/railtie"
require "carrierwave"
# require "carrierwave/mongoid"
I define the database with a mongoid.yml (config/mongoid.yml) file :
development:
sessions:
default:
database: lf_rest_api_development
hosts:
- localhost:27017
options:
consistency: :strong
options:
test:
sessions:
default:
database: lf_rest_api_test
hosts:
- localhost:27017
options:
consistency: :strong
And load it with an initializer (config/initializers/mongoid.rb) :
Mongoid.load!("config/mongoid.yml")
-- I can execute the "rails server" command without problems after the last file, config/initializers/carrierwave.rb :
CarrierWave.configure do |config|
config.grid_fs_database = Mongoid.database.name
config.grid_fs_host = Mongoid.config.master.connection.host
config.storage = :grid_fs
config.grid_fs_access_url = "/files"
end
And then get the following error when I run the "rails server" command :
=> Booting WEBrick
=> Rails 3.2.8 application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
Exiting
/{API_path}/config/initializers/zcarrierwave.rb:4:in `block in <top (required)>': undefined method `database' for Mongoid:Module (NoMethodError)
[...]
My file model is defined as following :
require 'carrierwave/orm/mongoid'
class File
include Mongoid::Document
store_in_collection: "files", database: "lf_rest_api_developement", session: "default"
key :filename, type: String
key :content_type, type: String
key :length, type: BigDecimal
key :chunk_size, type: Integer, :default => 256
key :upload_date, type: DateTime
key :md5, type: String
key :metadata, type: Array, :default => []
mount_uploader :file, FileUploader
index({ location: "2d" }, { min: -200, max: 200 })
end
The FileUploader is just an extension of CarrierWave uploader...
class FileUploader < CarrierWave::Uploader::Base
storage :grid_fs
end
Sorry about the slow response. Firstly, the reason for your error is that Mongoid 3 no longer supports Mongoid.database. You can now find these configurations in the Mongoid::Config.sessions[:default] object.
BUT THIS AIN'T GONNA FIX YOUR PROBLEM! Mongoid 3 has no GridFS support at all. From mongoid docs:
No GridFS Support
GridFS is marketed as a core database feature, when in fact it is not. It is simply a pattern for storing chunked file data as documents in a collection, just like any other document. The implementation of this behaviour is handled in the client drivers, not in the core database itself, which can lead to discrepencies in how this is handled across > platforms.
Even if having this behaviour in the client is acceptable, the effects of this on application performance where you are not just storing file data is quite large. Since files are stored as documents, they consume RAM just as any other document in the database would, and can easily cause memory consumption on your server to max out. There are also limitations in chunking the data, such as you do not have the ability to update a file - you must delete the file and replace it with a new one.
Given this, we did not prioritize any work with GridFS at the front, but there is a gem in the pipeline for those who can wait a bit to upgrade. In the meantime you have a few options...
So rather than seek other ways to store uploads in the GridFS at the expense of performance, I would suggest just throwing them in a SQL database. If your using Mongo as your only database, don't be put off by this option. It's not very difficult to get ActiveRecord and Mongoid working together side-by-side. But from my experience, uploading binary objects to any database may not perform well. I would personally use a filesystem for storage, with carrierwave or paperclip taking care of the management. Alternatively, I would suggest checking out some cheap cloud storage options. You can use something like aws-s3, a great service. It also has very well documented compatibility with Carrierwave.
If you are determined to use GridFS, I would check out the mongoid-grid_fs gem or check out some alternative ruby MongoDB drivers on the 10gen website.
This is my first time answering a question so I hope I'm doing this right.
I was struggling with the same issue uploading an image using carrier wave in my rails application with Mongoid 3. I believe I have a solution (at least got it working locally on my laptop.) Here is what I came up with:
Add carrierwave-mongoid gem to your gemfile with the branch mongoid-3.0. This gem uses mongoid-grid_fs:
# Image Uploading
gem "carrierwave-mongoid", :git => "git://github.com/jnicklas/carrierwave-mongoid.git", :branch => "mongoid-3.0"
Make an initializer for carrier wave:
#config/initializers/carrierwave.rb
CarrierWave.configure do |config|
config.storage = :grid_fs
# Storage access url
config.grid_fs_access_url = "/upload/grid"
end
I know I didn't set config.grid_fs_database or config.grid_fs_host. This seems to work locally (on my laptop) I haven't tried it with a remote gridfs database.
Mounting looks normal:
#app/models/user.rb
class User
include Mongoid::Document
mount_uploader :avatar, AvatarUploader
end
Uploader is also standard:
#app/uploaders/avatar_uploader
class AvatarUploader < CarrierWave::Uploader::Base
include CarrierWave::MiniMagick
def store_dir
"#{model.class.to_s.underscore}/#{mounted_as}/#{model.id}"
end
version :thumb do
process :resize_to_limit => [200, 200]
end
end
Create a controller for GridFS:
#app/controllers/gridfs_controller.rb
class GridfsController < ApplicationController
def serve
gridfs_path = env["PATH_INFO"].gsub("/upload/grid/", "")
begin
gridfs_file = Mongoid::GridFS[gridfs_path]
self.response_body = gridfs_file.data
self.content_type = gridfs_file.content_type
rescue
self.status = :file_not_found
self.content_type = 'text/plain'
self.response_body = ''
end
end
end
and add the route to the routes file:
#config/routes.rb
match "/upload/grid/*path" => "gridfs#serve"
Hope this helps.
When my script fails to parse for any reason, I get a stack trace from the compiler, with no insight at all into where in my script the problem lies:
mpurvis#citadel:~/coffee$ coffee -c Test.coffee
/usr/local/lib/node_modules/coffee-script/lib/command.js:15
return process.binding('stdio').writeError(line + '\n');
^
Error: No such module
at /usr/local/lib/node_modules/coffee-script/lib/command.js:15:20
at /usr/local/lib/node_modules/coffee-script/lib/command.js:167:7
at /usr/local/lib/node_modules/coffee-script/lib/command.js:115:26
at [object Object].<anonymous> (fs.js:108:5)
at [object Object].emit (events.js:64:17)
at afterRead (fs.js:1074:12)
at Object.wrapper [as oncomplete] (fs.js:246:17)
For now, it's just a toy script to try the system out, so I can usually just experiment until it works again, but that would be impossible in a file of any size. Is there some trick I'm not seeing to get the line where the error occurred?
Thanks!
the latest version from node isn't full compatible with cs..the node_stdio module ws removed...a simple way for fix it is open /usr/local/lib/node_modules/coffee-script/lib/command.js and change the line 15
process.binding('stdio').writeError(line + '\n')
for
process.stderr.write(line + '\n')
always you can get more help from github issues section
https://github.com/jashkenas/coffee-script/commit/c77f7737a5d94a05a999109810ea7634f540e1e2
good luck and happy coding
This doesn't look like a syntax issue. The error is coming from command.js, which is what defines the coffee command-line utility. If it were a compiler error, it would be from coffee-script.js.
So why is the process.binding('stdio') bit in command.js failing? There are two possibilities I can think of:
You're using a weird shell (or a weirdly configured one) that doesn't play nice with Node's version of stdio. This seems unlikely, but it's possible...
You're using a version of Node.js that CoffeeScript isn't currently compatible with. What do you get when you do node -v? Your safest bet is the latest 0.4.x, since those are stable releases (0.5.x is experimental).
This question is from awhile back.
Node 0.6.x throws a similar error with CoffeeScript 1.1.x; upgrading to 1.3.x does the trick.
Likely 2 different coffee-scripts on your system. check which coffee, than track down the older one and ice it. I had one from an install last summer (v1.1), it's all cleared up now.