Skip to content

systemd unit won't persist #1673

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
hluker opened this issue May 19, 2020 · 17 comments · Fixed by #1997
Closed

systemd unit won't persist #1673

hluker opened this issue May 19, 2020 · 17 comments · Fixed by #1997

Comments

@hluker
Copy link

hluker commented May 19, 2020

  • Web Browser: Chrome 81.0.4044.129
  • Local OS: Windows 10 10.0.18363 Build 18363
  • Remote OS: Debian 10
  • code-server --version: 3.3.0 52eecca
    Note: running behind Apache reverse-proxy

Last night, I re-built my development server and installed Code Server 3.3 using the guide provided (thanks!). Previously, I managed it via a systemd service which launched it on start-up and kept it running -- the guide now states to use 'systemctl --user restart code-server,' which works fine and launches it when the shell is open, but closes it when I close the shell. Is this behavior by design / is there any guidance for keeping it running?

@nhooyr nhooyr added the waiting-for-info Waiting for more information from submitter label May 19, 2020
@nhooyr
Copy link
Contributor

nhooyr commented May 19, 2020

If you run:

systemctl --user enable --now code-server

As mentioned in the guide, it should launch on startup.

restart is only for reloading from the config file.

If that doesn't work, lmk and I'll reopen this issue.

@nhooyr nhooyr closed this as completed May 19, 2020
@hluker
Copy link
Author

hluker commented May 19, 2020

Same behavior with that command. Stays open for as long as the Terminal window is open.

@nhooyr nhooyr reopened this May 19, 2020
@nhooyr
Copy link
Contributor

nhooyr commented May 19, 2020

Interesting, will try to reproduce.

@hluker
Copy link
Author

hluker commented May 19, 2020

Just as a note, I've upgraded to 3.3.1 6f13097 with same behavior observed.

@nhooyr nhooyr changed the title Code server doesn't remain open after closing shell How to make systemd unit persist after exiting terminal? May 19, 2020
@nhooyr nhooyr added needs-investigation and removed waiting-for-info Waiting for more information from submitter labels May 19, 2020
@nhooyr
Copy link
Contributor

nhooyr commented May 19, 2020

Seems to work for me.

I created a Debian 10 VM on GCP and then installed code-server with the instructions from the guide. Then followed the guide to setup a self signed certificate and listen on 0.0.0.0:443. Verified I could connect to the instance's public IP and then rebooted.

Confirmed I could access code-server once the instance was up. Did not login into the VM until I verified I could access code-server.

@nhooyr
Copy link
Contributor

nhooyr commented May 19, 2020

Might be something different about your systemd setup.

We're also using a systemd service but it's a systemd user service.

It's at https://github.com/cdr/code-server/blob/aa872701481ad371f25a6cc7042ca1e55d05e782/ci/build/code-server.service and installed as part of the .deb.

What does systemctl get-default print?

@hluker
Copy link
Author

hluker commented May 19, 2020

Prints graphical.target

@nhooyr
Copy link
Contributor

nhooyr commented May 19, 2020

Seems right to me.

How about systemctl --user status code-server?

@hluker
Copy link
Author

hluker commented May 19, 2020

image

It's perplexing. It works as long as my user is logged in, and Nagios confirms that Node is running, but as soon as I exit the terminal, the application stops and Nagios says Node is not running.

@nhooyr
Copy link
Contributor

nhooyr commented May 19, 2020

Do you see any logs in journalctl --user -u code-server?

@hluker
Copy link
Author

hluker commented May 19, 2020

Negatory.

@nhooyr
Copy link
Contributor

nhooyr commented May 19, 2020

I'm stumped. Can you try a fresh machine with Debian 10?

@hluker
Copy link
Author

hluker commented May 19, 2020

Yeah, I can. This was basically straight off a clean Deb10 distro last night, so I'm not sure what good it will do, but I'll try and let you know. The only slight deviation off your guide is that I'm running it through an Apache reverse proxy as opposed to Caddy; not sure if that would make a difference.

@nhooyr
Copy link
Contributor

nhooyr commented May 19, 2020

Shouldn't be a problem re Apache.

Weird thing is also I just tested a fresh Deb10 machine on GCP so then I'm not sure what the difference is between our setups.

If you copy the systemd user service and turn it into a system service, do things operate as expected?

@nhooyr nhooyr changed the title How to make systemd unit persist after exiting terminal? systemd unit won't persist May 19, 2020
@hluker
Copy link
Author

hluker commented May 19, 2020

I tried that earlier, copying it into /etc/systemd/system, running systemctl start code-server -- it would say that it was active, but nothing would happen.

Here's my Apache and config files for further
image
image

@hluker
Copy link
Author

hluker commented May 19, 2020

I think I might have fixed it. Tried a reboot with this and works normally now:
sudo loginctl enable-linger username
Sorry for all of the the trouble; appreciate the work you guys put into this.

@nhooyr
Copy link
Contributor

nhooyr commented May 19, 2020

I think I might have fixed it. Tried a reboot with this and works normally now:

Nice 🚀

Sorry for all of the the trouble; appreciate the work you guys put into this.

All good, appreciate the discusssion, didn't know you could configure lingering.

@nhooyr nhooyr closed this as completed May 19, 2020
nhooyr added a commit that referenced this issue Jul 22, 2020
systemd's user units are buggy on certain versions
and do not linger by default.

Closes #1771 #1673 #1882 #1861
nhooyr added a commit that referenced this issue Jul 22, 2020
systemd's user units are buggy on certain versions
and do not linger by default.

Closes #1771 #1673 #1882 #1861
nhooyr added a commit that referenced this issue Jul 22, 2020
systemd's user units are buggy on certain versions
and do not linger by default.

Closes #1771 #1673 #1882 #1861
nhooyr added a commit that referenced this issue Jul 22, 2020
systemd's user units are buggy on certain versions
and do not linger by default.

Closes #1771
Closes #1673
Closes #1882
Closes #1861
nhooyr added a commit that referenced this issue Jul 22, 2020
systemd's user units are buggy on certain versions
and do not linger by default.

Closes #1771
Closes #1673
Closes #1882
Closes #1861
nhooyr added a commit that referenced this issue Jul 22, 2020
systemd's user units are buggy on certain versions
and do not linger by default.

Closes #1771
Closes #1673
Closes #1882
Closes #1861
nhooyr added a commit that referenced this issue Jul 22, 2020
systemd's user units are buggy on certain versions
and do not linger by default.

Closes #1771
Closes #1673
Closes #1882
Closes #1861
nhooyr added a commit that referenced this issue Aug 4, 2020
systemd's user units are buggy on certain versions
and do not linger by default.

Closes #1771
Closes #1673
Closes #1882
Closes #1861
nhooyr added a commit that referenced this issue Aug 25, 2020
systemd's user units are buggy on certain versions
and do not linger by default.

Closes #1771
Closes #1673
Closes #1882
Closes #1861
nhooyr added a commit that referenced this issue Aug 26, 2020
systemd's user units are buggy on certain versions
and do not linger by default.

Closes #1771
Closes #1673
Closes #1882
Closes #1861
nhooyr added a commit that referenced this issue Aug 27, 2020
systemd's user units are buggy on certain versions
and do not linger by default.

Closes #1771
Closes #1673
Closes #1882
Closes #1861
nhooyr added a commit that referenced this issue Aug 27, 2020
systemd's user units are buggy on certain versions
and do not linger by default.

Closes #1771
Closes #1673
Closes #1882
Closes #1861
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants