Re: [hlds_linux] [hlds] Mandatory Team Fortress 2 update released

[sigsegv]

The beta version seems to have fixed the problems on my system as well.

Appreciate the fast turnaround time on this!

Justin
sigsegv

On Wed, Oct 26, 2016 at 1:35 PM, Charles Huber  wrote:

> Yup, the beta code seems to fix startup on my ZFS filesystem, thanks!
>
> On Wed, Oct 26, 2016 at 3:19 PM, Eric Smith 
> wrote:
> > We've released a fix that you can try if you're experiencing the problem
> described in this thread. To test the fix, you will need to opt-in to the
> steamcmd beta branch. To do this, you have two options:
> >
> > 1. run with "-clientbeta publicbeta" on the command line, or
> >
> > 2. In the steamcmd install folder there's a "package" directory,
> make a file named "beta" in there and put this text in it:
> >
> > publicbeta
> >
> > Just that word on one the top line, nothing else.
> >
> > Let me know if you're still having problems after testing the fix.
> Thanks.
> >
> > -Eric
> >
> >
> > -Original Message-
> > From: hlds_linux-boun...@list.valvesoftware.com [mailto:
> hlds_linux-boun...@list.valvesoftware.com] On Behalf Of sigsegv
> > Sent: Wednesday, October 26, 2016 11:38 AM
> > To: Half-Life dedicated Linux server mailing list
> > Subject: Re: [hlds_linux] [hlds] Mandatory Team Fortress 2 update
> released
> >
> > [CC'd to John Schoenick: please look into this, or forward it on to
> whoever works on steamcmd.]
> >
> > Yes, I too have run into this problem with steamcmd over the last week
> or so, as my Linux dedicated server installation is on ZFS.
> >
> > This appears to be a false positive from steamcmd: it queries the block
> size of the filesystem and says "holy crap, 128KB? can't deal with that"
> > even though it isn't actually a problem since ZFS's recordsize isn't
> really a fixed block size per se.
> >
> > I found that reducing the 'recordsize' property of the ZFS volume from
> 128K to 512 bytes made the errors go away, but then the ZFS performance
> became hideously slow (not an unexpected result), so I didn't go forward
> with that workaround.
> >
> > (You can run the command 'stat -f .' on a directory to see what the
> reported block size is; with recordsize=128K it was 128KB, and with
> > recordsize=512 it was 512B.)
> >
> > For the time being, I found a reasonable workaround to be to mount an
> > ext4 partition on the steamapps/downloading directory. The game
> directory itself can still be ZFS with normal 128K recordsize; it's just
> the downloading directory that steamcmd loses its mind over. It'll copy the
> updated files over to the ZFS game dir just fine.
> >
> > Hope that helps, and I hope Valve fixes this brokenness...
> >
> > Justin
> > (sigsegv)
> >
> > On Wednesday, October 26, 2016, Charles Huber 
> wrote:
> >
> >> Yup, I have the servers installed on a ZoL volume too, thanks for the
> >> confirmation!
> >>
> >> On Wed, Oct 26, 2016 at 11:05 AM, Jan  >> >
> >> wrote:
> >> > Hey,
> >> >
> >> > are you using ZFS on linux?
> >> > I had the same problem, steamcmd failed to update the server. It
> >> > works only on my ext4 partition for some reason.
> >> > Maybe it is a combination of ZFS on linux and the fix for the dirty
> >> > cow
> >> > bug: https://dirtycow.ninja/
> >> >
> >> >
> >> > On 26.10.2016 17:08, Charles Huber wrote:
> >> >> Hrm, still startup looping:
> >> >>
> >> >> WARNING: No map specified! Server may not heartbeat.
> >> >> Auto detecting CPU
> >> >> Using default binary: ./srcds_linux Server will auto-restart if
> >> >> there is a crash.
> >> >> Updating server using Steam.
> >> >> 
> >> >> Redirecting stderr to '/home/gameserver/Steam/logs/stderr.txt'
> >> >> Looks like steam didn't shutdown cleanly, scheduling immediate
> >> >> update
> >> check
> >> >> [  0%] Checking for available updates...
> >> >> [] Verifying installation...
> >> >> Steam Console Client (c) Valve Corporation
> >> >> -- type 'quit' to exit --
> >> >> Loading Steam API...Created shared memory when not owner
> >> >> SteamController_Shared_mem OK.
> >> >> login anonymous
> >> >>
> >> >> Connecting anonymously to Steam Public...Logged in OK Waiting for
> >> >> license info...OK force_install_dir ./tf2 app_update 232250
> >> >> validate  Update state (0x3) reconfiguring, progress: 0.00 (0 / 0)
> >> >> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read
> >> >> must be called with a cubData value that is a multiple of the
> >> >> sector size when using unbuffered IO ../tier1/fileio.cpp (3897) :
> >> >> Assertion Failed: CFileReader::Read must be called with a cubData
> >> >> value that is a multiple of the sector size when using unbuffered
> >> >> IO  Update state (0x81) committing, progress: 100.00 (180409744 /
> >> 180411440)
> >> >> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read
> >> >> must be called with a cubData value that is a multiple of the
> >> >> 

Re: [hlds_linux] [hlds] Mandatory Team Fortress 2 update released

[Charles Huber]

Yup, the beta code seems to fix startup on my ZFS filesystem, thanks!

On Wed, Oct 26, 2016 at 3:19 PM, Eric Smith  wrote:
> We've released a fix that you can try if you're experiencing the problem 
> described in this thread. To test the fix, you will need to opt-in to the 
> steamcmd beta branch. To do this, you have two options:
>
> 1. run with "-clientbeta publicbeta" on the command line, or
>
> 2. In the steamcmd install folder there's a "package" directory, make 
> a file named "beta" in there and put this text in it:
>
> publicbeta
>
> Just that word on one the top line, nothing else.
>
> Let me know if you're still having problems after testing the fix. Thanks.
>
> -Eric
>
>
> -Original Message-
> From: hlds_linux-boun...@list.valvesoftware.com 
> [mailto:hlds_linux-boun...@list.valvesoftware.com] On Behalf Of sigsegv
> Sent: Wednesday, October 26, 2016 11:38 AM
> To: Half-Life dedicated Linux server mailing list
> Subject: Re: [hlds_linux] [hlds] Mandatory Team Fortress 2 update released
>
> [CC'd to John Schoenick: please look into this, or forward it on to whoever 
> works on steamcmd.]
>
> Yes, I too have run into this problem with steamcmd over the last week or so, 
> as my Linux dedicated server installation is on ZFS.
>
> This appears to be a false positive from steamcmd: it queries the block size 
> of the filesystem and says "holy crap, 128KB? can't deal with that"
> even though it isn't actually a problem since ZFS's recordsize isn't really a 
> fixed block size per se.
>
> I found that reducing the 'recordsize' property of the ZFS volume from 128K 
> to 512 bytes made the errors go away, but then the ZFS performance became 
> hideously slow (not an unexpected result), so I didn't go forward with that 
> workaround.
>
> (You can run the command 'stat -f .' on a directory to see what the reported 
> block size is; with recordsize=128K it was 128KB, and with
> recordsize=512 it was 512B.)
>
> For the time being, I found a reasonable workaround to be to mount an
> ext4 partition on the steamapps/downloading directory. The game directory 
> itself can still be ZFS with normal 128K recordsize; it's just the 
> downloading directory that steamcmd loses its mind over. It'll copy the 
> updated files over to the ZFS game dir just fine.
>
> Hope that helps, and I hope Valve fixes this brokenness...
>
> Justin
> (sigsegv)
>
> On Wednesday, October 26, 2016, Charles Huber  wrote:
>
>> Yup, I have the servers installed on a ZoL volume too, thanks for the
>> confirmation!
>>
>> On Wed, Oct 26, 2016 at 11:05 AM, Jan > >
>> wrote:
>> > Hey,
>> >
>> > are you using ZFS on linux?
>> > I had the same problem, steamcmd failed to update the server. It
>> > works only on my ext4 partition for some reason.
>> > Maybe it is a combination of ZFS on linux and the fix for the dirty
>> > cow
>> > bug: https://dirtycow.ninja/
>> >
>> >
>> > On 26.10.2016 17:08, Charles Huber wrote:
>> >> Hrm, still startup looping:
>> >>
>> >> WARNING: No map specified! Server may not heartbeat.
>> >> Auto detecting CPU
>> >> Using default binary: ./srcds_linux Server will auto-restart if
>> >> there is a crash.
>> >> Updating server using Steam.
>> >> 
>> >> Redirecting stderr to '/home/gameserver/Steam/logs/stderr.txt'
>> >> Looks like steam didn't shutdown cleanly, scheduling immediate
>> >> update
>> check
>> >> [  0%] Checking for available updates...
>> >> [] Verifying installation...
>> >> Steam Console Client (c) Valve Corporation
>> >> -- type 'quit' to exit --
>> >> Loading Steam API...Created shared memory when not owner
>> >> SteamController_Shared_mem OK.
>> >> login anonymous
>> >>
>> >> Connecting anonymously to Steam Public...Logged in OK Waiting for
>> >> license info...OK force_install_dir ./tf2 app_update 232250
>> >> validate  Update state (0x3) reconfiguring, progress: 0.00 (0 / 0)
>> >> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read
>> >> must be called with a cubData value that is a multiple of the
>> >> sector size when using unbuffered IO ../tier1/fileio.cpp (3897) :
>> >> Assertion Failed: CFileReader::Read must be called with a cubData
>> >> value that is a multiple of the sector size when using unbuffered
>> >> IO  Update state (0x81) committing, progress: 100.00 (180409744 /
>> 180411440)
>> >> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read
>> >> must be called with a cubData value that is a multiple of the
>> >> sector size when using unbuffered IO ../tier1/fileio.cpp (3897) :
>> >> Assertion Failed: CFileReader::Read must be called with a cubData
>> >> value that is a multiple of the sector size when using unbuffered
>> >> IO ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read
>> >> must be called with a cubData value that is a multiple of the
>> >> sector size when using unbuffered IO 

Re: [hlds_linux] [hlds] Mandatory Team Fortress 2 update released

[Eric Smith]

We've released a fix that you can try if you're experiencing the problem 
described in this thread. To test the fix, you will need to opt-in to the 
steamcmd beta branch. To do this, you have two options:

1. run with "-clientbeta publicbeta" on the command line, or

2. In the steamcmd install folder there's a "package" directory, make a 
file named "beta" in there and put this text in it:

publicbeta

Just that word on one the top line, nothing else.

Let me know if you're still having problems after testing the fix. Thanks.

-Eric


-Original Message-
From: hlds_linux-boun...@list.valvesoftware.com 
[mailto:hlds_linux-boun...@list.valvesoftware.com] On Behalf Of sigsegv
Sent: Wednesday, October 26, 2016 11:38 AM
To: Half-Life dedicated Linux server mailing list
Subject: Re: [hlds_linux] [hlds] Mandatory Team Fortress 2 update released

[CC'd to John Schoenick: please look into this, or forward it on to whoever 
works on steamcmd.]

Yes, I too have run into this problem with steamcmd over the last week or so, 
as my Linux dedicated server installation is on ZFS.

This appears to be a false positive from steamcmd: it queries the block size of 
the filesystem and says "holy crap, 128KB? can't deal with that"
even though it isn't actually a problem since ZFS's recordsize isn't really a 
fixed block size per se.

I found that reducing the 'recordsize' property of the ZFS volume from 128K to 
512 bytes made the errors go away, but then the ZFS performance became 
hideously slow (not an unexpected result), so I didn't go forward with that 
workaround.

(You can run the command 'stat -f .' on a directory to see what the reported 
block size is; with recordsize=128K it was 128KB, and with
recordsize=512 it was 512B.)

For the time being, I found a reasonable workaround to be to mount an
ext4 partition on the steamapps/downloading directory. The game directory 
itself can still be ZFS with normal 128K recordsize; it's just the downloading 
directory that steamcmd loses its mind over. It'll copy the updated files over 
to the ZFS game dir just fine.

Hope that helps, and I hope Valve fixes this brokenness...

Justin
(sigsegv)

On Wednesday, October 26, 2016, Charles Huber  wrote:

> Yup, I have the servers installed on a ZoL volume too, thanks for the 
> confirmation!
>
> On Wed, Oct 26, 2016 at 11:05 AM, Jan  >
> wrote:
> > Hey,
> >
> > are you using ZFS on linux?
> > I had the same problem, steamcmd failed to update the server. It 
> > works only on my ext4 partition for some reason.
> > Maybe it is a combination of ZFS on linux and the fix for the dirty 
> > cow
> > bug: https://dirtycow.ninja/
> >
> >
> > On 26.10.2016 17:08, Charles Huber wrote:
> >> Hrm, still startup looping:
> >>
> >> WARNING: No map specified! Server may not heartbeat.
> >> Auto detecting CPU
> >> Using default binary: ./srcds_linux Server will auto-restart if 
> >> there is a crash.
> >> Updating server using Steam.
> >> 
> >> Redirecting stderr to '/home/gameserver/Steam/logs/stderr.txt'
> >> Looks like steam didn't shutdown cleanly, scheduling immediate 
> >> update
> check
> >> [  0%] Checking for available updates...
> >> [] Verifying installation...
> >> Steam Console Client (c) Valve Corporation
> >> -- type 'quit' to exit --
> >> Loading Steam API...Created shared memory when not owner 
> >> SteamController_Shared_mem OK.
> >> login anonymous
> >>
> >> Connecting anonymously to Steam Public...Logged in OK Waiting for 
> >> license info...OK force_install_dir ./tf2 app_update 232250 
> >> validate  Update state (0x3) reconfiguring, progress: 0.00 (0 / 0) 
> >> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read 
> >> must be called with a cubData value that is a multiple of the 
> >> sector size when using unbuffered IO ../tier1/fileio.cpp (3897) : 
> >> Assertion Failed: CFileReader::Read must be called with a cubData 
> >> value that is a multiple of the sector size when using unbuffered 
> >> IO  Update state (0x81) committing, progress: 100.00 (180409744 /
> 180411440)
> >> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read 
> >> must be called with a cubData value that is a multiple of the 
> >> sector size when using unbuffered IO ../tier1/fileio.cpp (3897) : 
> >> Assertion Failed: CFileReader::Read must be called with a cubData 
> >> value that is a multiple of the sector size when using unbuffered 
> >> IO ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read 
> >> must be called with a cubData value that is a multiple of the 
> >> sector size when using unbuffered IO ../tier1/fileio.cpp (3897) : 
> >> Assertion Failed: CFileReader::Read must be called with a cubData 
> >> value that is a multiple of the sector size when using unbuffered 
> >> IO depotreconstruct.cpp (490) : Assertion Failed:
> pInfo->nNumWritesFinished > 0
> >> ../tier1/fileio.cpp 

Re: [hlds_linux] [hlds] Mandatory Team Fortress 2 update released

[sigsegv]

[CC'd to John Schoenick: please look into this, or forward it on to whoever
works on steamcmd.]

Yes, I too have run into this problem with steamcmd over the last week or
so, as my Linux dedicated server installation is on ZFS.

This appears to be a false positive from steamcmd: it queries the block
size of the filesystem and says "holy crap, 128KB? can't deal with that"
even though it isn't actually a problem since ZFS's recordsize isn't really
a fixed block size per se.

I found that reducing the 'recordsize' property of the ZFS volume from 128K
to 512 bytes made the errors go away, but then the ZFS performance became
hideously slow (not an unexpected result), so I didn't go forward with that
workaround.

(You can run the command 'stat -f .' on a directory to see what the
reported block size is; with recordsize=128K it was 128KB, and with
recordsize=512 it was 512B.)

For the time being, I found a reasonable workaround to be to mount an
ext4 partition on the steamapps/downloading directory. The game directory
itself can still be ZFS with normal 128K recordsize; it's just the
downloading directory that steamcmd loses its mind over. It'll copy the
updated files over to the ZFS game dir just fine.

Hope that helps, and I hope Valve fixes this brokenness...

Justin
(sigsegv)

On Wednesday, October 26, 2016, Charles Huber  wrote:

> Yup, I have the servers installed on a ZoL volume too, thanks for the
> confirmation!
>
> On Wed, Oct 26, 2016 at 11:05 AM, Jan >
> wrote:
> > Hey,
> >
> > are you using ZFS on linux?
> > I had the same problem, steamcmd failed to update the server. It works
> > only on my ext4 partition for some reason.
> > Maybe it is a combination of ZFS on linux and the fix for the dirty cow
> > bug: https://dirtycow.ninja/
> >
> >
> > On 26.10.2016 17:08, Charles Huber wrote:
> >> Hrm, still startup looping:
> >>
> >> WARNING: No map specified! Server may not heartbeat.
> >> Auto detecting CPU
> >> Using default binary: ./srcds_linux
> >> Server will auto-restart if there is a crash.
> >> Updating server using Steam.
> >> 
> >> Redirecting stderr to '/home/gameserver/Steam/logs/stderr.txt'
> >> Looks like steam didn't shutdown cleanly, scheduling immediate update
> check
> >> [  0%] Checking for available updates...
> >> [] Verifying installation...
> >> Steam Console Client (c) Valve Corporation
> >> -- type 'quit' to exit --
> >> Loading Steam API...Created shared memory when not owner
> >> SteamController_Shared_mem
> >> OK.
> >> login anonymous
> >>
> >> Connecting anonymously to Steam Public...Logged in OK
> >> Waiting for license info...OK
> >> force_install_dir ./tf2
> >> app_update 232250 validate
> >>  Update state (0x3) reconfiguring, progress: 0.00 (0 / 0)
> >> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
> >> be called with a cubData value that is a multiple of the sector size
> >> when using unbuffered IO
> >> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
> >> be called with a cubData value that is a multiple of the sector size
> >> when using unbuffered IO
> >>  Update state (0x81) committing, progress: 100.00 (180409744 /
> 180411440)
> >> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
> >> be called with a cubData value that is a multiple of the sector size
> >> when using unbuffered IO
> >> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
> >> be called with a cubData value that is a multiple of the sector size
> >> when using unbuffered IO
> >> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
> >> be called with a cubData value that is a multiple of the sector size
> >> when using unbuffered IO
> >> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
> >> be called with a cubData value that is a multiple of the sector size
> >> when using unbuffered IO
> >> depotreconstruct.cpp (490) : Assertion Failed:
> pInfo->nNumWritesFinished > 0
> >> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
> >> be called with a cubData value that is a multiple of the sector size
> >> when using unbuffered IO
> >> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
> >> be called with a cubData value that is a multiple of the sector size
> >> when using unbuffered IO
> >>  Update state (0x81) committing, progress: 99.97 (180357888 / 180411440)
> >>  Update state (0x81) committing, progress: 99.97 (180357888 / 180411440)
> >>  Update state (0x81) committing, progress: 99.97 (180357888 / 180411440)
> >> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
> >> be called with a cubData value that is a multiple of the sector size
> >> when using unbuffered IO
> >> Error! App '232250' state is 0x606 after update job.
> >> Redirecting stderr to '/home/gameserver/Steam/logs/stderr.txt'
> >>
> >>
> >>
> >>
> >> On Tue, Oct 25, 

Re: [hlds_linux] Mandatory Team Fortress 2 update released

[Charles Huber]

Yup, I have the servers installed on a ZoL volume too, thanks for the
confirmation!

On Wed, Oct 26, 2016 at 11:05 AM, Jan  wrote:
> Hey,
>
> are you using ZFS on linux?
> I had the same problem, steamcmd failed to update the server. It works
> only on my ext4 partition for some reason.
> Maybe it is a combination of ZFS on linux and the fix for the dirty cow
> bug: https://dirtycow.ninja/
>
>
> On 26.10.2016 17:08, Charles Huber wrote:
>> Hrm, still startup looping:
>>
>> WARNING: No map specified! Server may not heartbeat.
>> Auto detecting CPU
>> Using default binary: ./srcds_linux
>> Server will auto-restart if there is a crash.
>> Updating server using Steam.
>> 
>> Redirecting stderr to '/home/gameserver/Steam/logs/stderr.txt'
>> Looks like steam didn't shutdown cleanly, scheduling immediate update check
>> [  0%] Checking for available updates...
>> [] Verifying installation...
>> Steam Console Client (c) Valve Corporation
>> -- type 'quit' to exit --
>> Loading Steam API...Created shared memory when not owner
>> SteamController_Shared_mem
>> OK.
>> login anonymous
>>
>> Connecting anonymously to Steam Public...Logged in OK
>> Waiting for license info...OK
>> force_install_dir ./tf2
>> app_update 232250 validate
>>  Update state (0x3) reconfiguring, progress: 0.00 (0 / 0)
>> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
>> be called with a cubData value that is a multiple of the sector size
>> when using unbuffered IO
>> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
>> be called with a cubData value that is a multiple of the sector size
>> when using unbuffered IO
>>  Update state (0x81) committing, progress: 100.00 (180409744 / 180411440)
>> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
>> be called with a cubData value that is a multiple of the sector size
>> when using unbuffered IO
>> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
>> be called with a cubData value that is a multiple of the sector size
>> when using unbuffered IO
>> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
>> be called with a cubData value that is a multiple of the sector size
>> when using unbuffered IO
>> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
>> be called with a cubData value that is a multiple of the sector size
>> when using unbuffered IO
>> depotreconstruct.cpp (490) : Assertion Failed: pInfo->nNumWritesFinished > 0
>> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
>> be called with a cubData value that is a multiple of the sector size
>> when using unbuffered IO
>> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
>> be called with a cubData value that is a multiple of the sector size
>> when using unbuffered IO
>>  Update state (0x81) committing, progress: 99.97 (180357888 / 180411440)
>>  Update state (0x81) committing, progress: 99.97 (180357888 / 180411440)
>>  Update state (0x81) committing, progress: 99.97 (180357888 / 180411440)
>> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
>> be called with a cubData value that is a multiple of the sector size
>> when using unbuffered IO
>> Error! App '232250' state is 0x606 after update job.
>> Redirecting stderr to '/home/gameserver/Steam/logs/stderr.txt'
>>
>>
>>
>>
>> On Tue, Oct 25, 2016 at 3:26 PM, Eric Smith  wrote:
>>> We've released a mandatory update for Team Fortress 2. The notes for the 
>>> update are below. The new version is 3666413.
>>>
>>> -Eric
>>>
>>> --
>>>
>>> - Extended Scream Fortress VIII to run through November 16th, 2016
>>> - Fixed a problem causing some players to receive the incorrect number of 
>>> Merasmissions
>>> - Players should receive one Scream Fortress VIII Merasmission per 
>>> day of the event, for a maximum possible of seven as of today
>>> - Players who received too few Merasmissions will be able to 
>>> quickly catch up to the intended amount
>>> - A small number of players who received too many Merasmissions 
>>> will not receive any for the next few days
>>> - Fixed the Tome of Merasmissions displaying an erroneous maximum number
>>> - All players will have the opportunity to receive twenty-six 
>>> Merasmissions during this year's event, regardless of number of 
>>> Merasmissions completed in previous years
>>> - Fixed a small number of unusuals that did not have the proper displayed 
>>> quality (unique (golden name) instead of unusual (purple name))
>>> - Updated the model/materials for The El Paso Poncho
>>> - Fixed not seeing the correct display name for featured community maps 
>>> (example: pl_fifthcurve_event vs. Brimstone)
>>> - Updated the localization files
>>> - Updated mvm_ghost_town to fix error models in the spawn rooms
>>> - Updated 

Re: [hlds_linux] Mandatory Team Fortress 2 update released

[Jan]

Hey,

are you using ZFS on linux?
I had the same problem, steamcmd failed to update the server. It works
only on my ext4 partition for some reason.
Maybe it is a combination of ZFS on linux and the fix for the dirty cow
bug: https://dirtycow.ninja/


On 26.10.2016 17:08, Charles Huber wrote:
> Hrm, still startup looping:
>
> WARNING: No map specified! Server may not heartbeat.
> Auto detecting CPU
> Using default binary: ./srcds_linux
> Server will auto-restart if there is a crash.
> Updating server using Steam.
> 
> Redirecting stderr to '/home/gameserver/Steam/logs/stderr.txt'
> Looks like steam didn't shutdown cleanly, scheduling immediate update check
> [  0%] Checking for available updates...
> [] Verifying installation...
> Steam Console Client (c) Valve Corporation
> -- type 'quit' to exit --
> Loading Steam API...Created shared memory when not owner
> SteamController_Shared_mem
> OK.
> login anonymous
>
> Connecting anonymously to Steam Public...Logged in OK
> Waiting for license info...OK
> force_install_dir ./tf2
> app_update 232250 validate
>  Update state (0x3) reconfiguring, progress: 0.00 (0 / 0)
> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
> be called with a cubData value that is a multiple of the sector size
> when using unbuffered IO
> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
> be called with a cubData value that is a multiple of the sector size
> when using unbuffered IO
>  Update state (0x81) committing, progress: 100.00 (180409744 / 180411440)
> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
> be called with a cubData value that is a multiple of the sector size
> when using unbuffered IO
> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
> be called with a cubData value that is a multiple of the sector size
> when using unbuffered IO
> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
> be called with a cubData value that is a multiple of the sector size
> when using unbuffered IO
> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
> be called with a cubData value that is a multiple of the sector size
> when using unbuffered IO
> depotreconstruct.cpp (490) : Assertion Failed: pInfo->nNumWritesFinished > 0
> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
> be called with a cubData value that is a multiple of the sector size
> when using unbuffered IO
> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
> be called with a cubData value that is a multiple of the sector size
> when using unbuffered IO
>  Update state (0x81) committing, progress: 99.97 (180357888 / 180411440)
>  Update state (0x81) committing, progress: 99.97 (180357888 / 180411440)
>  Update state (0x81) committing, progress: 99.97 (180357888 / 180411440)
> ../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
> be called with a cubData value that is a multiple of the sector size
> when using unbuffered IO
> Error! App '232250' state is 0x606 after update job.
> Redirecting stderr to '/home/gameserver/Steam/logs/stderr.txt'
>
>
>
>
> On Tue, Oct 25, 2016 at 3:26 PM, Eric Smith  wrote:
>> We've released a mandatory update for Team Fortress 2. The notes for the 
>> update are below. The new version is 3666413.
>>
>> -Eric
>>
>> --
>>
>> - Extended Scream Fortress VIII to run through November 16th, 2016
>> - Fixed a problem causing some players to receive the incorrect number of 
>> Merasmissions
>> - Players should receive one Scream Fortress VIII Merasmission per 
>> day of the event, for a maximum possible of seven as of today
>> - Players who received too few Merasmissions will be able to quickly 
>> catch up to the intended amount
>> - A small number of players who received too many Merasmissions will 
>> not receive any for the next few days
>> - Fixed the Tome of Merasmissions displaying an erroneous maximum number
>> - All players will have the opportunity to receive twenty-six 
>> Merasmissions during this year's event, regardless of number of 
>> Merasmissions completed in previous years
>> - Fixed a small number of unusuals that did not have the proper displayed 
>> quality (unique (golden name) instead of unusual (purple name))
>> - Updated the model/materials for The El Paso Poncho
>> - Fixed not seeing the correct display name for featured community maps 
>> (example: pl_fifthcurve_event vs. Brimstone)
>> - Updated the localization files
>> - Updated mvm_ghost_town to fix error models in the spawn rooms
>> - Updated pl_fifthcurve_event (Brimstone)
>> - Fixed RED players getting inside BLU's 2nd forward spawn
>> - Fixed skull's teeth in hell being non-solid
>> - Fixed hell's coffin tune and tiny spell song sometimes playing to 
>> the next round from previous 

Re: [hlds_linux] Mandatory Team Fortress 2 update released

[Charles Huber]

Hrm, still startup looping:

WARNING: No map specified! Server may not heartbeat.
Auto detecting CPU
Using default binary: ./srcds_linux
Server will auto-restart if there is a crash.
Updating server using Steam.

Redirecting stderr to '/home/gameserver/Steam/logs/stderr.txt'
Looks like steam didn't shutdown cleanly, scheduling immediate update check
[  0%] Checking for available updates...
[] Verifying installation...
Steam Console Client (c) Valve Corporation
-- type 'quit' to exit --
Loading Steam API...Created shared memory when not owner
SteamController_Shared_mem
OK.
login anonymous

Connecting anonymously to Steam Public...Logged in OK
Waiting for license info...OK
force_install_dir ./tf2
app_update 232250 validate
 Update state (0x3) reconfiguring, progress: 0.00 (0 / 0)
../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
be called with a cubData value that is a multiple of the sector size
when using unbuffered IO
../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
be called with a cubData value that is a multiple of the sector size
when using unbuffered IO
 Update state (0x81) committing, progress: 100.00 (180409744 / 180411440)
../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
be called with a cubData value that is a multiple of the sector size
when using unbuffered IO
../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
be called with a cubData value that is a multiple of the sector size
when using unbuffered IO
../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
be called with a cubData value that is a multiple of the sector size
when using unbuffered IO
../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
be called with a cubData value that is a multiple of the sector size
when using unbuffered IO
depotreconstruct.cpp (490) : Assertion Failed: pInfo->nNumWritesFinished > 0
../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
be called with a cubData value that is a multiple of the sector size
when using unbuffered IO
../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
be called with a cubData value that is a multiple of the sector size
when using unbuffered IO
 Update state (0x81) committing, progress: 99.97 (180357888 / 180411440)
 Update state (0x81) committing, progress: 99.97 (180357888 / 180411440)
 Update state (0x81) committing, progress: 99.97 (180357888 / 180411440)
../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must
be called with a cubData value that is a multiple of the sector size
when using unbuffered IO
Error! App '232250' state is 0x606 after update job.
Redirecting stderr to '/home/gameserver/Steam/logs/stderr.txt'




On Tue, Oct 25, 2016 at 3:26 PM, Eric Smith  wrote:
> We've released a mandatory update for Team Fortress 2. The notes for the 
> update are below. The new version is 3666413.
>
> -Eric
>
> --
>
> - Extended Scream Fortress VIII to run through November 16th, 2016
> - Fixed a problem causing some players to receive the incorrect number of 
> Merasmissions
> - Players should receive one Scream Fortress VIII Merasmission per 
> day of the event, for a maximum possible of seven as of today
> - Players who received too few Merasmissions will be able to quickly 
> catch up to the intended amount
> - A small number of players who received too many Merasmissions will 
> not receive any for the next few days
> - Fixed the Tome of Merasmissions displaying an erroneous maximum number
> - All players will have the opportunity to receive twenty-six 
> Merasmissions during this year's event, regardless of number of Merasmissions 
> completed in previous years
> - Fixed a small number of unusuals that did not have the proper displayed 
> quality (unique (golden name) instead of unusual (purple name))
> - Updated the model/materials for The El Paso Poncho
> - Fixed not seeing the correct display name for featured community maps 
> (example: pl_fifthcurve_event vs. Brimstone)
> - Updated the localization files
> - Updated mvm_ghost_town to fix error models in the spawn rooms
> - Updated pl_fifthcurve_event (Brimstone)
> - Fixed RED players getting inside BLU's 2nd forward spawn
> - Fixed skull's teeth in hell being non-solid
> - Fixed hell's coffin tune and tiny spell song sometimes playing to 
> the next round from previous round
> - Fixed some players dropping into hell's lava in rare cases
> - Fixed big pumpkin in RED 2nd base being non-solid
> - Updated pd_pit_of_death_event
> - Fixed an exploit which allowed players to enter the enemy spawn
> - Fixed enemy players teleported to the Underworld spawning in one 
> another
> - Fixed finale particles not being drawn from certain distances
> - Fixed certain overlays 

Re: [hlds_linux] TF2 sv_shutdown behavior

[David Parker]

Hello,

I'm still seeing this behavior, with sv_shutdown not working even though
the server is empty when the command is issued.  Following the most recent
update, I checked the console of my TF server and it's still doing this:

sv_shutdown
sv_shutdown command received.
Server will shut down in -40800 seconds, or when it becomes empty.
MasterRequestRestart
Your server will be restarted on map change.
Your server will be restarted on map change.
Your server needs to be restarted in order to receive the latest update.
Your server needs to be restarted in order to receive the latest update.
sv_shutdown
sv_shutdown command received.
Server will shut down in -41100 seconds, or when it becomes empty.
MasterRequestRestart
Your server will be restarted on map change.
Your server will be restarted on map change.
Your server needs to be restarted in order to receive the latest update.
Your server needs to be restarted in order to receive the latest update.

Is this sv_shutdown behavior a bug?  Any chance this can be fixed?

- Dave

On Fri, Sep 30, 2016 at 2:17 PM, David Parker  wrote:

> I just got back to testing this.  The sv_shutdown command appears to still
> be broken.  If I run it in the console of an empty server, I get this:
>
> sv_shutdown
> sv_shutdown command received.
> Server will shut down in 600 seconds, or when it becomes empty.
>
> And then the server doesn't shut down.  I didn't wait the 600 seconds,
> because shouldn't it shut down immediately since the server is already
> empty?  I swear that's how it used to work.
>
> - Dave
>
> On Thu, Sep 29, 2016 at 3:56 PM, David Parker  wrote:
>
>> Thanks for the suggestion.  I had not set sv_shutdown_timeout_minutes, so
>> it was set to the default of 360.  I set it to 10 and we'll see if that
>> makes a difference.  Still doesn't explain why the server won't shutdown
>> even though it's empty, though.
>>
>> - Dave
>>
>> On Thu, Sep 29, 2016 at 10:47 AM, Wander  wrote:
>>
>>> Have you tried setting sv_shutdown_timeout_minutes? It's how many minutes
>>> it should wait to force a shutdown
>>>
>>> On 29 Sep 2016 4:06 p.m., "David Parker"  wrote:
>>>
>>> > Hello,
>>> >
>>> > I have a script which checks for updates to TF2 and sends the
>>> sv_shutdown
>>> > command to my TF2 server if an update is available.  This worked fine
>>> for
>>> > over a year, but recently TF2 has stopped shutting down like it's
>>> supposed
>>> > to.  Instead, I see messages like this in the console:
>>> >
>>> > sv_shutdown
>>> > sv_shutdown command received.
>>> > Server will shut down in -4862700 seconds, or when it becomes empty.
>>> >
>>> > But the server is empty when this happens, and has been for a long
>>> time.
>>> > Any ideas?
>>> >
>>> > Thanks!
>>> > Dave
>>> >
>>> > --
>>> > Dave Parker
>>> > Database & Systems Administrator
>>> > Utica College
>>> > Integrated Information Technology Services
>>> > (315) 792-3229
>>> > Registered Linux User #408177
>>> > ___
>>> > To unsubscribe, edit your list preferences, or view the list archives,
>>> > please visit:
>>> > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
>>> >
>>> ___
>>> To unsubscribe, edit your list preferences, or view the list archives,
>>> please visit:
>>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
>>>
>>
>>
>>
>> --
>> Dave Parker
>> Database & Systems Administrator
>> Utica College
>> Integrated Information Technology Services
>> (315) 792-3229
>> Registered Linux User #408177
>>
>
>
>
> --
> Dave Parker
> Database & Systems Administrator
> Utica College
> Integrated Information Technology Services
> (315) 792-3229
> Registered Linux User #408177
>



-- 
Dave Parker
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux