MySQL: multiple instances using systemd

I have just installed Ubuntu 17.10 and I want to run MySQL with multiple instances.
I’ve read the MySQL documentation about this (https://dev.mysql.com/doc/refman/5.7/en/using-systemd.html) but I still don’t understand.

I have disabled the apparmor profile for mysql and added these lines to
/etc/mysql/mysql.conf.d/mysqld.cnf

[mysqld@replica01]
datadir=/var/lib/mysql-replica01
socket=/var/lib/mysql-replica01/mysql.sock
port=3307
log-error=/var/log/mysql/replica01.log

[mysqld@replica02]
datadir=/var/lib/mysql-replica02
socket=/var/lib/mysql-replica02/mysql.sock
port=3308
log-error=/var/log/mysql/replica02.log

Is it enough to copy /lib/systemd/system/mysql.service to /lib/systemd/system/mysql@.service or do I need to modify it somehow?
Because if I just copy it and run

systemctl start mysql@replica01

It will just start the default MySQL instance on port 3306.
And if I start mysql@replica02 it won’t start since it tries to start the same instance and I just get a bunch of

Unable to lock ./ibdata1 error: 11

What am I missing here? The only thing I can find online about this are old posts before this was supported in .deb-files. But since version 5.7.19 this should work and as of writing this the version is 5.7.21 that gets installed from Ubuntus repo.

I have an old installation on a Debian machine that is using the mysqld_multi but that’s not supported anymore if I understand the documentation right.

DNS over TLS with systemd-resolved

Folks,

I was trying to enable DNS over TLS via systemd-resolved. I changed /etc/systemd/resolved.conf as follows:

[Resolve]
DNS=1.1.1.1
#FallbackDNS=
Domains=~.
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
DNSOverTLS=opportunistic
#Cache=yes
#DNSStubListener=yes

while monitoring the network (with tcpdump) to see if the resulting behavior was the intended one, it seems a TLS session is established with the target server, but then the server closes the connection. I got the same results with 1.1.1.1, 8.8.8.8 and others.

Any clues?

P.S.: systemd-resolved ends up doing parallel resolution with traditional DNS (despite the setting of “Domains” above). But my main question for this post is what may be going wrong with the TLS one.

Thanks,
Fernando

Domains setting in systemd-resolved

Folks,

I’m running a fresh install of 18.10. I configured as:

[Resolve]
DNS=1.1.1.1
#FallbackDNS=
Domains=~.
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
DNSOverTLS=opportunistic
#Cache=yes
#DNSStubListener=yes

Still, when running tcpdump it seems systemd-resolved still tries to use (in parallel with 1.1.1.1) the DNS advertised by the DHCP server.

My assumption was that setting:

Domains=~.

would prevent that.

Any clues?

Thanks,
Fernando

Какие параметры systemd.serive необходимы для первичной…

Подготовка сервера разбита на две части

  1. Первичная PXE preseed установка чистой ОС (Debian Stretch/Jessie) с добавлением сервиса для systemd который должен завершить конфигурацию после перезагрузки.
  2. systemd сервис стартует bash скрипт, ставящий вереницу недостающих пакетов один из которых postgresql, в дальнейшем он добавляет базу данных по шаблону, где и ломается.

При запуске того же скрипта в “ручном режиме” все успешно ставится. Подозрения на то, что systemd НЕ стартует posgresql сервер, а просто продолжает выполнение установочного сценария.

Пробовал разные типы:

  • Type=simple ломается конфигурация модулей ядра; сервис виснет на полпути.
  • Type=forking не стартует база после установки, ломаются зависимости от этого в сценарий

firstboot.service

[Unit]
Description=Postinstall bootstrap
AssertPathExists=/path/to/dir

[Service]
Type=simple # forking
User=root
WorkingDirectory=/path/to/dir
Environment="INSTALL_SETTINGS=full-install"
ExecStart=/path/to/dir/script.sh
ExecStartPost=/usr/bin/systemctl disable fistboot

[Install]
WantedBy=multi-user.target

Так же пробовал ставить все за один заход в preseed не взлетело, в силу того что многие сервисы не стараются.


UPD

Ключевой момент в том, что установочный скрипт отрабатывает без проблем если запустить его после полной загрузки системы в ручную, и “ломается” на моменте, где создается БД по шаблону из systemd.service. Один из шагов – установка postgresql, которая НЕ стартует автоматически как при ручной установке.

Задача стоит в том, что бы сконцентрировать сервис systemd без сторонних пакетом (initscripts) стартующий все сервисы из предоставленного ему установочного сценария.

Изначальная проблема – автоспуск сценариия поставленного после preseed стадии PXE установки. На Debian stretch/jessie отсутствует «тёплый ламповый» /etc/rc.local

Is this a usable systemd startup script for bitcoind?

The script here in the official github repo

https://github.com/bitcoin/bitcoin/blob/0.13/contrib/init/bitcoind.service

looks like a systemd startupscript to me. However, it’s from 2014.

Can I put this into my /etc/systemd/system directory as a bitcoind.service startscript and enable it? Or do I have to configure something extra?

This what the source code of the script looks like in Sept 2017:

[Unit]
Description=Bitcoin's distributed currency daemon
After=network.target

[Service]
User=bitcoin
Group=bitcoin

Type=forking
PIDFile=/var/lib/bitcoind/bitcoind.pid
ExecStart=/usr/bin/bitcoind -daemon -pid=/var/lib/bitcoind/bitcoind.pid 
-conf=/etc/bitcoin/bitcoin.conf -datadir=/var/lib/bitcoind -disablewallet

Restart=always
PrivateTmp=true
TimeoutStopSec=60s
TimeoutStartSec=2s
StartLimitInterval=120s
StartLimitBurst=5

[Install]
WantedBy=multi-user.target

The script mentions a config-file -conf=/etc/bitcoin/bitcoin.conf – but I’m on Ubuntu/Debian, and the bitcoind package does not create a /etc/bitcoin/bitcoin.conf file.

What should I put it in there? Or should I leave it empty?

(I’ve already read this related question: Newbie question, bitcoind installation doubte )

Ahh there is already a pull request from June 2017 discussing various topics:

https://github.com/bitcoin/bitcoin/pull/10529/files

They propose, for instance, to rename /etc/bitcoin to /etc/bitcoind, for consistency reasons.

Please ignore the following error about deb-systemd-helper not finding samba-ad-dc.service

when i try to upgrade its come an i dont know how to resolve this

shashank@shashank-H110M-S2:~$ sudo apt install apt
[sudo] password for shashank: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
apt is already the newest version (1.6.6).
The following packages were automatically installed and are no longer required:
  linux-headers-4.15.0-34 linux-headers-4.15.0-34-generic
  linux-image-4.15.0-34-generic linux-modules-4.15.0-34-generic
  linux-modules-extra-4.15.0-34-generic
Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up samba (2:4.7.6+dfsg~ubuntu-0ubuntu2.2) ...
Samba is not being run as an AD Domain Controller.
Please ignore the following error about deb-systemd-helper not finding samba-ad-dc.service.
Job for nmbd.service failed because a timeout was exceeded.
See "systemctl status nmbd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript nmbd, action "start" failed.
● nmbd.service - Samba NMB Daemon
   Loaded: loaded (/lib/systemd/system/nmbd.service; disabled; vendor preset: enabled)
   Active: failed (Result: timeout) since Mon 2018-11-12 13:21:42 IST; 19ms ago
     Docs: man:nmbd(8)
           man:samba(7)
           man:smb.conf(5)
  Process: 6648 ExecStart=/usr/sbin/nmbd --foreground --no-process-group $NMBDOPTIONS (code=killed, signal=TERM)
 Main PID: 6648 (code=killed, signal=TERM)
   Status: "nmbd: No local IPv4 non-loopback interfaces available, waiting for interface ..."

Nov 12 13:20:12 shashank-H110M-S2 systemd[1]: Starting Samba NMB Daemon...
Nov 12 13:21:42 shashank-H110M-S2 systemd[1]: nmbd.service: Start operation timed out. Terminating.
Nov 12 13:21:42 shashank-H110M-S2 systemd[1]: nmbd.service: Failed with result 'timeout'.
Nov 12 13:21:42 shashank-H110M-S2 systemd[1]: Failed to start Samba NMB Daemon.
dpkg: error processing package samba (--configure):
 installed samba package post-installation script subprocess returned error exit status 1
Processing triggers for libc-bin (2.27-3ubuntu1) ...
Errors were encountered while processing:
 samba
E: Sub-process /usr/bin/dpkg returned an error code (1)

systemd user service not found after reboot

I set up syncthing as a systemd user service on a 16.04 computer. Worked fine. Since I upgraded to 18.04 the service disappears upon reboot.

After rebooting, I see:

$ systemctl --user status syncthing.service 
Unit syncthing.service could not be found.

And syncthing is indeed not running.

Here is ~/.config/systemd/user/syncthing.service (following the example, but note the binary is under my home dir):

[Unit]
Description=Syncthing - Open Source Continuous File Synchronization
Documentation=man:syncthing(1)

[Service]
ExecStart=/home/user/syncthing-prefix/syncthing -no-browser -no-restart -logflags=0
Restart=on-failure
SuccessExitStatus=3 4
RestartForceExitStatus=3 4

[Install]
WantedBy=default.target

I then run this:

$ systemctl --user enable syncthing.service
$ systemctl --user start syncthing.service

Following the setup instructions I used to install the user service originally.

After running the above two commands, I see:

$ systemctl --user status syncthing.service
● syncthing.service - Syncthing - Open Source Continuous File Synchronization
  Loaded: loaded (/home/user/.config/systemd/user/syncthing.service; enabled; 
  Active: active (running) since Tue 2018-11-06 15:28:16 PST; 4s ago
    Docs: man:syncthing(1)
Main PID: 4221 (syncthing)
  CGroup: /user.slice/user-1000.slice/user@1000.service/syncthing.service
          └─4221 /home/user/syncthing-prefix/syncthing -no-b

Nov 06 15:28:18 kind syncthing[4221]: [XXXXX] INFO: Device XXXXXXX-XXXXXXX-XXXXX
Nov 06 15:28:18 kind syncthing[4221]: [XXXXX] INFO: Device XXXXXXX-XXXXXXX-XXXXX
Nov 06 15:28:18 kind syncthing[4221]: [XXXXX] INFO: Device XXXXXXX-XXXXXXX-XXXXX
Nov 06 15:28:18 kind syncthing[4221]: [XXXXX] INFO: GUI and API listening on 127
Nov 06 15:28:18 kind syncthing[4221]: [XXXXX] INFO: Access the GUI via the follo
Nov 06 15:28:18 kind syncthing[4221]: [XXXXX] INFO: Completed initial scan of se
Nov 06 15:28:18 kind syncthing[4221]: [XXXXX] INFO: Completed initial scan of se
Nov 06 15:28:18 kind syncthing[4221]: [XXXXX] INFO: Completed initial scan of se
Nov 06 15:28:19 kind syncthing[4221]: [XXXXX] INFO: Completed initial scan of se
Nov 06 15:28:20 kind syncthing[4221]: [XXXXX] INFO: Completed initial scan of se

as expected. And syncthing then works, as expected, until the next reboot.

Note that I have an encrypted home dir. This was the case when I was using 16.04, too.

How do I add ~/bin to PATH for a systemd service?

I have a systemd service which calls a PHP script that creates a tmux session on boot.

Globally I have the most current tmux for the distro (V>=2.5).
The script’s USER has a $HOME/bin/tmux of 2.0

What I need is for this systemd to use the tmux binary in the user’s $HOME.
I have set the USER & GROUP variables in the systemd service file but it seems to call the globally installed binary.

Is it possible to explicitly set the binary that should be called for this service invocation?

If possible I’d rather not start to hardcode the path in the PHP file iteself.

Many thanks.