I am keep getting this error message when I run "meteor" on cmd on windows.
Unexpected mongo exit code 100. Restarting.
Unexpected mongo exit code 100. Restarting.
Unexpected mongo exit code 100. Restarting.
Can't start Mongo server.
MongoDB had an unspecified uncaught expection.
This can be caused by MongoDB being unable to write to a local database.
Check that you have permissions to write to .meteor/local. mongoDB does not support filesystems like NFS that do not allow file locking.
This happens right after I downloaded meteor and created my first project. I already tried resetting the project. I saw people recommend removing the lock file in db folder. However, when I check .meteor/local/db, its empty.
Try to reset Meteor.
-Meteor reset
-Meteor
Update Meteor.
-meteor update --release 1.4.0.1
Your username could be the problem.
In my case, it works fine when I moved the project's folder to other user's folder.
Check that you have permissions to write to .meteor/local. mongoDB does not support filesystems like NFS that do not allow file locking.
This is probably your problem.
If you use GitHub for your project, I'd strongly recommend you clone your project from GitHub into your Documents directory, and try running meteor again from there.
Don't copy your existing folder to Documents, because you'll just copy the existing busted permissions. If you're not familiar with the Windows folder permissions model, you're going to have a bad time dealing with this problem.
Related
A few days ago my shared hosting ISP apparently had server issues and ever since I get jailshell rather than bash when connecting with .ssh.
After three tech troubleshooting sessions, they have not been able to restore my bash capability. They say they get bash if they log in. They seem to keep trying ineffective measures, and provide no details about them.
During the server restart I had tried to log in, and saw the jailshell then. Could that attempted login during server restart have caused this issue?
In any case, advice would be appreciated on how I can get bash back or tell them what to try on their side. Are there useful questions to ask, or things to suggest to them to try to resolve this?
Multiple machines have been used with .ssh with same results. I can FTP into my account (if going to root I see just a few jailshell files; if going directly to folder and then up to root I see all my files; the web serving is not affected).
-Ken
I have an existing spark-job, the functionality of this spark-job is to connect kafka-server get the data and then storing the data into cassandra tables, now this spark-job is running on server inside spark-2.1.1-bin-hadoop2.7/bin but whenever I am trying to run this spark-job from other location, Its not running, this spark-job contains some JavaRDD related code.
Is there any chance, I can run this spark-job from outside also by adding any dependency in pom or something else?
whenever I am trying to run this spark-job from other location, Its not running
spark-job is a custom launcher script for a Spark application, perhaps with some additional command-line options and packages. Open it, review the content and fix the issue.
If it's too hard to figure out what spark-job does and there's no one nearby to help you out, it's likely time to throw it away and replace with the good ol' spark-submit.
Why don't you use it in the first place?!
Read up on spark-submit in Submitting Applications.
Good Day.
I've been developing with meteorJS which uses mongodb. No problems there. I've been using the mongo shell to access the database on my dev machine (osx 10.11). This is my first project with mongo and when the shell would load, it would connect to db.test and I'd always show dbs and get the list of database, then use myApp.
Yesterday whenever I go into the shell and I type show dbs the only one shown is local 0.078GB. However my app is still working and pulling and pushing data to the database.
I've checked the dbpath in the mongod.conf and that seems ok. I'm not entirely sure about the exact order of things, but two things where different (I'm not sure if these happened prior to the show dbs not showing everything or after, and I'm not sure which came first):
when loading the mongo shell I was getting this error:
WARNING: soft rlimits too low. Number of files is 256, should be at least 1000"
I followed these directions which seemed to stop that error from appearing (https://github.com/basho/basho_docs/issues/1402 )
I use Meteor Toys and for the first time I update user.profile.companyName (which is a custom field within the standard profile from within the Meteor Toys widget.
Just odd that the app can still access the database and collections, but that the mongo shell doesn't show. I've update mongod via brew upgrade mongodb from 3.0.2 to 3.0.7 to no avail.
Any ideas?
If you want to use the regular mongo console you have to specify the port to be 3001 for meteor apps instead of the default 27017. Otherwise it's much simpler to just type meteor mongo and connect that way. Then you can type 'show collections' and it will show them all just like normal.
MongoDB do not show the database unless if there is minimum of one collection with a document in it.
Refer to this link
For the past three to four months, we have our application live and running, we haven't deployed any new fixes / changes on Live. However ever unfortunately, we noticed that application has stopped running.
Following is the issue we observed from our logs :
"Can't create/write to file '/var/tmp/#sql_2f6_0.MYI" .
It would be really appreciable if anyone of you can extend your help.
Check the services and the User for which your Mysql is giving you this error. It is very much possible that any of the services might be down, or the User by which you are using the DB is not getting authenticated.
You or the user that handles your SQL service doesn't have permission to /var/tmp/. You can fix this by using chmod or Security permissions, depending on which platform you're on.
A PHP scriptof mine wants to write into a log folder, the resulting error is:
Unable to open the log file "E:\approot\framework\log/dev.log" for writing.
When I set the writing permissions for the WebRole User RD001... manually it works fine.
Now I want to set the folder permissions automatically. Is there an easy way to get it done?
Please note that I'm very new to IIS and the stuff around, I would appreciate precise answers, thx.
Short/Technical Response:
You could probably set permissions on a particular folder using full-trust and a startup taks. However, you'd need to account for a stateless OS and changing drive letters (possible, not likely) in this script, which would make it difficult. Also, local storage is not persisted, so you'd have no way to ensure this data stayed in the case of a reboot.
Recommendation: Don't write local, read below ...
EDIT: Got to thinking about this, and while I still recommend against this, there is a 3rd option: You can allocate local storage in the service config, then access it from PHP using a dll reference, then you will have access to that folder. Please remember local storage is not persisted, so it's gone during a reboot.
Service Config for local:
http://blogs.mscommunity.net/blogs/dadamec/archive/2008/12/11/azure-reading-and-writing-with-localstorage.aspx
Accessing config from php:
http://phpazure.codeplex.com/discussions/64334?ProjectName=phpazure
Long / Detailed Response:
In Azure, you really are encouraged to approach things as a platform and not as "software on a server". What I mean there is that ideas such as "write something to a local log file" are somewhat incompatible with the cloud "idea". Depending on your usage, you could (and should) convert this script to output this data to some cloud-based or external storage, vs just placing it on the disk.
I would suggest modifying this script to leverage the PHP Azure SDK and write these log entries out to table or blob storage in Azure. If this sounds good, please provide the PHP and I can give an exact example.
The main reason for that (besides pushing the cloud idea) is that in Azure, you cannot assume the host machine ("role instance") will maintain an OS state, so while you can set some things such as folder permissions, you can't rely on them sticking that way. You have no real way to guarantee those permissions won't be reset when the fabric has to update your role and react to some lower level problem. For example, a hard-drive cage on the rack where your current instance lives could fail. If the failure were bad enough, the Fabric controller would need to rebuild your instance. When that happens, your code is moved to an entirely different server, so the need would arise to re-set those permissions. Also, depending on the changes, the E:\ could all of a sudden need to be the F:\ or X:\ drive and you wouldn't know.
Its much better to pretend (at some level) that your application is running "in Azure" and not "on a server in azure", so you make no assumptions about the hosting environment. So anything you need outside of your code (data, logs, audits, etc) should be stored somewhere you can control (Azure Storage, external call-out, etc)