Packaging application that needs to write to socket

snapcraft
1

Hi,

I am trying to package the pre-built binaries of Facebook’s watchman tool because the version in Ubuntu’s repository is too old for what I need.

The basics are in place, but I cannot figure out how to get rid of the following warning, which occurs on running the installed snap package’s application:

[watchman] while computing sockname: failed to create /usr/local/var/run/watchman/user-state: No such file or directory

I have tried creating the directory inside the snap/local folder with the permissions detailed in the watchman install instructions, and moving it to the right place in a part, but that just yields a permission denied error when watchman tries to write to the directory.

From what I see there are two ways to handle what watchman needs:

  1. Create a writable directory inside the snap file system that has the right permissions
  2. Allow the snap to write on the host file system

It feels like it should be possible to create a writable part on the snap-internal file system, and I’m just not doing it correctly.

My snap is quite simple:

name: watchman # you probably want to 'snapcraft register <name>'
base: core18 # the base snap is the execution environment for this snap
version: 'v2022.06.20.00' # just for humans, typically '1.2+git' or '1.3.2'
summary: Single-line elevator pitch for your amazing snap # 79 char long summary
description: |
  This is my-snap's description. You have a paragraph or two to tell the
  most important story about your snap. Keep it under 100 words though,
  we live in tweetspace and your description wants to look good in the snap
  store.

grade: devel # must be 'stable' to release into candidate/stable channels
confinement: devmode # use 'strict' once you have the right plugs and slots

apps:
  watchman:
    plugs:
      - watchman-socket
    command: usr/local/bin/watchman
  watchmanctl:
    plugs:
      - watchman-socket
    command: usr/local/bin/watchmanctl

parts:
  file-part:
    plugin: dump
    source: snap/local
    source-type: local
    stage:
      - usr/local/
    prime:
      - usr/local/
  remote-part:
    source-subdir: watchman-v2022.06.20.00-linux/
    source-type: zip
    source: https://github.com/facebook/watchman/releases/download/v2022.06.20.00/watchman-    v2022.06.20.00-linux.zip
    plugin: dump
    organize:
      '*': usr/local/
    stage:
      - usr/local/
    prime:
      - usr/local/

layout:
  /usr/local/lib:
    bind: $SNAP/usr/local/lib

Do you have any hints on how I might proceed in this? Thanks :slight_smile:

[edit]: I forgot to add a link to the Watchman install documentation. It is here: Installation instructions for MacOS and Linux

2

I think you’ll need to compile watchman instead of installing the prebuilt binaries. Doing the compile as part of the snap build will mean you can add the --disable-statedir option which will force watchman to use the temporary directory pointed to by the TMPDIR environment variable at runtime (in a strict snap this will point to /tmp, which is mounted from a subdirectory of your host’s temporary directory e.g. /tmp/snap.watchman).

3

I was afraid that would be the answer. My initial try was to compile watchman from the git repo in my snap file, but it turns out that 32 GB of RAM is not enough to do that. At least I was hitting memory issues when it tried to compile FBThrift, which is a dependency of watchman.

I will have to look more into the various compiler options to see if I can get through with a compile. Thanks for highlighting the option to force watchman to use the snap temp. :pray:

4

This sounds strange, please make sure that you’re not hitting the limit of the VM used to compile the part if you’re using multipass. Have you tried to create your snap using snapcraft --use-lxd?

5

Thanks for your help, and sorry I never got back to you on this; work has taken me in a different direction for a time.

I managed to get past the memory error by way of --use-lxd, and moved on to what seems like an error in the project’s makefile. I haven’t investigated further over the last couple of days though, so this is still very much a work in progress.

So that means I still haven’t solved my initial problem, but I at least have a better base for compiling the project myself in the snap.