# systemd: [Solved] Make nmbd/apache2 wait for dhcpcd

## threadau

Solution: Start some services after boot using systemd .timer files.

The problem (using systemd):

At boot, apache2 fails (cannot bind to network address) and smbd/nmbd behave strangely. Sometimes nmbd reports that it cannot bind to a socket, sometimes it just doesn't work right.

If I restart these services when startup is finished, they appear to work fine.

From what I can tell from arch/gentoo forums and google, it appears "after=network.target" is not sufficient for the network device to be ready. Using "after=network-online.target" and "wants=network-online.target" seems to be recommended, but requires a network management package (e.g. networkmanager) to do the checking up on the network status. Everything else is working just fine for me with dhcpcd and I don't really want to go about installing additional packages. I tried it anyway, but no effect.

So:

- Is there a simple way to have these services start later?

- I'm even prepared to accept a hackish "wait 15s", as this box is rarely turned off, and the startup times don't really concern me.

- Does this mean I should be using systemd timers to schedule them sometime after boot?

Thanks all!

TLDR: I want smbd, nmbd and apache2 to start *after* my computer has been assigned a network address. How can I do that with systemd?Last edited by threadau on Sun Jul 27, 2014 11:05 am; edited 1 time in total

----------

## threadau

Well, 71 views, no ideas.

My current plan is to start these services a minute or two after boot using systemd timers, I'll let you know how I go I guess.

----------

## creaker

If dynamic ip assigning is not an essential condition, I would suggest you to switch to static ip. dhcpcd starts too slowly.

----------

## UberLord

 *creaker wrote:*   

> dhcpcd starts too slowly.

 

dhcpcd is also the only client that ARP checks the offered IP address, similar to the kernel automatically doing DAD for IPv6 addresses.

Of course, you are welcome to turn this off which makes it just as fast, if not faster, than other DHCP clients.

It's up to you, the user, to turn off correctness as dhcpcd strives to be as RFC correct and compliant as possible.

----------

## threadau

Thank you both.

The IP address is essentially static, but I prefer to fix all my IPs centrally using the router.

I should also acknowledge that I'm essentially ignorant of the differences in speed and compliance of difference dhcp clients! In any case, the whole boot process is over in 2s now on my machine according to systemd. I think this only includes the time spent starting services (and not getting the address), so I guess nearly any dhcp client will have trouble meeting that deadline.

I did manage to get the desired outcome using systemd timers with help from:

http://jason.the-graham.com/2013/03/06/how-to-use-systemd-timers/

Essentially, I have what I want starting on boot using direct calls of .service files, and the less essential things (and those that require a correct IP address assignment) starting 10s of seconds later using .timer files.

A bit hackish, but it does also make my boot faster when I don't have to get mysql up and running before I even have my login prompt.

----------

## tld

I happened to stumble onto this looking for something else regarding dhcp.  I was just really curious though...I have to ask:  Doesn't systemd have some concept of service dependencies...that is the equivalent of having a ""need net" in the depend() function of an openrc init script?  I can't imagine it doesn't.

----------

## threadau

Hi tld,

It does, but in the effort to make everything boot as fast as possible it seems to only check that a service has started before starting the next in the so-called "need net". However, dhcpcd (as an example) reports that it has "started" and is "running" a few seconds earlier than it is able to source an IP address from the router (otherwise a poorly configured router could hang the boot process). Thus services requiring an IP address at startup can run into problems, particularly if they are not good at resolving the issue at a later stage!

There are a few options for delaying services until a network device is "ready" (i.e. changing the network.target requirement to network-online.target), however, systemd still needs a network management program (such as network-manager or similar) to do the reporting on whether the device is ready and trigger that network-online.target status.

I'm pretty happy with my solution though, as there are no delays during boot, and I don't mind whether the filservers or webserver start up to 90s later.

----------

