pluginv2 jails do not auto-start

[DD4711]

Hello,

I have three jails: one is made myself (Dokuwiki), type jail, and two are plugins, type pluginv2. All are configured to auto-start. Dokuwiki does auto-start on boot but not the pluginv2-jails. All jails are installed on a freashly installed 11.2 System, no upgrades done from earlier versions.

I use disk encryption. But after unlocking the main storage where the jails are located jails are restarted. It should therefor not be a reason for my problem.

Could someone help me figure out this problem? I have currently no idea where to have a look for that.

Thanks :)

 

[DD4711]

I checked all my jails with
iocage get boot jailname
all are set on

 

[dlavigne]

Anything in /var/log/messages when the jails don't autostart?

 

[DD4711]

Anything in /var/log/messages when the jails don't autostart?

Hello dlavigne,
this should be the log after decrypting storage:

Code:

Jan  6 10:15:04 freenas GEOM_MIRROR: Device mirror/swap0 launched (2/2).
Jan  6 10:15:04 freenas GEOM_ELI: Device mirror/swap0.eli created.
Jan  6 10:15:04 freenas GEOM_ELI: Encryption: AES-XTS 128
Jan  6 10:15:04 freenas GEOM_ELI:     Crypto: hardware
Jan  6 10:15:04 freenas hwpmc: SOFT/16/64/0x67<INT,USR,SYS,REA,WRI> TSC/1/64/0x20<REA> K8/4/48/0x1ff<INT,USR,SYS,EDG,THR,REA,WRI,INV,QUA>
Jan  6 10:15:04 freenas kernel: bge0: link state changed to DOWN
Jan  6 10:15:04 freenas kernel: bge0: link state changed to DOWN
Jan  6 10:15:04 freenas kernel: bge0: link state changed to UP
Jan  6 10:15:04 freenas kernel: bge0: link state changed to UP
Jan  6 10:15:06 freenas ntpd[2246]: ntpd 4.2.8p11-a (1): Starting
Jan  6 10:15:15 freenas tap0: Ethernet address: 00:bd:ab:3e:f8:00
Jan  6 10:15:15 freenas bridge0: Ethernet address: 02:f1:a9:59:3d:00
Jan  6 10:15:15 freenas kernel: tap0: promiscuous mode enabled
Jan  6 10:15:15 freenas kernel: bridge0: link state changed to DOWN
Jan  6 10:15:15 freenas kernel: bridge0: link state changed to DOWN
Jan  6 10:15:15 freenas kernel: bridge0: link state changed to UP
Jan  6 10:15:15 freenas kernel: bridge0: link state changed to UP
Jan  6 10:15:15 freenas kernel: bge0: promiscuous mode enabled
Jan  6 10:21:07 freenas GEOM_ELI: Device gptid/c3991376-fb29-11e8-9301-d06726d3bdbc.eli created.
Jan  6 10:21:07 freenas GEOM_ELI: Encryption: AES-XTS 256
Jan  6 10:21:07 freenas GEOM_ELI:     Crypto: hardware
Jan  6 10:21:09 freenas GEOM_ELI: Device gptid/c53625e8-fb29-11e8-9301-d06726d3bdbc.eli created.
Jan  6 10:21:09 freenas GEOM_ELI: Encryption: AES-XTS 256
Jan  6 10:21:09 freenas GEOM_ELI:     Crypto: hardware
Jan  6 10:21:09 freenas ZFS: vdev state changed, pool_guid=5870723549770582304 vdev_guid=11878360020016085390
Jan  6 10:21:09 freenas ZFS: vdev state changed, pool_guid=5870723549770582304 vdev_guid=11992196756999854243
Jan  6 10:21:09 freenas ZFS: vdev state changed, pool_guid=5870723549770582304 vdev_guid=11878360020016085390
Jan  6 10:21:09 freenas ZFS: vdev state changed, pool_guid=5870723549770582304 vdev_guid=11992196756999854243
Jan  6 10:21:39 freenas syslog-ng[5403]: syslog-ng starting up; version='3.14.1'
Jan  6 10:21:49 freenas root: /usr/local/etc/rc.d/collectd: WARNING: failed to start collectd
Jan  6 10:21:49 freenas root: /usr/local/etc/rc.d/collectd: WARNING: failed to start collectd
Jan  6 10:23:21 freenas tap0: Ethernet address: 00:bd:89:a8:ff:00
Jan  6 10:23:21 freenas kernel: tap0: promiscuous mode enabled
Jan  6 10:23:21 freenas kernel: tap0: link state changed to UP
Jan  6 10:23:21 freenas kernel: tap0: link state changed to UP

I can see only a warning:
/usr/local/etc/rc.d/collectd: WARNING: failed to start collectd

Is that what we're searching for?

I also set up a VM Server which also does not autostart.

 

[DD4711]

OK, VMs won't start automatically as they are not mentioned in the "restart services"-list while decrypting storage.

Edit: But also for VM it would be great to auto-start when decrypting storage

 

[DD4711]

does anyone know how restart services is implemented after decrypting storage? Maybe there's a problem that not all jails are automatically started?

 

[dlavigne]

Were you able to resolve this?

 

[DD4711]

no :( still same behavior and I have no more ideas what to check

 

[dlavigne]

Looks like there's 2 current open tickets for this scenario, though you may not be able to see them until the dev has diagnosed the issue and removed the reporters' debug files.

 

[DD4711]

OK, thanks a lot. I'll have a look on that late.