在Windows Terminal中WSL无法打开错误代码是 process exited with code 4294967295 (0xffffffff)，但在命令行中 通过 "C:\Windows\System32\wsl.exe" -d ubuntu18 是正常的 解决方法是：通过修改启动的命令为 wsl.exe ~ -d Ubuntu 中间加一个 ~ 可以很好的解决掉 这种方法存在一个问题，打开的wsl终端将为根目录而不是当前windows目录 Reference Unable to launch WSL Ubuntu
进入后，找到linux16 开头的一行！将ro改为 rw init=/sysroot/bin/sh 查看passwd和 shadow 发现用户并没有锁，于是想到，应该是pam的设置。 text 1 pam_tally2.so deny=6 onerr=fail unlock_time=120 默认log在： /var/log/tallylog text 1 2 3 4 chroot /sysroot # 使用pam_tally2命令解锁 pam_tally2 --user=root --reset rw init=/sysroot/bin/sh Reference Centos7.x破解密码 pam_tally2锁用户
phenomenon： Specified key was too long; max key length is 3072 bytes 在修改一个数据库字段时，字段容量被限制为了表前缀的大小而不是本身的容量大小 查了一下innodb_large_prefix究竟是什么？ 动态行格式DYNAMIC row format 支持最大的索引前缀(3072)。由变量innodb_large_prefix进行控制。 By default, the index key prefix length limit is 767 bytes. See Section 13.1.13, “CREATE INDEX Statement”. For example, you might hit this limit with a column prefix index of more than 255 characters on a TEXT or VARCHAR column, assuming a utf8mb3 character set and the maximum of 3 bytes for each character....
sence：python中使用subprocess.Popen(cmd, stdout=sys.STDOUT, stderr=sys.STDERR, shell=True) ，stdout, stderr 为None. 在错误中执行是无法捕获 stderr的内容，后面将上面的改为 subprocess.Popen(cmd, stdout=PIPE, stderr=PIPE, shell=True),发现是可以拿到 stderr, 但是会遇到大量任务hanging，造成线上事故。 为此特意查询subprocess的一些参数的说明。 stdin stdout stderr 如果这些参数为 PIPE, 此时会为一个文件句柄，而传入其他（例如 sys.stdout 、None 等）的则为None 正如这里介绍的一样，subprocess 。 而使用 PIPE，却导致程序 hanging。一般来说不推荐使用 stdout=PIPE stderr=PIPE，这样会导致一个死锁，子进程会将输入的内容输入到 pipe，直到操作系统从buffer中读取出输入的内容。 查询手册可以看到确实是这个问题 Refernce Warning This will deadlock when using stdout=PIPE and/or stderr=PIPE and the child process generates enough output to a pipe such that it blocks waiting for the OS pipe buffer to accept more data. Use communicate() to avoid that....
goland使用vendor作为获取依赖源 软件版本： system：windows10 1709 terminal： wsl ubuntu1804 goland：201903 goland 打开项目时使用mod模式，无法识别外部包的依赖 根据goland官方提示，开启时，将忽略go.mod依赖描述，所以就找不到相对应的依赖，但是编译时正常的。可以看到下图中，external libraries 并没有加载外部的库导致了无法识别。 此时想要正常使用的话，可以按照提示操作 将 goland 改为gopath模式，执行go mod vendor 将依赖同步到vendor 。此时正常。 当依赖更新时，可以手动添加对应的依赖库，go mod tidy 后 。因为vendor中没有新的依赖，需要手动执行下go mod vendor即可正常使用。 使用vendor编译 在编译时，可以使用 -mod=vendor 标记，使用代码主目录文件夹下vendor目录满足依赖获取，go build -mod=vendor。此时，go build 忽略go.mod 中的依赖，（这里仅使用代码root目录下的vendor其他地方的将忽略） GOFLAGS=-mod=vendor 设置顶级vendor作为依赖 go env -w GOFLAGS="-mod=vendor" 进行设置。 取消 go env -w GOFLAGS="-mod="