Package Details: steamcmd latest-3

Git Clone URL: (read-only, click to copy)
Package Base: steamcmd
Description: Steam Command Line Tools
Upstream URL:
Keywords: download games network server steam
Licenses: custom
Submitter: markzz
Maintainer: markzz
Last Packager: markzz
Votes: 108
Popularity: 1.32
First Submitted: 2014-01-01 02:21 (UTC)
Last Updated: 2019-03-24 20:06 (UTC)

Latest Comments

Zepman commented on 2021-11-15 18:28 (UTC)

To avoid SDL errors, install lib32-sdl2.

Zepman commented on 2021-11-15 11:03 (UTC)

This package misses dependency lib32-dbus. Without lib32-dbus, steamcmd is unusable.

$ steamcmd
Redirecting stderr to '/home/user/.steam/logs/stderr.txt'
ILocalize::AddFile() failed to load file "public/steambootstrapper_english.txt".
[  0%] Checking for available update...
[----] Verifying installation...
[  0%] Downloading Update...
[  0%] Checking for available update...
[----] !!! Fatal Error: Steamcmd needs to be online to update.   Please confirm your network connection and try again.
threadtools.cpp (3294) : Assertion Failed: Illegal termination of worker thread 'Thread(0x0x5822b320/0x0xf7768a'

Installing lib32-dbus avoids this error, and allows steamcmd to make network connections.

markzz commented on 2021-11-13 23:17 (UTC)

0x5a17ed: The package bash is part of the group base and is expected to be installed. Any package from base (and make dependencies from base-devel) are not required to be included as per the packaging guidelines on the wiki.

0x5a17ed commented on 2021-11-13 10:25 (UTC)

The package providing bash is not declared as a dependency in the PKGBUILD file. It's required to execute the command.

excerpt from the file:

#!/usr/bin/env bash


Managor commented on 2021-04-02 07:25 (UTC)

Steamcmd often complains that Warning: failed to init SDL thread priority manager: SDL not found. Should SDL be made into a dependency?

cl0ne commented on 2020-11-24 01:17 (UTC)

Current MD5 is 09e3f75c1ab5a501945c8c8b10c7f50e, and steamerrorreporter are not present anymore.

moll commented on 2019-08-06 15:16 (UTC) (edited on 2019-08-06 15:18 (UTC) by moll)


In the steamcmd script, you must quote the "$@", or else arguments with spaces in their names will get split a second time.


Seeing as that script was taken with little modifications from Debian, I will leave it as is.

Nah, this is definitely a bug in the script. $@ must be quoted or arguments are not properly passed on.

You can see this yourself in a tiny example:

cat $@
$ ./ "1 2"
cat: 1: No such file or directory
cat: 2: No such file or directory

This would be the fix:

diff --git a/PKGBUILD b/PKGBUILD
index ac36b24..e8c9446 100644
@@ -9,7 +9,7 @@ license=('custom')
 source=( steamcmd)
-         '5de1fddd114f10ff5d2a8fbeee044a8f')
+         '116e6dc3d17a90ca4372235fa575263e')

diff --git a/steamcmd b/steamcmd
index 22a942c..ca2c1e8 100755
--- a/steamcmd
+++ b/steamcmd
@@ -21,4 +21,4 @@ then
     cp /usr/share/steamcmd/ ~/.steam/steamcmd/
     cp /usr/share/steamcmd/linux32/steamcmd ~/.steam/steamcmd/linux32/steamcmd
-exec ~/.steam/steamcmd/ $@
+exec ~/.steam/steamcmd/ "$@"

finesse commented on 2019-06-20 01:25 (UTC) (edited on 2019-06-20 01:35 (UTC) by finesse)

Can anyone else confirm that upgrading to kernel 5.1.11 breaks steamcmd? I keep getting time outs when trying to retrieve data. Downgrading kernel fixed it for me.

markzz commented on 2019-04-28 03:10 (UTC)

Seeing as that script was taken with little modifications from Debian, I will leave it as is.

lhark commented on 2019-04-28 03:06 (UTC)

In the steamcmd script, you must quote the "$@", or else arguments with spaces in their names will get split a second time.

markzz commented on 2019-03-14 19:38 (UTC)

Nukesor: I will get this updated and I will model this package after the one in Debian's repositories to not interfere with a possible steam desktop install.

Nukesor commented on 2019-03-04 13:59 (UTC)

The download link is obsolete. There is a new one from the official docs:}

curl -sqL ""

Please fix this one :) Otherwise the current version needs root access to update itself and can't be executed by an unprivileged user.

markzz commented on 2018-10-12 16:20 (UTC)

eimis: Your initial run of steamcmd needs to be ran as root to update steamcmd itself. Once this is done, you can run it as a non-root user to install the application you want with it.

eimis commented on 2018-10-12 15:49 (UTC)

Debian managed to package this properly - works fine on non privileged user. Works fine after chowning -R user.users the staemcmd dir.

Freso commented on 2018-02-05 12:04 (UTC)

Wouldn't it be possible to make a "steam" or "steamcmd" Unix group (or maybe even user as Valve suggests: ) and give that permissions instead of having to run as root?

markzz commented on 2017-10-27 15:48 (UTC)

Please read the note on the Wiki before using this PKGBUILD:

markzz commented on 2017-10-26 23:43 (UTC)

jtmb, Shatur, gary9872: Try running steamcmd as root to update.

gary9872 commented on 2017-09-13 01:42 (UTC)

+1 for Shatur

Shatur commented on 2017-09-01 23:21 (UTC) (edited on 2017-09-02 09:14 (UTC) by Shatur)

I suggest to add this line in steamcmd.install in post_install() section: chmod -R a+rwX /usr/share/steamcmd/ Otherwise this app doesn't work with this output: [gena@AlienwareM15x ~]$ steamcmd Redirecting stderr to '/home/gena/.local/share/Steam/logs/stderr.txt' ILocalize::AddFile() failed to load file "public/steambootstrapper_english.txt". ILocalize::AddFile() failed to load file "public/steambootstrapper_russian.txt". [ 0%] Checking for available update... [ 0%] Download Complete. [gena@AlienwareM15x ~]$

jtmb commented on 2017-09-01 23:10 (UTC)

I was unable to properly run steamcmd until I modified the permissions of /usr/share/steamcmd/public. I used chmod 777 on all the bootstrapper txt files. Probably not the best permission, but it worked.

demon012 commented on 2016-10-26 07:30 (UTC)

The URL in the package for downloading steamcmd does not seem to work anymore. This one does though: Please update the URL in the pkgbuild so that it builds cleanly again (I was getting an executable html file where the steamcmd binary was supposed to be).

markzz commented on 2016-10-16 20:47 (UTC)

JoZ3: They are the same file, therefore no change is needed.

JoZ3 commented on 2016-10-16 17:31 (UTC)

Change source to

markzz commented on 2016-02-20 06:49 (UTC)

I am on vacation from the time of this comment until 2016-03-01 and will not make changes to this package until I'm back home.

02m commented on 2016-02-20 00:31 (UTC)

I have tried to install this, and it still creates a /root/Steam folder. Could this package be updated to not use root?

markzz commented on 2016-02-08 01:07 (UTC)

I'm leaving it as is for now. End of discussion.

edh commented on 2016-02-08 00:49 (UTC)

Just please don't run it as root in the .install file... However like I already said it is your package! Do whatever you thing is appropiate but my point about that partial upgrades - and updating steamcmd manually is exactly that - are unsupported is not an opinion but a statement from the Arch devs.

markzz commented on 2016-02-08 00:30 (UTC)

I disagree, so therefore I will not make it run in build().

edh commented on 2016-02-08 00:27 (UTC)

Partial upgrades are always unsupported! In case one starts installing upgrades without using pacman one should be aware of that pacman can not track them anymore. Furthermore pacman does not even complain about that it just assumes files to be unchanged which in this case is absolutely okay.

markzz commented on 2016-02-08 00:05 (UTC)

The flaw in your way is that when steamcmd updates itself, the files will then no longer be tracked by pacman in the way you want it to. The reason I did it the way in steam.install was because I didn't want to have pacman be responsible for tracking files that can change or be removed.

edh commented on 2016-02-07 23:58 (UTC)

? My initial problem was that steamcmd was run as root in the .install file which led to /root/Steam being created. Therefore a whole dir was not being properly tracked by pacman which should not be located their anyway. Running it in the PKGBUILD makes sure that it is not run by root (since this is prohibited) and pacman can track the created files. Furthermore the newly crafted .install file helps organize and secure game builds to come. The error log residing under ~/.local/share/Steam/logs/stderr.txt is now just a minor problem.

markzz commented on 2016-02-07 23:47 (UTC)

Which doesn't solve your initial problem.

edh commented on 2016-02-07 23:38 (UTC)

I managed to achieve this by running " +quit" in the build() function. In addition it also lets pacman track most of the files which previously were not. Though with one minor flaw: The initial build log is still put into the users home directory.

markzz commented on 2016-02-07 23:32 (UTC)

Since I'm on vacation next week and am doing things in preparation for my absence, this will be put off for the moment. What my plan is to read into the steamcmd "ConVars" and to just simply change this package to save the logs and other related things into /var/lib/steamcmd/. If possible, of course.

edh commented on 2016-02-07 23:25 (UTC)

I got that but the location is just one variable which I set for my own personal use. It was not meant to be a copy and pasty solution.

markzz commented on 2016-02-07 23:22 (UTC)

I'm still putting my foot down that I'm not going to install it into /srv. Sorry.

edh commented on 2016-02-07 22:50 (UTC)

I would be interested whether you think something like this makes sense [1]. Please feel free to critizise whatever you want. [1]

edh commented on 2016-02-06 19:41 (UTC)

Sounds reasonable. Thanks.

markzz commented on 2016-02-06 19:12 (UTC) (edited on 2016-02-06 19:22 (UTC) by markzz)

I personally use /var/lib simply because other Arch Linux packages use that for a home folder for users that don't need to be in /home. If you wish to use /srv, it's your machine and you're free to put files where you please. You have to remember the UNIX filesystem hierarchy is a guideline, but not a must-do. Arch Linux itself breaks rules regarding this topic. Also, the only reason Volvo wishes you to create a new user (at least by my interpretation) is to avoid installing server software with root. What I'll do is think about revising some of the parts of this package to use a separate user (probably a steamcmd user, and it's home folder will be in /var/lib to conform with other Arch Linux packages). Deal?

edh commented on 2016-02-06 17:58 (UTC)

Sure this is fine as well. Though currently this package executes at least once steamcmd as root in the .install file which leads to /root/Steam being created. I would expect this package to be installed how it is recommended by the steam developers themselfs. Additionally I think /srv is a much more appropiate place for game files since according to the common filesystem hierachy it is supposed to be the "the location of the data files for particular service, and so that services which require a single tree for readonly data, writable data and scripts (such as cgi scripts) can be reasonably placed." [1] while /var/lib clearly serves a different purpose [2]. But hell it is your package! This is just my point of view. [1] [2]

markzz commented on 2016-02-06 17:16 (UTC) (edited on 2016-02-06 19:01 (UTC) by markzz)

I don't agree because it's not running as a daemon. Also, you should not run this as root (unless to run an update for SteamCMD itself). Furthermore, there's nothing stopping you from creating a user. When I use this, I create a user for the specific game (like tf2) and create a directory in /var/lib (e.g. /var/lib/tf2) and run steamcmd as that user just for that game.

edh commented on 2016-02-06 16:55 (UTC)

It is recommended that an extra user is created for SteamCMD [1]. I would suggest adapting the install file to properly implement that. It took me some time to figure out how to do that properly for a pacakge of mine so please feel free to build on top of my script [2]. Please set an appriopate home (maybe /srv/steam/) for that user and make sure to use it for running steamcmd since currently there is some junk residing in /root/Steam where it definitely should not belong. If you need any help please let me know and I would be happy to send some patches. Btw. tabs ftw! :D [1] [2]

WorMzy commented on 2014-01-28 19:43 (UTC)

Thanks for the quick update.

markzz commented on 2014-01-28 16:09 (UTC)

Updated PKGBUILD with WorMzy's suggestions.

WorMzy commented on 2014-01-28 13:57 (UTC)

Nice PKGBUILD. Three points though: 1. Why are you extracting the tarball in the build function when the tarball is automagically extracted by makepkg? 2. Why cd into $srcdir at the start of the package function when you don't use relative paths? 3. A package built with this PKGBUILD on a x86_64 system will have an additional dependency to a package built on a i686 system, which the i686 system will not be able to resolve, so the 'any' architecture is not accurate. You should specify 'i686' and 'x86_64' instead. Also, tabs are evil, but that's just my opinion. :P

markzz commented on 2014-01-18 15:32 (UTC)

Thanks, didn't think about passing arguments.

sten_gun commented on 2014-01-18 02:57 (UTC)

There's an error into /usr/bin/steamcmd startscript: you must add $@ for additional arguments to exec /usr/share/steamcmd/, or you'll be not able to pass direct commands to original steamcmd script like steamcmd +login anonymous.

markzz commented on 2014-01-06 00:20 (UTC)

steamdedicatedserver merged with steamcmd

markzz commented on 2014-01-05 23:08 (UTC) (edited on 2016-02-17 06:16 (UTC) by markzz)

This package (steamdedicatedserver) is depreciated by Valve in favor of SteamCMD. I have recently added SteamCMD to the AUR.

jnbek commented on 2011-12-10 18:05 (UTC)

Sure wish this would get fixed..

feilen commented on 2011-09-16 20:35 (UTC)

I built glibc 2.13 and ran it with LD_LIBRARY_PATH. Same problem...

feilen commented on 2011-09-16 19:51 (UTC)

Apparently the segfaults are caused by glibc being updated. I'll see what can be done...

tea commented on 2011-08-26 14:23 (UTC)

Segfault on 32bit, too.

laasonen commented on 2011-05-14 04:40 (UTC)

I haven't installed this package, but I'm getting this when I'm trying to upgrade the srcds: "[S_API FAIL] SteamAPI_Init() failed; unable to update local steamclient.dll. Continuing with current version anyway. pipes.cpp (706) : Assertion Failed: Stalled cross-thread pipe /home/VALVE/rackadmin/buildslave/steam_rel_client_linux/build/src/clientdll/../common/pipes.cpp 706 Assertion Failed: Stalled cross-thread pipe pipes.cpp (706) : Fatal assert failed: /home/VALVE/rackadmin/buildslave/steam_rel_client_linux/build/src/clientdll/../common/pipes.cpp, line 706. Application exiting."

tea commented on 2011-05-11 17:03 (UTC)

I'm on 64bit and I get a segfault running hldsupdatetool.bin. Not sure why, don't know what I'm missing.

commented on 2011-04-28 03:20 (UTC)

A note to 64 bit server admins running metamod/sourcemod with this steam server: you need lib32-glibc lib32-gcc-libs from [multilib] or development versions of mm/sm or it will complain about and not work at present. Many thanks to a user named "WindPower" for the info, but I figured it may help someone here too. I don't think it is necessary to add these to the pkgbuild dependency list, as it will be fixed in a later version somehow, I gather, but I'm not sure.

commented on 2010-12-06 04:10 (UTC)

Your tarball has some issues. AUR guidelines suggest to not include binaries. Take for example: steamdedicatedserver/helperscripts.tar.gz Try to find sources for the binaries instead of embedding them. And that binary compressed file you included? I bet if you google around you can find a URL for it. Please correct this.