Concern about SSH Connection Termination and Daemon Process Closure

Hi there,

I hope this message finds you well. I have been using an SSH client to connect to a remote server and run a daemon process. However, I noticed that when I disconnect from the SSH session, the daemon process is closed as well. I’m wondering if this is the expected behavior or if there might be something misconfigured on my end.

Here are some details regarding my setup:

Operating System: Manjaro GNOME
Connection Method: SSH

I have tried searching for information on this issue, but I haven’t been able to find a clear answer. Could you please help me understand if it is normal for the daemon process to be terminated when the SSH connection is closed? If so, is there any way to keep the process running even after disconnecting from the SSH session?

Thank you very much for your attention to this matter. I appreciate any guidance or suggestions you can provide.

Best regards


Additional information:

Manjaro GNOME Can’t work properly,
but Ubuntu is normal.

I checked the historical Topics, try to set the /etc/systemd/logind.conf.d/20- kill-user-processses.conf to NO, or removed this file. It’s not working.

when I disconnect from the SSH session, the daemon process is closed as well.

run app:
image

ps command:
image

pstree command:

my app code:

if appDaemon {
			if util.IsWindows() {
				return errors.New("daemon: Non-POSIX OS is not supported")
			}
			cntxt := &daemon.Context{
				PidFileName: serverPidFile,
				PidFilePerm: 0664,
				LogFileName: serverLogFile,
				LogFilePerm: 0640,
				WorkDir: currentFolder,
				Umask: 027,
				Args: []string{"", "app", "start", "--daemon=true"},
			}
			child, err := cntxt.Reborn()
			if err != nil {
				return err
			}
			if child != nil {
				fmt.Println("pid:", child.Pid)
				fmt.Println("log:", serverLogFile)
				return nil
			}
			defer cntxt.Release()
			fmt.Println("daemon started")
			if err := startAppServe(container, server); err != nil {
				fmt.Println(err)
			}
			return nil
		}

If the daemon is started as a regular process with & at the end, then yes. The parent process is still your remote shell, so if you close the remote shell, the daemon is killed.

Use nohup to start the daemon. :point_down:

nohup <name-of-process> &

But I use the Go-Daemon library to start the process,

If you look at it with the PS command, PPID = 1 and TT =?, Should this be separated from SSH Session?

And it works on other Linux distributions, such as Ubuntu.

You should not start a long running process in an interactive shell. Create for your daemon a systemd service file and the the process with systemd.

1 Like

I have an APP management program that restarts the APP service through the APP management program. The APP management program is used to launch an independent guardian process. It is reasonable to say that it should not be associated with the SSH link

If you start a process via an interactive shell, this process and all processes started by this process is associated to this interactive shell. This is an important security feature. If this is a problem for you, you should rethink your “APP” design.

1 Like

Are you suggesting that all applications should consider using tools like systemctl for management? It feels a bit strange to me, and the logic of the daemon works effectively on most other distributions, but fails on Manjaro.

No. systemctl is for humans not applications. For example D-Bus messages are for processes to communicate with other processes. If you do some research, you might find something that fits your use case better.

I just want to implement a simple automated deployment process, where I can upload deployment files to the server using SSH and SFTP, and then trigger the app’s built-in restart functionality. Using a daemon to independently start a new process seems like a straightforward and user-friendly choice. My question is, why is it possible to achieve this on other distributions but not on Manjaro? Is it due to an issue with the system or something I might be doing wrong?