Bug 857708 - missing jetty user
Summary: missing jetty user
Alias: None
Product: Fedora
Classification: Fedora
Component: jetty
Version: 18
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Mikolaj Izdebski
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2012-09-16 11:46 UTC by Nicolas Mailhot
Modified: 2013-08-26 07:29 UTC (History)
13 users (show)

Fixed In Version: 8.1.5-6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-06-13 14:18:38 UTC

Attachments (Terms of Use)

Description Nicolas Mailhot 2012-09-16 11:46:17 UTC
Description of problem:

# systemctl restart systemd-tmpfiles-setup.service 
Job failed. See system journal and 'systemctl status' for details.

# systemctl status systemd-tmpfiles-setup.service 
systemd-tmpfiles-setup.service - Recreate Volatile Files and Directories
	  Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-setup.service; static)
	  Active: failed (Result: exit-code) since Sun, 16 Sep 2012 13:43:06 +0200; 1s ago
	    Docs: man:tmpfiles.d(5)
	 Process: 2574 ExecStart=/usr/bin/systemd-tmpfiles --create --remove (code=exited, status=1/FAILURE)
	  CGroup: name=systemd:/system/systemd-tmpfiles-setup.service

Sep 16 13:43:06 arekh.okg systemd-tmpfiles[2574]: [/etc/tmpfiles.d/jetty.conf:1] Unknown user 'jetty'.


Comment 1 Nicolas Mailhot 2012-09-16 11:49:57 UTC
# id 110
id: 110: no such user
# id jetty
id: jetty: no such user

Comment 2 Mikolaj Izdebski 2012-09-17 11:39:14 UTC
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?

Comment 3 Jeff Bastian 2012-09-29 17:30:56 UTC
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'

Comment 4 Arnaud 2012-09-29 17:34:38 UTC
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:

# 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:

# 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 || :

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

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.

Comment 5 Arnaud 2012-09-29 17:44:16 UTC
After checking the spec file for F18, ther eis the same problem %pre and %post

Comment 6 Kevin Fenzi 2012-09-29 22:49:40 UTC
The userdel part should be dropped.

Please see: 


"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."

Comment 7 Mikolaj Izdebski 2012-10-04 22:18:13 UTC
Thank you for detailed explaination. I'll fix user and group deletion.

Comment 8 Mikolaj Izdebski 2012-10-05 14:55:28 UTC
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.

Comment 9 Fedora Update System 2012-10-05 16:23:26 UTC
jetty-6.1.26-9.fc16 has been submitted as an update for Fedora 16.

Comment 10 Fedora Update System 2012-10-05 16:24:08 UTC
jetty-8.1.2-12.fc17 has been submitted as an update for Fedora 17.

Comment 11 Fedora Update System 2012-10-05 16:24:39 UTC
jetty-8.1.5-6.fc18 has been submitted as an update for Fedora 18.

Comment 12 Fedora Update System 2012-10-06 03:49:10 UTC
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:
then log in and leave karma (feedback).

Comment 13 fri.K 2012-10-11 06:08:39 UTC
This fix won't work if there already exists user with uid 110. Why this uid have to be forced?

Comment 14 Mikolaj Izdebski 2012-10-11 07:35:52 UTC
(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.

Comment 15 fri.K 2012-10-11 07:51:32 UTC
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

Comment 16 paul59584 2012-10-23 08:21:52 UTC
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.

Comment 17 Alek Paunov 2012-11-13 22:24:43 UTC
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

Comment 18 Nathanael Noblet 2012-12-12 19:12:26 UTC
I don't see anywhere about the consistent UID here:


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

Comment 19 Mikolaj Izdebski 2012-12-12 19:33:20 UTC
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.

Comment 20 Kevin Fenzi 2012-12-12 19:52:42 UTC
But there is almost never a need for a static uid/gid.

Comment 21 Mikolaj Izdebski 2012-12-12 20:13:52 UTC
(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.

Comment 22 Nathanael Noblet 2012-12-12 20:21:11 UTC
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.

Comment 23 Kevin Fenzi 2012-12-12 20:23:41 UTC
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.

Comment 24 Nathanael Noblet 2012-12-12 20:43:46 UTC
@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.

Comment 25 Kevin Fenzi 2012-12-12 20:46:37 UTC
yeah, perhaps this is better a discussion for the packaging list ? 

Guidelines can be proposed to the FPC there...

Comment 26 Mikolaj Izdebski 2012-12-12 20:53:22 UTC
(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.

Comment 27 Fedora Update System 2012-12-20 16:16:19 UTC
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.

Comment 28 Mikolaj Izdebski 2013-06-13 14:18:20 UTC
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.

Comment 29 Mikolaj Izdebski 2013-06-13 14:18:38 UTC
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:

Comment 30 Michael Gruys 2013-08-24 09:25:40 UTC
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:

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

Comment 31 Mikolaj Izdebski 2013-08-26 06:57:08 UTC
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.

Comment 32 Michael Gruys 2013-08-26 07:29:04 UTC

Note You need to log in before you can comment on or make changes to this bug.