-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.

Improve this question
12
  • You're still using old-style init scripts, and not systemd units?
    – Michael Hampton
    May 1, 2016 at 2: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 1, 2016 at 3: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 1, 2016 at 3:06
  • The older init system is better anyways. It's simple.
    – OwN
    May 1, 2016 at 4: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 1, 2016 at 4:52

2 Answers 2

Reset to default
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

Improve this answer
2
  • 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 1, 2016 at 4:50
  • Try to edit <your daemon>.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 1, 2016 at 6:45
0

Nohup it is I guess: 

nohup bash_script_wrapper.sh /dev/null 2>&1 &
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .