Failed to bring up logger after a reload. Exiting

Operating System Version: Windows 10 Pro 18362
Provider (VirtualBox/VMWare): Virtualbox
Vagrant Version: 2.2.7
Packer Version: 1.5.1
Are you using stock boxes (downloaded) or were they built from scratch using Packer? Using full building and -VagrantOnly
Is the issue reproducible or intermittent?

Description of the issue:
While executing the script build.ps1, i have these issue :
AVERTISSEMENT : Something went wrong while attempting to build the logger box.
Attempting to reload and reprovision the host...
[main] Running vagrant_reload_host for: logger
[vagrant_reload_host] Running for logger
[vagrant_reload_host] Finished for logger. Got exit code: 1
C:\DetectionLab-master\DetectionLab-master\build.ps1 : Failed to bring up logger after a reload. Exiting
Au caractère Ligne:1 : 1
+ .\build.ps1 virtualbox -VagrantOnly
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,build.ps1

[main] Running post_build_checks
[post_build_checks] Running Splunk Check.
[download] Running for https://<IP_ADDRESS>:8000/en-US/account/login?return_to=%2Fen-US%2F, looking for This browser is not supported by Splunk
Error occured on webrequest: Exception lors de l'appel de « DownloadString » avec « 1 » argument(s) : « Impossible de se connecter au serveur distant »
[post_build_checks] Splunk Result: False
[post_build_checks] Running Fleet Check.
[download] Running for https://<IP_ADDRESS>:8412, looking for Kolide Fleet
Error occured on webrequest: Exception lors de l'appel de « DownloadString » avec « 1 » argument(s) : « Impossible de se connecter au serveur distant »
[post_build_checks] Fleet Result: False
[post_build_checks] Running MS ATA Check.
[download] Running for https://<IP_ADDRESS>, looking for
Error occured on webrequest: Exception lors de l'appel de « DownloadString » avec « 1 » argument(s) : « Impossible de se connecter au serveur distant »
[post_build_checks] ATA Result: False
AVERTISSEMENT : Splunk failed post-build tests and may not be functioning correctly.
AVERTISSEMENT : Fleet failed post-build tests and may not be functioning correctly.
AVERTISSEMENT : MS ATA failed post-build tests and may not be functioning correctly.
[main] Finished post_build_checks

My vagrant log file give me more details but i can't find where it can be fixed into the build.ps1 file. Can someone help me ? :) Thank you !
Bringing machine 'logger' up with 'virtualbox' provider...
==> logger: Importing base box 'bento/ubuntu-18.04'...

Progress: 40%
Progress: 60%
Progress: 90%
==> logger: Matching MAC address for NAT networking...
==> logger: Checking if box 'bento/ubuntu-18.04' version '202002.04.0' is up to date...
==> logger: Setting the name of the VM: logger
==> logger: Clearing any previously set network interfaces...
==> logger: Preparing network interfaces based on configuration...
    logger: Adapter 1: nat
    logger: Adapter 2: hostonly
==> logger: Forwarding ports...
    logger: 22 (guest) => 2222 (host) (adapter 1)
==> logger: Running 'pre-boot' VM customizations...
vagrant.exe : A customization command failed:
Au caractère C:\DetectionLab-master\DetectionLab-master\build.ps1:295 : 3
+   &vagrant.exe @('up', $VagrantHost, '--provider', "$ProviderName") 2 ...
+   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (A customization command failed::String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError

["modifyvm", :id, "--clipboard", "bidirectional"]

The following error was experienced:

#<Vagrant::Errors::VBoxManageError: There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["modifyvm", "7104e0f9-ab82-4a22-94b2-e62a9648b4b4", "--clipboard", "bidirectional"]

Stderr: Oracle VM VirtualBox Command Line Management Interface Version 6.1.2

VBoxManage.exe: error: Unknown option: --clipboard
>

Please fix this customization and try again.

It seems that it is linked to Vagrant and new version of Vbox :
https://github.com/oracle/vagrant-boxes/issues/188

Closing as a duplicate of https://github.com/clong/DetectionLab/issues/374


Intermittent packet loss between pods

After seeking advice on Slack, @brb advised that I log this as an issue.
We're seeing a small amount of intermittent packet loss on our Production environment, @backwardspy wrote a small rust application which pretends to speak http in order to further troubleshoot the issue.
use std::io::Write;
use std::net::{TcpListener, TcpStream};

const DATA: &[u8] = b"HTTP/1.1 200 OK
Content-Type: text
Content-Length: 6

\"echo\"";

fn handle_client(mut stream: TcpStream) {
    stream.write(DATA).unwrap();
}

fn main() {
    let listener = TcpListener::bind("<IP_ADDRESS>:8080").unwrap();

    // accept connections and process them serially
    for stream in listener.incoming() {
        handle_client(stream.unwrap());
    }
}

Running the above locally allows us to make approximately 800 connections per second using a Python client so it's reasonably performant. Once we deployed this into our Kubernetes cluster I launched a Ubuntu pod and put curl in a while true loop while true; do curl my360-jeff:8080; done, after approximately 350 connections we see instances of curl: (56) Recv failure: Connection reset by peer every now and then.
On Slack I was advised to look at the Weave logs which saw instances of (about 100 per hour):
# prod-worker-01
ERRO: 2018/07/24 14:36:20.139952 Captured frame from MAC (2e:2e:c5:80:80:c6) to (12:61:a3:9e:b0:b0) associated with another peer 66:d9:25:58:38:7c(prod-worker-09)
ERRO: 2018/07/24 14:36:20.136592 Captured frame from MAC (2e:2e:c5:80:80:c6) to (ae:d5:37:9e:f4:77) associated with another peer 66:d9:25:58:38:7c(prod-worker-09)

# prod-worker-08:
ERRO: 2018/07/24 14:36:38.431249 Captured frame from MAC (2e:2e:c5:80:80:c6) to (12:61:a3:9e:b0:b0) associated with another peer 66:d9:25:58:38:7c(prod-worker-09)
ERRO: 2018/07/24 14:36:38.426140 Captured frame from MAC (2e:2e:c5:80:80:c6) to (ae:d5:37:9e:f4:77) associated with another peer 66:d9:25:58:38:7c(prod-worker-09)

# prod-worker-10:
ERRO: 2018/07/24 14:35:48.005625 Captured frame from MAC (2e:2e:c5:80:80:c6) to (12:61:a3:9e:b0:b0) associated with another peer 66:d9:25:58:38:7c(prod-worker-09)
ERRO: 2018/07/24 14:35:48.003711 Captured frame from MAC (2e:2e:c5:80:80:c6) to (ae:d5:37:9e:f4:77) associated with another peer 66:d9:25:58:38:7c(prod-worker-09)

Additionally netstat -i shows some TX-DRP on the vxlan-6784 interface on some nodes:
# prod-worker-01 (1972 TX-DRP)
vxlan-6784 65535 0  48350779        0      0 0      52282585      0   1972      0 BMRU
# prod-worker-02 (29 TX-DRP)
vxlan-6784 65535 0  659979670       0      0 0      774399398     0     29      0 BMRU
# prod-worker-03 (74 TX-DRP)
vxlan-6784 65535 0<PHONE_NUMBER>      0      0 0<PHONE_NUMBER>    0     74      0 BMRU
# prod-worker-04 (206 TX-DRP)
vxlan-6784 65535 0<PHONE_NUMBER>      0      0 0<PHONE_NUMBER>    0    206      0 BMRU
# prod-worker-05 (88 TX-DRP)
vxlan-6784 65535 0  316929245       0      0 0      268493199     0     88      0 BMRU
# prod-worker-06 (52 TX-DRP)
vxlan-6784 65535 0  280753898       0      0 0      268094608     0     52      0 BMRU
# prod-worker-07 (30 TX-DRP)
vxlan-6784 65535 0  268853355       0      0 0      99970242      0     30      0 BMRU
# prod-worker-08 (0 TX-DRP)
vxlan-6784 65535 0  76848987        0      0 0      78291696      0      0      0 BMRU
# prod-worker-09 (455 TX-DRP)
vxlan-6784 65535 0  255571354       0      0 0      267805374     0    455      0 BMRU
# prod-worker-10 (8 TX-DRP)
vxlan-6784 65535 0<PHONE_NUMBER>      0      0 0<PHONE_NUMBER>    0      8      0 BMRU

What you expected to happen?
Connections arrive at the correct pod
What happened?
curl produces curl: (56) Recv failure: Connection reset by peer
How to reproduce it?
For us, just sending lots of traffic over the network shows the issue quite well.
Anything else we need to know?

Microsoft Azure
Ubuntu 16.04
Kubernetes 1.11.1
Kubernetes configured manually, can provide systemd unit examples if required.

Network:
ip route (worker-06):
cpressland@prod-worker-06 ~ ip route
default via <IP_ADDRESS> dev eth0
<IP_ADDRESS>/24 dev eth0  proto kernel  scope link  src <IP_ADDRESS>
<IP_ADDRESS>/12 dev weave  proto kernel  scope link  src <IP_ADDRESS>
<IP_ADDRESS> via <IP_ADDRESS> dev eth0
<IP_ADDRESS> via <IP_ADDRESS> dev eth0
<IP_ADDRESS>/16 dev docker0  proto kernel  scope link  src <IP_ADDRESS> linkdown

ip -4 -o addr
cpressland@prod-worker-06 ~ ip -4 -o addr
1: lo    inet <IP_ADDRESS>/8 scope host lo\       valid_lft forever preferred_lft forever
2: eth0    inet <IP_ADDRESS>/24 brd <IP_ADDRESS> scope global eth0\       valid_lft forever preferred_lft forever
3: docker0    inet <IP_ADDRESS>/16 scope global docker0\       valid_lft forever preferred_lft forever
6: weave    inet <IP_ADDRESS>/12 brd <IP_ADDRESS> scope global weave\       valid_lft forever preferred_lft forever

sudo iptables-save: https://gist.github.com/cpressland/9745d9e2fd9547c06e84b6ba11aede5e

I launched a Ubuntu pod and put curl in a while true loop while true; do curl my360-jeff:8080; done,

Just to narrow down the issue (taking out kube-proxy in the data path), would you mind trying the same tests directly from pod to pod i.e. without accessing the service my360-jeff and directly accessing the pod IP

Thanks @murali-reddy - unfortunately we see the same thing:
root@bash-7df6778f79-574dm:/# while true; do curl <IP_ADDRESS>:8080; done
"echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo""echo"curl: (56) Recv failure: Connection reset by peer"echo""echo"

Sorry, you may need to scroll a bit to see the curl: (56) Recv failure: Connection reset by peer

It's worth checking whether the number of the Captured <..> errors is equal to TX-DRP (as we drop a packet in the case of error) and whether the errors are logged due to https://github.com/weaveworks/weave/issues/2877.

@murali-reddy you can find the image in question here. please excuse any bad behaviour - it was a very quick hack!

I am not able to reproduce this issue. Are you able to easily replicate this scenario or any other cluster?

@murali-reddy - sorry for the delayed response.
I have confirmed that this happens in all three of our Kubernetes Clusters, which isn't all that surprising given then they're in the same Azure region, share the same Terraform deployment modules and are configured with the same Cookbooks. However, I did note that it does not happen if the curl pod and the jeff pod are on the same node, which I suppose makes sense as we should be hitting iptables before weave, right?
Is there any specific information I can provide to help troubleshoot this further? I'm on holiday for the next week so @BackwardSpy should be able to help with anything but I'll try to answer any questions as and when I see them.
@BackwardSpy - on the off chance this is some weirdness in Azure's Network can you load Jeff onto some new VMs in a new VNet and try again? Probably worth taking Docker out of the mix too and just running the binary on the system. If you are able to replicate, can you try in a different region too?

However, I did note that it does not happen if the curl pod and the jeff pod are on the same node, which I suppose makes sense as we should be hitting iptables before weave, right?

Right packets might getting bridged locally without going through data-path setup by weave.

Is there any specific information I can provide to help troubleshoot this further?

Could you please share the details for the question @brb asked. Basically if the number of packet drops seen correlates to the errors
ERRO: 2018/07/24 14:36:20.139952 Captured frame from MAC (2e:2e:c5:80:80:c6) to (12:61:a3:9e:b0:b0) associated with another peer 66:d9:25:58:38:7c(prod-worker-09)
ERRO: 2018/07/24 14:36:20.136592 Captured frame from MAC (2e:2e:c5:80:80:c6) to (ae:d5:37:9e:f4:77) associated with another peer 66:d9:25:58:38:7c(prod-worker-09)

@cpressland i just tested it on a fresh vm in a fresh vnet in azure, both with and without docker, and i could not replicate the connection issue at all.

@murali-reddy / @brb - I’ll get those stats for you on Monday when I’m back in the office.
@BackwardSpy - thanks for this. I guess this proves there isn’t an issue with the underlay Azure Network. Can you task somebody with spinning up a cluster with kubeadm tomorrow to repeat the above test with Weave and Kubernetes?

Finally had time to further test this. We've spun up a kubeadm Kubernetes Cluster in Azure with the following configuration, thankfully this is very easy to reproduce in Azure.
1 x Virtual Network with 2 Subnets
1 x Kubernetes Master in Subnet 1
2 x Kubernetes Nodes in Subnet 2
Kubernetes Master configured with latest docker version from https://get.docker.com/ and then kubeadm init, weave is installed with kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
Kubernetes Nodes simply have latest docker and the kubeadm join command run on them.
All three servers are configured with the default Ubuntu 16.04 Cannonical image in Azure.
The "Jeff" container is deployed with:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: jeff
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: jeff
    spec:
      containers:
      - name: jeff
        image: backwardspy/jeff
        ports:
        - containerPort: 8080

Once deployed I can see that Jeff is running on node 02
laadmin@weave-controller:~$ kubectl get pods -o wide
NAME                    READY     STATUS    RESTARTS   AGE       IP          NODE
jeff-6c66c6855b-s75z2   1/1       Running   0          9m        <IP_ADDRESS>   weave-node-02

From weave-node-01 I can run while true; do curl <IP_ADDRESS>:8080; done and see instances of curl: (56) Recv failure: Connection reset by peer however I do NOT observe the TX-DRP number increasing on any interfaces on weave-node-02:
Kernel Interface table
Iface           MTU   Met RX-OK   RX-ERR RX-DRP RX-OVR TX-OK   TX-ERR TX-DRP TX-OVR Flg
datapath        1376  0   1241    0      0      0      160     0      0      0      BMRU
docker0         1500  0   0       0      0      0      0       0      0      0      BMU
eth0            1500  0   5566011 0      0      0      5293097 0      0      0      BMRU
lo              65536 0   534327  0      0      0      534327  0      0      0      LRU
vethwe-bridge   1376  0   21050   0      0      0      24875   0      0      0      BMRU
vethwe-datapath 1376  0   24875   0      0      0      21050   0      0      0      BMRU
vethwepl1a4027b 1376  0   24672   0      0      0      19826   0      0      0      BMRU
vxlan-6784      65535 0   127498  0      0      0      132281  0      0      0      BMRU
weave           1376  0   1240    0      0      0      161     0      0      0      BMRU

Given that this is a cluster outside of any of our organisational assets if either @brb or @murali-reddy want to provide me with a public ssh key I'd be happy to give you access to help in any debugging efforts.

@cpressland So i tried on AWS, i am able to reproduce exact issue (56) Recv failure: Connection reset by peer. Strangely on my local cluster I am not able to reproduce. I will try to find the root cause now that I can reproduce easily.

I tired to find any possible issues from Weave side that is causing reported problem. While I am able to reproduce the connection failure with the image provided, I dont see any issues from Weave side. All the OVS flow rules are configured properly and in place, so there is no reason to belive packets are getting dropped in datapath setup by Weave. I have not seen any errors in Weave logs as well.
So I did while true; do curl --trace-ascii dump.txt <IP_ADDRESS>:8080 || break; done
== Info: Hostname was NOT found in DNS cache
== Info:   Trying <IP_ADDRESS>...
== Info: Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 8080 (#0)
=> Send header, 80 bytes (0x50)
0000: GET / HTTP/1.1
0010: User-Agent: curl/7.38.0
0029: Host: <IP_ADDRESS>:8080
0041: Accept: */*
004e:
== Info: Recv failure: Connection reset by peer
== Info: Closing connection 0

Clearly this is TCP connection reset from the peer which is the pod in the case.
Again to see there are no network issues while true; do ping -n -i 0.001 <IP_ADDRESS>; done runs fine.
I wonder if application is not able to take the load you are sending.
// accept connections and process them serially can you please make processing concurrent and see if you still see issue?

I'll close this off as we've been able to replicate the issue with Flannel, it's clearly not an issue with Weave, but it's really interesting that this only happens in kubernetes environments on cloud providers. My local Kubernetes Clusters and Docker environments never experience this issue regardless of the speed I throw requests at it. I guess our journey continues. Thanks for the assist!

@cpressland Thanks for the update.

Just FYI we are seeing this issue weave-2.5.0
vxlan-6784 65485 0  786351303      0      0 0      416236109      0     39      0 BMRU
vxlan-6784 65485 0  585180470      0      0 0      274931757      0     52      0 BMRU
vxlan-6784 65485 0  771039758      0      0 0      382114976      0    133      0 BMRU
vxlan-6784 65485 0<PHONE_NUMBER>      0      0 0<PHONE_NUMBER>      0  11771      0 BMRU
vxlan-6784 65485 0<PHONE_NUMBER>      0      0 0<PHONE_NUMBER>      0  16847      0 BMRU

@Hashfyre Please open a new issue.
Issue reported in this bug is nothing to do with Weave.


updated readme, ArticleHandler handles cnb.go.sg as well as onlinecitizen fine so added to han…

…dler.py

Please do not merge directly into master, all PRs should go to develop


"Return to game" from the menu resets something

and then the game is buggy. Can you look into it @secretrobotron

I think if we move the controls menu to another another page this won't matter as much anyway

#61 obliterates the menu. So, maybe it's ok now. hahaha


fix: updated scipy version to allow 1.14.x

Updated requirements.txt to support Scipy versions 1.14.x
closes : #1648

@melanopsis would you please review this PR?

@fabclmnt would you please check if the changes done are alright?

Hi @ankana2113,
I've forced the required change this time.  I've insured the expected naming and convention "fix: updated spicy...".
I hope this was an incentive to keep contributing to Ydata-profiling! Thank you 🚀


Can't get better ascii border to display only the simple +,-,| ones.

Hi. Im new to this library and I am testing it out right now. When I copy the demo projects and run them it works but I only get "basic" borders meaning only "+ - |" symbols and not the better looking ascii borders.
The demo looks like this:
package main

import (
	"log"

	ui "github.com/gizak/termui/v3"
	"github.com/gizak/termui/v3/widgets"
)

func main() {
	if err := ui.Init(); err != nil {
		log.Fatalf("failed to initialize termui: %v", err)
	}
	defer ui.Close()

	p := widgets.NewParagraph()
	p.Text = "Hello World!"
	p.SetRect(0, 0, 25, 5)

	ui.Render(p)

	for e := range ui.PollEvents() {
		if e.Type == ui.KeyboardEvent {
			break
		}
	}
}

I don't know if it should make a differance but I'm using windows. Under linux the proper ascii borders get displayed but in windows not. Even in git bash in windows only the basic borders get displayed.

sounds like a windows unicode rendering bug?

Hello,
Given the time past I figure u have already moved on from the issue you were facing.
For others that might come across the same "issue", it's quite simple.
The symbols used for rendering on Windows are coded in that way.
You could make a fork and edit them manually, these can be found in "master/symbols_windows.go"
package termui

const (
    TOP_LEFT     = '┌'
    TOP_RIGHT    = '┐'
    BOTTOM_LEFT  = '└'
    BOTTOM_RIGHT = '┘'

    VERTICAL_LINE   = '│'
    HORIZONTAL_LINE = '─'

    VERTICAL_LEFT   = '├'
    VERTICAL_RIGHT  = '┤'
    HORIZONTAL_UP   = '┬'
    HORIZONTAL_DOWN = '┴'

    QUOTE_LEFT  = '‹'
    QUOTE_RIGHT = '›'

    VERTICAL_DASH   = '│'
    HORIZONTAL_DASH = '─'
)


where model

Can you tell me where model is if i want to run demo?

We do not provide pre-trained models. You'll have to train your own model using the data provided by the authors of "Deep Automatic Portrait Matting" at http://xiaoyongshen.me/webpages/webpage_automatting/

ok,i'm try.thanks
------------------ 原始邮件 ------------------
发件人: "Sungjoo<EMAIL_ADDRESS>发送时间: 2019年5月29日(星期三) 下午5:19
收件人<EMAIL_ADDRESS>抄送: "sharon"296865232<EMAIL_ADDRESS>主题: Re: [hyperconnect/MMNet] where model (#5)
We do not provide pre-trained models. You'll have to train your own model using the data provided by the authors of "Deep Automatic Portrait Matting" at http://xiaoyongshen.me/webpages/webpage_automatting/
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.


feat: initial release process

Created Initial Release Process
This pr adds the following functionality to setup and aid the release process.

Creates and saves logs action
Goreleaser action to creating binary releases
Goreleaser config for configuring goreleaser action
Release process documentation

The config file helps setup goreleaser. It will determine the build binaries and the changelog messages. Currently set to append so it will add each piece to the same changelog for a release. (Similar to Zarf and others)
To do a release you need to have permissions  to push tags which will trigger the GitHub goreleaser action.
git tag -s vX.X.X -m "Release Commit Message"
git push origin vX.X.X

Closes Issue https://github.com/defenseunicorns/go-oscal/issues/46

I didn't see anything out of order currently. Updated repository permissions to add the lula-dev team as maintainers and therefor capable of releasing protected tags.
Would like @mike-winberry approval before merge.


Genome missing strain name

https://www.patricbrc.org/view/Genome/43770.28
Should be called Corynebacterium striatum strain BM4687

Updated to Corynebacterium striatum strain BM4687.
https://www.patricbrc.org/view/Genome/43770.28


Space between buttons that are large 150px * 64px

How can I eliminate the space between 2 buttons?

Do you mean allowing different button sizes? Right now buttons are forced to have the same size (the size of the largest button)

I have added allowsButtonsWithDifferentWidth property in 1.4.0