Re: date -r {big number} results in segmentation fault
On 30 August 2017 at 01:12, Xin LI wrote: > I think emaste@ have fixed it in r321293. MFC? Thanks for the note, now merged in r323044. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Bridged networking regression in 11.0?
On 30 August 2017 at 20:49, Patrick M. Hausen wrote: > > The only real change relates to IF teardown and we did not change anything > (stop/restart jails) when the outages occured. > > So ... the network interface driver? Probably? > > > We are using igb(4) with vlan(4), tap(4) bundled into bridge(4). The taps are entries to bhyve guests. These were built initially on FreeBSD 11.0 and have been recently uplifted to FreeBSD 11.1. We have never had any issues with these bridges, even under heavy load. We do want to netmap/vale but not until it is maintainable via freebsd-update (built into generic). So based on what you have said, a bit more of a breakdown to determine the culprit that is within the bridge might be needed, especially with VIMAGE (though our FreeNAS jails use VIMAGE and bridges without breakage also). Cheers, Jason. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: pkg issue after FreeBSD 11 upgrade
Thank you for your support Baptiste, I really appreciate that. As same as HANDLE_RC_SCRIPTS option the new one should be handled carefully. Please keep us posted when it's ready. On Wednesday, August 30, 2017, Baptiste Daroussin wrote: > On Wed, Aug 30, 2017 at 10:07:51AM -0300, Cassiano Peixoto wrote: > > Ok I know about HANDLE_RC_SCRIPTS, it's a good approach. But how to deal > > with when I need to restart a service without upgrading? Reaper > > functionnality is a trouble for many administrators who made meta ports > to > > manage their servers. I really think it could be a option to be > > enabled/disabled. Can you see this possibility? > > > > Yes I could add an option to disable the reaper functionnality (and will > probably to unblock such use case as soon as I have time to do it.) > > However I still think this is not the right idea :) and a better one could > be > found > > Bapt > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: pkg issue after FreeBSD 11 upgrade
On Wed, Aug 30, 2017 at 10:07:51AM -0300, Cassiano Peixoto wrote: > Ok I know about HANDLE_RC_SCRIPTS, it's a good approach. But how to deal > with when I need to restart a service without upgrading? Reaper > functionnality is a trouble for many administrators who made meta ports to > manage their servers. I really think it could be a option to be > enabled/disabled. Can you see this possibility? > Yes I could add an option to disable the reaper functionnality (and will probably to unblock such use case as soon as I have time to do it.) However I still think this is not the right idea :) and a better one could be found Bapt signature.asc Description: PGP signature
Re: pkg issue after FreeBSD 11 upgrade
Cassiano Peixoto wrote: Ok I know about HANDLE_RC_SCRIPTS, it's a good approach. But how to deal with when I need to restart a service without upgrading? Reaper functionnality is a trouble for many administrators who made meta ports to manage their servers. I really think it could be a option to be enabled/disabled. Can you see this possibility? Thanks. On Wed, Aug 30, 2017 at 9:59 AM, Baptiste Daroussin wrote: On Wed, Aug 30, 2017 at 09:55:22AM -0300, Cassiano Peixoto wrote: Hi Baptiste, Why it used to work on FreeBSD 10? It stopped worked on FreeBSD 11 only. It only worked on FreeBSD 10 prior to 10.2, the reaper functionnality in freebsd kernel appeared in 10.2 Cron is just an example, I manage more than 50 FreeBSD servers, and I've been using ports for years to update some configs and restart the service on all of them. Many times I need to change nginx config, ldap, etc. I just need to restart the service. HANDLE_RC_SCRIPTS=true in your pkg.conf and pkg will automatically restart anything rc script provide once the package containing it is upgrading. This is off by default because in many cases it is dangerous (database upgrades, dovecot like things upgrade etc). But if you know what you are doing it does the job. Best regards, Bapt Hey, I think you also want process supervision given your other comments. You can do this easily using daemon -P to run your scripts (but you'd need to rewrite the rc script...) Or use runit or similar? You could implement "runlevels" with that if that's REALLY what you want :) Cheers, Chris -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: pkg issue after FreeBSD 11 upgrade
Hi Baptiste, > On 30. Aug 2017, at 3:05 PM, Baptiste Daroussin wrote: > >> No. At OPNsense we use a patch to revert the behaviour. >> >> https://github.com/opnsense/ports/blob/master/ports-mgmt/pkg/files/patch-libpkg_scripts.c > > Why and what is your use case, there is a reason why this code has been added, > and I would like to hear more about use cases so we can try to address them. There's to things in this patch. (1) The hard fail for scripts leaves a GUI-driven environment without its package, so post-install fails become fatal and appliances are completely stranded, possibly left without means of recovery. This is where FreeBSD base and the "appliance" GUI packages are completely separated. This is somewhat mitigated by marking said GUI package vital, but vital won't help if the package was deinstalled during an upgrade and then the upgrade script itself fails. Every now and then, I see "user disappeared" during package installs on stock FreeBSD systems so the install fails. I am guessing that's the same issue. (2) The reaper kills a package-based watchdog / backend service. Maybe HANDLE_RC_SCRIPTS can cope with this, but it would be beneficial to be able to enable this per package / rc service / metadata as generally the reaper is a fine and sane addition. Cheers, Franco ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: pkg issue after FreeBSD 11 upgrade
Hi Franco, Thank you. You know what I'm suffering. As I said in my last email I think it would be an option to enable/disable. I just upgraded my customers servers to FreeBSD 11 and I just realized it. I think when more admins who maintain this kind of port (needing to restart services), as soon as they migrate they will face the same problem. On Wed, Aug 30, 2017 at 10:01 AM, Franco Fichtner wrote: > Hi Cassiano, > > > On 30. Aug 2017, at 2:55 PM, Cassiano Peixoto > wrote: > > > > Why it used to work on FreeBSD 10? It stopped worked on FreeBSD 11 only. > > It was a later 10.x change as far as I know. > > > Is there some flag to disable it? Or some hack that I could do? > > No. At OPNsense we use a patch to revert the behaviour. > > https://github.com/opnsense/ports/blob/master/ports-mgmt/ > pkg/files/patch-libpkg_scripts.c > > > Cheers, > Franco ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: pkg issue after FreeBSD 11 upgrade
Ok I know about HANDLE_RC_SCRIPTS, it's a good approach. But how to deal with when I need to restart a service without upgrading? Reaper functionnality is a trouble for many administrators who made meta ports to manage their servers. I really think it could be a option to be enabled/disabled. Can you see this possibility? Thanks. On Wed, Aug 30, 2017 at 9:59 AM, Baptiste Daroussin wrote: > On Wed, Aug 30, 2017 at 09:55:22AM -0300, Cassiano Peixoto wrote: > > Hi Baptiste, > > > > Why it used to work on FreeBSD 10? It stopped worked on FreeBSD 11 only. > > It only worked on FreeBSD 10 prior to 10.2, the reaper functionnality in > freebsd > kernel appeared in 10.2 > > > > Cron is just an example, I manage more than 50 FreeBSD servers, and I've > > been using ports for years to update some configs and restart the service > > on all of them. Many times I need to change nginx config, ldap, etc. I > just > > need to restart the service. > > HANDLE_RC_SCRIPTS=true in your pkg.conf and pkg will automatically restart > anything rc script provide once the package containing it is upgrading. > > This is off by default because in many cases it is dangerous (database > upgrades, > dovecot like things upgrade etc). But if you know what you are doing it > does the > job. > > Best regards, > Bapt > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: pkg issue after FreeBSD 11 upgrade
On Wed, Aug 30, 2017 at 03:01:30PM +0200, Franco Fichtner wrote: > Hi Cassiano, > > > On 30. Aug 2017, at 2:55 PM, Cassiano Peixoto > > wrote: > > > > Why it used to work on FreeBSD 10? It stopped worked on FreeBSD 11 only. > > It was a later 10.x change as far as I know. > > > Is there some flag to disable it? Or some hack that I could do? > > No. At OPNsense we use a patch to revert the behaviour. > > https://github.com/opnsense/ports/blob/master/ports-mgmt/pkg/files/patch-libpkg_scripts.c Why and what is your use case, there is a reason why this code has been added, and I would like to hear more about use cases so we can try to address them. Best regards, Bapt signature.asc Description: PGP signature
Re: pkg issue after FreeBSD 11 upgrade
Hi Cassiano, > On 30. Aug 2017, at 2:55 PM, Cassiano Peixoto > wrote: > > Why it used to work on FreeBSD 10? It stopped worked on FreeBSD 11 only. It was a later 10.x change as far as I know. > Is there some flag to disable it? Or some hack that I could do? No. At OPNsense we use a patch to revert the behaviour. https://github.com/opnsense/ports/blob/master/ports-mgmt/pkg/files/patch-libpkg_scripts.c Cheers, Franco ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: pkg issue after FreeBSD 11 upgrade
On Wed, Aug 30, 2017 at 09:55:22AM -0300, Cassiano Peixoto wrote: > Hi Baptiste, > > Why it used to work on FreeBSD 10? It stopped worked on FreeBSD 11 only. It only worked on FreeBSD 10 prior to 10.2, the reaper functionnality in freebsd kernel appeared in 10.2 > > Cron is just an example, I manage more than 50 FreeBSD servers, and I've > been using ports for years to update some configs and restart the service > on all of them. Many times I need to change nginx config, ldap, etc. I just > need to restart the service. HANDLE_RC_SCRIPTS=true in your pkg.conf and pkg will automatically restart anything rc script provide once the package containing it is upgrading. This is off by default because in many cases it is dangerous (database upgrades, dovecot like things upgrade etc). But if you know what you are doing it does the job. Best regards, Bapt signature.asc Description: PGP signature
Re: pkg issue after FreeBSD 11 upgrade
Hi Baptiste, Why it used to work on FreeBSD 10? It stopped worked on FreeBSD 11 only. Cron is just an example, I manage more than 50 FreeBSD servers, and I've been using ports for years to update some configs and restart the service on all of them. Many times I need to change nginx config, ldap, etc. I just need to restart the service. Is there some flag to disable it? Or some hack that I could do? Thanks. On Wed, Aug 30, 2017 at 9:48 AM, Baptiste Daroussin wrote: > On Wed, Aug 30, 2017 at 09:00:55AM -0300, Cassiano Peixoto wrote: > > Hi Matthew, > > > > Sorry back to this subject. But I really need to restart services with a > > port. I'm quite sure there is a bug with pkg and FreeBSD 11. > > > > I made a simple port to restart cron service: > > It is not a bug, it is by design, pkg becomes the reaper of the scripts it > runs > and kills everything once the script is executed. > > btw if you install crontab in cron.d you do not need to restart the > service, > cron will figure out itself and reload what it needed. > > Bapt > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
zfs, iSCSI and volmode=dev
Hi, I have an iSCSI production system that exports a large number of zvols as the iSCSI targets. System is running FreeBSD 11.0-RELEASE-p7 and initially all of the zvols were confugured with default volmode. I've read that it's recommended to use them in dev mode, so the system isn't bothered with all of these geom structures, so I've switched all of the zvols to dev mode, then I exported/imported the pools back. Surprisingly, the performance has fallen down like 10 times (200-300 Mbits/sec against 3-4 Gbits/sec previously). After observing for 5 minutes the ESXes trying to boot up, and doing this extremely slowly, I switched the volmode back to default, then again exported/imported the pools. The performance went back to normal. So... why did this happen ? The result seems to be counter-intuitive. At least not obvious to me. Thanks. Eugene. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: pkg issue after FreeBSD 11 upgrade
On Wed, Aug 30, 2017 at 09:00:55AM -0300, Cassiano Peixoto wrote: > Hi Matthew, > > Sorry back to this subject. But I really need to restart services with a > port. I'm quite sure there is a bug with pkg and FreeBSD 11. > > I made a simple port to restart cron service: It is not a bug, it is by design, pkg becomes the reaper of the scripts it runs and kills everything once the script is executed. btw if you install crontab in cron.d you do not need to restart the service, cron will figure out itself and reload what it needed. Bapt signature.asc Description: PGP signature
Re: pkg issue after FreeBSD 11 upgrade
Hi Matthew,
Sorry back to this subject. But I really need to restart services with a
port. I'm quite sure there is a bug with pkg and FreeBSD 11.
I made a simple port to restart cron service:
# $FreeBSD$
PORTNAME= ze
PORTVERSION=1.0
CATEGORIES= custom
MASTER_SITES= #
DISTFILES= #
EXTRACT_ONLY= # NONE
MAINTAINER= peixotocassi...@gmail.com
COMMENT=ze port
#NO_MTREE= yes
SUB_FILES= pkg-install
NO_BUILD= yes
NO_WRKSUBDIR= yes
do-install:
mkdir -p ${STAGEDIR}${DATADIR}
@${CP} -r ${FILESDIR}/versions ${STAGEDIR}${DATADIR}/
post-install:
${SH} ${PKGINSTALL} ${PKGNAME} POST-INSTALL
.include
Here is my pkg-install to restart cron service:
#!/bin/sh
if [ $2 = "POST-INSTALL" ]; then
service cron restart
fi
Here is the output when I install the port:
root@kkk:~ # service cron start
cron already running? (pid=2287).
root@kkk:~ # pkg install ze
Updating Custom repository catalogue...
Fetching meta.txz: 100%560 B 0.6kB/s00:01
Fetching packagesite.txz: 100% 122 KiB 62.6kB/s00:02
Processing entries: 100%
Custom repository update completed. 427 packages processed.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):
New packages to be INSTALLED:
ze: 1.0
Number of packages to be installed: 1
672 B to be downloaded.
[1/1] Fetching ze-1.0.txz: 100%672 B 0.7kB/s00:01
Checking integrity... done (0 conflicting)
[1/1] Installing ze-1.0...
+ set -- ze-1.0 PRE-INSTALL
+ [ PRE-INSTALL '=' POST-INSTALL ]
Extracting ze-1.0: 100%
+ set -- ze-1.0 POST-INSTALL
+ [ POST-INSTALL '=' POST-INSTALL ]
+ service cron restart
Stopping cron.
Waiting for PIDS: 2287.
Starting cron.
root@kkk:~ # ps ax | grep cron
2320 1 S+ 0:00.00 grep cron
As you can see the cron has stopped but hasn't started.
But If I install the same port with traditional ports approach it works,
see:
root@kkk: /usr/ports/custom/ze/# ps ax | grep cron
1280 - Is 0:00.97 /usr/sbin/cron -s
root@kkk: /usr/ports/custom/ze# make install
===> ze-1.1 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by ze-1.1 for building
===> Extracting for ze-1.1
===> Patching for ze-1.1
===> Configuring for ze-1.1
===> Staging for ze-1.1
===> Generating temporary packing list
mkdir -p /usr/ports/custom/ze/work/stage/usr/local/share/ze
/bin/sh /usr/ports/custom/ze/work/pkg-install ze-1.1 POST-INSTALL
> Compressing man pages (compress-man)
===> Installing for ze-1.1
===> Checking if ze already installed
Stopping cron.
Waiting for PIDS: 1280.
Starting cron.
===> Registering installation for ze-1.1
Installing ze-1.1...
root@kkk: /usr/ports/custom/ze# ps ax | grep cron
37527 - Ss 0:00.00 /usr/sbin/cron -s
Thanks for your help.
On Fri, Aug 11, 2017 at 1:45 PM, Cassiano Peixoto wrote:
> Hi Matthew,
>
> Thanks for your answer. Slapd is just an example, it happens with any
> application like apache, mysql, dovecot and others.
>
> I can see the process is running and up, and it dies after pkg process has
> finished. Looks like pkg is killing any application related to its thread.
>
> I know it's not the best approach, but used to work on FreeBSD 10.
>
> Anyway, I'll change my script to restart services out of pkg process.
>
> Thanks.
>
> On Fri, Aug 11, 2017 at 5:09 AM, Matthew Seaman
> wrote:
>
>> On 10/08/2017 22:05, Cassiano Peixoto wrote:
>> > I ran into an issue after FreeBSD 11 upgrade. I have some meta ports
>> that
>> > starts services like slapd.
>> >
>> > Its has been working fine on 10-STABLE. But after FreeBSD
>> > 11-STABLE r321625M upgrade it stopped working.
>> >
>> > Here is a simple example of my pkg-install.in script:
>> >
>> > #!/bin/sh
>> > /usr/local/etc/rc.d/slapd stop
>> > /usr/local/etc/rc.d/slapd start
>> >
>> > I can see its executing while upgrading a package:
>> >
>> > Stopping slapd.
>> > Waiting for PIDS: 13875.
>> > Starting slapd.
>> >
>> > But looking if the process is running, it's not:
>> >
>> > # ps ax | grep slapd
>> > 14164 0 S+ 0:00.00 grep slapd
>> >
>> > Then I manually run the rc.d script and the service starts:
>> >
>> > # /usr/local/etc/rc.d/slapd restart
>> > slapd not running? (check /var/run/openldap/slapd.pid).
>> > Starting slapd.
>> >
>> > So my question is: something has changed on FreeBSD 11 not allowing this
>> > kind of execution?
>> >
>> > BTW, I'm using pkg 1.10.1 and my ports collection is as same as I was
>> using
>> > on FreeBSD 10.
>>
>> Restarting daemons after upgrading is something the project has been
>> quite resistant to implementing. Mostly because as soon as you start
>> looking into it in any depth the true complexity of doing that sort of
>> thing reliably for any conceivable system becomes apparent and you end
>> up muttering darkly about systemd and losing the will to live.
>>
>> However, yes, restarting slapd -- it's clear that your script does get
>> called, but slapd fai
Re: Bridged networking regression in 11.0?
OK, guys, more replying to myswlf ;-) > Am 30.08.2017 um 12:04 schrieb Patrick M. Hausen : > > Hi, all, > >> Am 30.08.2017 um 09:29 schrieb Patrick M. Hausen : >> one of the systems on which we run our jail based "proServer" product failed >> in a very odd way for the second time with a couple of days between the two >> incidents. >> [...] > > We found this open bug: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217606 > [...] To me it looks like not much changed in if_bridge.c from RELENG_10_3 to RELENG_11_0 ... https://svnweb.freebsd.org/base/releng/11.0/sys/net/if_bridge.c?view=diff&r1=303975&r2=296373&diff_format=h The revisions are the topmost entries in https://svnweb.freebsd.org/base/releng/11.0/sys/net/if_bridge.c https://svnweb.freebsd.org/base/releng/10.3/sys/net/if_bridge.c respectively. Is this the correct/best way to answer the question what changed? The only real change relates to IF teardown and we did not change anything (stop/restart jails) when the outages occured. So ... the network interface driver? Probably? ix0: port 0x6020-0x603f mem 0xc7c0-0xc7df,0xc7e04000-0xc7e07fff irq 26 at device 0.0 numa-domain 0 on pci3 ix0: Using MSIX interrupts with 9 vectors ix0: Ethernet address: 0c:c4:7a:34:ec:ba ix0: PCI Express Bus: Speed 5.0GT/s Width x8 ix0: netmap queues/slots: TX 8/2048, RX 8/2048 Patrick signature.asc Description: Message signed with OpenPGP
Re: Bridged networking regression in 11.0?
Hi, all, > Am 30.08.2017 um 09:29 schrieb Patrick M. Hausen : > one of the systems on which we run our jail based "proServer" product failed > in a very odd way for the second time with a couple of days between the two > incidents. > [...] We found this open bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217606 What puzzles me is the fact that the original reporter claims that ifconfig down/up fixes the problem temporarily for him. Which in my case it didn't. But possibly I should have down/up'ed *all* bridge members not only the physical IF ... Patrick signature.asc Description: Message signed with OpenPGP
Bridged networking regression in 11.0?
Hi, everyone, one of the systems on which we run our jail based "proServer" product failed in a very odd way for the second time with a couple of days between the two incidents. We run VIMAGE based jails (a lot) and bridge them with the physical interface of the machine. - cloned_interfaces="bridge0 bridge1" ifconfig_bridge0_name="inet0" ifconfig_inet0="addm ix0 up" ifconfig_inet0_alias0="inet 217.29.41.2/24" ifconfig_inet0_ipv6="inet6 2a00:b580:8000:11:44e8:ab80:816:7869/64 auto_linklocal" ifconfig_bridge1_name="mgmt0" ifconfig_mgmt0="addm ix1 up" ifconfig_mgmt0_alias0="inet 10.5.105.7/16" ifconfig_mgmt0_ipv6="inet6 auto_linklocal" - The rest is managed by iocage wich creates the needed epair(4) interfaces, for some reason renames them to "vnetX" and adds them as members to the bridge. E.g. - [ry93@ph002 ~]$ ifconfig inet0 inet0: flags=8843 metric 0 mtu 1500 ether 02:50:51:fe:cc:00 inet6 fe80::50:51ff:fefe:cc00%inet0 prefixlen 64 scopeid 0x4 inet6 2a00:b580:8000:11:44e8:ab80:816:7869 prefixlen 64 inet 217.29.41.2 netmask 0xff00 broadcast 217.29.41.255 nd6 options=21 groups: bridge id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: vnet0:69 flags=143 ifmaxaddr 0 port 76 priority 128 path cost 2000 [... 50 vnet interfaces following ...] member: ix0 flags=143 ifmaxaddr 0 port 1 priority 128 path cost 2000 - When the system fails - no jail is reachable from the outside via IP - no jail is reachable from the host via IP - the host itself is reachable just fine - when we `iocage console` into a jail it can reach it's own IP addresses but nothing "outside" I tried - ifconfig ix0 down; ifconfig ix0 up - ifconfig inet0 down; ifconfig inet0 up # aka bridge0 - iocage stop ; iocage start The latter deletes the epair instance connected to the jail and creates a fresh one, then adds it to the bridge. No change in connectivity ... the start of the jail takes "forever" because various processes hang waiting DNS timeouts (no networking ;-) There's nothing in /var/log/messages or the dmesg buffer that relates to networking! Rebooting the host system "fixes" the situation. Now I'm well aware that this is too little information to draw some definite conclusions. Hence my first question is: what should I do (commands) when the situation arises again to gather more evidence? Or maybe we are just lucky and there is a known problem? Yes, I know VIMAGE is still considered experimental. We have been running this in production for months and it looks like it could be related to upgrading host and jails from 10.3 to 11.0 *or* switching the old shell based iocage for Brandon's new python based version. I cannot rule out iocage, yet it's not very probable - this is not a Docker like running service or network component, after all. Once the jails are up, iocage is done ... An then there's the chance that it is something with the ix driver and the way we use the interface ... so for completeness: - ix0: port 0x6020-0x603f mem 0xc7c0-0xc7df,0xc7e04000-0xc7e07fff irq 26 at device 0.0 numa-domain 0 on pci3 ix0: Using MSIX interrupts with 9 vectors ix0: Ethernet address: 0c:c4:7a:34:ec:ba ix0: PCI Express Bus: Speed 5.0GT/s Width x8 ix0: netmap queues/slots: TX 8/2048, RX 8/2048 ix0: promiscuous mode enabled ix0: link state changed to UP - As usual thanks for any hints, Patrick signature.asc Description: Message signed with OpenPGP
