[BUG] Changing default user shell renders LinuxGSM inoperable

[Memphizzz]

User Story

It looks like LinuxGSM does not take kindly to changing the users default shell.
Example: the vhserver user has default shell /usr/bin/fish set when running wget -O linuxgsm.sh https://linuxgsm.sh && chmod +x linuxgsm.sh && bash linuxgsm.sh vhserver and ./vhserver install. Starting and stopping the server works just fine using ./vhserver start/stop. Now if we change the shell to bash for example chsh -s /bin/bash. ./vhserver stop or /vhserver details doesn't seem to work at all anymore whereas start does start the server but the shell hangs with output [ .... ] Starting vhserver: <serverName>.

Basic info

• Distro: Ubuntu 20.04
• Game: Valheim but not really relevant I assume
• Command: any
• LinuxGSM version: v20.1.3

Further Information

To Reproduce

Steps to reproduce the behaviour:

1. Install a valheim server for example with default shell set to /usr/bin/fish for the vhserver user
2. Start stop the server using ./vhserver start ./vhserver stop
3. Change the default shell using chsh -s /bin/bash to bash
4. Use exit to quit the current shell and login again using su - vhserver
5. Try to start/stop the server now using the commands above in bash

Expected behaviour

Same as when using /usr/bin/fish.

[dgibbs64]

LinuxGSM is written in bash and not tested with another shell such as fish.

[Memphizzz]

I understand that but that shouldn't force the users shell to bash now does it?
Shouldn't a simple shebang like #!/bin/bash or even better #!/usr/bin/env bash be an easy fix for this?
As far as I can see the vhserver file itself contains it but it might be missing in some other scripts that get called by it?
Whatever the case, the fact remains that after changing the shell to bash this problem occurs. I assume the script is somewhere storing something from the shell it was installed with which then doesn't work after changing the shell to bash.

[dgibbs64]

Every file contains '#!/bin/bash' on its first line so I am unsure why you are having issues with this 🤔

[Memphizzz]

I will try and analyze it a bit more in the coming days, for now I have to leave the shell set to fish as a workaround then. Interestingly creating a sub-process using bash -c './vhserver details' from fish does work but it refuses to work if the login shell is set to bash. I suspect it has something to do with environment variables..

[Xalorous]

I understand that but that shouldn't force the users shell to bash now does it?

Actually, yes. Fish !=bash. Those who run fish do so because they want something that it offers that bash does not.

If you want a gameserver system that runs in fish, you can always fork it and port it. @dgibbs64 created and maintains this on a volunteer basis, with support from donations, and with help from contributors, but the product is free to use.

It would be extremely difficult to maintain this project in two shells. Also, if the project adds fish, what about Bourne, C shell, zsh? Lots of folks use these shells as well. Go into the repo here and look at all the files. Yes, there are bashisms hardcoded into this complex code. No, it's not reasonable to expect a piece of software written in a shell script to run in all shells.

Bottom line, bash is a prerequisite for the user created to run the scripts.

My suggestion? Delete the gameserver user, or at least the linuxgsm files in that user's home. Create a new user or users to run your server or servers. Make their shell /bin/bash. Install fresh. Leave their shells alone. The gameserver admin uses a handlful of commands, and even adding optional cron jobs for updates and status monitoring is simple enough in bash. This will not prevent you from using fish on any number of user accounts.

[WildPenquin]

My 2 cents as another regular user:

This seems like a bug in Fish, if I've uinderstood the bug report correctly. I.e.: installing via fish produces different output than installing via bash. Another point of view: fish does not actually run the scripts by bash despite them having the shebang, or if it does run scripts by itself by design, it should behave like bash - not something else. Either way, it's a bug in fish. These are bash scripts and should remain compatible with bash despite being run by fish.

I would suggest repeat this bug with a clean user account running fish and then make exact same thing with another user account running bash and then compare the difference. Otherwise it can be a bit difficult to see what is actually going on with fish.

Another point: one should not run linuxgsm with a user which has the user shell set to something which could be considered "exotic" from linuxgsm's point of view. I know it can be considered as a workaround (in fish or LinuxGSM) and as such is not an excuse to fixing actual bugs, however running server software as a regular user with their own configuration (being set up like how it is for whatever reason) is like asking for trouble, and generally not a good idea IMHO.

(EDITed second paragraph, it was conveying a wrong message I was trying to say!)

[Memphizzz]

@WildPenquin It actually doesn't though, the scripts run fine in fish. It just for some reason that when you switch the shell to bash that it stops working.

[WildPenquin]

@WildPenquin It actually doesn't though,

What doesn't what?

Fish certainly does something differently than bash (<- this is my claim!), since the installation stops working with bash if you've made it with fish (as per your bug report). That's why I suggested you re-create the situation once more with fish and make an identical installation with bash and compare (with diff or something similar). That way we can see where fish goes wrong - or, maybe there's something else going on. Either way, without this comparison IMO this bug report should be closed (though I'm not the one to make that decision), and with that comparison you could gather enough information to make a bug report against fish or (in the unlikely event) perhaps have some grounds for keeping this bug report open.

[Memphizzz]

@WildPenquin It doesn't give different output.

@WildPenquin @Xalorous Since the shebang is present everywhere, it ensures that bash is used to interpret the script even if launched from another shell, in other words the script is executed in bash no matter what shell runs the script, hence my confusion on why changing the login shell TO bash messes things up.

[Xalorous]

Bottom line, LGSM is supported on bash, not fish. So this is not a bug in LGSM (I'm using "the code doesn't do something that it is supposed to do" as a working definition of bug). Having said that, I have no problem working to help find out if there is a workaround here. From what I understand the sequence went like this: 1. lgsm installed in fish 2. installed game server in fish 3. that server worked in fish 4. the maintenance scripts worked? (I'm not clear on this) 5. user shell changed to bash (I'm not clear why a change was made to a running system) 6. maintenance scripts stopped working When you went from "working under fish" to "switched to bash", you may have lost environment variables or configuration that is needed. I'm curious, did you reload the environment after changing to bash? The easiest way would be to modify the default environment of the user, log out, then log in again. Finally, if your goal is to learn about Linux and system administration, this is an interesting exercise. If you just want the server to be up and running, my suggestion remains what it was before. Use a stock, out of the box user, with bash, for the server admin. I recommend a dedicated vm for the game server. If you want to learn Linux admin, or various tools under Linux, build one or more separate vms. If you use snapshots liberally, you can break and revert your vms at will.

…

On Thu, Mar 4, 2021 at 6:15 AM WildPenguin ***@***.***> wrote: @WildPenquin <https://github.com/WildPenquin> It actually doesn't though, What doesn't what? Fish certainly does something differently than bash (<- this is my claim!), since the installation stops working with bash if you've made it with fish (as per your bug report). That's why I suggested you re-create the situation once more with fish and make an identical installation with bash and compare. That way we can see where fish goes wrong - or, maybe there's something else going on. Either way, without this comparison IMO this bug report should be closed (though I'm not the one to make that decision), and with that comparison you could gather enough information to make a bug report against fish or (in the unlikely event) perhaps have some grounds for keeping this bug report open. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3313 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACZD77YNFDOIWOKEXHFWRTDTB52WNANCNFSM4YLLYMJQ> .

[Memphizzz]

@dgibbs64 I found the issue. It's the tmux list-sessions... call in check_status.sh. To verify if tmux is installed the script seems to be using dpkg-query but if the system has another tmux version installed besides the one from the distro and in it's PATH the call to tmux might use the wrong binary. I would suggest having the installer script also store the full path of the dependencies (using dpkg -L <package> for example) and use that to call them.