# id 110
id: 110: no such user
# id jetty
id: jetty: no such user

I can't reproduce this in Fedora 18 chroot. I tried the following steps:

$ koji download-build 350702
$ mock -r fedora-18-x86_64 init
$ mock -r fedora-18-x86_64 install jetty-*.rpm
$ mock -r fedora-18-x86_64 shell "id jetty"

id jetty shows the expected output:
uid=110(jetty) gid=110(jetty) groups=110(jetty)

Could you please provide more information on how to reproduce the bug?
Did you modify user settings manually?
Did you upgrade jetty from Fedora 17 or earlier?

I hit this problem too after upgrading from Fedora 17.  I did a 'yum distro-sync' to upgrade (since Anaconda is not ready for upgrades yet).

A simple fix is 'yum reinstall jetty'

I am not using F18 (F17), but I am getting the same thing.
So I posted here in case it would be the same source of the problem.
If you prefer I open a new bug for F17, sorry in advance.

It isn't from installation but after updating the package jetty.
During an update, the user jetty is deleted but not recreated.

In the spec file of version: jetty-8.1.2-11.fc17.noarch.rpm, the user is deleted during the update in the postun section:

%postun
[..]
# Remove the user even during upgrade, it will be added later in %post.
# This is required to force incorrect UID to be replaced with the new one.
userdel  %username &>/dev/null || :
groupdel %username &>/dev/null || :

But there is no user creation in %post, there is one in %pre:

%pre
# Add the "jetty" user and group
(getent group  %username || groupadd -r -g %jtuid %username) &>/dev/null || :
(getent passwd %username || useradd  -r -u %jtuid -g %username -d %homedir \
                              -M -s /sbin/nologin %username) &>/dev/null || :

%post
if [ $1 -eq 1 ] ; then
    # Initial installation
    /bin/systemctl daemon-reload >/dev/null 2>&1 || :
fi

After an update, it doesn't seem to execute the %pre section, but will for an install.

Checked with yum and rpm commands, and both act the same.

After checking the spec file for F18, ther eis the same problem %pre and %post

The userdel part should be dropped.

Please see: 

http://fedoraproject.org/wiki/Packaging:UsersAndGroups

"We never remove users or groups created by packages."

"Cleanup of unused users/groups is left to the system administrators to take care of if they so desire."

Thank you for detailed explaination. I'll fix user and group deletion.

Fixed in rawhide in 8.1.5-6.
All supported releases of Fedora were affected.
Aggregated updates for F16, F17 and F18 will be prepared later.

jetty-6.1.26-9.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/jetty-6.1.26-9.fc16

jetty-8.1.2-12.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/jetty-8.1.2-12.fc17

jetty-8.1.5-6.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/jetty-8.1.5-6.fc18

Package jetty-8.1.2-12.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing jetty-8.1.2-12.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-15501/jetty-8.1.2-12.fc17
then log in and leave karma (feedback).

This fix won't work if there already exists user with uid 110. Why this uid have to be forced?

(In reply to comment #13)
> This fix won't work if there already exists user with uid 110. Why this uid
> have to be forced?

According to current policy, users and groups created during package instalation should have static UIDs and GIDs for various reasons (like sharing one filesystem between multiple systems).

There should be no conflict with users/groups created by other packages because UIDs and GIDs are being reserved at system level. Currently UID/GID 110 is reserved for jetty package, so no other package is allowed to use it.

There should be no conflict with user-created accounts either. Low IDs were traditionally reserved for system and useradd/groupadd won't use ID of 110 by default, unless directly told so by root.

So there is conflict on my system, but I'll fix it by hand:

$ cat /etc/passwd |grep 110
mediatomb:x:111:110:To run Mediatomb:/etc/mediatomb:/sbin/nologin
gmediaserver:x:110:109:gmediaserver daemon user:/var/lib/gmediaserver:/sbin/nologin

jetty was updated to jetty-8.1.2-12.fc17.noarch.rpm on my system today and the jetty user and group disappeared. Had to reinstall jetty to get them back. This has been happening for me the last three (that's a guess maybe more than 3, maybe less) or so updates as described by others above.

no conflict with other users/groups on this machine.

In a F17 instance the issue has been fixed as follows:

systemctl stop colord-sane.service colord.service
userdel colord
yum reinstall jetty
yum reinstall colord

I don't see anywhere about the consistent UID here:

http://fedoraproject.org/wiki/Packaging:UsersAndGroups

I remember a few years ago having to set the uid and reserve it on a page. I think it changed though.

Currently static UID/GID mapping for packages is maintained as part of uidgid document, which is installed with setup package. See /usr/share/doc/setup-2.8.62/uidgid for the list.

But there is almost never a need for a static uid/gid.

(In reply to comment #20)
> But there is almost never a need for a static uid/gid.

I believe that in case of jetty the use of a static UID and GID is justified.

If you think jetty shouldn't use a static UID/GID please open a new bug.

So if there are cases for static uid/gid *and* non static uid/gid system users. Shouldn't there be a way for non-static uid/gid accounts to not stomp on the static ones? I have packages that create system accounts but aren't static... I see nothing about that in the guidelines.

Yes. If you have a site that requires constant uid's for package accounts like this, you should create those before you install the software. Then the dynamic uid/gid scriptlets will simply see the account exists and use it. Dynamic scriptlets will not reuse an existing uid/gid, they just use the next free one. 

I don't see what is stomping on anything here.

@Kevin, Not sure if you are responding to me, however here's how the bug is triggered on my system.

So for example the gitolite package creates a system user. Because it isn't a static uid/gid and whatever stars aligned on my system. It was assigned uid 110. Sometime later jetty must have been installed, but fails to create its user.

I also maintain dspam which creates a system user and doesn't care what the UID/GID number becomes. However it could easily cause this same issue. So the jetty package has a reserved id, but it wasn't reserved on my system when gitolite was installed... 

So if static uid/gids are legit, it seems the method to reserve them is broken, not clearly documented or fragile or something.

yeah, perhaps this is better a discussion for the packaging list ? 

Guidelines can be proposed to the FPC there...

(In reply to comment #22)
> So if there are cases for static uid/gid *and* non static uid/gid system
> users. Shouldn't there be a way for non-static uid/gid accounts to not stomp
> on the static ones? I have packages that create system accounts but aren't
> static... I see nothing about that in the guidelines.

See the package fedora-usermgmt-core (and fedora-usermgmt-default-fedora-setup). Currently base dynamic UID is 300 (as specified in /etc/fedora/usermgmt/base[ug]id files). This means that if your package uses %__fe_groupadd and %__fe_useradd macros (or %{_sbindir}/fedora-user{add,del} scripts) then UID/GID will be >= 300. All static IDs are < 300, so there is no conflict.

jetty-6.1.26-9.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

This bug is fixed in Jetty in Fedora 19 and later as well as updates for Fedora 18.  After successfull installation of jetty >= 8.1.5-6 the jetty use should be no longer removed.  Said that, there is no easy way to fix buggy packages that were already installed - during removal (upgrade) they may remove jetty user.

I believe that this bug is fixed in jetty-8.1.5-6,
which is available in updates for Fedora 18, so I am closing this bug now.

The build containing the fix can be found at Koji:
http://koji.fedoraproject.org/koji/buildinfo?buildID=358455

a reinstall of jetty.noarch 0:9.0.3-3.fc19 gives still:
yum reinstall jetty
Running transaction
groupadd: GID '110' already exists
useradd: group 'jetty' does not exist
  Installeren             : jetty-9.0.3-3.fc19.noarch                       1/1 
warning: user jetty does not exist - using root
warning: group jetty does not exist - using root
warning: user jetty does not exist - using root
warning: group jetty does not exist - using root

Because my /etc/group contains:
stapusr:x:110:

Googling on this user gives no results. I want to know what package has created it.

Now my logfiles will not be cleaned...
Anyone has a solution?
Thanks in advance

You could find what files use this group:
# find / -gid 110
this can help you identify what package created the group.
If there are any files then reassign them to a new GID and update /etc/group.
Then reinstall jetty.

Thanks!