Updated to suse 9.3 binaries, but problem still exists. I can see the same
issue on my dual P3 machines running rh9.
strace on rh9 (no trace child processes activated):
open("/server/test/hldss/cstrike/cfg/server.cfg", O_RDONLY) = 7
stat64("/server/test/hldss/cstrike/cfg/server.cfg", {st_mode=S_IFREG|0644,
st_size=586, ...}) = 0
fstat64(7, {st_mode=S_IFREG|0644, st_size=586, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x46ce0000
read(7, "hostname \"some stupid test serve"..., 4096) = 586
close(7) = 0
munmap(0x46ce0000, 4096) = 0
brk(0) = 0x8eaa000
brk(0x8eab000) = 0x8eab000
futex(0x8ea9884, FUTEX_WAKE, 2147483647, {1210879016, 149592248}) = 1
gettimeofday({1133545365, 330374}, NULL) = 0
gettimeofday({1133545365, 330411}, NULL) = 0
futex(0x8ea98fc, FUTEX_WAIT, 3, {59, 999963000}) = 0
futex(0x8ea98d4, FUTEX_WAIT, 2, NULL) = 0
futex(0x8ea98d4, FUTEX_WAKE, 1, {0, 0}) = 0
futex(0x4835e86c, FUTEX_WAIT, 2, NULL) = 0
futex(0x4835e86c, FUTEX_WAKE, 1, NULL) = 0
gettimeofday({1133545365, 332098}, NULL) = 0
nanosleep({0, 1000000}, NULL) = 0
select(1, [0], NULL, NULL, {0, 0}) = 0 (Timeout)
gettimeofday({1133545365, 336721}, NULL) = 0
gettimeofday({1133545365, 336764}, NULL) = 0
gettimeofday({1133545365, 336798}, NULL) = 0
nanosleep({0, 1000000}, NULL) = 0
select(1, [0], NULL, NULL, {0, 0}) = 0 (Timeout)
gettimeofday({1133545365, 341726}, NULL) = 0
gettimeofday({1133545365, 341771}, NULL) = 0
gettimeofday({1133545365, 341805}, NULL) = 0
nanosleep({0, 1000000}, NULL) = 0
select(1, [0], NULL, NULL, {0, 0}) = 0 (Timeout)
gettimeofday({1133545365, 346702}, NULL) = 0
gettimeofday({1133545365, 346740}, NULL) = 0
gettimeofday({1133545365, 346773}, NULL) = 0
nanosleep({0, 1000000}, NULL) = 0
select(1, [0], NULL, NULL, {0, 0}) = 0 (Timeout)
gettimeofday({1133545365, 351727}, NULL) = 0
gettimeofday({1133545365, 351767}, NULL) = 0
gettimeofday({1133545365, 351801}, NULL) = 0
nanosleep({0, 1000000}, NULL) = 0
etc...
Looks like srcds is waiting for some fd forever...
This issue _only_ occurs on my dual P3 machines.
/ manuel
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Steven
> Hartland
> Sent: Friday, December 02, 2005 6:10 PM
> To: [email protected]
> Subject: Re: [hlds_linux] Still problems with hlds v27
>
>
> We still run redhat8 base here and no problems FreeBSD 5.4 ( P4 CPU )
>
> N.B. To get rid of the first two warnings / errors:
> sysctl kern.ipc.maxsockbuf=524288
> or
> kern.ipc.maxsockbuf=524288
> in /etc/sysctl.conf and reboot
>
> Steve / K
> ----- Original Message -----
> From: "William Warren" <[EMAIL PROTECTED]>
>
>
>
> > try an updated RH version. The rh9 is seriously old. maybe that's your
> > issue under freebsd.
> >
> > Manuel Mausz wrote:
> >> Having the same problem after the source engine update now (on freebsd
> >> 5.4)...
> >> - linux_base-rh-9 installed.
> >>
> >> Commandline:
> >> ./srcds_run -timeout 60 -game cstrike -port 27020 -nohltv -tickrate 66
> >> -steamport 27021 +clientport 27022 +tv_port 27023 +ip
> >> 80.64.134.1 +maxplayers 12 +map de_dust -secure
> >>
> >> srcds-Output:
> >> Auto detecting CPU
> >> Using default binary.
> >> Auto-restarting the server on crash
> >>
> >> Console initialized.
> >> Attempted to create unknown entity type event_queue_saveload_proxy!
> >> Game.dll loaded for "Counter-Strike: Source"
> >> maxplayers set to 32
> >> maxplayers set to 12
> >> Network: IP 80.64.134.1, mode MP, dedicated Yes, ports 27020 SV / 27022 CL
> >> Executing dedicated server config file
> >> Summary: 322 resources total 13.35 Mb, 19.90 % of capacity
> >> net.cpp (818) : Assertion Failed: 0 == iRet
> >> net.cpp (821) : Assertion Failed: 0 == iRet
> >> <... nothing more happens here ...>
> >>
> >> Strace-Output of the first thread:
> >> getdomainname(Process 685 attached - interrupt to quit
> >> "EA~PU~Ia~Ci^H~KE^L~EAt^SeUhoyC", 3217016800) = 0
> >> gethostid?() = 0
> >> mincore(0xbfbfc780, 0, []) = 0
> >> mincore(0xbfbfc540, 0, []) = 0
> >> mincore(0xbfbfc540, 0, []) = 0
> >> getdomainname("EA~PU~Ia~Ci^H~KE^L~EAt^SeUhoyC", 3217016800) = 0
> >> gethostid?() = 0
> >> mincore(0xbfbfc780, 0, []) = 0
> >> mincore(0xbfbfc540, 0, []) = 0
> >> mincore(0xbfbfc540, 0, []) = 0
> >> getdomainname("EA~PU~Ia~Ci^H~KE^L~EAt^SeUhoyC", 3217016800) = 0
> >> gethostid?() = 0
> >> mincore(0xbfbfc780, 0, []) = 0
> >> mincore(0xbfbfc540, 0, []) = 0
> >> mincore(0xbfbfc540, 0, []) = 0
> >> <... etc ...>
> >>
> >> Strace-Output of the second thread:
> >> getdomainname("A
> >> Au$Qj", 3208640444) = 0
> >> SYS_175() = 0
> >> fchdir(0) = 1133535224
> >> mincore(0xbf3ffa1c, 0, 0) = 0
> >> gethostid?() = 0x1
> >> mincore(0xbf3ff9fc, 0, []) = 0
> >> SYS_175() = 0
> >> SYS_175() = 0
> >> mincore(0xbf3ff7c4, 0, []) = 0
> >> getdomainname("A
> >> Au$Qj", 3208640444) = 0
> >> SYS_175() = 0
> >> fchdir(0) = 1133535224
> >> mincore(0xbf3ffa1c, 0, 0) = 0
> >> gethostid?() = 0x1
> >> mincore(0xbf3ff9fc, 0, []) = 0
> >> SYS_175() = 0
> >> SYS_175() = 0
> >> mincore(0xbf3ff7c4, 0, []) = 0
> >> <... etc ...>
> >>
> >> CPU_ENABLE_SSE is in kernel although this is default in I686_CPU
> >>
> >> Looks like srcds wants to resolve some memory data? :)
> >>
> >> Any help would be greatly appreciated.
> >>
> >> / manuel
>
>
> ================================================
> This e.mail is private and confidential between Multiplay (UK) Ltd. and the
> person or entity to whom it is addressed. In
> the event of misdirection, the recipient is prohibited from using, copying,
> printing or otherwise disseminating it or any
> information contained in it.
>
> In the event of misdirection, illegible or incomplete transmission please
> telephone (023) 8024 3137
> or return the E.mail to [EMAIL PROTECTED]
>
>
> _______________________________________________
> To unsubscribe, edit your list preferences, or view the list archives, please
> visit:
> http://list.valvesoftware.com/mailman/listinfo/hlds_linux
>
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
