Arch Linux User Repository

Unfortunately, upstream does not really have proper releases but instead points to build-versions of the software. Note, I will not push every new build of the package to the AUR but I will update the package upon new minecraft releases, e.g. for 1.14.4 to 1.14.5.

@edward-p Well... Yes and no. It was very much designed to chown existing files and directories. Its scope is certainly not limited to temporary caches. Though, I admit it was probably not designed to chown a large directory in a server directory.

Yes, exactly. I guess I was overthinking this problem way too much. The umask by the papermc user will ensure that every file created by running papermc is owned by papermc. I'll update the tmpfiles instructions with the next release.

Thanks for poking me about this!

@edh

By now, I don't think systemd-tmpfiles was designed to set file permissions and ownership for normal files.

It was designed for managing lifecycle of tmpfiles(create remove clean etc.) I think.

I think we just need to consider the files that provided by the package, then we only need:

z /srv/papermc 2775 papermc papermc - -
z /srv/papermc/log 2775 papermc papermc - -

As for /srv/papermc/papermc_server.jar we only need read permission guaranteed.

@edh

I just tested the config in https://aur.archlinux.org/packages/papermc/#comment-796931

It became normal:

$ systemd-analyze critical-chain systemd-tmpfiles-setup.service        [21:54:48]
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

systemd-tmpfiles-setup.service +2.570s
└─local-fs.target @6.181s
  └─run-user-1000.mount @13.695s
    └─local-fs-pre.target @3.387s
      └─systemd-tmpfiles-setup-dev.service @2.830s +557ms
        └─kmod-static-nodes.service @2.569s +72ms
          └─systemd-journald.socket @2.541s
            └─system.slice @2.162s
              └─-.slice @2.162s

But looking at the details, /srv/papermc/*, /srv/papermc/world* were ignored.

Mar 17 21:48:03 Ezpro-V5 systemd-tmpfiles[332]: Running create action for entry z /srv/papermc
Mar 17 21:48:03 Ezpro-V5 systemd-tmpfiles[332]: "/srv/papermc" matches mode 2775 already.
Mar 17 21:48:03 Ezpro-V5 systemd-tmpfiles[332]: Failed to determine whether '/srv/papermc/*' is below autofs, ignoring: No such file or directory
Mar 17 21:48:03 Ezpro-V5 systemd-tmpfiles[332]: Running create action for entry z /srv/papermc/*
Mar 17 21:48:03 Ezpro-V5 systemd-tmpfiles[332]: Running create action for entry Z /srv/papermc/cache
Mar 17 21:48:03 Ezpro-V5 systemd-tmpfiles[332]: Running create action for entry Z /srv/papermc/logs
Mar 17 21:48:03 Ezpro-V5 systemd-tmpfiles[332]: Failed to determine whether '/srv/papermc/world*' is below autofs, ignoring: No such file or directory
Mar 17 21:48:03 Ezpro-V5 systemd-tmpfiles[332]: Running create action for entry Z /srv/papermc/world*
Mar 17 21:48:05 Ezpro-V5 systemd-tmpfiles[332]: Running create action for entry z /usr/bin/postdrop
Mar 17 21:48:05 Ezpro-V5 systemd-tmpfiles[332]: "/usr/bin/postdrop" matches mode 2755 already.

I have no idea what "autofs" is.

@edward-p That's unexpected but just might be due to caching. Can you test the suggested papermc.conf and see whether that resolved the problem for you?

@edh I just noticed something weired, when I try to execute it manually after boot:

root:~/ # time systemd-tmpfiles --create --prefix=/srv/papermc
systemd-tmpfiles --create --prefix=/srv/papermc  0.93s user 1.58s system 96% cpu 2.595 total
root:~/ # time chown -R papermc:papermc /srv/papermc
chown -R papermc:papermc /srv/papermc  0.39s user 1.82s system 25% cpu 8.698 total

It shows that systemd-tmpfiles is even faster than chown.

But none of them took more than 2min!

So systemd-tmpfiles was only slow on system boot.

papermc.conf:

z /srv/papermc 2775 papermc papermc - -
Z /srv/papermc - papermc papermc - -

And, I put papermc on HDD.

@edward-p hmm, I am not really sure how to handle this case neatly. I definitely don't want to hard-code the user ID into the PKGBUILD to make the /srv/papermc files belong to papermc but I admit slowing down the boot that much isn't nice either.

Can you try adapting the tmpfile to something akin to this:

z /srv/papermc 2775 papermc papermc - -
z /srv/papermc/* - papermc papermc - -
Z /srv/papermc/cache - papermc papermc - -
Z /srv/papermc/logs - papermc papermc - -
Z /srv/papermc/world* - papermc papermc - -

This basically excludes the plugins directory from being chowned recursively. Maybe your plugin only needs read access and will still work.

Btw. what kind of hard or solid state drive are you using? Even for thousands of files changing the ownership shouldn't take that long!

Z /srv/papermc - papermc papermc - - can cause slow boot(since some plugin like dynmap have so many files in /src/papermc/plugins/dynmap):

$ systemd-analyze blame                                                                    
2min 23.574s systemd-tmpfiles-setup.service

$ journalctl -u systemd-tmpfiles-setup.service
Mar 17 03:17:02 Ezpro-V5 systemd-tmpfiles[340]: Running create action for entry Z /srv/papermc
Mar 17 03:19:25 Ezpro-V5 systemd-tmpfiles[340]: Running create action for entry z /srv/papermc

@xiretza Yes, you're absolutely right! I fixed the issue just now!

LICENSE_1.16.5+b427.md checksum is wrong - should be d4c645a58e1a17a0a1e42856a3cc43097711a05bf3d9f18c77c3bc9874417f223552859042ff00b7d3dda0003f49a9ee568540c2eb24e9f8fbb3c055f3b6e0a5.

Unfortunately there was a bug related to the new way users are created. It has been fixed in the new release of the package but for servers already featuring a papermc user, manual intervention is needed: If you happen to encounter the error message This account is currently not available., you will need to update the login shell such that you can interact with the console again by running usermod -s /bin/bash papermc as root.