SSH तुटल्यानंतरही tmux मध्ये Claude Code चालवा

लॅपटॉपचे झाकण समस्या आहे, CLI नाही

लॅपटॉपचे झाकण बंद करेपर्यंत Claude Code व्यवस्थित चालते. झाकण बंद केल्यावर SSH session बंद होते, shell ला SIGHUP मिळतो आणि test run सुरू झाल्यानंतर तीन मिनिटांनी agent देखील बंद होतो. कधीही sleep मध्ये न जाणाऱ्या मशीनवर CLI चालवा. ते SSH session ची child processes नसलेल्या terminal multiplexer मध्ये चालवा. हाच संपूर्ण उपाय आहे. यामध्ये install पेक्षा tmux अधिक महत्त्वाचा भाग आहे.

ही पृष्ठिका अशा मशीनचे संचालन करण्याबद्दल आहे, जिथे तुम्ही agents चालू ठेवू शकता. सतत सुरू ठेवता येईल असा Linux server तुमच्याकडे नसेल, तर यापैकी काहीही लागू होत नाही. हीच एक आवश्यक पूर्वअट आहे.

tmux प्रत्यक्षात काय करते

तुम्ही SSH द्वारे लॉग इन करता तेव्हा, sshd एक shell fork करते आणि त्याला pseudo-terminal देते; त्या shell मधून सुरू केलेली प्रत्येक प्रक्रिया तिची child असते. कनेक्शन तुटल्यावर kernel pty काढून टाकतो, shell ला SIGHUP मिळतो आणि ती पुढे आपल्या child प्रक्रियांनाही hangup करते. त्यामुळे foreground मध्ये चालणाऱ्या दीर्घकाळाच्या प्रक्रिया बंद होतात.

tmux मध्ये प्रक्रिया-मालकीची रचना उलट असते. तुम्ही टाइप केलेली tmux command unix socket द्वारे तुमच्या terminal पासून स्वतंत्रपणे चालणाऱ्या tmux server शी संवाद साधणारा thin client असतो. Session मधील shells या sshd च्या नव्हे, तर त्या server च्या children असतात. SSH कनेक्शन बंद केल्यावर client निघून जातो; पण server, session आणि त्यामध्ये सुरू असलेला agent चालू राहतो. पुन्हा कनेक्ट करा, tmux attach चालवा आणि तुम्ही त्याच shell मध्ये, त्याच scrollback सह परत येता. nohup hangup नंतरही चालू राहते; परंतु त्यात पुन्हा प्रवेश करण्याची कोणतीही पद्धत नसते. Background मध्ये पाठवलेल्या TUI ला पुन्हा attach करता येत नाही. Claude Code interactive आहे; त्यामुळे tmux (किंवा screen) हे योग्य साधन आहे.

सर्व्हरचे आकारमान

CLI ही Node प्रक्रिया आहे; मशीनची संसाधने ती स्वतः वापरून संपवत नाही. मशीनची संसाधने तुमच्या वतीने agent चालवत असलेल्या गोष्टी वापरतात: build, पूर्ण test suite, tsc, language server किंवा Docker मधील database. त्यामुळे CLI साठी नव्हे, तर toolchain साठी सर्व्हरचे आकारमान ठरवा. तुम्ही swap कधीही वापरणार नसला तरी ते जोडा. त्यामुळे कठोर OOM kill ऐवजी build धीम्या गतीने चालेल:

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

डिस्कवरही लक्ष ठेवा: repos, node_modules आणि Docker images वेगाने साठतात. Toolchain containers च्या पुढे जाऊन पूर्ण virtual machines, KVM guest किंवा स्थानिक Kubernetes node चालवत असल्यास, अंतिम निर्णय घेण्यापूर्वी plan मध्ये CPU virtualisation extensions उपलब्ध आहेत का ते तपासा. कारण VPS वर nested virtualization चालवणे ही सुविधा provider ने सक्षम करायची असते; guest मधून ती सुरू करता येत नाही.

प्रथम non-root वापरकर्ता

स्वतंत्र home directory असलेला dedicated वापरकर्ता तयार करा आणि त्याची public key योग्य ठिकाणी ठेवा:

sudo adduser --disabled-password --gecos "" agent
sudo install -d -m 700 -o agent -g agent /home/agent/.ssh
sudo cp ~/.ssh/authorized_keys /home/agent/.ssh/authorized_keys
sudo chown agent:agent /home/agent/.ssh/authorized_keys
sudo chmod 600 /home/agent/.ssh/authorized_keys

पुढे जाण्यापूर्वी दुसऱ्या terminal मधून login करून तपासा. Fallback म्हणून password authentication अद्याप सक्षम ठेवा. login करताना publickey साठी Permission denied असा संदेश आल्यास, समस्या सहसा key मध्ये नसते. ती .ssh directory च्या ownership किंवा mode मध्ये असते.

जाणीवपूर्वक, agent हा sudo group मध्ये नाही. एखादे system package आवश्यक असल्यास ते install करा. या एका निर्णयामुळे एखाद्या अनपेक्षित shell command मुळे host बिघडण्याचे बहुतेक मार्ग बंद होतात.

दीर्घकाळ सुरू ठेवलेल्या सर्व्हरसाठी SSH स्वच्छता

सार्वजनिक इंटरनेटवर दिवसभर उपलब्ध असलेल्या आणि agent तसेच तुमचा source code ठेवणाऱ्या मशीनवर password authentication सुरू ठेवणे अनावश्यक जोखीम आहे. ते बंद करा. Ubuntu 24.04 आणि Debian 13 मध्ये /etc/ssh/sshd_config मध्ये /etc/ssh/sshd_config.d/*.conf समाविष्ट आहे. त्यामुळे मुख्य configuration संपादित करण्याऐवजी स्वतंत्र file ठेवा:

# /etc/ssh/sshd_config.d/10-hardening.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

तपासणी करून reload करा. चाचणी करताना सध्याचे session उघडे ठेवा आणि दुसऱ्या terminal मधून नवीन session वापरून पाहा:

sudo sshd -t && sudo systemctl restart ssh

Ubuntu 24.04 संदर्भात एक महत्त्वाची बाब आहे: sshd socket-activated आहे. Authentication settings systemctl restart ssh वर लागू होतात. मात्र listening Port मध्ये बदल केल्यास systemctl daemon-reload आणि ssh.socket restart करणे देखील आवश्यक आहे.

त्यानंतर firewall configure करा. Firewall enable करण्यापूर्वी SSH ला परवानगी द्या. अन्यथा तुम्ही स्वतःलाच server बाहेरून access करण्यापासून रोखाल:

sudo ufw allow OpenSSH
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

fail2ban install करण्यापूर्वी त्याचा उपयोग स्पष्टपणे समजून घ्या. Password authentication बंद केल्यानंतर brute-force प्रयत्न यशस्वी होऊ शकत नाहीत. fail2ban मुळे अशा अयशस्वी प्रयत्नांची नोंद journal मध्ये होण्यापासून रोखली जाते.

# /etc/fail2ban/jail.local
[sshd]
enabled = true
backend = systemd
maxretry = 5
bantime = 1h

शेवटी sudo apt install unattended-upgrades आणि sudo dpkg-reconfigure -plow unattended-upgrades वापरून automatic patching सुरू करा. tmux सोबत याचा परिणाम लक्षात घ्या: Unattended-Upgrade::Automatic-Reboot सुरू केल्यास kernel update नंतर server reboot होतो आणि सर्व session बंद होतात. ते बंद ठेवा आणि तुमच्या वेळापत्रकानुसार reboot करा, म्हणजे त्या वेळी कोणतेही काम सुरू नसेल. हीच खबरदारी release upgrade साठीही लागू होते: Ubuntu 24.04 वरून 26.04 वर server हलवणे sshd आणि kernel restart करते. त्यामुळे ज्या वेळी महत्त्वाचे काम असलेले tmux session सुरू नसतील, त्याच maintenance window मध्ये हे करा.

Ubuntu वर Node.js आणि Claude Code स्थापित करा

Claude Code हे Node CLI आहे. त्यामुळे सध्याचे Node आवश्यक आहे. Distro package अनेकदा जुन्या आवृत्तीचे असते. Ubuntu आणि Debian वर NodeSource हा नेहमीचा मार्ग आहे. त्यासोबत signed repo मिळते (`apt-key` आवश्यक नाही; ते साधन आता वापरात नाही):

curl -fsSL https://deb.nodesource.com/setup_24.x | sudo -E bash -
sudo apt install -y nodejs
node --version

आता लोकांकडून होणारी सामान्य चूक टाळा: CLI तुमच्या agent user म्हणून स्थापित करा; sudo npm -g सह कधीही स्थापित करू नका. Root-owned global prefix मुळे पुढे permission errors येतात आणि npm cache मध्ये root-owned files तयार होतात. प्रथम npm चा prefix user च्या home directory कडे निर्देशित करा:

mkdir -p ~/.npm-global
npm config set prefix ~/.npm-global
echo 'export PATH="$HOME/.npm-global/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
npm install -g @anthropic-ai/claude-code
claude --version

हा export ~/.bashrc मध्ये असतो, ~/.profile मध्ये नाही. तसेच तो file च्या सुरुवातीला असलेल्या “If not running interactively, don't do anything” guard च्या वर असावा. tmux non-login shells सुरू करू शकतो. हे shells ~/.bashrc वाचतात आणि ~/.profile वगळतात. ~/.profile फक्त login shells साठी चालते. nvm सारख्या version manager द्वारे per-user Node वापरल्यास हाच परिणाम मिळतो. कोणताही मार्ग निवडला तरी npm install -g साठी sudo आवश्यक नसावे. npm अजूनही व्यवस्थित कार्य करते. किंवा Anthropic चे native install script वापरा; सध्या documentation मध्ये हाच default आहे. Paste करण्यापूर्वी Anthropic चे install docs तपासा. Install methods बदलू शकतात.

Repo च्या आत claude चालवून ते सुरू करा. पहिल्या run मध्ये authentication साठी आवश्यक टप्पे दाखवले जातात. Headless box वर browser नसतो. त्यामुळे flow तुम्ही स्वतःच्या machine वर उघडण्यासाठी एक URL आणि terminal मध्ये परत आणण्यासाठी एक code देते. (Environment मधील API key हा दुसरा मार्ग आहे.) कोणताही मार्ग वापरला तरी ती credential आता server वर साठवली जाते. पुढे अनेकदा वगळला जाणारा भाग याच्याशी संबंधित आहे.

धोक्याचा विस्तार

Shell access असलेला agent म्हणजे shellच असतो. तो ज्या user म्हणून चालतो, त्या user ला वाचता येणारी कोणतीही गोष्ट तो वाचू शकतो आणि त्या user ला जिथे push करता येते तिथे push करू शकतो. ही tool ची उणीव नाही; ही त्याची व्याख्याच आहे. म्हणून agent ज्या account अंतर्गत चालतो ते कोणत्याही स्वतंत्र setting पेक्षा अधिक महत्त्वाचे असते.

• स्वतंत्र, unprivileged user. कोणताही sudo group नसावा आणि तुमच्या स्वतःच्या account सोबत home directory share केलेली नसावी.
• या मशीनवर production credentials ठेवू नका. production keys असलेले ~/.aws/credentials ठेवू नका, production मधून कॉपी केलेले .env ठेवू नका आणि महत्त्वाच्या कोणत्याही गोष्टीवर write access असलेला database password ठेवू नका. Agent ला staging किंवा read-only credential द्या.
• मर्यादित tokens. एका repository पुरता मर्यादित fine-grained GitHub token वापरा; read access पुरेसे असल्यास deploy key वापरा.

Claude Code मध्ये permission prompts पूर्णपणे वगळणारा flag आहे. Laptop किंवा तात्पुरत्या project वर तो वापरायचा की नाही हे तुमच्या निर्णयावर आहे. परंतु tokens असलेल्या server वर तो वापरल्यास चुकीच्या समजलेल्या instruction आणि git push --force यांच्यामध्ये उरलेला शेवटचा अडथळाही दूर होतो. तुम्ही वगळत असलेले prompts हे पूर्णपणे all-or-nothing नसतात. तसेच नवीन default म्हणून auto mode उपलब्ध होत असल्याने, तुम्ही monitor करत नसलेल्या server वर कोणता permission mode निश्चित ठेवायचा हे जाणून घेणे महत्त्वाचे आहे. हा flag नेमका काय बदलतो आणि तो वापरून चालणाऱ्या agent ला कसे मर्यादित ठेवायचे, built-in sandbox पासून disposable VPS पर्यंत, याचे वर्णन server वर Claude Code सुरक्षितपणे चालवणे येथे केले आहे.

Deploy key विरुद्ध SSH agent forwarding

Git ला तुमच्या laptop वरील key वापरता यावी म्हणून ssh -A करणे आकर्षक वाटू शकते. परंतु त्यामुळे कोणता access मिळतो हे समजून घ्या: agent forwarding मुळे तुमच्या local SSH agent चे socket त्या box वर त्या user म्हणून चालणाऱ्या processes साठी उपलब्ध होते. agent म्हणून चालणारी कोणतीही गोष्ट, agent सहित, तुम्ही connected राहिलात तोपर्यंत तिला पोहोचता येणाऱ्या कोणत्याही host साठी signature तयार करण्यास तुमच्या key ला सांगू शकते. हे “या एका repo साठी git pull करू द्या” यापेक्षा खूप अधिक access आहे.

त्याऐवजी server वर key generate करा. ती प्रत्येक repository साठी deploy key म्हणून register करा; agent ला push करायचे असल्यासच write access द्या. त्यानंतर box वरून केलेले commits ओळखता यावेत यासाठी git identity सेट करा:

ssh-keygen -t ed25519 -C "agent deploy key" -f ~/.ssh/id_ed25519_repo
cat ~/.ssh/id_ed25519_repo.pub   # paste into the repo's Deploy Keys
git config --global user.name "Agent (build box)"
git config --global user.email "agent@example.com"

tmux कार्यपद्धती

ते स्थापित करा (sudo apt install tmux), त्यानंतर किमान ~/.tmux.conf:

set -g mouse on
set -g history-limit 50000
set -g default-terminal "tmux-256color"

दैनंदिन वापरासाठी चार commands पुरेसे आहेत:

tmux new -A -s claude     # attach to session "claude", creating it if absent
# ...run `claude` inside it, work normally...
# Ctrl-b then d           -> detach; everything keeps running
tmux ls                   # list sessions
tmux attach -t claude     # reattach, from this machine or any other
tmux kill-session -t claude

tmux new -A -s claude हे लक्षात ठेवण्यासारखे command आहे. Session अस्तित्वात असल्यास ते त्याला जोडते आणि नसल्यास तो तयार करते. त्यामुळे दिवसाची सुरुवात करणे आणि connection तुटल्यानंतर पुन्हा जोडणे या दोन्हीसाठी एकच command वापरता येतो. त्याचा alias तयार करा. Session मध्ये Ctrl-b c नवीन window उघडते, Ctrl-b n आणि Ctrl-b p त्यांमध्ये पुढे-मागे फिरवतात, तर Ctrl-b [ मागील मजकूर पाहण्यासाठी copy mode सुरू करते (बाहेर पडण्यासाठी q वापरा).

तुम्ही कधीही बंद न करणाऱ्या sessions संदर्भात एक गोष्ट लक्षात ठेवा: agent प्रत्येक turn वेळी संपूर्ण conversation पुन्हा पाठवतो. त्यामुळे एखादी session आठवडाभर सुरू ठेवण्यापूर्वी दीर्घकाळ सुरू असलेली Claude Code session तिचे tokens कशावर खर्च करते हे वाचा.

अपयशाच्या परिस्थिती

"माझे session नाहीसे झाले." tmux ls, no server running on /tmp/tmux-1000/default दाखवते. याचा अर्थ जवळजवळ नेहमी असा असतो की process tmux मध्ये चालूच नव्हता, तुम्ही SSH द्वारे login करून claude थेट चालवले आणि connection तुटल्यावर तो process बंद झाला. पुनर्प्राप्त करण्यासारखे काहीही नाही. हे टाळण्यासाठीची सवय: प्रत्येक login नंतरची पहिली command tmux new -A -s <project> असावी.

Pane अतिशय छोट्या चौकटीत आकुंचन पावतो. tmux session चा आकार जोडलेल्या clients पैकी सर्वात लहान client नुसार ठरवतो. त्यामुळे दुसऱ्या machine वरून अजून जोडलेला जुना client display अरुंद करतो. जोडताना इतर clients सक्तीने disconnect करा: tmux attach -d -t claude.

Build Killed दाखवतो. फक्त एक शब्द, stack trace नाही. sudo dmesg -T | grep -i -E 'out of memory|killed process' वापरून खात्री करा; kernel OOM killer ने सर्वात मोठा process निवडला आहे. Node मधून त्याऐवजी FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory दिसू शकते. उपायांचा क्रम असा: वर दिल्याप्रमाणे swap जोडा, test आणि compiler ची parallelism मर्यादित करा, NODE_OPTIONS=--max-old-space-size=... वापरून Node ची heap वाढवा किंवा VPS चे आकारमान वाढवा. OOM killer build ऐवजी tmux server देखील निवडू शकतो आणि त्यामुळे तुमचे session बंद होऊ शकते; systemd-oomd चालू असल्यास, त्याच परिणामाने तो संपूर्ण user slice बंद करू शकतो.

npm error code EACCES / permission denied, mkdir '/usr/lib/node_modules/...'. root च्या मालकीच्या prefix मध्ये global install केले आहे. वरील ~/.npm-global prefix वापरा. तुम्ही यापूर्वी कधीतरी sudo npm चालवले असल्यास Your cache folder contains root-owned files देखील दिसू शकते; sudo chown -R $(id -u):$(id -g) ~/.npm वापरून दुरुस्ती करा.

claude: command not found, पण फक्त कधीकधी. तुमचे PATH export, "If not running interactively, don't do anything" या guard खालील ~/.bashrc मध्ये आहे. त्यामुळे non-interactive shells ते वगळतात. हे export त्या guard च्या वर हलवा आणि ते ~/.bashrc मध्येच ठेवा, ~/.profile मध्ये नाही: tmux non-login shells सुरू करू शकतो. हे shells ~/.bashrc वाचतात आणि ~/.profile ला कधीही हात लावत नाहीत.

Attach केल्यानंतर रंग विस्कळीत दिसतात. हा TERM mismatch आहे. वरील default-terminal ओळ त्याचे निराकरण करते.

Reboot नंतर sessions नाहीसे होतात. ही bug नाही: tmux server हा process आहे आणि reboot मुळे तो बंद होतो. uptime तपासा.

हे वाढत असताना काय बिघडते

अधिक प्रकल्प. प्रत्येक repository साठी एक tmux session ठेवा आणि त्याला repository च्या नावावरून नाव द्या; त्यानंतर tmux ls हे तुमचे dashboard ठरते. नामकरणाची शिस्त पाळली नाही, तर 0, 1 आणि 2 अशी sessions तयार होतात. एकाच वेळी अनेक sessions चालू असतील, तरी त्यांना स्वतंत्रपणे काम करावे लागेलच असे नाही. कारण एकाच मशीनवरील एक session दुसऱ्या session कडे संदेश पाठवू शकते. उदाहरणार्थ, दीर्घ refactor करणाऱ्या agent ला दुसऱ्या agent कडून tests चालवून घ्यायचे असतील, तर हे उपयुक्त ठरते. Ports ची संख्याही अशाच प्रकारे वाढते. सहा repositoriesना :3000 हाच port हवा असेल, तर ports स्वतः वाटप करणे थांबवून Docker Compose अंतर्गत अनेक अॅप्सना hostname नुसार route करण्यासाठी Traefik reverse proxy वापरण्याची वेळ आली आहे.

अधिक वापरकर्ते. tmux sockets प्रति-वापरकर्ता असतात. त्यामुळे एकाच मशीनवरील दोन developersना स्वतंत्र tmux servers मिळतात आणि ते एकमेकांच्या sessions पाहू शकत नाहीत. Shared socket वापरून एक session share केल्यास, सर्वजण समान Unix user म्हणून त्याच shell मध्ये input देतात. यामुळे audit आणि permissions संदर्भातील परिणाम उद्भवतात. स्वतंत्र users वापरणे हे साधे आणि योग्य उत्तर आहे.

नजर ठेवली जात नसलेले काम. tmux हे तुम्ही attach होऊन वापरत असलेल्या interactive sessions साठी आहे. कोणीही पाहत नसताना schedule नुसार चालणारी jobs systemd unit आणि timer मध्ये ठेवावीत. त्यांना logging, restart policy आणि boot नंतर सुरू राहण्याची सुविधा आपोआप मिळते. cron-सदृश job चालवण्यासाठी tmux वापरण्याचा प्रयत्न होत असेल, तर ती job service म्हणून चालवण्याची गरज असल्याचे ते सूचित करते.

शेवटची एक सूचना: agent ने सुरू केलेले dev servers 127.0.0.1 ला bind करा, 0.0.0.0 ला नाही. Ports ufw मध्ये उघडण्याऐवजी त्यांच्यापर्यंत SSH tunnel (ssh -L 3000:127.0.0.1:3000 agent@your-server) द्वारे पोहोचा. अर्धा डझन ports forward करावे लागत असतील, किंवा phone आणि laptop दोघांनाही त्याच preview पर्यंत पोहोचायचे असेल, तर त्यांच्यासमोर VPS वर self-hosted WireGuard VPN ठेवा. Dev servers private interface ला bind होतील आणि ufw public interface वरील सर्व traffic नाकारत राहील. Firewall उपयोगी ठरण्यासाठी त्यात सतत अपवाद जोडणे थांबवावे लागते.

Claude Code हा एकमेव पर्याय नाही: VPS वर coding AI agent चालवताना Aider आणि Goose यांचाही विचार करता येतो.

FAQ

Claude Code तुमचे SSH कनेक्शन तुटल्यानंतरही चालू राहते का?

फक्त ते tmux मध्ये सुरू केले असेल तरच. SSH shell मधून थेट सुरू केलेली process त्या shell ची child असते आणि connection तुटल्यावर pty सोबत बंद होते. tmux मध्ये shell detached tmux server शी संबंधित असते. त्यामुळे agent कामाच्या मध्यातही सुरू राहतो आणि tmux attach तुम्हाला त्याच scrollback मध्ये परत आणते. प्रत्येक login नंतर tmux new -A -s <project> हा पहिला command चालवा. त्यामुळे ही समस्या दूर होते.

sudo npm install -g वापरून CLI install करावे का?

नाही. root-owned global prefix मुळे पुढील install वेळी EACCES errors येतात आणि npm cache मध्ये root-owned files तयार होतात. npm चा prefix ~/.npm-global वर सेट करा किंवा nvm सारखा version manager वापरा. install हे unprivileged agent user म्हणून करा आणि ~/.bashrc मधून interactive guard च्या वर PATH वर ~/.npm-global/bin export करा. तुम्ही sudo npm आधीच एकदा चालवले असेल, तर sudo chown -R $(id -u):$(id -g) ~/.npm ने cache दुरुस्त करा.

agent चालू असलेल्या box वर ssh -A agent forwarding सुरक्षित आहे का?

यामुळे job ला आवश्यकतेपेक्षा खूप अधिक अधिकार मिळतात. Forwarding मुळे त्या user म्हणून चालणाऱ्या प्रत्येक process ला तुमच्या स्थानिक SSH agent चा socket उपलब्ध होतो. त्यामुळे तुम्ही connection जोडलेले असेपर्यंत box वरील कोणतीही process, तिला पोहोचता येणाऱ्या कोणत्याही host साठी तुमच्या key कडून signing करून घेऊ शकते. Server वर ed25519 key तयार करा आणि ती प्रत्येक repository साठी deploy key म्हणून register करा. Agent ला प्रत्यक्ष push करणे आवश्यक असेल तेव्हाच write access द्या.

माझा build फक्त Killed का दाखवतो?

Stack trace नसलेला एकच शब्द kernel OOM killer कडे निर्देश करतो. sudo dmesg -T | grep -i -E 'out of memory|killed process' ने याची पुष्टी करा. Node मधून त्याऐवजी JavaScript heap out of memory दिसू शकते. उपाय क्रमाने करा: swapfile जोडा, test आणि compiler parallelism ला मर्यादा घाला, NODE_OPTIONS=--max-old-space-size=... वाढवा आणि नंतर VPS चे आकारमान वाढवा. OOM killer build ऐवजी tmux server निवडू शकतो, याची जाणीव ठेवा. त्यामुळे तुमचे संपूर्ण session बंद होऊ शकते.

tmux की systemd service?

ज्या interactive sessions शी तुम्ही attach होता, त्यांचे निरीक्षण करता आणि त्यात input देता, त्यांच्यासाठी tmux योग्य आहे. Agent session नेमके असेच असते. कोणीही निरीक्षण न करता schedule वर चालणारे काम systemd unit आणि timer मध्ये असावे. तेथे logging, restart policy आणि boot नंतरही चालू राहण्याची सुविधा आपोआप मिळते. cron सारखे काम चालवण्यासाठी तुम्ही tmux वापरण्याचा विचार करत असाल, तर ते काम service म्हणून चालवणे योग्य आहे.