Can confirm. Problem seems to be fixed now.

I'm also experiencing this for the latest rolling versions eg. https://downloads.vyos.io/rolling/current/amd64/vyos-1.3-rolling-201912181733-amd64.iso. This is causing issues when trying to create Packer image builds - total first reboot wait time extended to over 2mins for a successful image build.

Added PR
https://github.com/vyos/vyos-1x/pull/190

@jjakob It's not really relevant if you SIGHUP or SIGKILL as RAs have no status, they are just send. I was looking into rewriting it anyway and port it into frr as frr sends RAs reliably as well. (https://phabricator.vyos.net/T1831) So the above is just a quick fix to get it working again with buster using the original logic.

If this is the issue I would replace the init.d call with systemctl since in 1.3 init.d/radvd is redirected to systemd anyway (maybe the bugs are present in this redirection so it's best to completely avoid it).
1.2 and earlier would still need to call init.d as-is.

@kroy I think I found the issue, the script just called start every time when radvd was already running, please test with either tomorrows iso or: http://dev.packages.vyos.net/repositories/current/pool/main/v/vyatta-ipv6-rtradv/vyatta-ipv6-rtradv_0.38+vyos2+current1_all.deb

It sends it after a while, I was waiting around 5 minutes and captured 1 RA msg.
But it sends only on vlan 22, which is quite unusual since all vlans are setup and readable by radvd, at least when I check /proc/<pid> it has it setup.
After the restart it sends on all interfaces (Just sent a SIGHUP, so no systemd involved). Reboot fixes it then as well.

All right, I can reproduce it now, thanks for the detailed report. I see what I can find out.

So I guess the key to duplication here is to:

Maybe even just the action of sudo systemctl restart radvd.service is enough to fix it? It seems to maybe be the case

It seems like maybe something doesn't exist, or permissions aren't working right on a freshly upgraded system, until you manually do something to create it?

So the problem went away until I upgraded to the latest rolling. VyOS 1.3-rolling-201912211124

VyOS 1.3 (rolling/equuleus) is now based on Debian Buster so has isc-dhcp-client 4.4.1.
According to the manual dhclient now has a command line option

--prefix-len-hint
When used in conjunction with -P, it directs the client to use the given length to use a prefix hint of, "::/length", when requesting new prefixes.

It was added in 4.3.6:
https://ftp.isc.org/isc/dhcp/4.4.1/dhcp-4.4.1-RELNOTES

Added explanation on how to use quotes inside raw parameters to the docs.
https://github.com/vyos/vyos-documentation/pull/163

Confirmed on 1.3-20191213, tcpdump on the router shows no advertisements until radvd is restarted with sudo systemctl restart radvd.

This is a known fault, and is not easily fixable in the current implementation. This fault is because the vuos cli manually configures the frr process after it's started, and when the process dies/restarts it will read its config from the saved config file. This makes the process restart into an empty config as we have no way to save the config from the prior process.

According to https://live-team.pages.debian.net/live-manual/html/live-manual/customizing-package-installation.en.html#474 some more packages are required.

Weird, afaik there was nothing to migrate yet.

Also tried that:

My output there basically matches yours.

That can't be the issue, what do you see if you do a grep radvd /var/log/messages?

My guess would be missing live-tools in the recommends=false case; live-tools replaces update-initramfs with its version. I'm building to check ...

And I don't know if it's relevant, but the syslog output is definitely different depending on whether I restart it, or it gets restarted on boot

Upgraded to lastest official rolling:

Tried almost all packages via CI, looks very good.

I used your config and just changed to eth1, commit works and after reboot radvd runs and sends RAs as well. radvd has a very low priority, I think 999 or so to ensure all interfaces are up and running plus the fact that radvd runs with a flag which allows the config running on an offline interface. (IgnoreIfMissing on;) Could anything else x-fire?

On current Debian Buster tose are the lsit of installed packages. I have not found the reasion why building with --apt-recommends false makes the ISO unbootable

https://github.com/vyos/vyos-build/pull/70

Really thanks for your reply. It's nice to have this fix. But to be honest, crash of vyos-hostsd is not so big deal for me, what really concern me is that restart of vyos-hostsd is followed by restart of vyos-router.

Maybe it's because I have multiples? Or on vlans (not that that should matter)

@fcqpl any chance to test it in your environment?

@kroy can you please share your config? I used a minimal one and everything works without issues.