Arch Linux User Repository

For what it's worth, my service file was incorrect after updating - it still pointed to the old location. Replacing the ExecStart line with ExecStart="/opt/plexmediaserver/Plex Media Server" fixed the issue.

I had an issue on an older desktop with core being dumped (illegal instruction) on start up. gdb traced it to the instruction SIGILL in libopencv_imgproc.so.2.4. The OpenCV forum suggested it uses an instruction for a particular instruction set (http://answers.opencv.org/question/25109/sigill-illegal-instruction-cvtps2pd/). To replace the linked library with a version compatible with my computer I installed opencv with pacman, and copied /usr/lib/libopencv_imgproc.so.2.4 to /opt/plexmediaserver. This fixed the problem. Hope this helps someone else.

The service file is working just fine, and has been working for a while now. The path is right so error 127 shouldn't occur at all. I don't know about error 134, but the only additional operation that might be required with the last update applies to users of SELinux or grsecurity only. One of the provided libs (libgnsdk_dsp.so.3.07.5) has execstack even though it doesn't appear to need it. That execstack has to be removed for PMS to start.

There seems to be something wrong with the service file. When I originally installed, it wasn't working, so I modified and fixed it. Now I updated and I can't get it to work any more for some reason. According to systemd, the two errors I always get are either 127 (command not found) or 134 (exit code 6)

I assumed that may have been the case. But again, the reasoning behind using static IDs for VDR was again not really required other than to stop warnings about file ownership on upgrades. Which is kind of the opposite of your point.

FTR, I don't vouch for VDR, I haven't even looked at it. It was only the result of a quick googling on the subject, I was referring to post #5 with some reasons why it needs to be done like this.

@alucryd: Reading those links really doesn't say anything in regards to doing it on the AUR. the dev wiki discussion page says that ' it would be good to have a clearer process for the addition of system users, and maybe a specific sub-namespace (_e.g._ from 500 to 749) for AUR' and then some random people putting discussion notes to please add their AUR package. At the moment it prints an inoccuous warning, which is somewhat better than randomly chowning things to a UID that may or may not be in use (I'll agree that 421 is unlikely). Without a database or table or some way of recording which UIDs are in use (and a page full of comments on a discussion page on the dev wiki really is not going to cut it there) then using fixed uid/gids on AUR packages is worse than just creating system users with -r. There is no reason that plex requires a specific uid other than avoiding that warning. Not to mention you added plex's "reserved" uid to that list a few days after @djo0012's initial comment anyway. As for [3] I would be more than a little worried if you actually used that vdr app and it's PKGBUILDs as an example of how to do things. Spending less than 10 mins browsing his github there is a big list of things that break the packaging standards and in some cases are just bad practice. On top of that, there does not appear to be any reason he 'needed' to use a specific UID; everything in the repo depends on VDR being installed first, which means it can be addressed by name. The only thing it prevents is the 'file was owned by vdr instead of root' warnings on package install. But picking random UIDs is not going to be maintainable either and will end up with a bigger mess to clean up afterwards. Anyway, this discussion should probably be moved to either the forums or the mailing list. I've made a post on the AUR sub-forum to try and see what others think of it and what we should all be doing going forward with packaging on the AUR: https://bbs.archlinux.org/viewtopic.php?pid=1523924

Just spend over an hour installing pms with some shitty tutorial... Thanks for the package here!

Official and unofficial UID/GID database [1][2] Thread that explains once more why it can't be done another way [3] Can't get my hands on the last discussion nor associated bug report though. I added more warnings to address your complaints. I thought pacman warned about differing permissions and owners, but it seems to be permissions only. I'll have a look at it, see if I include the latter. In the meantime, added a temporary chown when updating the user. [1] https://wiki.archlinux.org/index.php/DeveloperWiki:UID_/_GID_Database [2] https://wiki.archlinux.org/index.php/Talk:DeveloperWiki:UID_/_GID_Database [3] https://bbs.archlinux.org/viewtopic.php?id=191918

I still think uid is wrong in a package, but the way proposed to merge it at least warn the user in case of potential problem. At the moment I tested the upgrade with the last package and I received this warning because the plex server was still running (like when I do most update) "userdel: user plex is currently used by process 12291" I don't think you can do much more than this warning to the user to do the upgrade again with the server stopped. But a bigger problem is that the /var/lib/plex isn't chowned and it still used the old uid/gid Another problem found with that way of working is that I added the user 'plex' to the group 'users' for it to access my libraries. So at least a warning telling the user that the original user was delete and recreated and as such any mapping existing need to be recreated. Do you have any link to the general discussion about this? I find it really strange that pacman keep track of ownership by id instead of by name.