I have a tmuxinator (note not tmux, tmuxinator) project running on Ubuntu 18.04 (running in headless/server mode). My tmuxinator project file is located in the default directory of /home/karsh/.tmuxinator/testProject.yml. When I am SSH'ed into the system and just run tmuxinator start testProject via the terminal, everything runs normally and a new Tmux session gets launched with my project configurations.
My goal is to run this command automatically when the computer boots up. My approach was to create a systemd service file located at /etc/systemd/system/testProject.service with the following settings:
[Unit]
Description=Test Project
[Service]
Type=forking
ExecStart=/usr/bin/tmuxinator start testProject
[Install]
WantedBy=multi-user.target
However, when I start this service via sudo systemctl start testProject.service, it crashes. Upon checking status using sudo systemctl status testProject.service, I get the following errors:
● testProject.service - Test Project
Loaded: loaded (/etc/systemd/system/testProject.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Fri 2022-04-08 06:08:43 CST; 8s ago
Process: 3298 ExecStart=/usr/bin/tmuxinator start testProject (code=exited, status=1/FAILURE)
Main PID: 32756 (code=exited, status=1/FAILURE)
4月 08 06:08:43 nvidia-desktop systemd[1]: Starting Test Project
4月 08 06:08:43 nvidia-desktop tmuxinator[3298]: Project testProject doesn't exist.
4月 08 06:08:43 nvidia-desktop systemd[1]: testProject.service: Control process exited, code=exited status=1
4月 08 06:08:43 nvidia-desktop systemd[1]: testProject.service: Failed with result 'exit-code'.
4月 08 06:08:43 nvidia-desktop systemd[1]: Failed to start Test Project.
It seems that when running via systemd, tmuxinator is not able to locate /home/karsh/.tmuxinator/testProject.yml file and says that the project does not exist.
How can I give systemd access to the /home/<user>/ directories, assuming that's the problem?
Related
I am trying to configuer pgbouncer for the first time.
My postgres DB is running as a container (with port 5011)
My OS is debian 10.
I used apt-install to install pgbouncer:
sudo apt-get install pgbouncer
and then could see that pgbouncer status was OK:
# sudo systemctl status pgbouncer
● pgbouncer.service - LSB: start pgbouncer
Loaded: loaded (/etc/init.d/pgbouncer; generated)
Active: active (running) since Wed 2021-05-26 16:15:49 IDT; 11min ago
Docs: man:systemd-sysv-generator(8)
Tasks: 2 (limit: 4915)
Memory: 2.4M
CGroup: /system.slice/pgbouncer.service
└─4392 /usr/sbin/pgbouncer -d /etc/pgbouncer/pgbouncer.ini
my database name is mydb, postgres container is running on port 5011, so I configured /etc/pgbouncer/pgbouncer.ini like this:
[databases]
octopus-bouncer = host=10.1.1.1 port=5011 user=dbauser dbname=mydb
;; Configuration section
[pgbouncer]
auth_file = userlist.txt
; IP address or * which means all IPs
listen_addr = *
listen_port = 6432
; any, trust, plain, crypt, md5, cert, hba, pam
auth_type = md5
auth_file = /etc/pgbouncer/userlist.txt
; total number of clients that can connect
max_client_conn = 100
; default pool size. 20 is good number when transaction pooling
; is in use, in session pooling it needs to be the number of
; max clients you want to handle at any moment
default_pool_size = 20
I finally put my user to /etc/pgbouncer/userlist.txt:
"dbauser" "mypassword"
Then I restarted pgbouncer - but failed:
# sudo systemctl restart pgbouncer
Job for pgbouncer.service failed because the control process exited with error code.
See "systemctl status pgbouncer.service" and "journalctl -xe" for details.
status shows only this:
# sudo systemctl status pgbouncer
● pgbouncer.service - LSB: start pgbouncer
Loaded: loaded (/etc/init.d/pgbouncer; generated)
Active: failed (Result: exit-code) since Wed 2021-05-26 17:04:00 IDT; 2min 3s ago
Docs: man:systemd-sysv-generator(8)
Process: 28111 ExecStart=/etc/init.d/pgbouncer start (code=exited, status=1/FAILURE)
May 26 17:04:00 Octopus systemd[1]: Starting LSB: start pgbouncer...
May 26 17:04:00 Octopus pgbouncer[28111]: Starting PgBouncer: pgbouncer failed!
May 26 17:04:00 Octopus systemd[1]: pgbouncer.service: Control process exited, code=exited, status=1/FAILURE
May 26 17:04:00 Octopus systemd[1]: pgbouncer.service: Failed with result 'exit-code'.
May 26 17:04:00 Octopus systemd[1]: Failed to start LSB: start pgbouncer.
Am I missing something?
How can I debug the problem?
You can add KillSignal=SIGINT to service unit file:
cat /usr/lib/systemd/system/pgbouncer.service
[Unit]
Description=A lightweight connection pooler for PostgreSQL
Documentation=man:pgbouncer(1)
After=syslog.target network.target
[Service]
RemainAfterExit=yes
User=postgres
Group=postgres
# Path to the init file
Environment=BOUNCERCONF=/etc/pgbouncer/pgbouncer.ini
#Environment=SYSTEMD_LOG_LEVEL=debug
ExecStart=/usr/bin/pgbouncer -q ${BOUNCERCONF}
ExecReload=/usr/bin/pgbouncer -R -q ${BOUNCERCONF}
KillSignal=SIGINT
# Give a reasonable amount of time for the server to start up/shut down
TimeoutSec=300
[Install]
WantedBy=multi-user.target
from pgbouncer man:
Signals
SIGHUP Reload config. Same as issuing the command RELOAD on the console.
SIGINT Safe shutdown. Same as issuing PAUSE and SHUTDOWN on the console.
I found that DolphinDB now supports a quick cluster deployment with docker containers and I followed the guide on github: https://github.com/dolphindb/Tutorials_CN/blob/master/docker_deployment.md to deploy a cluster with DolphinDB Docker package. But I encountered a problem. I looked at any other questions but can't find my own solution.
Here is the problem:
xllu#xllu-OptiPlex-7060:~/DolphinDB-Docker-Compose/Dockerbuild$ docker -v
Docker version 18.09.3, build 774a1f4
xllu#xllu-OptiPlex-7060:~/DolphinDB-Docker-Compose/Dockerbuild$ docker-compose --version
docker-compose version 1.24.0, build 0aa59064
xllu#xllu-OptiPlex-7060:~/DolphinDB-Docker-Compose/Dockerbuild$ docker build -t ddb:latest ./
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
I tried restarting docker:
xllu#xllu-OptiPlex-7060:~/DolphinDB-Docker-Compose/Dockerbuild$ sudo service docker restart
Job for docker.service failed because the control process exited with error code.
See "systemctl status docker.service" and "journalctl -xe" for details.
Then I checked this :
xllu#xllu-OptiPlex-7060:~/DolphinDB-Docker-Compose/Dockerbuild$ systemctl status docker.service
● docker.service - LSB: Create lightweight, portable, self-sufficient containers.
Loaded: loaded (/etc/init.d/docker; generated)
Active: failed (Result: exit-code) since Fri 2019-05-31 15:16:01 CST; 16s ago
Docs: man:systemd-sysv-generator(8)
Process: 29234 ExecStart=/etc/init.d/docker start (code=exited, status=1/FAILURE)
Main PID: 2596 (code=exited, status=0/SUCCESS)
5月 31 15:16:01 xllu-OptiPlex-7060 systemd[1]: Starting LSB: Create lightweight, portable, self-sufficient containers....
5月 31 15:16:01 xllu-OptiPlex-7060 docker[29234]: * /usr/bin/dockerd not present or not executable
5月 31 15:16:01 xllu-OptiPlex-7060 systemd[1]: docker.service: Control process exited, code=exited status=1
5月 31 15:16:01 xllu-OptiPlex-7060 systemd[1]: docker.service: Failed with result 'exit-code'.
5月 31 15:16:01 xllu-OptiPlex-7060 systemd[1]: Failed to start LSB: Create lightweight, portable, self-sufficient containers..
Can you try removing /var/lib/docker with sudo rm -rf /var/lib/docker and try restarting the docker?
You will lose the images stored.
I have installed mssql on Ubuntu 16.04. following are the details of sql server.
ms sql (14.0.3015.40-1) i.e SQL server 2017.
when I run the configuration command #sudo /opt/mssql/bin/sqlservr-setup
I got error sudo: /opt/mssql/bin/sqlservr-setup: command not found
I have stopped and restarted but of no use.
When I check the status by command #systemctl status mssql-server
I got
mssql-server.service - Microsoft SQL Server Database Engine
Loaded: loaded (/lib/systemd/system/mssql-server.service; enabled; vendor preset: enabled)
Active: inactive (dead) (Result: exit-code) since Fri 2018-02-02 16:15:29 IST; 4min 20s ago
Docs: https://learn.microsoft.com/en-us/sql/linux
Process: 28050 ExecStart=/opt/mssql/bin/sqlservr (code=exited, status=200/CHDIR)
Main PID: 28050 (code=exited, status=200/CHDIR)
Feb 02 16:15:28 chetan-desktop systemd[1]: mssql-server.service: Unit entered failed state.
Feb 02 16:15:28 chetan-desktop systemd[1]: mssql-server.service: Failed with result 'exit-code'.
Feb 02 16:15:29 chetan-desktop systemd[1]: mssql-server.service: Service hold-off time over, scheduling restart.
Feb 02 16:15:29 chetan-desktop systemd[1]: Stopped Microsoft SQL Server Database Engine.
Feb 02 16:15:29 chetan-desktop systemd[1]: mssql-server.service: Start request repeated too quickly.
Feb 02 16:15:29 chetan-desktop systemd[1]: Failed to start Microsoft SQL Server Database Engine.
I have googled and tried all possible options. But unable to start SQL server.
Please guide me through this.
I had the same two problems.
First, I was referencing very old documentation that applied to an early (preview) release for RHEL, and so I was using the wrong command. The correct command is:
/opt/mssql/bin/mssql-conf setup
Second, the service was failing to start because my virtual machine did not have enough RAM available (SQL Server on Linux requires at least 2GiB of RAM available.) The documentation I was referred to incorrectly stated that only 0.5GiB was required, this is incorrect and journalctl was not providing any useful information about the start failure.
After configuring available memory to 2GiB and using the correct mssql-conf command I was able to successfully configure and start an MSSQL Server instance on Linux.
References:
Configure SQL Server on Linux with the mssql-conf tool (Microsoft Docs)
KB052969: FIX: Minimum memory limit set to 2GB to install or start SQL Server 2017 (Microsoft Support)
Installation guidance for SQL Server on Linux (Microsoft Docs)
The error says that the executable wasn't found in this path, not that the service couldn't start.
According to the installation instructions for Ubuntu you need to run mssql-conf setup to configure the server :
sudo /opt/mssql/bin/mssql-conf setup
not sqlservr-setup
Increasing the RAM size to 3GB on my VM resolved the issue for me.
I followed the instructions on https://ctors.net/2015/07/14/solr5_java8_debian8.
As the root
First I installed Java 8:
mkdir -p /opt/java
wget --no-cookies --no-check-certificate --header "Cookie: gpw_e24=http%3A%2F%2Fwww.oracle.com%2F; oraclelicense=accept-securebackup-cookie" "http://download.oracle.com/otn-pub/java/jdk/8u45-b14/jdk-8u45-linux-x64.tar.gz"
tar xvf jdk-8u45-linux-x64.tar.gz -C /opt/java
update-alternatives --install /usr/bin/java java /opt/java/jdk1.8.0_45/bin/java 1
update-alternatives --set java /opt/java/jdk1.8.0_45/bin/java
Then I installed Solr:
wget http://apache.belnet.be/lucene/solr/5.2.1/solr-5.2.1.tgz
tar xvf solr-5.2.1.tgz
./solr-5.2.1/bin/install_solr_service.sh solr-5.2.1.tgz
But the installation ends up with the following error message:
solr.service - LSB: Controls Apache Solr as a Service
Loaded: loaded (/etc/init.d/solr)
Active: failed (Result: exit-code) since Wed 2015-11-18 02:29:36 TMT; 5s ago
Process: 1679 ExecStart=/etc/init.d/solr start (code=exited, status=1/FAILURE)
Nov 18 02:29:36 solrhost su[1681]: Successful su for solr by root
Nov 18 02:29:36 solrhost su[1681]: + ??? root:solr
Nov 18 02:29:36 solrhost su[1681]: pam_unix(su:session): session opened for user solr by (uid=0)
Nov 1`enter code here`8 02:29:36 solruser solr[1679]: This script requires extracting a WAR file with either the jar or unzip utility, please install these utilities or con...assistance.
Nov 18 02:29:36 solrhost su[1681]: pam_unix(su:session): session closed for user solr
Nov 18 02:29:36 solrhost systemd[1]: solr.service: control process exited, code=exited status=1
Nov 18 02:29:36 solrhost systemd[1]: Failed to start LSB: Controls Apache Solr as a Service.
Nov 18 02:29:36 solrhost systemd[1]: Unit solr.service entered failed state.
Hint: Some lines were ellipsized, use -l to show in full.
Service solr installed.
Does anyone have any idea what is going on?
solr needs unzip to work. Install unzip if it isn't available on the system.
apt-get install unzip
It should fix the problem.
I got my colleague to have a look at the issue. He found two causes of error:
1) Insufficient memory (my box had 512 MB RAM memory). Additional memory resolved the issue.
2) Wrong jdk package, that is, wrong architecture choice. For different JDK packages look here: http://www.oracle.com/technetwork/java/javase/downloads/java-se-6u24-download-338091.html.
Hope someday this will save someone else's time and nerves.
As for Debian and Solr developers, it would be great if you could come up with simple receipt about how to install Solr 5 under Debian 8. For example, https://www.digitalocean.com/community/tutorials/how-to-install-solr-5-2-1-on-ubuntu-14-04.
Our hard disk, with Mageia 3, got a bad block problem. We can still read it, but not boot on it. I installed this disk as secondary disk (on another computer working with Fedora 20 Gnome). I would like to save the databases (containing Drupal websites) of the old disk, so I installed mariadb and phpmyadmin packages on a new booting hard disk with Mageia 4, set up the same password as for the old disk (I don't know where MariaDB password is stored), copied the configuration file /etc/my.cnf and the folder /var/lib/mysql to the new disk. But mysqld refuses to start. I get
# systemctl status mysqld.service
mysqld.service - MySQL database server
Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled)
Active: failed (Result: start-limit) since Wed 2014-03-12 18:08:35 ULAT; 2s ago
Process: 20618 ExecStartPost=/usr/sbin/mysqld-wait-ready $MAINPID (code=exited, status=1/FAILURE)
Process: 20245 ExecStart=/usr/bin/mysqld_safe --nowatch (code=exited, status=0/SUCCESS)
Process: 20228 ExecStartPre=/usr/sbin/mysqld-prepare-db-dir (code=exited, status=0/SUCCESS)
Main PID: 20617 (code=exited, status=1/FAILURE)
Mar 12 18:08:35 Dell-graphist systemd[1]: Failed to start MySQL database server.
Mar 12 18:08:35 Dell-graphist systemd[1]: Unit mysqld.service entered failed state.
Mar 12 18:08:35 Dell-graphist systemd[1]: mysqld.service holdoff time over, scheduling restart.
Mar 12 18:08:35 Dell-graphist systemd[1]: Stopping MySQL database server...
Mar 12 18:08:35 Dell-graphist systemd[1]: Starting MySQL database server...
Mar 12 18:08:35 Dell-graphist systemd[1]: mysqld.service start request repeated too quickly, refusing to start.
Mar 12 18:08:35 Dell-graphist systemd[1]: Failed to start MySQL database server.
Mar 12 18:08:35 Dell-graphist systemd[1]: Unit mysqld.service entered failed state.
Or is it better, in my Fedora computer, to configure MariaDB to read the old disk databases and to produce a .sql file? If so, how to configure MariaDB for this ?
Thank you if you can help.
biz -- I think you can try to do the dump following this method:
MYSQLDUMP without the password prompt
If you have access to the file system and server, you can use dump to put the database stuff some where ready for recovery.
I'm not sure if this approach also works when starting the daemon. It is worth a try if you are still wanting to save your stuff.
Another less 'interesting' option is to do a deep copy of the whole mysql/mariadb folder. You need to change ownership of the target folder after copying to be "mysql:mysql" and change your mysql config to point to the new location.
Use start and see if the server will come-up on the cloned directory? You may still find problems on some queries if there's a hole in the (origin) disk. Either way you ought to be able to just dump to a text file stream as long as you get a server working.