-1

How does one go about delaying a service init script in Linux until the MySQL socket exists? Does the sleep command in a startup script delay the entire boot process, or are init scripts each executed by a different thread to prevent blocking?

I am trying to get my PolicyD service to start after MySQL. Currently it does in /etc/rc5.d because PolicyD's script starts with S06 while MySQL's starts with S04. The problem is that when the policyd init script runs, if /var/run/mysqld/mysqld.sock doesn't exist, it won't work. If I delay the script for 60 seconds, it works fine (giving MySQL enough time to initialize its system and socket), but I don't want to pause the entire boot process for this long?

I don't suppose MySQL has any virtual facility LSB names to slow down policyd's initialization? (https://wiki.debian.org/LSBInitScripts)

What's the best way to handle this? The init system is multi-threaded since startup scripts run other daemons and programs which can loop? I'm a bit confused...

If it matters, I'm running Ubuntu 16.04. If someone can help clarify how the init process works and how to approach this problem, I'd really appreciate it.

OwN
  • 177
  • 3
  • 13
  • You're still using old-style init scripts, and not systemd units? – Michael Hampton May 01 '16 at 02:57
  • What's the difference between a systemd script? Ubuntu 16.04 services still appear to work the same way as they always have. It uses systemd for boot, but it is still running the same old init scripts minus a bash commented LSB block for telling systemd what to do? I really don't care. I just want to run a service that waits until MySQL is ready. – OwN May 01 '16 at 03:02
  • Because this is trivially easy when both services use systemd units to start up, instead of the old-style scripts. Ubuntu is the last major distribution to switch to systemd, and it looks like it's going to be at least another couple of years before they've done anything like a decent job of it. If they ever do. The rest of us have been able to take advantage of this for years; consider switching to another distribution. – Michael Hampton May 01 '16 at 03:06
  • The older init system is better anyways. It's simple. – OwN May 01 '16 at 04:45
  • But it would still have the same problem. My PolicyD daemon needs to run when the MySQL socket is available. This takes time... the boot sequence is correct, but my daemon is initialized too quickly after to give MySQL a chance to spawn its socket. – OwN May 01 '16 at 04:52
  • I already understand the problem well enough; you don't need to repeat yourself. And no, it would not have the same problem under systemd, because with a proper systemd service, MySQL tells systemd when it's ready, and systemd waits to start any services that depend on mysql. – Michael Hampton May 01 '16 at 05:09
  • So how do I tell systemd init script to wait on MySQL? Don't you need to use a virtual boot facility? But how do you know what to use in the script? The script is already telling it this: # Required-Start: $remote_fs $all --- so it waits until $all is ready... so how do I tell it to wait for MySQL? $mysql? lol who makes these and how do you tell systemd anything? – OwN May 01 '16 at 05:30
  • First, your installation of MySQL has to already be started with a systemd unit and be compiled with systemd awareness. I don't think Ubuntu has done this yet. Then you just add `After=mysql.service` to your own systemd unit, and you're done. – Michael Hampton May 01 '16 at 05:33
  • So, it looks like systemd looks at services files first in /lib/systemd/system and /etc/systemd/system in Ubuntu. If it finds a systemd service file, it runs it. If not, it looks like systemd generates one based on the LSB init script. Unfortunately, in Ubuntu, the MySQL package does not have its own systemd init script. It's generated (/run/systemd/generator.late/mysql.service), so I guess After=mysql.service will not work in my case. – OwN May 01 '16 at 07:29
  • Right, it won't work until Ubuntu recompiles MySQL with systemd support and creates a proper systemd unit. Maybe 18.04 LTS :) Or try another distribution. – Michael Hampton May 01 '16 at 07:38
  • Switching distributions is not a possibility. The software I develop is specifically written for Ubuntu, and I've always preferred Ubuntu over any other distribution. No biggie, there's always the nohup work-around. – OwN May 01 '16 at 16:13
  • To further clarify, I'm not even sure if using a systemd unit to boot the service would work either. With the old school way, my daemon is already starting after the MySQL init script, but MySQL still isn't ready to accept connections when my service runs. I bet the same thing would happen using systemd because I doubt systemd will know when the MySQL socket is ready. It just knows when its job is complete which is to start MySQL. – OwN May 01 '16 at 16:41

2 Answers2

0

I think you have systemd at your disposal with Ubuntu 16.04 otherwise you can refer to upstart system in which you can write a conf file for your service. In this file you can specify that the service start only after one or more services.

I found this article about upstart very useful Digital Ocean - The upstart event system

Oroki
  • 1
  • 1
  • Thanks, I read the article, but that only talks about jobs. I have a daemon that I want to start after the MySQL socket is there and ready. My daemon already starts after the MySQL daemon, but the MySQL socket is still not available .005ish seconds after MySQL is started when my daemon script runs. It appears that systemd is asynchronous though, so a wait time should be OK in the init script for starting / stopping? – OwN May 01 '16 at 04:50
  • Try to edit .services file and put at the end of [Unit] section: After= MySQL.service and then restart all and test if your socket is ready before your daemon start. – Oroki May 01 '16 at 06:45
0

Nohup it is I guess: 

nohup bash_script_wrapper.sh /dev/null 2>&1 &
OwN
  • 177
  • 3
  • 13