Forem: Dan Steren

Ubuntu 22.04 Hibernate Using Swap File

Dan Steren — Mon, 25 Nov 2024 05:04:46 +0000

If you're like me, you expect that in 2024 you can close the lid on your laptop and your computer won't be dead when you pick it up the next day. Unfortunately, that's not the case after a default install of Ubuntu. To get this behavior, you need to enable hibernation through a swap partition or file. I've always used a swap file, so this guide will be for a swap file, not a swap partition.

Because I always forget how to set this up, I'm writing a canonical reference for myself and hopefully it helps you as well.

TLDR;

Just follow this guide. If it's confusing then come back here as I might have some helpful insight.

Overview

The way hibernation basically works is that it takes a snapshot of your system and saves it to disk right before shutting down, and then restores your system from that snapshot when you start your computer up again. To do that you need a swap system. So, we need to set that up first.

Setup Swap Area

Check swap setup

Very first we need to see if we even have a swap area. You can check by running this:

swapon --show

My output was:

NAME      TYPE SIZE USED PRIO
/swapfile file   2G   0B   -2

This means we are using a swapfile because it says "/swapfile", not something like "/dev/sdax partition" which would indicate a swap partition. So that's good, but 2GB isn't going to be large enough because it needs to be as big as your memory. So, we need resize the swapfile, or rather, delete the old one and make a new one.

Resize your Swapfile

So to make a new swap file we first turn off swap for all processes (so we're not using it while we go through the process):

sudo swapoff -a

We then remove the current swapfile:

sudo rm /swapfile

We create a new swapfile that is the same size as our memory:

sudo dd if=/dev/zero of=/swapfile bs=1G count=32

My memory is currently 32 GB, but whatever it is you pass it to the count flag.

Note: When looking at the guide in the ubuntu handbook they use a block size (bs) value of 1MiB. When I asked ChatGPT it said the difference only mattered when creating the swapfile and not afterwards. If you have a smaller/older system then using 1MB block size may be easier on your system. You'll just have to multiply your count by 1024 then. But for me the above worked fine so as long as it creates the swap file you're good.

You then need to adjust the permissions so that only the root user can use the swapfile:

sudo chmod 600 /swapfile

Make the file useable as swap:

sudo mkswap /swapfile

Then activate it:

sudo swapon /swapfile

To ensure the swap file is activated on boot we need to have a line with this contents in the /etc/fstab file:

/swapfile none swap sw 0 0

It should already be there though so check the file first. If it isn't there already you can add it with this command:

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Mine was already there so I just skipped this step.

Find the Physical Offset

We then need to find the physical location of the swapfile. We can do so with the following command:

sudo filefrag -v /swapfile | awk '{ if($1=="0:"){ print $4 } }'

This will give a number like 226572288.., you don't want the final .. though, so you'll have to manually grab just the number.

Update the GRUB Configuration

You'll add the resume and resume_offset parameters to your GRUB configuration to tell the system where to resume from when coming out of hibernation.

You'll want to open the GRUB configuration file with an editor (vim, nano, vscode, etc.):

sudo vim /etc/default/grub

We then update that with a line referencing the output of blkid ("/dev/nvme0n1p2") and the physical offset we just found (226572288).

Suspend then Hibernate

Ok, so the secret sauce to make it all come together is to use suspend-then-hibernate rather than suspend. You do this by editing /etc/systemd/logind.conf.

sudo nano /etc/systemd/logind.conf

Find the lines starting with HandleLidSwitch and HandleLidSwitchExternalPower in the file. If they don't exist, you can add them. Change or add these lines to specify suspend-then-hibernate:

HandleLidSwitch=suspend-then-hibernate
HandleLidSwitchExternalPower=suspend-then-hibernate

Next, you need to specify the delay before transitioning from suspend to hibernate. This is done by creating or editing a file in /etc/systemd/sleep.conf or overriding the default configuration by creating a file in /etc/systemd/sleep.conf.d/.

For example, to set a 30-minute delay, create or edit /etc/systemd/sleep.conf:

sudo nano /etc/systemd/sleep.conf

[Sleep]
HibernateDelaySec=1800s

Then, all you should need to do is restart your computer to restart the systemd-logind service.

Epilogue

Someone should really automate this whole process. I may get to it one day. Ideally it would be checked into my .dotfiles so I can just have it setup automatically when I get a new linux box. This may be a fun project for you if you're feeling ambitious. I'd love to see what you come up with!

Resources

Adding Postgres to a Node app on DO's App Platform

Dan Steren — Sun, 20 Dec 2020 07:20:49 +0000

Source code available at https://github.com/ardentink/adr-api

Backstory

I'm participating in Digital Ocean's App Platform (DOAP) Hackathon and am building a graphQL server using:

node
postgres
typescript
graphql
apollo-server
type-graphql
type-orm

In my last two posts I mostly rambled 😬 but talked about getting a basic node server deployed on DOAP. However it was just the graphQL server without a database. Today I need to add a persistence layer. I'll be using TypeORM and Postgres.

I created a PR for all my changes in the hopes that you could see exactly where my code was before and after this process. I actually ran into some issues with the deploy after committing though so it might be easier to look at this diff instead.

The main steps were:

Install Postgres locally
Add TypeORM and DB migrations
Create a Postgres component in DOAP
Add a Job component in DOAP to run migrations

Get Postgres working locally

There are a couple ways to get Postgres working locally including installing it directly on my machine. My company uses Docker though and I know that will make things easier in the long run so I'm going to do that instead.

I'm using a mac (thanks SimpleNexus) so the best way to do this is to install the docker desktop app. You can download it directly from https://www.docker.com/products/docker-desktop, or through Homebrew with brew cask install docker. Then start it up with open -a Docker.

Once Docker is running we need to start up our DB container. By looking at the dockerhub page for Postgres we find that the DB name, username, and password can all be set with environment variables. To do that we create a .env file and set the necessary variables there.

Then we can use docker-compose to pass all those variables to docker run: docker-compose up -d {your container_name here}.

And just like that we have Postgres running on our local machine.

Installing TypeORM

Getting TypeORM working locally was pretty straightforward. I mostly just followed the guide on their website. I did hit some "gotchas" though so that's what I'll highlight here.

Because I'm using typescript the ormconfig.json file didn't work for me. There is a whole page on their site dedicated to using different configuration sources. I ended using a typeorm.js file. This allowed me to change my folder locations dynamically based on my my environment.

I don't know if it was how I'm using ts-node to run my files, but basically I wanted my local cli to run the typescript migrations in the src folder and production to run the compiled js migrations in my dist folder. That way I didn't have to run my build step every time I wanted to migrate my local db.

The other gotcha was that if you want UUIDs to be generated by the DB you need to add in the uuid-ossp extension. This just requires creating a DB migration with the following SQL statement: CREATE EXTENSION IF NOT EXISTS "uuid-ossp";.

After that I updated my model with the entity and column tags, to connect it to my db. Then I ran my migrations and fired things up and everything worked.

Adding Postgres to DOAP

Very first we need to create a Postgres component:

After selecting your tier and clicking "Create and Attach" DOAP will start provisioning your DB. Once it's fully provisioned DOAP shows you the connection credentials:

We need to get those connection details to our main app now as environment variables. Now you may be tempted to type these out, but DOAP actually has a neat concept called bindable variables. These allow you to references variables in other DOAP components without typing raw strings:

And with those all entered we should be good to deploy all our new code!

Chances are though that at this point you will get an error when your new code rolls out. Why? The database doesn't know about our models because we haven't run the migrations on our server.

Create a Migration Runner

Well that's an easy fix. We just create a Job component and tell it to run the database migrations before each deploy. You can run migrations in TypeORM with the provided command: typeorm migration:run. I ended up adding this as the "migrate" script in my package.json. Then I had my new Job component use npm run migrate as my run command.

And after the container re-builds with those changes... more errors 😢:

🤦🏻‍♂️ I forgot to add all my environment variables to the new container. Once again, this was quickly resolved by adding those.

And... we hit one last error:

This time it was complaining about a self-signed certificate. This actually took a little bit of googling to figure out but in the end I ended up on looking at these two issues:

I'm still not sure if my fix is ok in production or not, but I ended up telling it to not warn about self-signed certs by setting rejectUnauthorized to false in my ormconfig.js:

Conclusion

All in all, adding Posgres and TypeORM was a pretty straightforward process. Definitely better than writing a complex docker-compose or Kubernetes yaml file. I did hit a few more errors than I expected but nothing too bad. Hopefully though this will help you get past any errors you encounter. Good luck!

DOAP Day 2

Dan Steren — Thu, 17 Dec 2020 06:36:42 +0000

I ended my first post saying I couldn't get my backend to build due to using an old codebase as a starting point. I actually kept working for a little bit after I posted though and ended up getting things working! Something super weird was going on with my imports that I still can't figure out... (smh)... but I've got a workaround that's good enough for now.

Initial Deploy to DOAP

So day 2. Now that I have a basic node backend that can actually build, I was able to deploy it in DOAP. I got a little hung up on the env variables and http port. I use the APP_PORT environment variable in my node server to choose where to host the app, so I wasn't entirely sure if it was supposed to be different than the HTTP Port setting or not. I ended up setting both to 8080 and that did the trick.

The actual build process ended up taking about 10 minutes after clicking "Launch Basic App". I think something went wrong during my first attempt because I waited like 15 minutes and it stayed at 17% and never showed any logs. I ended up deleting my app and starting over. Second time only took 10 minutes though and everything worked nice and smoothly!

So there isn't much to look at, but my server is now up and running at: https://adr-api-jp4aj.ondigitalocean.app/

Setting up Apollo Studio

Ever since Graphql Summit 2020 I've been looking forward to using Apollo Studio and I thought this would be a good time to try it out. So I created an account, selected a deployed schema, and was happy to see that hooking things up was as simple as setting 3 environment variables. Once I added those in DOAP it re-deployed my backend and voila, my schema appeared in apollo studio!

There's a bunch of panes where it wants me to upgrade to a paid plan, but at it's free tier it looks pretty great. I especially love the way you can build queries by just clicking on fields/subfields and slowly building out your query that way. Don't get me wrong, graphiQL and graphQL playground are ok, but I could see where it's easier to click buttons than waiting on an autocomplete and having to know specific field names. I'm looking forward to giving it a try on this project.

Next Steps

Technical Steps

I think the next hurdle will be to add type-orm to my project and get things working with a DO managed DB. Last time I tried to do a backend I ended up diving into docker, docker-compose and kubernetes. That was certainly a learning experience but I ended up burning myself out trying to figure it all out. Hopefully setting up a managed DB is easier.
The other part I need to tackle is building a simple frontend and getting it hosted in DOAP as well. I could add express to my backend and serve my frontend from there. I think instead though I'm going to just create a new repo and serve my site statically.

Design Steps

I need to put together a good list of user stories. I have some rough ideas of how things will work but I think making sure I have the main features is important. I'll probably draw a lot from https://adr.github.io/.
I was reading through @yvesnrb's post and I really liked that he created Figma mockups before he really dove into the code. I need to do the same thing before I start really building the UI.
I should probably lay out some basic routes, auth flow, etc. I'm kinda just winging things here.

DOAP Day 1

Dan Steren — Wed, 16 Dec 2020 08:12:01 +0000

First time on Dev.to here so be patient with me. I'm gonna try participating in Digital Ocean's App Platform Hackathon (Which I'll be abbreviating as DOAP from now on) and wanted to document my journey.

My Project

I think my goal for this is to build a platform for either storing/managing Architectural Decision Records or something to do with making municipal code more accessible to constituents. So I'm sitting in either the Program for the People or Built for Business category. We'll just see where we end up in the end.

Today's Work

So, Day 1... I started the evening just doing some quick reading about the platform, watching some tutorials and doing some maintenance on my Dev.to, DigitalOcean, and GitHub accounts. Of course I also applied for the $50 credit for DigitalOcean.

The main thing I learned today is that the very first step to all this is to have a repo that already has some code ready to be deployed. I'm going to go with a node backend so I think the next step is for me to either fork the Node Sample App, or to just start a new node project from scratch and hook it up to DO.

I'm going for a node + apollo-server + type-graphl backend and I happen to have repo that has most of the setup that I want. Unfortunately, it's been a year since I've touched it so it's a little the worse for wear. Additionally it is all hooked up to Postgres and I think that's more than I want at first. So, I spent the evening stripping out all DB stuff and trying to get it to build... and to no avail.

So, goal for tomorrow? Go back through the docs for all the dependencies and get it to build. Then we can actually start doing something in DO.

https://github.com/ardentink/adr-api