I have searched the community questions before posting this and tried the suggestions to no avail.
I am confused as to why my cron jobs in my ec2 are not getting triggered.
I ran the following in my ec2:
sudo service crond start
sudo crontab -e
Here I added the following:
30 7 * * * root /usr/bin/python3 /home/ec2-user/hello-world.py
The python script creates a file on running. The job is not running as scheduled.
Please suggest me what I am missing here.
Related
I am trying to execute drush commands through a crontab for a Drupal 8 site. These commands work when I call them directly, but when run through my user's crontab I get the following error:
\Drupal::$container is not initialized yet. \Drupal::setContainer() must be
called with a real container.
Other posts suggest this is a bug within older versions of Drush, but I am on 10.3.5.
I have tried a number of things over the past few hours including reconfiguring cron, but ultimately it seems Drush is not bootstrapping Drupal correctly, but I need to be able to run the queue from cron
This is a test command I'm running which just adds to the Drupal log...
crontab (my user)
* * * * * /var/www/html/vendor/bin/drush scr /var/www/html/scripts/what.php -r /var/www/html/web
what.php
<?php
\Drupal::logger('mymod')->info("CHECKING IN FROM CRON CLI...");
Here is another command, closer to what I'm trying to accomplish...
crontab (my user)
* * * * * /var/www/html/vendor/bin/drush queue:run commerce_recurring -r /var/www/html/web >> /var/www/html/private/logs/cron_commerce_recurring.log
The error I get here is:
Command queue:run was not found. Drush was unable to query the database. As
a result, many commands are unavailable. Re-run your command with --debug
to see relevant log messages.
I get this same error when running this command with drupal console.
Any suggestions appreciated.
Thanks.
This turned out to be a database connectivity issue. The tricky part was getting to the error. I had to install an MTA, so that cron could write errors to my local user's mailbox and then add the --debug option, so that I could see the real error.
I'm working on a DDEV instance and for some reason the DDEV settings were not being loaded. An issue for another day...
TL;DR The command npm run build is taking forever to run on the Amazon EC2 [Ubuntu] instance when I tried running it explicitly by making an SSH. Meanwhile, when I try to create a deployment using CodeDeploy, the deployment takes a good 1 hour time and succeeds but the build folder doesn't get populated, hence I am unable to view my website on the public URL of the EC2 instance. Also, the instance reachability check fails every time after I try to run the command explicitly, and then I have to start and then stop the ec2 instance again! Woof!
Hello everyone, I am trying to deploy my MERN Stack application to AWS but I am stuck now!
Current Progress:
Added both Nginx configs.[Attaching image below]
Nginx is running and there is no problem there!
Added build-app.sh in appspec.yml in the root directory. [View code below]
#!/bin/bash
#clear build directory
cd /home/ubuntu/badlav-app/badlav-client
sudo rm -rf build
sudo mkdir build
#client (Generates a new `build` directory)
cd /home/ubuntu/badlav-app/badlav-client
sudo sh set-prod-env-aws.sh
sudo rm -rf node_modules
sudo npm i
sudo npm run build
#server
cd /home/ubuntu/badlav-app/badlav-server
sudo sh set-prod-env.sh
#back to root
cd /home/ubuntu
appspec.yml
version: 0.0
os: linux
files:
- source: /
destination: /home/ubuntu/badlav-app
hooks:
BeforeInstall:
- location: scripts/build-app.sh
runas: root
Using the above appspec.yml file, the deployment using CodeDeploy succeeds but didn't populate the build folder within /home/badlav-app/badlav-client/build.
So I tried to debug on my own and started running the commands one by one by myself after SSH(ing :P) into the EC2 instance. But when I reach npm run build, the instance just hangs forever. After being exhausted, I have no option left, I terminate the task. Now, when I view my instance on the AWS Console, it has gone berserk! The instance reachability check fails! The only way, I get my instance back is by stopping it and starting it again.
Since I am new to CI/CD, please don't judge my appspec.yml. It'd be great if anyone of you could suggest a better way, thanks for that! :)
To sum up, I want to be able to create a deployment using AWS CodeDeploy, but due to this npm run build taking so much time and hanging my server(instance reach check fails!), I am unable to do so. Moreover, I am not even sure whether npm run build is a problem at all!
I would be more than happy to share any further details/screenshots in order to support my question. Please ask over.
Thanks in advance!
/etc/nginx/nginx.conf/etc/nginx/conf.d/default.conf
If you're using EC2 free tier, the chance is that the instance may have low spec and memory (t2.nano has 0.5G and t2.micro has 1G of memory).
Maybe npm run build consumes all of the memory space.
I often face the same problem with my vue project.
Solution: Do NOT use free tier for medium and large projects. Upgrade your plan and use better instances e.g. t2.medium
Whenever an AWS autoscaling group launches new ubuntu instance and I try to install any package on that instance it gives me the following error:
[stderr]E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable)
[stderr]E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend),
Is there another process using it?
I tried to find a solution and manually fixed it but I don't know why whenever the autoscaling group launches a new ubuntu instance it gives the following error.
When any command updates the Ubuntu or installs a new application, it locks the dpkg(Debian Package Manager).
To identify the problem, please look at the logs
If your system is installing some updates you may find journalctl logs journalctl -u apt-daily.service. This usually happend when the system is set to update itslef and you will notice such activity with this ps -ef | grep apt.systemd.daily and you can check these setting in the file /etc/apt/apt.conf.d/20auto-upgrades
/var/log/dpkg.log*(as it may get rotated) check these logs to find which all services were trying to get installed
Once you have identified the problem, you can solve with these methods:
If system is updating, then try to wait by executing sleep command in the --user-dataof your bootstrapping script
If your 1st installation of an service/application is blocking other one, then put a condition to wait/sleep until the first service is up and so on with rest of the services you are installing.
This was a common problem in Ubuntu 16.04 LTS as per, and you can find the same with the solution code https://forums.aws.amazon.com/thread.jspa?threadID=251663
A snippet of code from the referenced link:
until service codedeploy-agent status >/dev/null 2>&1; do
sleep 60
rm -f install
wget https://aws-codedeploy-us-west-2.s3.amazonaws.com/latest/install
chmod +x ./install
sudo ./install auto
service codedeploy-agent restart
done
SSH into the instance before/while the UserData is running and check which process has acquired the lock:
$ lsof /var/lib/dpkg/lock-frontend
Also, try to enable CodeDeploy agent at the last step after performing all other steps in UserData, like:
https://gist.github.com/say8425/8344d19911dba20fab5538b85006bd31
I would like to know how create a cron with AWS elastic beanstalk and laravel task scheduling.
Currently AWS elastic beanstalk propose to create a cron.yaml file but this file take in paramters only the url. However laravel need to execute a command. I don't know how to do it.
Can you help me please ?
Having done lots of googling, I don't think AWS EB supports executing the schedule:run command directly from app. Instead, the command will have to be triggered from an endpoint just as explained in the docs here.
I found a package here which helped me setup the endpoint easily
Hope it helps...
Getting Laravel Scheduled tasks working is a lot simpler if you just do this:
sudo vi /etc/crontab
and add the line to the bottom of the file:
* * * * * webapp cd /var/www/html/<yourAppFolder>/ && php artisan schedule:run >> /dev/null 2>&1
Done!
I'm on an AWS server. I wrote a crontab and placed it on the server under /etc/cron.d. The contents of the crontab are the following:
SHELL=/bin/bash
PATH=/sbin:/bin:usr/sbin:/usr/bin
MAILTO=root
HOME=/
*/5 * * * * root <full-path-to-write-command> >> <full-path-to-txt-output-file>
After running sudo service crond restart, I check the logs by doing sudo tail -f /var/log/cron.
I can observe the cronjob in the logs:
<date-time-stamp> ip-<ip-address> CROND[12930]: (root) CMD (<full-path-to-write-command> >> <full-path-to-txt-output-file>)
However, when I check the <full-path-to-txt-output-file>, I don't see file being written to.
What could be the problem, if I see that the cronjob is executing? Thanks