Maintenance Procedure for a Laravel Forge Instance
October 3, 2019
I've been using Laravel Forge for over a year at my day job, but also to provision and deploy my side project 1Secret.app. To me, the biggest benefit that Forge brings is the ability to easily and quickly provision Laravel-ready server instances, whether on AWS, DigitalOcean, Linode or others.
My server OS of choice is Ubuntu, and Forge has been doing some sort of magic to keep it updated to the latest version. This means I'm currently running 18.04 on multiple instances. This is all good, however there's still some maintenance that I need to perform manually from time to time, namely OS security patch and package updates. I also like to keep an eye on disk space and clear some of that if necessary.
If, when you SSH into your Forge instance, you see a message like below...
14 packages can be updated. 1 update is a security update. *** System restart required *** Last login: Sun Sep 8 22:09:04 2019 from xxx.xxx.xxx.xxx
... that means it's probably time to update those packages. Here's my procedure for doing that, bearing in mind that I'm not a sysadmin, and everything you read below was cobbled together from various sources but works 👍 for me.
SSH into the instance
In my case, 1Secret.app is served from
220.127.116.11 so my command will be (
id_rsa is my private SSH key):
ssh firstname.lastname@example.org -i ~/.ssh/id_rsa
Check and reclaim disk space
The file system can easily fill up with stuff like uploaded files, logs, database, etc. First I like to see an overview of the total disk usage.
df -h Filesystem Size Used Avail Use% Mounted on udev 985M 0 985M 0% /dev tmpfs 200M 816K 199M 1% /run /dev/xvda1 20G 7.1G 13G 37% / tmpfs 996M 0 996M 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 996M 0 996M 0% /sys/fs/cgroup /dev/loop0 18M 18M 0 100% /snap/amazon-ssm-agent/1068 /dev/loop2 18M 18M 0 100% /snap/amazon-ssm-agent/930 /dev/loop4 18M 18M 0 100% /snap/amazon-ssm-agent/1335 /dev/loop1 89M 89M 0 100% /snap/core/7169 /dev/loop5 89M 89M 0 100% /snap/core/7270 tmpfs 200M 0 200M 0% /run/user/1001
In this example, the important line is
/dev/xvda1 20G 7.1G 13G 37% / because that is my primary disk. Here, it is 37% full out of a total of 20 GB, which is good.
Laravel apps store stuff and things in
myapp/storage. If you find a lot of disk space is consumed by the storage folder, refering to my Useful Linux Commands article, you can run something like this to check which subfolder takes the most space:
du -ch -d 1 | sort -hr 760K total 760K . 704K ./framework 28K ./logs 16K ./app 8.0K ./debugbar
In this example there's almost no space used. Let's move on.
Another place where a lot of storage can potentially be used is the system journal. This is a where Linux stores a lot of logging data, for example system events and such. It tends to grow in size over time. Depending how important this data is to you, you can choose to delete some or all of it, or restrict how much space it can use.
Here's how I would check how much space the system journal uses on my Ubuntu 18.04 instances:
du -ach /var/log/journal/ | sort -hr 1.8G total 1.8G /var/log/journal/1302ef9b7d514d588b562228feb06a4c 1.8G /var/log/journal/ 81M /email@example.com 81M /firstname.lastname@example.org ... 41M /var/log/journal/1302ef9b7d514d588b562228feb06a4c/system.journal 8.1M /email@example.com ... 8.0M /var/log/journal/1302ef9b7d514d588b562228feb06a4c/user-1001.journal 8.0M /var/log/journal/1302ef9b7d514d588b562228feb06a4c/user-1000.journal
1.8 GB may not seem much, but when your entire instance is 20 GB, that's actually quite significant.
Clear journal entries manually
To recover disk space, journal entries can be cleared manually in a couple ways.
Retain only the past two days:
sudo journalctl --vacuum-time=2d
Retain only the past 500 MB:
sudo journalctl --vacuum-size=500MB
Restrict max journal size
The journal size can be restricted through the configuration.
sudo vi /etc/systemd/journald.conf
SystemMaxUse=500M to restrict it to 500M.
systemd-journald service (see this for more details):
sudo systemctl restart systemd-journald
CAUTION Working with AWS instances, as well as S3, I found lots of
linux-aws-headers-* files in
/usr/src/. Based on my research, these should be safe to delete, which I did without negative consequences, but you should be extra careful just in case I'm wrong.
To clear the AWS-specific files out of
/usr/src/, run this command:
sudo apt-get purge linux-aws-headers-4.15.0
Update system packages
Finally we're ready to update the system packages. The commands below can be run in sequence to upgrade all the packages. You can skip the
list commands if you wish, those are just to give you an overview of what packages there are.
You may see a prompt asking if you want to upgrade certain packages or configurations. That's where you need to be extra careful because it may overwrite your custom configurations. In my case, I usually get two prompts, for Redis and php.ini.
N (keep the local version currently installed)
# updates available list of packages & versions sudo apt update # lists the installed packages sudo apt list --installed # lists the packages that can be upgraded sudo apt list --upgradeable # actually perform the packages sudo apt upgrade # removes packages that are no longer required sudo apt autoremove
Finally, reboot the server.
Check if services are running
Once the system has rebooted, SSH back into it. You should be greeted with this shiny new message:
0 packages can be updated. 0 updates are security updates.
Now check if your vital services are running. In my case there are only 3 I care about:
systemctl status systemd-journald supervisor redis
If these are green (
Active: active (running)), you are good to go.
This concludes my maintenance procedure for Laravel Forge provisioned servers. I will update these instructions as I see fit, but in the meantime keep on forging ahead!Laravel Forge