Unable to start service with --password flag

[LastElf]

Describe the bug
Starting Glances via systemctl with glances -w --password causes a crash with getpass.py, error log from systemctl status is below. It runs fine when run manually, it runs fine without the --password flag.
This is the third server I've set up with Glances today so I know the process worked, the other two servers didn't have an issue.

Expected behavior
The service to start running

Textshots
/etc/systemd/system/glances.service

[Unit]
Description=Glances
After=network.target

[Service]
ExecStart=/usr/local/bin/glances -w --password
Restart=on-abort
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

systemctl status glances.service

● glances.service - Glances
   Loaded: loaded (/etc/systemd/system/glances.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sun 2022-04-17 03:23:33 UTC; 10s ago
  Process: 8179 ExecStart=/usr/local/bin/glances -w --password (code=exited, status=1/FAILURE)
 Main PID: 8179 (code=exited, status=1/FAILURE)

Apr 17 03:23:33 dockernc glances[8179]:     password_sha256 = self.sha256_hash(getpass.getpass(description))
Apr 17 03:23:33 dockernc glances[8179]:   File "/usr/lib/python3.6/getpass.py", line 91, in unix_getpass
Apr 17 03:23:33 dockernc glances[8179]:     passwd = fallback_getpass(prompt, stream)
Apr 17 03:23:33 dockernc glances[8179]:   File "/usr/lib/python3.6/getpass.py", line 126, in fallback_getpass
Apr 17 03:23:33 dockernc glances[8179]:     return _raw_input(prompt, stream)
Apr 17 03:23:33 dockernc glances[8179]:   File "/usr/lib/python3.6/getpass.py", line 148, in _raw_input
Apr 17 03:23:33 dockernc glances[8179]:     raise EOFError
Apr 17 03:23:33 dockernc glances[8179]: EOFError
Apr 17 03:23:33 dockernc systemd[1]: glances.service: Main process exited, code=exited, status=1/FAILURE
Apr 17 03:23:33 dockernc systemd[1]: glances.service: Failed with result 'exit-code'.

Desktop (please complete the following information):

• OS: Ubuntu 18.04
• Glances Version v3.2.5
• Glances logs file not relevant, log says everything's fine
• Glances test All showing OK except smart is N/A

Additional context
This server was an odd one out, I had to run the install via pip3 instead of pip after installing all the python 3 requirements. I have uninstalled and reinstalled Python and the pre-reqs twice without a change, and removed the password file thinking that might have been corrupt.

I am technical (This will be going on Windows servers later too) but I'm not great on Linux, I just use it as a platform to host Docker containers but I want Glances outside of Docker in case my containers are busted.

[RazCrimson]

@LastElf

It runs fine when run manually, it runs fine without the --password flag.

Did you try manually running it with the --password flag? Or did you just run it manually without the --password

The error is probably due to glances prompting for the password.
Also I recommend adding User and Group under service, as glances would be running as root user now.

[LastElf]

Did you try manually running it with the --password flag? Or did you just run it manually without the --password

Yep, works manually with the password flag, remote login works with the password as expected. It's only if password is enabled in the service that doesn't work. Service works without the flag.

[RazCrimson]

@LastElf
Could you let me know where the password file that you have configured is located?

If you run glances as a systemd service without the User parameter, then glances would be running as the root user and will look for the password file in the root user's home directory (usually /root) not in your user's home directory.

If you are fine with running glances as a root process then you could try copying your password file to /root.
sudo cp ~/.config/glances/* /root/.config/glances

Other alternative would be to use the User=<your username here> parameter under Service section of the systemd unit.

[LastElf]

Other alternative would be to use the User= parameter under Service section of the systemd unit.

This worked, which is weird cause the other two servers I did also have custom root usernames but still run with the password without an issue. I knew about the password file (Had to do the same thing for my Windows server) but thought since the user I was setting it up with was root it would load it. Thanks for your help!