/dev/shm not present on new (raspberry2) base images?

Product support
1

Seems like the new resin base images are missing /dev/shm? I was trying to start up postgresql, and it complained that it couldn’t write to shared memory.

From inspecting the layers, it seems like it might be related to changing over to systemd?

I’m currently not having ENV INITSYSTEM on in my Dockerfile.

For resin/raspberrypi2-node:

root@raspberrypi2:/# df -h                                                      
Filesystem      Size  Used Avail Use% Mounted on                                
/dev/mmcblk0p6   15G  1.6G   12G  12% /                                         
none            483M     0  483M   0% /dev                                      
/dev/root       171M  134M   28M  83% /lib/modules                              
/dev/mmcblk0p6   15G  1.6G   12G  12% /data                                     
tmpfs           487M   14M  474M   3% /run/dbus

For resin/arm7hf-node:

root@raspberrypi2:/# df -h                                                      
Filesystem      Size  Used Avail Use% Mounted on                                
/dev/mmcblk0p6   60G  1.7G   57G   3% /                                         
tmpfs           487M     0  487M   0% /dev                                      
shm              64M  4.0K   64M   1% /dev/shm  <----- PRESENT HERE         
/dev/root       171M  134M   28M  83% /lib/modules                              
/dev/mmcblk0p6   60G  1.7G   57G   3% /data                                     
tmpfs           487M   14M  474M   3% /run/dbus

Anybody got any ideas why?

2

Hello,

I just tested a container based on resin/raspberrypi2-node:latest and:

root@84539d36a5ce:/# mount | grep shm
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)

This is available with or without INITSYSTEM=on.

Andrei

3

Hi Andrei,

Thanks for the reply, I guess I should be more clear in saying how come shm is not mounted in a way which is visible to df (or in fact, to any other program expecting shared memory).

You’re right, I’m able to see from mount that shm looks mounted.

root@raspberrypi2:/# df -h 
Filesystem Size Used Avail Use% Mounted on 
/dev/mmcblk0p6 15G 1.4G 12G 10% / 
none 483M 0 483M 0% /dev 
/dev/root 171M 134M 28M 83% /lib/modules 
/dev/mmcblk0p6 15G 1.4G 12G 10% /data 
tmpfs 487M 14M 474M 3% /run/dbus

root@raspberrypi2:/# mount | grep shm 
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)

But when I try to do this:

root@raspberrypi2:/# umount shm                                                 
umount: /dev/shm: not mounted

is /dev/shm mounted or not?

But then if I do this:

root@raspberrypi2:/# mount shm 

root@raspberrypi2:/# df -h                                                      
Filesystem      Size  Used Avail Use% Mounted on                                
/dev/mmcblk0p6   15G  1.4G   12G  10% /                                         
none            483M     0  483M   0% /dev                                      
shm              64M     0   64M   0% /dev/shm                                  
/dev/root       171M  134M   28M  83% /lib/modules                              
/dev/mmcblk0p6   15G  1.4G   12G  10% /data                                     
tmpfs           487M   14M  474M   3% /run/dbus

root@raspberrypi2:/# mount | grep shm 
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k) 
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)

mount-ception!

Starting my postgres service (which is setup to use shared memory) works after this.

You should be able to replicate this in a container based on resin/raspberrypi2-node:latest.

So I guess the weird things are:

  1. Shared memory doesn’t seem to be loaded in a way that can be used by applications in the container - this is a change from previous behaviour - but I guess adding /dev/shm as a mountpoint in fstab can be a quick fix for people that require it.

  2. How come there seems to be a double-mounting of /dev/shm.

4

Hi bakavic,

The reason you see different mounts in the output of mount and df -h is because df will only list the mount points that are accessible. A mountpoint can become inaccessible if you mount something over it. For example if you first mount /dev/shm and then do mount -t devtmpfs devtmpfs /dev, then the first /dev/shm will become inaccessible and therefore will not be listed in df -h.

Can you post the Dockerfile you’re using with its configured environment variables? It will make debugging this a lot easier.

5

Hi Petro,

Thanks for the reply.

I think Andrei was right - there seems to be nothing wrong with the images :

docker@default:/usr/bin$ docker run -it resin/raspberrypi2-node:latest /bin/bash
hostname: you must be root to change the host name
mount: permission denied
root@d6e52050ecdf:/# df -h
Filesystem      Size  Used Avail Use% Mounted on
none             19G  9.0G  8.3G  53% /
tmpfs          1002M     0 1002M   0% /dev
shm              64M     0   64M   0% /dev/shm
tmpfs          1002M     0 1002M   0% /sys/fs/cgroup
/dev/sda1        19G  9.0G  8.3G  53% /etc/hosts

I tried running the image locally on my laptop with the help of qemu, and /dev/shm shows up correctly. So the problem probably lies in my Dockerfile.

My current Dockerfile looks like this:

FROM resin/raspberrypi2-node:4.0

RUN apt-get update && apt-get install -y --no-install-recommends \
    postgresql-9.4 postgresql-client-9.4 postgresql-contrib-9.4 avahi-daemon libnss-mdns cron && apt-get clean && rm -rf /var/lib/apt/lists/*

# Prep Db conf
RUN sed -i '/^data_directory*/ s|/var/lib/postgresql/9.4/main|/data/db/|' /etc/postgresql/9.4/main/postgresql.conf && \
    sed -i 's/ssl = true/ssl = false/g' /etc/postgresql/9.4/main/postgresql.conf && \
    sed -i '/# DO NOT DISABLE!/i local all trust\nhost all all 127.0.0.1/32 trust' /etc/postgresql/9.4/main/pg_hba.conf

# copy over bonjour config
COPY deployment/http.service /etc/avahi/services/
RUN sed -i 's/#enable-dbus=yes/enable-dbus=no/g' /etc/avahi/avahi-daemon.conf && \
    update-rc.d avahi-daemon enable

# install pm2
RUN npm -g install pm2 --unsafe-perm
RUN (crontab -u root -l; echo "0 1 * * * /usr/local/bin/pm2 flush" ) | crontab -u root -

RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app
COPY package.json /usr/src/app/
RUN npm install --unsafe-perm --production

COPY . /usr/src/app
CMD "npm" "start"

Probably one of the packages I’m installing is clobbering the mountpoint? The other actions the Dockerfile performs here don’t seem like they would mess up mountpoints.

Thanks Andrei and Petro for the assistance so far.

Victor

6

Hmm, I tried pushing an empty image to a new raspi2, and it seems like the /dev/shm isn’t showing up on the pi itself, but shows up if you try to run it with qemu locally?

I made a new project with this Dockerfile:

FROM resin/raspberrypi2-node:4.0

CMD "bash"

and on the terminal on the pi:

root@raspberrypi2:/# df -h                                                      
Filesystem      Size  Used Avail Use% Mounted on                                
/dev/mmcblk0p6  7.0G 1005M  5.7G  15% /                                         
none            483M     0  483M   0% /dev                                      
/dev/root       182M  144M   29M  84% /lib/modules                              
/dev/mmcblk0p6  7.0G 1005M  5.7G  15% /data                                     
tmpfs           487M  9.4M  478M   2% /run/dbus                                 
root@raspberrypi2:/# mount | grep shm                                           
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)

But when I run the same exact Dockerfile locally:

root@918a742ee2a0:/# df -h
Filesystem      Size  Used Avail Use% Mounted on
none             19G  8.4G  8.9G  49% /
tmpfs          1002M     0 1002M   0% /dev
shm              64M     0   64M   0% /dev/shm
tmpfs          1002M     0 1002M   0% /sys/fs/cgroup
/dev/sda1        19G  8.4G  8.9G  49% /etc/hosts
root@918a742ee2a0:/# mount | grep shm
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)
7

Hi Bakavic,

Thanks your input, we managed to reproduce the issue and it is indeed an problem with our image when the environment variable INITSYSTEM isn’t set to on. We override the /dev mountpoint with a devtmpfs mount which shadows all the nice things docker kindly mounted for us, including /dev/console, /dev/shm, /dev/mqueue and /dev/mqueue.

This is the code responsible for that https://github.com/resin-io-library/base-images/blob/6b2717fde11c3ed755180a7f20961e334c34738f/systemd/armv7hf/jessie/entry.sh#L26-L32

The reason it worked locally for you is that you ran it without the --privileged flag which made our mount -t devtmpfs none /dev command to fail and so the problem doesn’t happen.

We will update our images to fix this problem and also get rid of the shadowed mounts as an extra bonus to avoid confusion. In the meantime you can test if /dev/shm is mounted in your code and mount it yourself if it isn’t or you could try and set INITSYSTEM=on which will let systemd take care of all these for you.

Thanks again,
Petros

8

Hi Petro,

Thanks for the update - I’ve tried setting up my image with systemd enabled, and /dev/shm appears fine for me now.

Regards,
Victor

9

Hi Bakavic,

We just fixed this in our image source code. You can see the commit here https://github.com/resin-io-library/base-images/commit/fdb81009727d49174c06f72f85aadd3e4a419bdc

We haven’t rebuilt the images on dockerhub yet but we’ll hopefully rebuild them all during this week!

Cheers,
Petros

1 Like