Memory issue with meteor up (mup) on Digital Ocean - meteor

I couldn't find existing posts related to my issue. On a Digital Ocean Droplet, mup setup went fine, but when I try to deploy, I get the following error. Any ideas? Thanks!
root#ts:~/ts-deploy# mup deploy
Meteor Up: Production Quality Meteor Deployments
Building Started: /root/TS/
Bundling Error: code=137, error:
-------------------STDOUT-------------------
Figuring out the best package versions to use. This may take a moment.
-------------------STDERR-------------------
bash: line 1: 31217 Killed meteor build --directory /tmp/dc37af3e-eca0-4a19-bf1a-d6d38bb8f517
Below are the logs. node -v indicates I am using 0.10.31. How do I check which script is exiting with the error? Any other ideas? Thanks!
error: Forever detected script exited with code: 1
error: Script restart attempt #106
Meteor requires Node v0.10.29 or later.
error: Forever detected script exited with code: 1
error: Script restart attempt #107
Meteor requires Node v0.10.29 or later.
error: Forever detected script exited with code: 1
error: Script restart attempt #108
stepping down to gid: meteoruser
stepping down to uid: meteoruser
After I went back to an old backup of the DO Droplet, and re-ran mup setup and mup deploy, I now get this in the command line output
Building Started: /root/TS
Bundling Error: code=134, error:
-------------------STDOUT-------------------
Figuring out the best package versions to use. This may take a moment.
-------------------STDERR-------------------
FATAL ERROR: JS Allocation failed - process out of memory
bash: line 1: 1724 Aborted (core dumped) meteor build --directory /tmp/bfdbcb45-9c61-435f-9875-3fb304358996
and this in the logs:
>> stepping down to gid: meteoruser
>> stepping down to uid: meteoruser
Exception while invoking method 'login' TypeError: Cannot read property '0' of undefined
at ServiceConfiguration.configurations.remove.service (app/server/accounts.js:7:26)
at Object.Accounts.insertUserDoc (packages/accounts-base/accounts_server.js:1024)
at Object.Accounts.updateOrCreateUserFromExternalService (packages/accounts-base/accounts_server.js:1189)
at Package (packages/accounts-oauth/oauth_server.js:45)
at packages/accounts-base/accounts_server.js:383
at tryLoginMethod (packages/accounts-base/accounts_server.js:186)
at runLoginHandlers (packages/accounts-base/accounts_server.js:380)
at Meteor.methods.login (packages/accounts-base/accounts_server.js:434)
at maybeAuditArgumentChecks (packages/ddp/livedata_server.js:1594)
at packages/ddp/livedata_server.js:648
Exception while invoking method 'login' TypeError: Cannot read property '0' of undefined
at ServiceConfiguration.configurations.remove.service (app/server/accounts.js:7:26)
at Object.Accounts.insertUserDoc (packages/accounts-base/accounts_server.js:1024)
at Object.Accounts.updateOrCreateUserFromExternalService (packages/accounts-base/accounts_server.js:1189)
at Package (packages/accounts-oauth/oauth_server.js:45)
at packages/accounts-base/accounts_server.js:383
at tryLoginMethod (packages/accounts-base/accounts_server.js:186)
at runLoginHandlers (packages/accounts-base/accounts_server.js:380)
at Meteor.methods.login (packages/accounts-base/accounts_server.js:434)
at maybeAuditArgumentChecks (packages/ddp/livedata_server.js:1594)
at packages/ddp/livedata_server.js:648

The memory issue stems from using DigitalOcean's $5 Droplet. To solve the problem, I added swap to the server, as explained in detail below.
Create and enable the swap file using the dd command :
sudo dd if=/dev/zero of=/swapfile bs=1024 count=256k
“of=/swapfile” designates the file’s name. In this case the name is swapfile.
Next prepare the swap file by creating a linux swap area:
sudo mkswap /swapfile
The results display:
Setting up swapspace version 1, size = 262140 KiB
no label, UUID=103c4545-5fc5-47f3-a8b3-dfbdb64fd7eb
Finish up by activating the swap file:
sudo swapon /swapfile
You will then be able to see the new swap file when you view the swap summary.
swapon -s
Filename Type Size Used Priority
/swapfile file 262140 0 -1
This file will last on the virtual private server until the machine reboots. You can ensure that the swap is permanent by adding it to the fstab file.
Open up the file:
sudo nano /etc/fstab
Paste in the following line:
/swapfile none swap sw 0 0
Swappiness in the file should be set to 10. Skipping this step may cause both poor performance, whereas setting it to 10 will cause swap to act as an emergency buffer, preventing out-of-memory crashes.
You can do this with the following commands:
echo 10 | sudo tee /proc/sys/vm/swappiness
echo vm.swappiness = 10 | sudo tee -a /etc/sysctl.conf
To prevent the file from being world-readable, you should set up the correct permissions on the swap file:
sudo chown root:root /swapfile
sudo chmod 0600 /swapfile

This only worked for me by increasing the swap space to 1gb:
Make all swap off
sudo swapoff -a
Resize the swapfile
sudo dd if=/dev/zero of=/swapfile bs=1M count=1024
Make swapfile usable
sudo mkswap /swapfile
Make swapon again
sudo swapon /swapfile

Related

Permission issues with external ntfs HDD, gitlab-ctl reconfigure changing permissions: "Operation not permitted"

I'm using gitlab on a rasberry pi model 3 B. Following some information about my setup (sudo gitlab-rake gitlab:env:info):
System information
System: Raspbian 8.0
Current User: git
Using RVM: no
Ruby Version: 2.3.6p384
Gem Version: 2.6.13
Bundler Version:1.13.7
Rake Version: 12.3.0
Redis Version: 3.2.11
Git Version: 2.14.3
Sidekiq Version:5.0.5
Go Version: go1.3.3 linux/arm
GitLab information
Version: 10.6.0-rc3
Revision: 52fa89e
Directory: /opt/gitlab/embedded/service/gitlab-rails
DB Adapter: postgresql
URL: http://gitlab.example.com
HTTP Clone URL: http://gitlab.example.com/some-group/some-project.git
SSH Clone URL: git#gitlab.example.com:some-group/some-project.git
Using LDAP: no
Using Omniauth: no
GitLab Shell
Version: 6.0.3
Repository storage paths:
- default: /mnt/SeagateExpansion/GitLab/repositories
Hooks: /opt/gitlab/embedded/service/gitlab-shell/hooks
Git: /opt/gitlab/embedded/bin/git
After the gitlab update to version 10.6.0 I need to change the url again but when I do the necessary changes in /etc/gitlab/gitlab.rb and run sudo nano gitlab-ctl reconfigure I get the following error messages:
========================================================================
Error executing action `run` on resource 'ruby_block[directory resource:
/mnt/SeagateExpansion/GitLab]'
========================================================================
and
============================================================================
Error executing action `create` on resource
'storage_directory[/mnt/SeagateExpansion/GitLab]'
============================================================================
The result message says:
There was an error running gitlab-ctl reconfigure:
storage_directory[/mnt/SeagateExpansion/GitLab] (gitlab::gitlab-rails line 42) had an error: Mixlib::ShellOut::ShellCommandFailed: ruby_block[directory resource: /mnt/SeagateExpansion/GitLab] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/package/resources/storage_directory.rb line 33) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
---- Begin output of chmod 00700 /mnt/SeagateExpansion/GitLab ----
STDOUT:
STDERR: chmod: changing permissions of ‘/mnt/SeagateExpansion/GitLab’: Operation not permitted
---- End output of chmod 00700 /mnt/SeagateExpansion/GitLab ----
Ran chmod 00700 /mnt/SeagateExpansion/GitLab returned 1
So the problem seems to be, that the execution of the run and create command on the resource storage (GitLab folder on the external HDD [HDD = SeagateExpansion]) expects the permissions to be 700, right?
According to this errors I tried to change the permission of
the external HDD folder /mnt/SeagateExpansion/GitLab see the ls -l output:
drwxrwxrwx 1 root GitLabUser 0 Jan 4 17:55 GitLab
With the help of this post I tried to change the permission with the command:
sudo find /mnt/SeagateExpansion/GitLab -type d -exec chmod 700 {} \;
to the required permission 700. But the changes don't take affect. I also tried chmod -R 700 /mnt/SeagateExpansion/GitLab and executed the commands as root but the changes don't take effect. Even after restarting the raspberry pi. What am I doing wrong?
I also tried to change the options settings/flag of the HDD in /etc/fstab to user but this doesn't help ether.
I'm thankful for every hint and answer :).
Best regards,
Bredjo
I finally figured it out. The solution is to change the mount settings in the /etc/fstab. Because if you have the wrong options settings (see: https://en.wikipedia.org/wiki/Fstab) you are not able to change the permissions because its a ntfs filesystem.
So my old fstab entry was this:
UUID=FE820568820526AD /mnt/SeagateExpansion ntfs defaults,gid=GitLabUser 0 0
And the new entry is this:
UUID=FE820568820526AD /mnt/SeagateExpansion ntfs-3g permissions 0 0
Note that you need to install ntfs-3g to use it in fstab. And the permissions options only comes with ntfs-3g. See: https://www.tuxera.com/community/ntfs-3g-advanced/ownership-and-permissions/
After this change I executed again:
sudo gitlab-ctl reconfigure
Now the error disappeared and the permission 700 of the folder /mnt/SeagateExpansion/GitLab could be set. I also noticed that the owner of the GitLab folder was also changed to user git after the reconfiguration:
drwx------ 1 git root 0 Jan 4 17:55 GitLab
That's because I don't need the option gid=GitLabUserany more.
Now everything works again :).

Command failed when running ghost start

Fresh install, trying to run ghost start I get the following error:
Debug Information:
OS: Raspbian, v8.0
Node Version: v6.13.0
Ghost-CLI Version: 1.5.2
Environment: production
Command: 'ghost start'
An error occurred.
Message: 'Command failed: /bin/sh -c systemctl is-active ghost_blog-dev
unknown
'
Stack: Error: Command failed: /bin/sh -c systemctl is-active ghost_blog-dev
unknown
at makeError (/usr/lib/node_modules/ghost-cli/node_modules/execa/index.js:169:9)
at module.exports.sync (/usr/lib/node_modules/ghost-cli/node_modules/execa/index.js:338:15)
at handleShell (/usr/lib/node_modules/ghost-cli/node_modules/execa/index.js:116:9)
at Function.module.exports.shellSync (/usr/lib/node_modules/ghost-cli/node_modules/execa/index.js:361:43)
at SystemdProcessManager.isRunning (/usr/lib/node_modules/ghost-cli/extensions/systemd/systemd.js:88:19)
at Instance.running (/usr/lib/node_modules/ghost-cli/lib/instance.js:120:34)
at StartCommand.run (/usr/lib/node_modules/ghost-cli/lib/commands/start.js:28:22)
at precheck.then (/usr/lib/node_modules/ghost-cli/lib/command.js:159:52)
at process._tickCallback (internal/process/next_tick.js:109:7)
at Module.runMain (module.js:613:11)
at run (bootstrap_node.js:387:7)
at startup (bootstrap_node.js:153:9)
at bootstrap_node.js:500:3
Code: 3
If I manually run the command that is says failed it seems to execute without error though I am not sure what it does. I assume it has something to do with checking with nginx if ghost has actually started or not.
Any suggestions would be very helpful! Thank you!
I faced with the same problem. You should add your service file to etc directory also as symbolic link using the following command:
sudo ln -sf /var/www/html/your-blog/system/files/ghost_blog-yourblog.service /etc/systemd/system/ghost_blog-yourblog.service
After adding this, you should execute the following commands:
sudo systemctl stop ghost_blog-yourblog.service
sudo systemctl start ghost_blog-yourblog.service
Then, I hope you'll see 'active' result for is-active command.

composer cannot allocate memory inside container docker

I currently use docker to run my Symfony3. But I get this error when I try to run composer update inside my container (after doing command docker exec -it <name of the bash container>)
[ErrorException]
Proc_open (): fork failed - Can not allocate memory
The composer documentation asks to configure the swap of the machine but I get this error by following the steps of the documentation
/bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024 (OK)
/sbin/mkswap /var/swap.1 (OK)
/sbin/swapon /var/swap.1 (KO) -->
Swapon: /var/swap.1: swapon failed: Operation not permitted
(Even though I'm in root mode)
I finally found the answer to my problem.
You can start by adding space on your virtual machine (default). In my case I switched from 1GB to 2GB.
Then you can, if you wish, launch your container with the option --memory-swap = -1 or a space you have chosen
https://docs.docker.com/engine/admin/resource_constraints/#memory-swap-details
It's OK for me now ;) .

Can't complete the mup setup in Meteor-Up

I have been able to get past #mup setup. I get the following error;
Meteor Up: Production Quality Meteor Deployments
------------------------------------------------
Started TaskList: Setup (linux)
[212.1.213.20] - Installing Node.js
[212.1.213.20] â Installing Node.js: FAILED
-----------------------------------STDERR-----------------------------------
Warning: Permanently added '212.1.213.20' (RSA) to the list of known hosts.
stdin: is not a tty
sudo: sorry, you must have a tty to run sudo
sudo: sorry, you must have a tty to run sudo
sudo: sorry, you must have a tty to run sudo
sudo: sorry, you must have a tty to run sudo
-----------------------------------STDOUT-----------------------------------
----------------------------------------------------------------------------
Completed TaskList: Setup (linux)
I've found a lot about the error stdin: is not a tty but none of them make much sense to me.
Open your /etc/sudoers file, find the line that says Defaults requiretty, and change it to Defaults !requiretty.
This will disable the tty requirement globally.

Baffling Debian installation script: service starts but then quits mysteriously - Why?

I've been struggling with this one for a while and I'm thoroughly baffled.
I have this postinst Debian script that is supposed to start a service once installation (of the service executable) is complete. As best I can tell, the service does start successfully, but it then immediately and mysteriously quits. Restarting the service from the command-line works fine once Synaptic concludes.
I tried writing a dummy package to verify this. The dummy package installs /etc/init/service-dummy.conf and a symbolic link to that file, named /etc/init.d/service-dummy (just like the original service). The contents of service-dummy.conf are the same as service.conf. The dummy starts the service...and then the service keeps on running. So I can't even reproduce my problem!
The postinst script does this:
#!/bin/sh
set -e
case "$1" in
configure)
# (instructions which config, make and install the freshly installed source code)
ldconfig
echo "Install concluded"
if [ -e "/etc/init/service-dummy.conf" ]; then
echo "Starting service-dummy root service" | tee service.log
service service-dummy restart | tee --append service.log
else
echo "service-dummy.conf not installed"
fi
echo "Postinst complete"
;;
*)
echo "postinst called with unknown argument '$1'" >&2
;;
esac
# exit 1 to ensure installer stalls
exit 1
Synaptic displays the log:
...
Starting service-dummy root service
stop: Unknown instance:
service-dummy start/running, process 9207
Postinst complete
dpkg: error processing service-dummy (--configure):
subprocess installed post-installation script returned error exit status 1
...
It's as if upstart needed to be refreshed?
I tried more things and then I did get it to work, sort of: I try starting the service, then abort the script with an exit 1, and when the script runs a second time (postinst, same parameters, so I detect the second run otherwise), I start the service again, and this time it sticks.
A key clue is in the log:
Postinst complete (aborting script)
dpkg: error processing service-dummy (--configure):
subprocess installed post-installation script returned error exit status 1
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
Errors were encountered while processing:
service-dummy
E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install. Trying to recover:
Setting up service-dummy ...
service-dummy postinst configure
Starting service-dummy a second time
stop: Unknown instance:
service-dummy start/running, process 4034
Postinst complete (aborting script recovery attempt)
So I guess my question now becomes:
How do I force ldconfig to not defer its processing?
Found the right clue here: http://lists.debian.org/debian-glibc/2008/07/msg00169.html
Turns out apt-get temporarily prevents use of ldconfig by replacing it with something else. The solution to my problem is to very simply call ldconfig.real instead of ldconfig in the script.

Resources