[Gentoo] "mtimes differ" error on unreal start

[MasterOfTheHat]

When trying to start the server using "/etc/init.d/unrealircd start", I was receiving an error. Because I couldn't tell what it was, I removed the "--quiet" flag from the start-stop-daemon line in the unrealircd script and tried again. This is what it gives me:

Code: Select all

* Re-caching dependency info (mtimes differ)...
* Starting unrealircd                                                    [ !! ]

Note also that I can successfully start the server using just "unrealircd" as root.

After searching docs, the forum, etc and then googling for the error, I'm no closer to understanding it than I was before. Any suggestions?

-MotH

[Dukat]

What "unrealircd script" are you using there in /etc/init.d/ ?


Oh, and... you shouldn't run Unreal as root... (heck, you shouldn't run anything as root...)

[MasterOfTheHat]

yeah, the script in /etc/init.d.

and i don't plan on running anything as root, i just tried to see if it could be done.

[Dukat]

yes, but what script is that? where's it from?

[MasterOfTheHat]

it was loaded when i installed unrealircd on the box (emerge-ed, actually. this is a Gentoo box)

Code: Select all

#!/sbin/runscript
# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/net-irc/unrealircd/files/unrealircd.rc,v 1.6 2004/08/15 15:57:50 swegener Exp $

opts="reload start stop"

depend() {
	need net
	use dns
	provide ircd
}

start() {
	ebegin "Starting unrealircd"
	start-stop-daemon --start --quiet --exec /usr/bin/unrealircd \
		--chuid ${UNREALIRCD_USER} -- ${UNREALIRCD_OPTS} &>/dev/null
	eend $?
}

stop() {
	ebegin "Shutting down unrealircd"
	killall unrealircd
	eend $?
}

reload() {
	ebegin "Re-Loading unrealircd"
	killall -1 unrealircd
	eend $?
}

[AngryWolf]

MasterOfTheHat, I haven't ever tried Gentoo Linux, but you'd better forget that init script unless you have a very good reason to run Unreal as root, know how the script works, and can keep the ircd up-to-date. What we generally do instead is, install Unreal as a normal user in our home directory, and add a crontab entry of that user to ensure it will always be running (see the comments in Unreal3.2/ircdcron/ircdchk). Nothing's eaiser, imho.

(heck, you shouldn't run anything as root...)

It's of no consequence (rather offtopic), but "anything" is a too strong word here, isn't it?

[codemastr]

Well, it doesn't seem to be running as root. I see --chuid ${UNREALIRCD_USER} which I assume means it is changing the uid. However, the fact that it doesn't seem to change the gid is a bit troubling.

In any case, Unreal doesn't have an "mtimes" error message. So I'd guess that is generated by the Gentoo script. I'd suggest you contact the person who wrote the Gentoo package for Unreal, swegener *AT* gentoo.org

[MasterOfTheHat]

Well crap! All right, thanks, guys...

-MotH

[mhammett]

I am having this same error. How did you solve it?

[MasterOfTheHat]

Gave up on it, mhammett... sorry!

I was running it on an old box that I decided to retire, and because of other things going on, haven't built another machine to run the daemon.

I would try unmerging the package, (I'm assuming you're using Gentoo), and then re-emerging it using the "~x86" ACCEPT_KEYWORDS switch. This will grab the latest build in portage, the only thing is that it's a build that the folks at Gentoo haven't tested as thoroughly as they would like to.

Code: Select all

ACCEPT_KEYWORDS="~x86" emerge -p unrealircd

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild  N    ] net-irc/unrealircd-3.2.3

EDIT: Well, nevermind... looks like the normal package is the same as the ~x86 package... Try unmerging and re-emerging it, and if that doesn't help, check the Gentoo forums. You can just copy your unrealircd.conf to your home directory before the unmerge/reemerge and then copy back to it's proper place after the re-emerge.

Sorry I couldn't be any more help.

-MotH

[w00t]

I'm no gentoo expert, but wouldn't it be easier just to download the official tarball and install through that? :p (Admittedly this doesnt use the package system, but it works; probably! ).

[mhammett]

On Sat, Apr 30, 2005 at 10:48:44AM -0500, Mike Hammett wrote:
> I saw another user on the Unreal forums with this same error and one of their programmers directed him to you.
>
> http://forums.unrealircd.com/viewtopic. ... 0906#10906
>
> root@piro root # /etc/init.d/unrealircd start
> * Re-caching dependency info (mtimes differ)...
> * Starting unrealircd... [ !! ]
>
> root@piro root #

The mtimes differ is not an error, it's just that our init script system
recognized an updated init script and the dependency cache needs to be
updated.

Could you remove the &>/dev/null from the start-stop-daemon line in the
init script. Then try to /etc/init.d/unrealircd start and it should
print a bit more info about what went wrong. Currently I'm guessing that
it's a permission issue.





On Sun, May 01, 2005 at 10:18:51AM -0500, Mike Hammett wrote:
> Sure enough it was a permissions error. The username that it creates on
> setup didn't have permission to the aliases directory.

Uhm, yeah, portage handles directories quite special. If I change mode
or ownership in the ebuild, portage won't update the directories in the
system with the new owner and mode. Sometimes this causes trouble.

--
Sven Wegener
Gentoo Linux Developer
http://www.gentoo.org/

[MasterOfTheHat]

cool. good to know!

[philone]

Alright, to anyone reading this. The mtimes differ error is *not* the reason that unreal fails to load. It is really a problem with your unrealircd.conf file. In order to see the output you should edit the /etc/init.d/unrealircd file and remove "&>/dev/null" from the end of the start string. This way when you run "/etc/init.d/unrealircd start" you'll see the normal startup screen with it's errors and whatnot. Once you fix the problems you can change it back so that you get the simple [ OK ] at startup.

[w00t]

If you read up a little, you'll note that this was already said.