Closed guihkx closed 8 years ago
I decided to disable the auto-updates because since I use Mono, everytime there's an update I first go to Travis CI and see if it compiles OK using Mono.
Why? Auto-updates are always working with binary, and if you're using self-compiled build then you should have auto-updates completely disabled as you're compiling yourself.
Take a look at cc.sh
and run.sh
scripts - instead of relying on auto-updates you could simply put those two in a loop, so when ASF exits (e.g. by !exit
command) - script would automatically pull latest changes, compile, and run (with run.sh
).
I can understand the override with !update
, and it's valid suggestion that I +1, but it's most likely not what you want for your own purposes. Self-compiled build should have auto-updates disabled, that's one of the reasons why ASF will refuse to update if you run self-compiled (and recommended) ArchiSteamFarm.exe
binary instead of ASF.exe
dedicated for consumers.
I just check it on Travis CI because if it doesn't compile using Mono, I imagine it won't even run the binaries compiled on Windows? If I'm wrong I'm sorry, because what I'm asking would be pointless. >:D
So no, I don't compile it myself.
Travis and AppVeyor are there to watch the build process, which means if ASF compiles in given environment, and if it passes tests, but as ASF doesn't have any yet, only compilation process is checked.
So no, it's not equal to being able to run. There can be a binary that doesn't compile with Mono, but runs with Mono properly (e.g. because xbuild in given Mono version is broken), and there can also be build that compiles properly with Mono (xbuild), but doesn't work because Mono of given version is broken (very often case).
Travis and AppVeyor can be used to check if build is passing, which means if ASF is able to compile (and work) in current state. This is true nearly always, as I tend to avoid any build breakings (unless accidentally). But it's not reliable way of telling if such ASF is working properly.
Oh, interesting! Yeah, a couple of days ago I saw that the Mono build wasn't passing and the Windows one were fine, so I immediately disabled the auto-updates. Anyway, sorry for the misunderstanding and thank you.
Don't blindly trust Travis as well, build can fail very often due to things such as networking issues, packages being broken on Debian and many other cases - if build failed then it's wise to check why, because it could be a pure coincidence that e.g. mono repo was down at the time of the build due to networking issues.
So in the end, my suggestion remains same. If you're consumer and you don't want to bother with that stuff, you can't go wrong with auto updates being enabled. Of course, in very rare cases such as pre-releases or bugs slipping to stable releases, it's still possible of getting "broken" ASF, but such "broken" ASF is corrected quite fast (ASAP), and you can always download older binary from GitHub, disable auto-updates and keep using that version - I don't remove any version from GitHub, you can even use version 0.1 if you want to.
And if you're developer or user that wants to compile himself because of one reason or another - you shouldn't be using auto-updates at all (AutoUpdates
equal to false
and UpdateChanel
set to 0
), and instead handle updates manually with cc.sh
and run.sh
scripts, or whatever that suits you.
I appreciate the advices!
Also keep in mind that you don't need to compile in order to use ASF - official releases should work on both Windows and Mono. You can compile if you want to, but you're also good to go with wget ASF.exe
and mono ASF.exe
.
Even if I wanted I can't, my VPS server has only 128MB RAM, and right now I don't have any interest in compiling ASF myself. One thing I want to ask you though if you're familiar with systemd. I created an systemd unit file to run ASF whenever the server starts. If I'm running ASF directly from the terminal window and it starts updating, ASF is able to successfully re-open itself. However, if I start ASF using systemd and update it, for some reason that I'm not aware of, ASF can't re-open itself... Is this a mono or systemd issue? Or neither?
systemd expects service to be a daemon, and ASF (in default settings) acts as a program, not service.
If you want to run ASF as a service, consider setting AutoRestart
to false
, as stated in the wiki - this way ASF will only exit itself, instead of proceeding with the restart.
When that happens, systemd should be smart enough to notice that process exited, and if you configured your service properly - systemd should restart new ASF.
Another option is to avoid systemd, and instead use e.g. /etc/rc.local
and your own script, for example the one I wrote in wiki link above.
Also, if you're low on RAM, you might be interested in fine-tuning Mono for lower memory needs, e.g. by using --desktop
option, which should perform garbage collections more aggresively (for performance cost of course). There are also MONO_GC_PARAMS
and other things which you can find in man
or on Mono website. ASF code-wise tries to be as low on resources as possible, but garbage collector is controlled by runtime and not ASF itself.
Thank you very much, I'll be checking it when I get home.
Okay, so the first thing I noticed is that my config file was lacking the AutoRestart
option. After I added it and set it to false
, systemd will automatically restart ASF after an update. Yay!
Here's my current ASF.service
file, in case somebody searches for one... (tweaks are welcome!)
Description=Archi Steam Farm
[Service]
Type=simple
User=your_user
Environment="MONO_ENV_OPTIONS=--desktop --gc=sgen"
ExecStart=/usr/bin/mono /path/to/ArchiSteamFarm/ASF.exe
Restart=always
RestartSec=15s
[Install]
WantedBy=multi-user.target
Alias=asf.service
As I'm running ASF in a low-memory server, I've set ShutdownOnFarmingFinished=true
to all bots (I just leave one account online so I can issue commands!) and ASF can free some memory for other stuff I use in the server.
However, when I need to redeem a CD-KEY to a bot that's offline, I run !start bot
, ASF starts it normally, but immediatelly shuts the bot down when it realizes it has nothing to farm, and then I can't redeem the CD-KEY.
IMO, when you !start
a bot, it should not go offlinee unless you manually !stop
it, overriding the settings in the config file. However, I realized that when I use the !redeem
command to an offline bot, when it gets online I assume it tries to redeem it, but I get these errors:
http://pastebin.com/raw/rNFLYLfB
What do you think?
You've tried to redeem key on offline instance, so you got an exception - it's obvious.
ShutdownOnFarmingFinished
set to true
must exit also instances started with !start
, otherwise your bots would not automatically shutdown after farming is done.
The only thing which seems logical to me is waiting up to X seconds, and it nothing happens - shutdown.
I thought it was weird because when I redeemed the CD-KEY to that offline bot, nothing showed up in the console, I only got those messages after I !start
ed the bot. But I guess that's the expected behavior? I don't know, I don't have much knowledge of how ASF works. >:P
You can't redeem cd-key to an offline bot, because when bot is offline it's not connected with Steam. That's why exception is thrown.
Gotcha! I liked the new addition. Thanks!
BTW there is no need for --gc=sgen
as SGen
is default garbage collector since some time already in Mono.
Also I do not recommend Restart=always
, you don't want to restart ASF when it crashes or suddenly file disappears, right? Use Restart=on-success
instead - ASF uses proper exit code.
Okay, I'll remove the --gc
parameter. Yeah, it might not be good to Restart=always
, but in my experience, the mono process got killed so many times because it ran out of memory, so I just set it to restart always because it's annoying.
In this case I suggest catching Mono OOM exit code (I don't know which one it is) and using RestartForceExitStatus
, which is still better than restarting on every problem.
I'll definitely check it out. But changing a bit the subject (I know this isn't the right place, but I promise this is the last time hahah).
Do you know what is the requirement to get the unrestricted cards dropping? I noticed in the wiki page you say there's no obvious answer, but maybe the requirement is to at least have one badge manually crafted? From my observations in my accounts, I never issued a refund to any game I bought and in these accounts the drops are restricted. My accounts which don't have the restriction, have at least one badge crafted. Of course it needs more investigation into it, and people who got tons of bots maybe can verify this easily, but it's just a thought. I'm collecting cards to one game and I'll craft it on my restricted account and then I'll see if the restriction is removed right away or after a few days,
You're free to test - I don't know. I'm happy to update wiki with any valid theories if you find out something interesting, but I'm not going to become detective Archi trying to find out the reason of restricted card drops. Not to mention that the restriction can change without any reason as well (as stated).
Yeah, I've read about this, and none of my bots finishes farming before 2 hours... Anyway, I'll check if my theory is true and I'll give you a heads up. Thank you for your tremendous help,
BTW, I spent some time writing https://github.com/JustArchi/ArchiSteamFarm/wiki/Low-memory-setup - you might be interested in order to decrease memory usage of ASF and avoid Mono's OOM. More tricks and improvements are welcome.
Really useful article, thank you!
My ASF setup is pretty much the same as what you suggested on the ASF section, and they do help a lot. My low budget VPS server have 128MB of RAM, running CentOS 7.2.1511 64-bit and Mono 4.2.3 (by the way, feel free to add it to the "Supported/Tested Operating Systems" section if you want). And honestly, it suits my needs pretty well at the moment. I can have, for example, all of my 10 bots farming one game and ASF will use only 58.9MB of 128MB.
For now I don't intend to try the advanced setup, but maybe in the future when I have more bots or if I run out of memory. I did run out of memory before, but that was because some useless services were enabled. Now that I've disabled them, ASF is running flawlessly. :smile:
Thanks.
If the option
AutoUpdates
is disabled in the config file, when you manually issue the!update
command, ASF should ignore that option, because you're deciding to update it by yourself.I decided to disable the auto-updates because since I use Mono, everytime there's an update I first go to Travis CI and see if it compiles OK using Mono. Thanks