starred/LinuxGSM

Fork 0

mirror of https://github.com/GameServerManagers/LinuxGSM.git synced 2026-04-25 06:05:57 +03:00

[GH-ISSUE #3313] [BUG] Changing default user shell renders LinuxGSM inoperable #2289

New issue

Open

opened 2026-02-27 03:02:01 +03:00 by kerem · 11 comments

kerem commented

2026-02-27 03:02:01 +03:00

Owner

Originally created by @Memphizzz on GitHub (Feb 28, 2021).
Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/3313

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:

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

Expected behaviour

Same as when using /usr/bin/fish.

Originally created by @Memphizzz on GitHub (Feb 28, 2021). Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/3313 ## 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` 4. Try to start/stop the server now using the commands above in bash ## Expected behaviour Same as when using /usr/bin/fish.

kerem added the

type: bug

distro: Ubuntu

labels

2026-02-27 03:02:01 +03:00

kerem commented

2026-02-27 03:02:02 +03:00

Author

Owner

@dgibbs64 commented on GitHub (Feb 28, 2021):

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

@dgibbs64 commented on GitHub (Feb 28, 2021): LinuxGSM is written in bash and not tested with another shell such as fish.

kerem commented

2026-02-27 03:02:02 +03:00

Author

Owner

@Memphizzz commented on GitHub (Feb 28, 2021):

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.

@Memphizzz commented on GitHub (Feb 28, 2021): 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.

kerem commented

2026-02-27 03:02:02 +03:00

Author

Owner

@dgibbs64 commented on GitHub (Feb 28, 2021):

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

@dgibbs64 commented on GitHub (Feb 28, 2021): Every file contains '#!/bin/bash' on its first line so I am unsure why you are having issues with this 🤔

kerem commented

2026-02-27 03:02:02 +03:00

Author

Owner

@Memphizzz commented on GitHub (Feb 28, 2021):

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..

@Memphizzz commented on GitHub (Feb 28, 2021): 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..

kerem commented

2026-02-27 03:02:02 +03:00

Author

Owner

@Xalorous commented on GitHub (Mar 3, 2021):

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.

@Xalorous commented on GitHub (Mar 3, 2021): `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.

kerem commented

2026-02-27 03:02:02 +03:00

Author

Owner

@WildPenquin commented on GitHub (Mar 4, 2021):

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!)

@WildPenquin commented on GitHub (Mar 4, 2021): 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!)

kerem commented

2026-02-27 03:02:02 +03:00

Author

Owner

@Memphizzz commented on GitHub (Mar 4, 2021):

@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.

@Memphizzz commented on GitHub (Mar 4, 2021): @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.

kerem commented

2026-02-27 03:02:02 +03:00

Author

Owner

@WildPenquin commented on GitHub (Mar 4, 2021):

@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.

@WildPenquin commented on GitHub (Mar 4, 2021): > @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.

kerem commented

2026-02-27 03:02:02 +03:00

Author

Owner

@Memphizzz commented on GitHub (Mar 4, 2021):

@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.

@Memphizzz commented on GitHub (Mar 4, 2021): @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.

kerem commented

2026-02-27 03:02:02 +03:00

Author

Owner

@Xalorous commented on GitHub (Mar 4, 2021):

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:

lgsm installed in fish
installed game server in fish
that server worked in fish
the maintenance scripts worked? (I'm not clear on this)
user shell changed to bash (I'm not clear why a change was made to a
running system)
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 notifications@github.com 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
https://github.com/GameServerManagers/LinuxGSM/issues/3313#issuecomment-790575493,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACZD77YNFDOIWOKEXHFWRTDTB52WNANCNFSM4YLLYMJQ
.

@Xalorous commented on GitHub (Mar 4, 2021): 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 <notifications@github.com> 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 > <https://github.com/GameServerManagers/LinuxGSM/issues/3313#issuecomment-790575493>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACZD77YNFDOIWOKEXHFWRTDTB52WNANCNFSM4YLLYMJQ> > . >

kerem commented

2026-02-27 03:02:02 +03:00

Author

Owner

@Memphizzz commented on GitHub (Mar 4, 2021):

@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.

@Memphizzz commented on GitHub (Mar 4, 2021): @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.

kerem referenced this issue

2026-02-27 03:55:00 +03:00

[PR #2289] [MERGED] fix(fix): re-add fix_tf2 and minor fix refactor #3572