text:
Distro shut down even with running processes

Version
Microsoft Windows [Version 10.0.22621.521]
WSL Version

[X] WSL 2
[ ] WSL 1

Kernel Version
5.15.62.1
Distro Version
Ubuntu 20.04
Other Software
Docker Engine version 20.10.18
Repro Steps

Create fresh Ubuntu 20.04 image
Enable systemd
Install Docker into Ubuntu (Ansible example)
Run nginx in Docker (docker run -d -p 80:80 nginx)
Verify nginx is running in your browser (http://localhost/)
Exit the shell

Expected Behavior
Since nginx is running, the distro should not shut down.
Prior to upgrading to 0.67.6 w/ systemd support, this was the (presumably correct, but definitely desired) behavior.
Actual Behavior
After a short period of time, the distro is forcefully shut down by the system.
Logging back in, you can see it was forcefully shut down:
 sh$ docker ps -a
CONTAINER ID   IMAGE     COMMAND                  CREATED          STATUS                       PORTS                               NAMES
ad20314283c5   nginx     "/docker-entrypoint.…"   14 minutes ago   Exited (255) 4 minutes ago   0.0.0.0:80->80/tcp, :::80->80/tcp   admiring_bardeen

Diagnostic Logs
No response

Unfortunately, this is the new documented behavior, per blog post:

It is also important to note that with these change, systemd services will NOT keep your WSL instance alive.

You've currently got to have something running as a child of init - the Microsoft init, not pid 1 - to keep the distro running. Not my preference, but.

This is (fairly) explicitly stated in Craig's DevBlog announcement:

It is also important to note that with these change, systemd services will NOT keep your WSL instance alive. Your WSL instance will stay alive in the same way it did before, which you can read more about here.

That was actually surprising to me, as Windows 11's wsl.conf boot.command used to keep services running after exiting the shell.  It was only in the Preview releases that it was changed to terminate when all processing started interactively had terminated.  Hence I filed #8661, thinking this was a regression.  Based on the text above, it seems that this might have been an intentional change.
Perhaps we should have a feature-request for a /etc/wsl.conf flag to allow the instance to continue running when any background task is still running.

Or just

Perhaps we should have a feature-request for a /etc/wsl.conf flag to allow the instance to continue running when any background task is still running.

Or just "until systemctl poweroff", which is pretty much how the above should behave when systemd support is enabled.

Fair points - I think an option to keep distros running (and not idle terminate them) is a good idea.

systemd services will NOT keep your WSL instance alive

Is a process launched by Docker considered to be a "systemd service"? Docker itself is, obviously, but things launched by Docker, I would've expected to keep the distro alive.
It seems to me like they implemented one thing (always shut it down when there's no interactive shell) but documented something else (don't let systemd services keep it alive).

(BTW, hearing the description of "we only stay alive for things rooted on Microsoft's init" helps me understand the exact implementation. It's unfortunate that the blog post described in a way that doesn't seems to match the actual implementation. Why not just describe it in the technically correct way?)

Fair points - I think an option to keep distros running (and not idle terminate them) is a good idea.

But what does this mean for systemd, then? I mean ps aux on a systemd-enabled distro has, as expected, a ton of stuff running. How would the proposed flag change the behavior? Would it basically always leave systemd distros always running, because of all those systemd processes? Or would the implementation better match the blog post description ("systemd services will NOT keep your WSL instance alive" but anything else will...?)

Fair points - I think an option to keep distros running (and not idle terminate them) is a good idea.

@benhillis
Just for clarity, it would be great if that option still allowed distros to terminate if no other processes were running, similar to the way it worked with the [boot].command section in the GA Windows 11 release.  I'd only expect/want it to stay running if there's some background process, whether it was started through:

Docker
Systemd
/etc/wsl.conf [boot].command (#8661)
Etc.?

Basically, I think the flag would say "Work like it did in Windows 11 GA" ;-)

@bradwilson

It's unfortunate that the blog post described in a way that doesn't seems to match the actual implementation. Why not just describe it in the technically correct way?

I'm not sure they realized they had ever changed it to work any other way.  The way I read the description, it seems Craig thought that was the way it always worked.

Answering my own question above, I guess it could be a "whitelist process" implementation, where /etc/wsl.conf had a keep-alive (or something named better) option with a list of processes that would prevent the distro from self-terminating.
Just throwing it out there - I'm not tied to it by any means.

Basically, I think the flag would say "Work like it did in Windows 11 GA" ;-)

I have doubts about this being what I want, though I recognize that may be where this falls back to (see my question above about systemd services in general keeping things alive with this new proposed flag).
Having Docker keep the distro alive in Win11 GA is acceptable but not ideal. It's something that's I've come to accept, and I have quick commands to kill the things that are most likely to be "daemonized" in a pre-systemd world (notably, Docker and the GPG agent). In a world where we have systemd (and I have Docker's life cycle owned by systemd), I wouldn't want Docker itself to be something that would keep the distro alive, just the case of running Docker containers.

@bradwilson  Yes, our replies are getting out of sync  ;-) - I saw that you post that concern above and posted a separate reply (actually two now) regarding it.

How would you tell the difference between the System dbus instance vs. Nginx, for instance?

That's why I'm asking. A mode where "any background process keeps the distro alive" + systemd means the distro will never shut itself down, and I'll be running a lot of wsl -t distro to keep things clean. In that case, I'm better off without systemd (despite it ostensibly providing other value that I might want).

That means it would also be critical to ensure that systemd is something I can opt out of. Microsoft makes it sounds like it will eventually become the default, which is fine, so long as the wsl.conf flag to disable it doesn't disappear.

Definitely agree (and was just about to post that).  I definitely want it opt-in regardless, since I think I'll prefer to run without it most of the time (and I have some distros that absolutely don't use Systemd at all).
But what about the "whitelist" option I mentioned above?  Would that work for the scenarios you envision?

You're always going to want distros without systemd, because Linux namespaces (which separate the distros) don't cover everything; things systemd does in one distro will and do leak to the others. For that reason alone, I can't see it ever becoming compulsory.
(This is why I put an explicit mention in the systemd-genie docs that running more than one distro at a time with systemd was unsupported. You don't want them fighting over whose sysctl values, whose AppArmor profiles, or whose network configuration is the validest. That way lies many subtle and impossible-to-diagnose issues.)

Having mentioned this elsewhere, for anyone who finds it of interest - the current workaround for this is to create a process that runs forever and detach it from the calling terminal such that it will persist (as a child of the init) even when the terminal is closed. So you can create a script, call it wait-forever.sh:
#!/bin/sh
while true
do
  sleep 1h
done

then run it with
nohup wait-forever.sh > /dev/null &
and then when you exit the terminal that script will keep running as a child of init, and that will keep the instance open.
(Make sure you don't run it inside a tmux session or anything else that might kill its children in ways nohup won't stop.)

Or use https://linux.die.net/man/1/daemonize to accomplish this? I'd recommend this.

@pmartincic
Have you tested this one? And if so, what did you use as the process to daemonize?
Because as far as I know, the criteria for "keeps the instance open" requires that a process be a child of the Microsoft init to do so, and since daemonize (unlike nohup) disassociates the daemonized process from its process group, it stops being a child of its init and becomes a child of pid 1 (systemd), which shouldn't work to keep the instance running.
And when I tested it, sure enough, it didn't.

Hmmmm. I tested it once upon a time when I was fixing an issue relating to interop and shell lifetimes. But haven't touched it since then. I can check again. I don't remember what all I tested with.

FWIW, I think it may have worked in the past (pre-systemd-support), as I used daemonize to run my bottled systemd when writing genie, and the instance didn't go away then.
But when using the current native systemd support, daemonized processes don't appear to keep instances around.

Thank-you, I'll look into that. Shouldn't have changed because of systemd support.

The reason seems fairly straight-forward: when you enable systemd, nothing is going to keep the instance alive except for an interactive shell, and this is by design.

My personal preference at the moment to keep a distro running is to:

Install Funtoo keychain (available in most Linux distributions), which I use anyway (e.g. sudo apt install keychain).  Keychain is a front-end that creates a singleton (per-user) ssh-agent that is then attached to (via environment variables) in each shell instance.  It's nice for this purpose because of the singleton design.

Create /etc/profile.d/wsl_keepalive.sh with the following:
#!/usr/bin/env sh
eval $(keychain -q)

That ensures that even if you the distribution as root, the keep-alive code will still run.  Note that it only works if your shell is POSIX compliant and is loaded as a login-shell.
To terminate the keepalive process, keychain - all (for each user that has started one -- typically only your default user, but could be root as well).

Lol! By design. Those are my words to utter :), or more specifically Ben's.
My smoke tests with daemonize $(which sleep) n and detaching tmux seem to work as expected as I test it now. Both are reparented to relay init. The console is closed and relay init persists so long as the children are alive. Once relay init dies cleanup commences after a brief delay. I'm running 0.70.5.0
Perhaps I don't see what you see?

Okay, that is weird.
I just tried it now on 0.70.5.0, and I can reproduce your results in which the sleep gets reparented to the relay init. (Unless I run it inside a systemd user session, when it gets reparented to the user systemd --
(So, bottle-imp or other user-systemd-session users, don't do that. But then, if you're using bottle-imp, it does the hold-the-instance-open thing for you.)
-- but I would swear under oath and wager negotiable instruments that the last time I tried this, sleep got reparented to the pid 1 systemd. I'm going to go check my other machines - meanwhile, could this have changed recently, or I am going nuts?

Okay, I found a machine with 0.67.6 installed and gave it a try there. Same behavior.
I guess nuts it is. Sorry to have wasted your time, @pmartincic . 😳

Hey! No worries, you have a good reputation on our side of the fence @cerebrate. Keep keeping on.

To start wsl on windows startup and keep it running:
touch ~/startup.sh && chmod +x ~/startup.sh

vim ~/startup.sh
--
#!/usr/bin/bash
while [ true ]; do
  nohup sleep 120 > /dev/null
done

shell:startup / wsl-startup.vbs
set ws=wscript.CreateObject("wscript.shell")
ws.run "wsl -d Arch ~/startup.sh",0

https://askubuntu.com/a/1452424/911078

Please fix this, I was running a nginx and after a few seconds it shut down automatically

Here's a simple script I'm using.
It opens a hidden terminal window and waits for it to return.
Because it's a terminal waiting for user input, it never returns and WSL will keep running indefinitely.
Set shell = CreateObject("WScript.Shell")
shell.Run "wsl", 0, True

This wouldn't work if WSL is shutdown manually and restarted again though, right?

You can try use:
wsl screen
or
wsl tmux new -s backgroundsession
and then close the console window.

You can try use: wsl screen or wsl tmux new -s backgroundsession and then close the console window.

But add command = runuser -u myuser -- tmux new -s bg -d to /etc/wsl.conf not work.

My workaround  is to spawn the sleeping windows process in systemd service. I use the builtin windows command waitfor to keep distro alive.
[Unit]
Description=Keep Distro Alive

[Service]
ExecStart=/windows/path/to/waitfor.exe MakeDistroAlive

[Install]
WantedBy=multi-user.target

It will not shutdown Ubuntu as long as waitfor process is alive.

@firejox thanks! Do I put it in /etc/wsl.conf ?

It is systemd service, so you need to save as [service name].service file and put the file under systemd folder e.g. /etc/systemd/system/. And you can run these commands.

Start systemd service

sudo systemctl start [service name].service

Make it can auto run in next booting.

systemctl enable [service name].service

Using this setup, WSL 2 won't shut down when you close all the shells/terminals:
https://github.com/microsoft/WSL/issues/9968#issuecomment-1510916463

My workaround is to spawn the sleeping windows process in systemd service. I use the builtin windows command waitfor to keep distro alive.
Update: signal first in order to cleanup previous waitfor command
[Unit]
Description=Keep Distro Alive

[Service]
ExecStartPre=/windows/path/to/waitfor.exe /si MakeDistroAlive #cleanup the waiting signal
ExecStart=/windows/path/to/waitfor.exe MakeDistroAlive

[Install]
WantedBy=multi-user.target

It will not shutdown Ubuntu as long as waitfor process is alive.
Another way is to block the stdin of choice command. See https://github.com/firejox/hang-stdin#keep-wsl-distro-alive

Thanks for your scripts.
It worked when I removed the ExecStartPre line seems it caused some errors.
Any idea about that?
 The unit keep-wsl-distro-alive.service has entered the 'failed' state with result 'exit-code'.
Apr 02 15:51:48 systemd[1]: keep-wsl-distro-alive.service: Service will not restart (restart setting)
Apr 02 15:51:48 systemd[1]: keep-wsl-distro-alive.service: Changed start-pre -> failed
Apr 02 15:51:48 systemd[1]: keep-wsl-distro-alive.service: Job 588 keep-wsl-distro-alive.service/start finished>
Apr 02 15:51:48 systemd[1]: Failed to start Keep WSL Distro Alive.

I just nuked my wsl instance thinking there was a problem with my distro, as a recent update seemed to have killed KDE's gui. I use wsl to persist a btrfs drive partition, and since redoing my wsl distro, the connection is severed frequently due to wsl shutting down. There was never a custom service needed. I also run SUSE, not ubuntu.

@biggestsonicfan If you start the WSL 2 instance like this, it will keep on running even if you close all the shells:
C:\>wsl.exe --distribution Ubuntu-22.04 --exec dbus-launch true & wsl.exe --distribution Ubuntu-22.04

Currently, I use tmux to prevent shutdown.
# 1. enter WSL
wsl

# 2. start a tmux session and deatch it.
tmux new -s bg -d

# 3. exit WSL
exit

@biggestsonicfan You can check whether systemd feature was enabled in your distro. When systemd feature is enabled, the init process will be /sbin/init instead of /init. That will lead gui program killed because they would be reset as the child process of /sbin/init. After you closing the terminal, there is no /init process in your running distro. WSL will shutdown running distro automatically due to no /init process.

@firejox The WSL 2 instance automatic shutdown is happening because Microsoft decided that's how they wanted it to behave by default. Closing your shells have no effect on the init process. WSL 2 instances run systemd by default now.

@firejox After installing x11-utils in the WSL 2 instance, you can run:
C:\>wsl.exe --distribution Ubuntu-22.04 --exec xev

and xev opens. But this doesn't make any change to how Microsoft has designed the WSL 2 instance auto-shutdown.

@aki-k xev prove nothing. I ran omnetpp and there was no gui appeared. BTW, I just explain what situation would lead auto-shutdown happen. My systemd service is toggleable. It can be easily back to auto-shutdown mechanism.

@biggestsonicfan If you start the WSL 2 instance like this, it will keep on running even if you close all the shells:
C:\>wsl.exe --distribution Ubuntu-22.04 --exec dbus-launch true & wsl.exe --distribution Ubuntu-22.04

Thanks, but I don't want to start my instance like that.

@biggestsonicfan You can check whether systemd feature was enabled in your distro. When systemd feature is enabled, the init process will be /sbin/init instead of /init. That will lead gui program killed because they would be reset as the child process of /sbin/init. After you closing the terminal, there is no /init process in your running distro. WSL will shutdown running distro automatically due to no /init process.

Do I check the logs for that? ls -l /sbin/init shows lrwxrwxrwx 1 root root 22 Apr  3 00:04 /sbin/init -> ../lib/systemd/systemd

@biggestsonicfan firejox doesn't know how systemd in WSL 2 and the WSL 2 auto-shutdown work.

@biggestsonicfan It means systemd enabled in your distro. There are several ways you can try in your scenario.

disable systemd in wsl.conf
Because your scenario works before distro update, there are some processes be the child processes of /init.
start invisible interactive shell in Windows side.
potchy's solution is for this.
run command that make /init process exist in your system after closing interactive shell.

cerebrate's solution use nohup to run sleeping program to prevent shutdown after closing interactive shell.
pmartincic's solution use daemonize do the same thing.
NotTheDr01ds's solution use keychain to accomplish.
aki-k's solution run dbus-launch to start message bus
my solution spawn sleeping Windows process because WSL Interop internally spawn /init process.

The third way you can put the command in profile script which will automatically run when you start an interactive shell (see what NotTheDr01ds does). If you don' want spawn new running process for every time you start an interactive shell, you can use flock to control it. Here is an example.
# put below in your profile script ( /etc/profile, /etc/profile.d/ ...)
nohup flock -nxF / keep-wsl-alive-script >/dev/null &  #  keep-wsl-alive-script can be replace by `flock -xF / true` due to double locking mechanism.

If you want to use systemd service, I will recommend you to spawn sleeping Windows process in systemd service script. Because systemd service script will spawn child process of systemd instead of /init, it will not keep WSL alive except that child process use /init.
@aki-k Please give helpful information. Among these discussions, you just keep saying this is by design and don't explain the workflow of the design. It is important for those people who have the same problem and want to seek the solution.

@biggestsonicfan It means systemd enabled in your distro.

It is not. As you state. systemd requires the systemd=true flagin the[boot]of/etc/wsl.conf. I do not have this. Further, as I [previously stated](https://github.com/microsoft/WSL/issues/8854#issuecomment-2042021469), I had nuked my WSL instance in attempt to fix GUI application issues. The issue turned out to be having systemd enabled. With systemd enabled, a few GUI applications could not launch and Dolphin could not open applications.  All applications launch and now Dolphin can open applications again as the kactivitymanagerd` service could not run with systemd enabled.
Continuing on, I am running a SUSE distro. All three patterns of wsl_base, wsl_gui, and wsl_systemd are not installed.
To go the absolute furthest step, ps --no-headers -o comm 1 returns init(openSUSE-T, not systemd, as well as systemctl is-system-running returning offline.
I feel that the suggested "invisible shells" and "heartbeat checks" are only band-aids to a problem which needs a solution.
Unsubscribing from this as I don't think I'm going to get a real answer until I accidentally discover it as a feature pushed upstream.

Honestly the best way to know whether systemd is enabled is to run ps aux (or whatever the equivalent switches might be in your distro). My non-systemd distro only shows /init, plan9, and the shell I'm running in:
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0   2280  1524 ?        Sl   11:41   0:00 /init
root         8  0.0  0.0   2280     4 ?        Sl   11:41   0:00 plan9 --control-socket 5 --log-level 4 --server-fd 6 --pipe-fd 8 --log-truncate
root        11  0.0  0.0   2296   116 ?        Ss   11:41   0:00 /init
root        12  0.0  0.0   2296   124 ?        S    11:41   0:00 /init
bradwil+    13  0.0  0.0  15256  9416 pts/0    Ss   11:41   0:00 -bash
bradwil+  2772  0.0  0.0  12676  1552 pts/0    R+   17:14   0:00 ps aux

A systemd distro will show a much more:
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.5  0.0 167056 12780 ?        Ss   17:16   0:00 /sbin/init
root           2  0.0  0.0   2280  1304 ?        Sl   17:16   0:00 /init
root           9  0.0  0.0   2716   384 ?        Sl   17:16   0:00 plan9 --control-socket 6 --log-level 4 --server-fd 7 --pipe-fd 9 --log-truncate
root          38  0.0  0.0  39608 15168 ?        S<s  17:16   0:00 /lib/systemd/systemd-journald
root          56  0.1  0.0  21960  5944 ?        Ss   17:16   0:00 /lib/systemd/systemd-udevd
root          67  0.0  0.0   4492   168 ?        Ss   17:16   0:00 snapfuse /var/lib/snapd/snaps/bare_5.snap /snap/bare/5 -o ro,nodev,allow_other,suid
root          70  0.7  0.0   4756  1756 ?        Ss   17:16   0:00 snapfuse /var/lib/snapd/snaps/core22_864.snap /snap/core22/864 -o ro,nodev,allow_other,suid
root          74  0.0  0.0   4624   168 ?        Ss   17:16   0:00 snapfuse /var/lib/snapd/snaps/gtk-common-themes_1535.snap /snap/gtk-common-themes/1535 -o ro,nodev,allow_ot
root          76  2.1  0.0   4708  1724 ?        Ss   17:16   0:01 snapfuse /var/lib/snapd/snaps/snapd_20290.snap /snap/snapd/20290 -o ro,nodev,allow_other,suid
root          78  1.0  0.0   4956  1700 ?        Ss   17:16   0:00 snapfuse /var/lib/snapd/snaps/ubuntu-desktop-installer_1276.snap /snap/ubuntu-desktop-installer/1276 -o ro,
systemd+     118  0.0  0.0  25532 12728 ?        Ss   17:16   0:00 /lib/systemd/systemd-resolved
root         128  0.0  0.0   4304  2752 ?        Ss   17:16   0:00 /usr/sbin/cron -f -P
message+     130  0.0  0.0   8592  4732 ?        Ss   17:16   0:00 @dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
root         138  0.0  0.0  30100 18548 ?        Ss   17:16   0:00 /usr/bin/python3 /usr/bin/networkd-dispatcher --run-startup-triggers
syslog       143  0.0  0.0 222400  5052 ?        Ssl  17:16   0:00 /usr/sbin/rsyslogd -n -iNONE
root         146  0.3  0.1 2205684 37280 ?       Ssl  17:16   0:00 /usr/lib/snapd/snapd
root         151  0.0  0.0  15324  7252 ?        Ss   17:16   0:00 /lib/systemd/systemd-logind
root         222  0.0  0.0   4780  3348 ?        Ss   17:16   0:00 /bin/bash /snap/ubuntu-desktop-installer/1276/bin/subiquity-server
root         224  0.0  0.0 107228 21368 ?        Ssl  17:16   0:00 /usr/bin/python3 /usr/share/unattended-upgrades/unattended-upgrade-shutdown --wait-for-signal
root         233  0.0  0.0   3236  1116 hvc0     Ss+  17:16   0:00 /sbin/agetty -o -p -- \u --noclear --keep-baud console 115200,38400,9600 vt220
root         235  0.0  0.0   3192  1116 tty1     Ss+  17:16   0:00 /sbin/agetty -o -p -- \u --noclear tty1 linux
root         321  2.2  0.2 154372 69200 ?        Sl   17:16   0:01 /snap/ubuntu-desktop-installer/1276/usr/bin/python3.10 -m subiquity.cmd.server --use-os-prober --storage-ve
root         405  0.0  0.0   7532  4864 pts/1    Ss   17:16   0:00 /bin/login -f
bradwil+     434  0.0  0.0  17040  9260 ?        Ss   17:16   0:00 /lib/systemd/systemd --user
bradwil+     439  0.0  0.0 169976  4616 ?        S    17:16   0:00 (sd-pam)
bradwil+     470  0.0  0.0   6068  5052 pts/1    S+   17:16   0:00 -bash
root         485  1.1  0.1  44204 37536 ?        S    17:16   0:00 python3 /snap/ubuntu-desktop-installer/1276/usr/bin/cloud-init status --wait
root         509  0.0  0.0   2296   120 ?        Ss   17:17   0:00 /init
root         510  0.0  0.0   2296   128 ?        R    17:17   0:00 /init
root         511  0.0  0.0  21960  3388 ?        S    17:17   0:00 /lib/systemd/systemd-udevd
root         512  0.0  0.0  21960  3388 ?        S    17:17   0:00 /lib/systemd/systemd-udevd
bradwil+     513  0.5  0.0   6080  5032 pts/0    Ss   17:17   0:00 -bash
root         514  0.0  0.0  21960  3388 ?        S    17:17   0:00 /lib/systemd/systemd-udevd
root         515  0.0  0.0  21960  3388 ?        S    17:17   0:00 /lib/systemd/systemd-udevd
root         516  0.0  0.0  21960  3388 ?        S    17:17   0:00 /lib/systemd/systemd-udevd
bradwil+     529  0.0  0.0   7480  3236 pts/0    R+   17:17   0:00 ps aux

(These are both Ubuntu 22.04) As previously mentioned, seeing PID 1 being /init (non-systemd) vs. /sbin/init (systemd) is the tip off, even if the extra 30 processes weren't enough. 😂

-> The issue turned out to be having systemd enabled. With systemd enabled, a few GUI applications could not launch
This is false.

Unsubscribing from this as I don't think I'm going to get a real answer until I accidentally discover it as a feature pushed upstream.

This is temper tantrum.

@firejox thanks! Do I put it in /etc/wsl.conf ?

It is systemd service, so you need to save as [service name].service file and put the file under systemd folder e.g. /etc/systemd/system/. And you can run these commands.

Start systemd service

sudo systemctl start [service name].service

Make it can auto run in next booting.

systemctl enable [service name].service

Autostart (enable) didn't work for me.
keep-distro-alive.service: Failed to execute /mnt/c/Windows/system32/waitfor.exe: Exec format error
keep-distro-alive.service: Failed at step EXEC spawning /mnt/c/Windows/system32/waitfor.exe: Exec format error

But the service itself is fine. Seems like the interop layer is not ready during wsl startup.

@codeart1st  It looks like keep-distro-alive.service which is loaded before wsl-binfmt.service or before systemd-binfmt.service. You can check startup order with command systemd-analyze
systemd-analyze plot > startup_order.svg

startup_order.svg will show the loaded order of all services in systemd.
If yes, you can add this line into your service file under [Unit] section.
After=wsl-binfmt.service systemd-binfmt.service

This will make keep-distro-alive.service executed after the service which setup binfmt.

@codeart1st It looks like keep-distro-alive.service which is loaded before wsl-binfmt.service or before systemd-binfmt.service. You can check startup order with command systemd-analyze
systemd-analyze plot > startup_order.svg

startup_order.svg will show the loaded order of all services in systemd.
If keep-distro-alive.service is loaded before those binfmt services, you can add this line into your service file under [Unit] section.
After=wsl-binfmt.service systemd-binfmt.service

This will make keep-distro-alive.service executed after the service which setup binfmt.
resources: https://stackoverflow.com/questions/29309717/is-there-any-way-to-list-systemd-services-in-linux-in-the-order-of-they-were-l https://stackoverflow.com/questions/21830670/start-systemd-service-after-specific-service

Thank you, you're right.

@firejox Your solution works well when there is only one active distribution, but I am working with two, when starting the second one, the process in the first one is interrupted.

@everson-plantae It is because the [signal name] in waitfor.exe [signal name] is globally shared. You need to use different signal names for different distributions. For example, there are Fedora and Ubuntu in WSL. You may use waitfor.exe FedoraAlive for Fedora and waitfor.exe UbuntuAlive for Ubuntu. Or you can use choice.exe with named pipe to keep distro alive. choice.exe is no need to setup special [signal name] for different distribution.

@firejox It seems WSL2 has become more aggressive when trying to shutdown itself.
I added the systemd service suggested above (with the After=wsl-binfmt.service systemd-binfmt.service). However, after a night, WSL2 still shut down. Then I went to check the Task Manager, the waitfor.exe process is still there... somehow it survives but didn't keep WSL2 alive...
Any suggestions would be greatly appreciated.

Like I said way back in the thread, the only processes that will keep the WSL session from being auto-terminated are children of the Microsoft init (not the pid 1 init, the WSL-supplied init). No systemd service can be this, so you won't get anywhere with those.
To be clear, here's a pstree:
systemd─┬─Relay(1061)───wait-forever.sh───sleep
        ├─2*[agetty]
        ├─automount───5*[{automount}]
        ├─containerd───12*[{containerd}]
        ├─dbus-daemon
        ├─dockerd───14*[{dockerd}]
        ├─init-systemd(De─┬─SessionLeader───Relay(1936)───machinectl
        │                 ├─SessionLeader───Relay(332257)───sleep
        │                 ├─init───{init}
        │                 ├─sh
        │                 └─{init-systemd(De}
        ├─polkitd───3*[{polkitd}]
        ├─rpc.gssd───{rpc.gssd}
        ├─rpcbind
...etc....

What you are looking for is the Relay(number) parent. A process which has that above it in the tree (here, that would be wait-forever.sh, machinectl, and sleep) will keep the WSL instance running; one that doesn't, won't.
_nohup_ing or _daemonize_ing a waitforever script is still the best option, I believe.

I used to use dbus-launch true in shell config to solve this problem, but recently after I updated, wsl will automatically close after one night, is there any plan to add "wsl never automatically closes" to wslconfig?

is there any plan to add "wsl never automatically closes" to wslconfig?

After following this saga since the beginning: "No."

is there any plan to add "wsl never automatically closes" to wslconfig?

https://github.com/microsoft/WSL/issues/8854#issuecomment-1255501711 , but since it's got such a simple workaround, I can't imagine it's anywhere near the top of the WSL team's list of possible new features.

_nohup_ing or _daemonize_ing a waitforever script is still the best option, I believe.

@cerebrate I tried _nohup_ing and WSL2 (Ubuntu 22.04) still stopped after a night. Previously dbus-launch true was sufficient to keep distro alive.
Feels like the shutdown did become more aggressive since a very recent update (I think maybe I'm seeing what @Parsifa1 sees).
WSL version: 2.3.11.0
Kernel version: 6.6.36.3-1
WSLg version: 1.0.63
MSRDC version: 1.2.5326
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.22635.3930

Fair points - I think an option to keep distros running (and not idle terminate them) is a good idea.

Are there still plans to implement this?

Small update for Windows 11 24H2 the waitfor.exe solution won't work anymore.
Failed to start keep-distro-alive.service: Interactive authentication required.
See system logs and 'systemctl status keep-distro-alive.service' for details.

authors: NotTheDr01ds Parsifa1 SashiRin aki-k astroboylrx benhillis biggestsonicfan bradwilson cerebrate codeart1st darrenchang everson-plantae firejox kotx leruetkins mokeyish pmartincic potchy wswind wutongskype


text:
How to run win app driver desktop tests remotely

HI Guys,
I have created a small automated script using winappdriver to run and test a desktop application. i have installed a copy of this framework on 2 different vm's. is there a way i can control and run those tests remotely from my local ? without having to connect to vm and run the test from nunit console or visualstudio ? i know there is an issue with having an active remote session but if i resolve this by automating the process to connect to vm is there away to launch it remotely ?

You can write a small batch file and using the task scheduler can launch the automation other option would be to use Azure pipleline  for your tests.

@anunay1 : We tried creating the Task scheduler for our Jenkins job, but since it doesn’t open Winappdriver in Interactive mode, hence the approach  failed

@samkhayal  - We were able to configure WAD on remote using instructions here :
https://github.com/microsoft/WinAppDriver/pull/1368

Hello everyone, I don't know if others have finally found the solution.
My case I use Jenkins to launch the run i.e. my desktop application which is in a VM. All works when the session is not locked. But once locked, the display scripts pass (System.out.println) and even the winappdriver launches correctly, however I can't click on the elements.
Could you please help me.

@MamadouAlphaDiallo  - You can find the solution which worked for us here :
https://github.com/microsoft/WinAppDriver/blob/819b7416c5e2081bedfce34861316776b8d28d36/Docs/RunningOnRemoteMachine.md

We did not face that error after configuring the firewall rules.

Hello,
Thank you @smilinrobin. I'll be back again, I've done my setup as requested. However my tests still fail.
For information, for the logout-rdp.bat batch file, I planned a scheduler task in which:
Begin the task: On disconnect from user session
Specific User: "My account"
Connection from remote computer
I even tried
Begin the task: On workstation lock.
Could you please help me or tell me which one you chose.

Hello @smilinrobin,
it worked for me too.
Thank you very much

Wow , awesome @MamadouAlphaDiallo . Did you have to do any extra configurations ?

Hello @smilinrobin,
I think I rejoiced so quickly. Because this morning I see that:
When my session is closed beyond 1 hour and I launch my tests, No interaction so my tests fail. On the other hand, when my session is closed for less than an hour, and I restart my tests, it works correctly.
For configuration nothing special:
In Jenkins I just put batch scripts
Each launch of the jenkins run:
Before maven run
1 - SCHTASKS.EXE /RUN /TN "RunWD"
2 - cmdkey /generic:TERMSRV/Hostname.socgen /user:${user} /pass:${pass}
3 - cmdkey /delete:TERMSRV/Hostname
After maven run
4- SCHTASKS.EXE /End /TN "StartTestSession"

@MamadouAlphaDiallo  - If you see multiple issues with WinAppDriver , you can even try out : https://github.com/karatelabs/karate/tree/master/karate-robot . They have active community support as well.

@smilinrobin
Thank you for the link

Hello @smilinrobin sorry to bother you
I come back to this problem after a break.
I wanted to know how do you configure with the task scheduler logout-rdp.bat because I tried after creating the task:
Trigger:

On disconnect for user session
On workstation lock
But still a problem.
And possibly Dim objResult Set objShell = WScript.CreateObject("WScript.Shell") Do While True objResult = objShell.sendkeys("{NUMLOCK}{NUMLOCK}") Wscript.Sleep(6000) Loop

with which trigger it is triggered.
thanks in advance

source: gharchive/issue

authors: MamadouAlphaDiallo anunay1 samkhayal smilinrobin

repo: microsoft/WinAppDriver

license: MIT

license_type: permissive

license_source: github-api


text:
Winform app process not closing?

Hi,
We got a Winform application that hides the Mainform at startup and shows a login dialog instead. If the login is not successful and/or the Mainform is never shown the process will not close after finished test(tried them all close, dispose and closeApp) .
If the test is executed local, we can have a dispose with kill process but this does not work when we run the test on a remote server. The session.WindowHandles only contain the login dialog so we cant switch focus.
Is there any way to close the process with WinAppDriver or do we have to change your winform application to make this work?
Regards

Which language binding are you using? You can use the process class to kill the process.

Im using framework .NET 6.0 and language C#. System.Diagnostics.Process cannot be used to kill process on a remote computer.

Is the remote server windows server?

Yes it is.

Is there any way to make sure that the process is killed before starting a new test even if it runs on a remote Windows Server?


text:
New PackageDeploymentManager methods not tagged with new v2 contract

https://task.ms/53375777
static Boolean IsPackageDeploymentFeatureSupported(PackageDeploymentFeature feature);
Boolean IsPackageRegistrationPending(String packageFullName);
Boolean IsPackageRegistrationPendingForUser(String userSecurityId, String packageFullName);

Should be prefixed with [contract(PackageDeploymentContract, 2)]
NOTE: Also backporting to 1.6

/azp run

/azp run

source: gharchive/pull-request

repo: microsoft/WindowsAppSDK


text:
Please double check you have all the required session delivery resources

Please double check you have all the required resources to deliver this session:

[x] Main ppt file
[ ] Links to localized versions (when available)
[ ] Presentation recording
[x] Silent recording/screen cap only of ALL demos
[ ] Any deployment instructions

@softchris @gloveboxes I couldn't find the link to the session walkthrough and instructions to set up the dev environment (including Azure resources provisioning). Can you please have a look into the pending items?


text:
API - Get list of active users.

Describe the solution you'd like
I'd like to have an endpoint at the API that would show me all the active user's so i can handle the push notification via users_id correctly.
Describe alternatives you've considered
For now i'll keep sending push notifications to users that are not currently active but in order to handle resources better this functionality would help.
Additional context
I've got a problem where clients can clear the cache from their cellphones and therefore they don't follow the logout path wich clears them from my database... so in those cases i'll be firing some unecessary push notifications to all those users.

@FelipeGatti Are we talking about user identities set using the SDK, or App Center Auth?

Sorry for the delayed response!
Via SDK @jwargo , when the user login into the app i retrieve an unique id and use the following:
AppCenter.setUserId(UID);
wich is loaded using import AppCenter from 'appcenter';.

@FelipeGatti OK, thanks for that clarification. As I understand it, that capability is not on our roadmap due to some technical limitations. Our recommendation is for you to send the User ID to your app backend at the same time you set it through the SDK, then you'll have a repository with all the User IDs associated with your app.

Ok, thanks for the response !
Thats what i'm currently doing but when de app gets uninstalled or the user clears the cache before logging out the logout path is not followed so i cant clear that id in my database.
It's not a big deal but when i'm in another backend application that will fire those push notifications it checks in this same database, so there will be an lost call to the api with an id that is not currently set to any mobile therefore unnecessary.

@FelipeGatti OK, I understand your need here and I'm trying to figure out what we can do to help you. What you really need is an uninstall event and a cache clearing event on the device you can hook and take care of this yourself (in the app) when the user acts. Unfortunately this isn't possible as I understand it.
The problem for us is that we don't know whether the device is actually inactive. We know we haven't heard from the device in a while, but we don't really know what the user did with the app.  Giving you a list of users doesn't really solve your problem because you still have to process the whole list against your internal list of users. We don't have a way to give you this list today (and, like I said, I'm not sure it's really possible) and you'd have a lot of work to do on the backend to process this list. With that in mind, wouldn't this be easier?
Every time your user opens your app, you notify your backend (send a date/time value or some sort of semaphore) and store it with the user ID in your backend. Then, write a scheduled tasks (daily for example) that purges user IDs from your system after ## days. Wouldn't that be easier?

@jwargo, thank you again for taking time to evaluate and consider my feature request.
Oh, I thought you could figure out if an user is reachable or not before even sending the notification.
Actually I haven't thought in anything like your method and It could work well, I will try this way.

authors: FelipeGatti jwargo

repo: microsoft/appcenter


text:
dotnet restore --interactive fails with SSL errors on WSL

Hi Guys-
I'm running WSL (Pengwin) on Win10. I've installed the credprovider. (Though the plugin dir ended up being ~/.nuget/NuGet/plugins). When I run dotnet restore --interactive, I get:
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :     [CredentialProvider]Failed to acquire session token: System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception. ---> System.Security.Authentication.AuthenticationException: Authentication failed, see inner exception. ---> System.TypeInitializationException: The type initializer for 'SslMethods' threw an exception. ---> System.TypeInitializationException: The type initializer for 'Ssl' threw an exception. ---> System.TypeInitializationException: The type initializer for 'SslInitializer' threw an exception. ---> Interop+Crypto+OpenSslCryptographicException: error:0E076071:configuration file routines:MODULE_RUN:unknown module name [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at Interop.SslInitializer..cctor() [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    --- End of inner exception stack trace --- [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at Interop.Ssl..cctor() [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    --- End of inner exception stack trace --- [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at Interop.Ssl.SslV2_3Method() [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at Interop.Ssl.SslMethods..cctor() [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    --- End of inner exception stack trace --- [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at Interop.OpenSsl.AllocateSslContext(SslProtocols protocols, SafeX509Handle certHandle, SafeEvpPKeyHandle certKeyHandle, EncryptionPolicy policy, SslAuthenticationOptions sslAuthenticationOptions) [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at System.Net.Security.SafeDeleteSslContext..ctor(SafeFreeSslCredentials credential, SslAuthenticationOptions sslAuthenticationOptions) [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at System.Net.Security.SslStreamPal.HandshakeInternal(SafeFreeCredentials credential, SafeDeleteContext& context, SecurityBuffer inputBuffer, SecurityBuffer outputBuffer, SslAuthenticationOptions sslAuthenticationOptions) [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    --- End of inner exception stack trace --- [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, ExceptionDispatchInfo exception) [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest) [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest) [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest) [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult) [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at System.Net.Security.SslStream.BeginAuthenticateAsClient(SslClientAuthenticationOptions sslClientAuthenticationOptions, CancellationToken cancellationToken, AsyncCallback asyncCallback, Object asyncState) [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at System.Net.Security.SslStream.<>c.<AuthenticateAsClientAsync>b__47_0(SslClientAuthenticationOptions arg1, CancellationToken arg2, AsyncCallback callback, Object state) [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at System.Threading.Tasks.TaskFactory`1.FromAsyncImpl[TArg1,TArg2](Func`5 beginMethod, Func`2 endFunction, Action`1 endAction, TArg1 arg1, TArg2 arg2, Object state, TaskCreationOptions creationOptions) [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at System.Threading.Tasks.TaskFactory.FromAsync[TArg1,TArg2](Func`5 beginMethod, Action`1 endMethod, TArg1 arg1, TArg2 arg2, Object state, TaskCreationOptions creationOptions) [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at System.Threading.Tasks.TaskFactory.FromAsync[TArg1,TArg2](Func`5 beginMethod, Action`1 endMethod, TArg1 arg1, TArg2 arg2, Object state) [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at System.Net.Security.SslStream.AuthenticateAsClientAsync(SslClientAuthenticationOptions sslClientAuthenticationOptions, CancellationToken cancellationToken) [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at System.Net.Http.ConnectHelper.EstablishSslConnectionAsyncCore(Stream stream, SslClientAuthenticationOptions sslOptions, CancellationToken cancellationToken) [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    --- End of inner exception stack trace --- [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at System.Net.Http.ConnectHelper.EstablishSslConnectionAsyncCore(Stream stream, SslClientAuthenticationOptions sslOptions, CancellationToken cancellationToken) [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at System.Threading.Tasks.ValueTask`1.get_Result() [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at System.Net.Http.HttpConnectionPool.CreateConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken) [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at System.Threading.Tasks.ValueTask`1.get_Result() [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at System.Net.Http.HttpConnectionPool.WaitForCreatedConnectionAsync(ValueTask`1 creationTask) [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at System.Threading.Tasks.ValueTask`1.get_Result() [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken) [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken) [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at System.Net.Http.HttpClient.FinishSendAsyncBuffered(Task`1 sendTask, HttpRequestMessage request, CancellationTokenSource cts, Boolean disposeCts) [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at NuGetCredentialProvider.CredentialProviders.Vsts.AuthUtil.GetResponseHeadersAsync(Uri uri, CancellationToken cancellationToken) [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at NuGetCredentialProvider.CredentialProviders.Vsts.AuthUtil.GetAadAuthorityUriAsync(Uri uri, CancellationToken cancellationToken) [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at NuGetCredentialProvider.CredentialProviders.Vsts.VstsCredentialProvider.HandleRequestAsync(GetAuthenticationCredentialsRequest request, CancellationToken cancellationToken) [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :    at NuGetCredentialProvider.RequestHandlers.GetAuthenticationCredentialsRequestHandler.HandleRequestAsync(GetAuthenticationCredentialsRequest request) [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error : Unable to load the service index for source https://mscatapult.pkgs.visualstudio.com/_packaging/FpgaTools/nuget/v3/index.json. [/mnt/c/code/HWBuild/hwbuild.sln]
/usr/share/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :   Response status code does not indicate success: 401 (Unauthorized). [/mnt/c/code/HWBuild/hwbuild.sln]

I'm not sure where to go from here. Is the credprovider not compatible with WSL or am I missing a package...? Is this even a credprovider issue or should I submit this to the .net core team?

Sorry... scratch that part about the plugins dir

Apparently, this is a dotnet core bug
https://github.com/dotnet/corefx/issues/33179
It was fixed in https://github.com/dotnet/corefx/pull/34443

Hey @teqdruid , Thanks for filing this issue and finding the root cause! As you said, this is a .NET core bug. Please update your .Net core sdk with the recent versions and let me know if that fixes it.

Closing this issue. Please let me know if you see this with fixed versions of dotnet core and I'll re-open. Thanks!

@teqdruid you are using 2.2.300, which is the latest version, it should contain the fix already, right?

Sorry to take so long, but yes... I was using 2.2.300, which is the latest. (I had implemented the workaround which removed this issue as a blocker.)
I think that CredentialProvider.Microsoft needs to upgrade its SDK to resolve this issue on WSL (and presumably Linux).

authors: YongliangLi shubham90 teqdruid

repo: microsoft/artifacts-credprovider


text:
Return Continuation Token in response

The continuation token cannot be retrieved from the response- which means that one cannot know if he got all the data.

Our http client code generator does not support this feature yet.  We will get to it soon.

@eyalag ,
The general issue should have been addressed in 0.1.21.  Which version are you using?  Also what method is not working?
Thanks,
Ted

I'm having issues on version 1.22. Please reopen this ticket, as this bug makes retrieving large lists impossible.

@phclark Can you provide more details? Which method are you having problems with?

Sure,  a basic example of what I'm trying to do:
build_client = azure_devops_connection.clients.get_build_client()
builds = build_client.get_builds(project='Apps', top=500)
print(type(builds)) # Returns list
for b in builds:
    print(b) # Prints raw builds

There seems to be no way of retrieving a continuation token, which is returned as expected from the equivalent REST API call.

Thank you.  The client code generator needs to be updated to fix this method.

i have the same issue with the method get_projects from core client. There is not way to retrieve the continuation token.
core_client = azure_devops_connection.clients.get_core_client()
projects = core_client.get_projects(top=10)
print(type(projects)) # Returns list
for p in projects:
    print(p) # Prints raw project

Interestingly, I'm also having issues with getting continuationTokens to work when using the raw REST API. When I make a GET request like,
https://{workspace}.visualstudio.com/{project}/_apis/build/builds?%top=100&api-version=5.0
The token, returned in the header field x-ms-continuationtoken does not vary when the returned continuationToken is included in the next request.
Has anyone else experienced this?

@phclark Can you try the $top instead of %top, and see if you get the behavior you are expecting.
https://{workspace}.visualstudio.com/{project}/_apis/build/builds?$top=100&api-version=5.0

Sorry, that was a typo.  I am using $top.
For example, the subsequent calls, with urlencode, resolve to
.../_apis/build/builds?%24top=1000&continuationtoken=2017-12-05T20%3A35%3A46.9163266Z&api-version=5.0

Duplicate to https://github.com/MicrosoftDocs/vsts-rest-api-specs/issues/178, which sounds like it has been fixed in the service.

reopening for the broader ContinuatuonToken issue, which should be fixed soon.

Fixed in #258
https://github.com/microsoft/azure-devops-python-api/releases/tag/5.1.0b3
Continuation Token example:
get_builds_response = build_client.get_builds(project=project_name)
index = 0
while get_builds_response is not None:
    for build in get_builds_response.value:
        pprint.pprint("[" + str(index) + "] " + build.build_number)
        index += 1
    if get_builds_response.continuation_token is not None and get_builds_response.continuation_token != "":
        get_builds_response = build_client.get_builds(project=project_name, continuation_token=get_builds_response.continuation_token)
    else:
        get_builds_response = None

#381

authors: RolfJordi eyalag phclark tedchamb watsnav

repo: microsoft/azure-devops-python-api


text:
Create 'Dockerfile' in the project when docker property is set false

Environment:
Eclipse: 2019-12
azure-functions-archetype: 1.26
Reproduce Steps:

In Eclipse, select the File menu, then select New -> Maven Project.
Accept the defaults in the New Maven Project dialogue and select Next.
Select Add Archetype and add the entries for the azure-functions-archetype.

Archetype Group ID: com.microsoft.azure
Archetype Artifact ID: azure-functions-archetype
Version: Use latest version 1.26 from the central repository

Click OK and then click Next. Be sure to fill in values for all of the fields, and eventually Finish.

Result:
Create 'Dockerfile' in the project when docker property is set false.

Eclipse didn't support our custom archetype parameters and will always set docker to be true, as a workaround, please try generate the project in bash first and then open the project with eclipse

repo: microsoft/azure-maven-archetypes


text:
Sometimes the warning message that instance is not stable does not automatically line feed

Plugin name and version
OS: Win 10/Mac 10.15.3
Plguin: azure-spring-cloud-maven-plugin:1.3.0
Actual behavior

Test in branch: hanxiao/fixDeploymentStatus, this issue is fixed

repo: microsoft/azure-maven-plugins


text:
Cannot trigger "Online" custom build agents using ./svc.sh script

What I need:
I need to build a custom build agent on an EC2 instance inside of my VPC environment. The instance is Amazon Linux 2, which is just a modified version of RHEL. I'm running this on an Enterprise Azure DevOps account (dev.azure.com).
### The problem:
The ideal build agent would trigger builds on demand from the pipeline, without having to be "activated" by SSH'ing into the box first. My build agents work fine when I run the script ./run.sh, but doesn't register when I run the script ./svc.sh (which is the script that lets it run as a service.) Without running ./svc.sh, I would have to ssh into the box every time I need to run the build to trigger ./run.sh.
Screenshots of ./svc.sh runs below...

As you can see, the pipeline is waiting for an available agent, even though this agent is now listed as "Online" after starting the service via ./svc.sh

This second image shows the box itself, the box is supposedly listening... but nothing happening.

### What I've done:

Changed the type of instance to ensure that systemd is available and running
Checked the capabilities to make sure they are available
Use different versions of azure devops build agents
Changed various permissions and file ownerships, running things via sudo/user
Installed, uninstalled, start and stop ./svc.sh
Looked at the logs in _diag. It looks like ./svc.sh IS in fact registering and processing the build request, but its not actually running in the Pipeline. I see the job names, stage, etc in the logs, but nothing actually happening in Pipelines.

Hi @michellehodges looks like images are not attached - could you please attach them?
Could you also share agent logs?

Hi @michellehodges looks like images are not attached - could you please attach them?
Could you also share agent logs?

Hi @michellehodges could you please agent logs?

Closing this at the moment due to inactivity - please feel free to reopen or ping if it is still actual for you.

authors: anatolybolshakov michellehodges

repo: microsoft/azure-pipelines-agent


text:
vsts-agent-linux-x64-2.185.1

We are using the latest agent provided by Microsoft i.e. vsts-agent-linux-x64-2.185.1, When we did the security scanning and vulnerability assessment of the image using Anchore tool, we saw a significant amount of vulnerabilities, please find below.
Vulnerability Id | Severity | Package Type | Package | Fix Available

CVE-2019-17571 | Critical | java | log4j-1.2.14 | 2.08.02
CVE-2020-7788 | Critical | npm | ini-1.3.5 | 1.03.06
CVE-2019-16776 | Critical | npm | npm-3.10.10 | 6.13.03
CVE-2019-16775 | Critical | npm | npm-3.10.10 | 6.13.03
CVE-2020-7774 | Critical | npm | y18n-4.0.0 | 3.2.2, 4.0.1, 5.0.5
CVE-2018-14718 | Critical | java | jackson-databind-2.4.1 | None
CVE-2018-7489 | Critical | java | jackson-databind-2.4.1 | None
CVE-2018-16492 | Critical | npm | extend-3.0.0 | None
CVE-2018-10237 | High | java | guava-12.0.1 | 23.6.1, 24.1.1, 25.0
CVE-2020-8840 | High | java | jackson-databind-2.4.1 | 2.8.11.5, 2.9.10.3
CVE-2019-16943 | High | java | jackson-databind-2.4.1 | 2.10.0, 2.9.10.1
CVE-2020-8244 | High | npm | bl-1.1.2 | 1.2.3, 2.2.1, 3.0.1, 4.0.3
CVE-2019-16777 | High | npm | npm-3.10.10 | 6.13.04
CVE-2020-7754 | High | npm | npm-user-validate-1.0.0 | 1.00.01
CVE-2021-27290 | High | npm | ssri-6.0.1 | 8.00.01
CVE-2018-21270 | High | npm | stringstream-0.0.5 | 0.00.06
CVE-2020-35491 | High | java | jackson-databind-2.4.1 | None
CVE-2020-35490 | High | java | jackson-databind-2.4.1 | None
CVE-2019-13173 | High | npm | fstream-1.0.10 | None
CVE-2020-7788 | High | npm | ini-1.3.4 | None
CVE-2016-10540 | High | npm | minimatch-3.0.0 | None
CVE-2017-18077 | High | npm | minimatch-3.0.3 | None
CVE-2017-18077 | High | npm | minimatch-3.0.3 | None
CVE-2017-18077 | High | npm | minimatch-3.0.3 | None
CVE-2017-18077 | High | npm | minimatch-3.0.3 | None
CVE-2017-18077 | High | npm | minimatch-3.0.3 | None
CVE-2020-7754 | High | npm | npm-user-validate-0.1.5 | None
CVE-2017-15010 | High | npm | tough-cookie-2.3.1 | None

As you can see, these vulnerabilities are of Critical and High severity and needs to be corrected so that we can get the vsts-agent-linux-x64 with the latest versions of the software. Thank you.

We found these security vulnerabilities in vsts-agent-linux-x64 image version 2.185.1. Since then we have updated our agent with latest  vsts-agent-linux-x64 images released by Microsoft (the latest one being 2.190.1) but none of the images provided a fix for this issue. Could you please let us know when can we expect a fix for this?
These vulnerabilities are of Critical and High severity and we are waiting for a release where this has been fixed.

@singhalnidhi  We know about this set of vulnerabilities, most of the npm dependencies come with node 6 (externals/node directory) that is shipped with an agent since there are in-the-box tasks that still work on the Node 6 execution handler. We are not able to resolve this issue since Node 6 is not updated currently. As a workaround, you can try to use an alternative agent build, where Node 6 is excluded. The only thing you need to keep in my in this way, all the tasks that are used in your pipeline should support the Node 10 handler. This agent version is presented in Alternate Agent Downloads in release (ref to alternative linux package pipelines-agent-linux-x64-2.191.1.tar.gz).
What concerns Java dependencies, they come with the Jackson library that is used by the TEE plugin (externals/TEE) that we are shipping for Linux users that are using Team Foundation Version Control (abbreviated TFVC) based repositories. But the Agent is using only Command-line Client for the checkout job. Command-line Client is not using functionality that is affected by described vulnerabilities. So in fact those vulnerabilities are not actual for agents.

Not wanting to hijack the original issue but adding some additional input as I encountered a similar problem.  This is the process that I followed:
Based on Run a self-hosted agent in Docker I created:
Dockerfile

FROM ubuntu:18.04

# To make it easier for build and release pipelines to run apt-get,
# configure apt to not require confirmation (assume the -y argument by default)
ENV DEBIAN_FRONTEND=noninteractive
RUN echo "APT::Get::Assume-Yes \"true\";" > /etc/apt/apt.conf.d/90assumeyes

RUN apt-get update && apt-get install -y --no-install-recommends \
    ca-certificates \
    curl \
    jq \
    git \
    iputils-ping \
    libcurl4 \
    libicu60 \
    libunwind8 \
    netcat \
    libssl1.0 \
  && rm -rf /var/lib/apt/lists/*

RUN curl -LsS https://aka.ms/InstallAzureCLIDeb | bash \
  && rm -rf /var/lib/apt/lists/*

ARG TARGETARCH=amd64
ARG AGENT_VERSION=2.195.1

WORKDIR /azp
RUN if [ "$TARGETARCH" = "amd64" ]; then \
      AZP_AGENTPACKAGE_URL=https://vstsagentpackage.azureedge.net/agent/${AGENT_VERSION}/pipelines-agent-linux-x64-${AGENT_VERSION}.tar.gz; \
    else \
      AZP_AGENTPACKAGE_URL=https://vstsagentpackage.azureedge.net/agent/${AGENT_VERSION}/pipelines-agent-linux-${TARGETARCH}-${AGENT_VERSION}.tar.gz; \
    fi; \
    curl -LsS "$AZP_AGENTPACKAGE_URL" | tar -xz

COPY ./start.sh .
RUN chmod +x start.sh

ENTRYPOINT [ "./start.sh" ]

startup.sh

#!/bin/bash
set -e

if [ -z "$AZP_URL" ]; then
  echo 1>&2 "error: missing AZP_URL environment variable"
  exit 1
fi

if [ -z "$AZP_TOKEN_FILE" ]; then
  if [ -z "$AZP_TOKEN" ]; then
    echo 1>&2 "error: missing AZP_TOKEN environment variable"
    exit 1
  fi

  AZP_TOKEN_FILE=/azp/.token
  echo -n $AZP_TOKEN > "$AZP_TOKEN_FILE"
fi

unset AZP_TOKEN

if [ -n "$AZP_WORK" ]; then
  mkdir -p "$AZP_WORK"
fi

export AGENT_ALLOW_RUNASROOT="1"

cleanup() {
  if [ -e config.sh ]; then
    print_header "Cleanup. Removing Azure Pipelines agent..."

    # If the agent has some running jobs, the configuration removal process will fail.
    # So, give it some time to finish the job.
    while true; do
      ./config.sh remove --unattended --auth PAT --token $(cat "$AZP_TOKEN_FILE") && break

      echo "Retrying in 30 seconds..."
      sleep 30
    done
  fi
}

print_header() {
  lightcyan='\033[1;36m'
  nocolor='\033[0m'
  echo -e "${lightcyan}$1${nocolor}"
}

# Let the agent ignore the token env variables
export VSO_AGENT_IGNORE=AZP_TOKEN,AZP_TOKEN_FILE

source ./env.sh

print_header "1. Configuring Azure Pipelines agent..."

./config.sh --unattended \
  --agent "${AZP_AGENT_NAME:-$(hostname)}" \
  --url "$AZP_URL" \
  --auth PAT \
  --token $(cat "$AZP_TOKEN_FILE") \
  --pool "${AZP_POOL:-Default}" \
  --work "${AZP_WORK:-_work}" \
  --replace \
  --acceptTeeEula & wait $!

print_header "2. Running Azure Pipelines agent..."

trap 'cleanup; exit 0' EXIT
trap 'cleanup; exit 130' INT
trap 'cleanup; exit 143' TERM

# To be aware of TERM and INT signals call run.sh
# Running it with the --once flag at the end will shut down the agent after the build is executed
./run.sh "$@" &

wait $!

and then built the container image locally:

docker build -t azdo-docker:latest .

Install trivy and scan the image:

trivy image azdo-docker:latest > trivy.out

The contents of trivy.out can be viewed here.  You will notice a number of HIGH and CRITICAL issues, similar to those reported by @singhalnidhi.  Note that this was built with the alternate agent.

Hello, using an agent without Node 6 did not resolved all the vulnerabilities. Can you please let us know when will this ticket be resolved?

Is there any update on when these vulnerabilities will be addressed?  Both the main and the alternative agent still have numerous high and critical vulnerabilities.  This is currently a blocker on our SOC 2 audit.

Hi @singhalnidhi, @nsinghal99, @vf-doctor, @tonyskidmore. I have scanned 2.214.1 version (without Node6). It doesn't contain CRITICAL vulnerabilities. And all HIGH vulnerabilities are from NodeJS10. Is it appropriate for you?

Hi all. Closing this one, feel free to ask any other questions or let us know if it's still relevant for you.

authors: EzzhevNikita Roman-Shchukin nsinghal99 singhalnidhi tonyskidmore vf-doctor


text:
[Deployment, databases, and servers tasks] Update dependencies on "utility-common-v2" package to fix high vulnerability issues

Required Information
Entering this information will route you directly to the right team and expedite traction.
Question, Bug, or Feature?
Type: Bug
Enter Task Name:

AzureAppServiceManageV0
AzurePowerShellV4
AzurePowerShellV5
AzureWebAppV1

Issue Description
These tasks have dependency on "azure-pipelines-tasks-utility-common" that has critical vulnerability in "azure-pipelines-tool-lib > typed-rest-client > underscore".

Please update this dependency to the latest version.
This vulnerability was fixed in PR.
Error logs
To get error log for each task run npm audit

Hi, @nadesu could you please take a look?

PR has been merged.

authors: tatyana-kostromskaya v-saikumart

repo: microsoft/azure-pipelines-tasks


text:
[BUG]: Automated tests from test plans fail at VSTest task not discovering tests when executed

Task name
VsTest
Task version
2.x
Environment type (Please select at least one enviroment where you face this issue)

[ ] Self-Hosted
[x] Microsoft Hosted
[x] VMSS Pool
[ ] Container

Azure DevOps Server type
dev.azure.com (formerly visualstudio.com)
Azure DevOps Server Version (if applicable)
No response
Operation system
Windows
Task log
2023-11-06T20:25:00.4717439Z ==============================================================================
2023-11-06T20:25:00.4717748Z Task         : Visual Studio Test
2023-11-06T20:25:00.4717891Z Description  : Run unit and functional tests (Selenium, Appium, Coded UI test, etc.) using the Visual Studio Test (VsTest) runner. Test frameworks that have a Visual Studio test adapter such as MsTest, xUnit, NUnit, Chutzpah (for JavaScript tests using QUnit, Mocha and Jasmine), etc. can be run. Tests can be distributed on multiple agents using this task (version 2).
2023-11-06T20:25:00.4719605Z Version      : 2.229.0
2023-11-06T20:25:00.4719715Z Author       : Microsoft Corporation
2023-11-06T20:25:00.4719870Z Help         : https://docs.microsoft.com/azure/devops/pipelines/tasks/test/vstest
2023-11-06T20:25:00.4720201Z ==============================================================================
2023-11-06T20:25:01.4045017Z In distributed testing flow
2023-11-06T20:25:01.4078805Z ======================================================
2023-11-06T20:25:01.4099576Z Test selector : Test run
2023-11-06T20:25:01.4101677Z Test run Id : '9999999'
2023-11-06T20:25:01.4103302Z Search folder : C:\a\r1\a
2023-11-06T20:25:01.4273716Z Action when minimum tests threshold not met : donothing
2023-11-06T20:25:01.4275354Z Minimum tests expected to be run: 0
2023-11-06T20:25:01.7381653Z Distributed test execution, number of agents in job : 1
2023-11-06T20:25:01.7394818Z Run settings file : C:\a\r1\a\__artifactAlias\Test.Automation.xxxxxxxxxxxx\test.runsettings
2023-11-06T20:25:01.7400384Z Run in parallel : false
2023-11-06T20:25:01.7402004Z Run in isolation : false
2023-11-06T20:25:01.7403679Z Path to custom adapters : undefined
2023-11-06T20:25:01.7407979Z Other console options : /diag:C:\a\_temp\TestResults\diagnostic.txt
2023-11-06T20:25:01.7462887Z ##[warning]Other console options is not supported for this task configuration. This option will be ignored.
2023-11-06T20:25:01.7475340Z Code coverage enabled : false
2023-11-06T20:25:01.7477895Z Diagnostics enabled : true
2023-11-06T20:25:01.7482579Z Rerun failed tests: true
2023-11-06T20:25:01.7485799Z Rerun failed tests threshold: 30
2023-11-06T20:25:01.7487520Z Rerun maximum attempts: 3
2023-11-06T20:25:01.7612050Z ======================================================
2023-11-06T20:25:01.7616615Z Source filter: **\*test*.dll,!**\*TestAdapter.dll,!**\obj\**
2023-11-06T20:25:02.8406336Z ##[warning]Test Impact (Run only Impacted tests) and Code Coverage data collector will not work.
2023-11-06T20:25:02.8558104Z ##[warning]Test Impact (Run only Impacted tests) and Code Coverage data collector will not work.
2023-11-06T20:25:03.0655309Z ##[warning]Test Impact (Run only Impacted tests) and Code Coverage data collector will not work.
2023-11-06T20:25:03.0762832Z [command]C:\a\_tasks\VSTest_ef087383-ee5e-42c7-9a53-ab56c98420f9\2.229.0\Modules\DTAExecutionHost.exe --inputFile C:\a\_temp\input_90e405e0-7ce2-11ee-a7d4-5fbeb6c44523.json
2023-11-06T20:25:03.1460510Z ##########################################################################
2023-11-06T20:25:03.1461947Z DtaExecutionHost version 19.229.34210.1.
2023-11-06T20:25:04.8620369Z ===========================================
2023-11-06T20:25:04.8621522Z AgentName: agenttest-agenttest-63040
2023-11-06T20:25:04.8622439Z ServiceUrl: https://dev.azure.com/ORG/
2023-11-06T20:25:04.8623207Z TestPlatformVersion: 17.7.2
2023-11-06T20:25:04.8624085Z EnvironmentUri: vstest://env/PROJECT/_apis/release/777/88888/000000/1
2023-11-06T20:25:04.8625204Z QueryForTaskIntervalInMilliseconds: 3000
2023-11-06T20:25:04.8626051Z MaxQueryForTaskIntervalInMilliseconds: 10000
2023-11-06T20:25:04.8626687Z QueueNotFoundDelayTimeInMilliseconds: 3000
2023-11-06T20:25:04.8627426Z MaxQueueNotFoundDelayTimeInMilliseconds: 50000
2023-11-06T20:25:04.8628353Z ===========================================
2023-11-06T20:25:05.4883421Z Result Attachments will be stored in LogStore
2023-11-06T20:25:05.5030430Z Run Attachments will be stored in LogStore
2023-11-06T20:25:05.6587930Z TestExecutionHost.Execute: Registered TestAgent : 54119 : agenttest-agenttest-63040
2023-11-06T20:25:05.6804108Z Provided settings file:
2023-11-06T20:25:05.6821804Z <?xml version="1.0" encoding="utf-8"?>
2023-11-06T20:25:05.6822728Z <RunSettings>
2023-11-06T20:25:05.6823430Z 	<!-- Configurations that affect the Test Framework -->
2023-11-06T20:25:05.6824409Z 	<RunConfiguration>
2023-11-06T20:25:05.6825600Z 		<DisableParallelization>false</DisableParallelization>
2023-11-06T20:25:05.6826515Z 		<MaxCpuCount>1</MaxCpuCount>
2023-11-06T20:25:05.6827182Z 	</RunConfiguration>
2023-11-06T20:25:05.6827705Z 	<DataCollectionRunSettings>
2023-11-06T20:25:05.6829232Z 		<DataCollectors>
2023-11-06T20:25:05.6833679Z 			<DataCollector uri="datacollector://microsoft/VideoRecorder/1.0" assemblyQualifiedName="Microsoft.VisualStudio.TestTools.DataCollection.VideoRecorder.VideoRecorderDataCollector, Microsoft.VisualStudio.TestTools.DataCollection.VideoRecorder, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" friendlyName="Screen and Voice Recorder">
2023-11-06T20:25:05.6838490Z 				<!--Video data collector was introduced in Visual Studio 2017 version 15.5-->
2023-11-06T20:25:05.6839988Z 				<Configuration>
2023-11-06T20:25:05.6841487Z 					 <!--Set "sendRecordedMediaForPassedTestCase" to "false" to add video attachments to failed tests only-->
2023-11-06T20:25:05.6843404Z 					<MediaRecorder sendRecordedMediaForPassedTestCase="false"  xmlns="">
2023-11-06T20:25:05.6853458Z
2023-11-06T20:25:05.6854664Z 						<ScreenCaptureVideo bitRate="512" frameRate="2" quality="20" />
2023-11-06T20:25:05.6855808Z 					</MediaRecorder>
2023-11-06T20:25:05.6856397Z 				</Configuration>
2023-11-06T20:25:05.6856925Z 			</DataCollector>
2023-11-06T20:25:05.6857466Z 		</DataCollectors>
2023-11-06T20:25:05.6857991Z 	</DataCollectionRunSettings>
2023-11-06T20:25:05.6858446Z
2023-11-06T20:25:05.6859068Z 	<!-- MSTest adapter -->
2023-11-06T20:25:05.6859650Z 	<MSTest>
2023-11-06T20:25:05.6860082Z 		<Parallelize>
2023-11-06T20:25:05.6860603Z 			<Workers>1</Workers>
2023-11-06T20:25:05.6861361Z 			<Scope>MethodLevel</Scope>
2023-11-06T20:25:05.6861992Z 		</Parallelize>
2023-11-06T20:25:05.6862519Z 	</MSTest>
2023-11-06T20:25:05.6862981Z </RunSettings>
2023-11-06T20:25:05.6863291Z
2023-11-06T20:25:05.6975334Z IsValidServiceResponse: Received None command..Service Workflow is not active
2023-11-06T20:25:05.7126093Z Updated Run Settings:
2023-11-06T20:25:05.7126936Z <RunSettings>
2023-11-06T20:25:05.7128560Z   <!-- Configurations that affect the Test Framework -->
2023-11-06T20:25:05.7129565Z   <RunConfiguration>
2023-11-06T20:25:05.7130385Z     <DisableParallelization>false</DisableParallelization>
2023-11-06T20:25:05.7132110Z     <MaxCpuCount>1</MaxCpuCount>
2023-11-06T20:25:05.7132889Z     <BatchSize>1000</BatchSize>
2023-11-06T20:25:05.7133939Z     <ResultsDirectory>C:\a\_temp\TestResults</ResultsDirectory>
2023-11-06T20:25:05.7135539Z   </RunConfiguration>
2023-11-06T20:25:05.7136593Z   <DataCollectionRunSettings>
2023-11-06T20:25:05.7137390Z     <DataCollectors>
2023-11-06T20:25:05.7141811Z       <DataCollector uri="datacollector://microsoft/VideoRecorder/1.0" assemblyQualifiedName="Microsoft.VisualStudio.TestTools.DataCollection.VideoRecorder.VideoRecorderDataCollector, Microsoft.VisualStudio.TestTools.DataCollection.VideoRecorder, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" friendlyName="Screen and Voice Recorder">
2023-11-06T20:25:05.7148324Z         <!--Video data collector was introduced in Visual Studio 2017 version 15.5-->
2023-11-06T20:25:05.7149933Z         <Configuration>
2023-11-06T20:25:05.7151568Z           <!--Set "sendRecordedMediaForPassedTestCase" to "false" to add video attachments to failed tests only-->
2023-11-06T20:25:05.7153701Z           <MediaRecorder sendRecordedMediaForPassedTestCase="false" xmlns="">
2023-11-06T20:25:05.7155995Z
2023-11-06T20:25:05.7157022Z 						<ScreenCaptureVideo bitRate="512" frameRate="2" quality="20" />
2023-11-06T20:25:05.7158314Z 					</MediaRecorder>
2023-11-06T20:25:05.7159299Z 				</Configuration>
2023-11-06T20:25:05.7160126Z       </DataCollector>
2023-11-06T20:25:05.7161238Z       <DataCollector friendlyName="blame" enabled="True">
2023-11-06T20:25:05.7162481Z         <Configuration>
2023-11-06T20:25:05.7163601Z           <ResultsDirectory>C:\a\_temp\TestResults</ResultsDirectory>
2023-11-06T20:25:05.7164956Z           <CollectDump CollectAlways="true" />
2023-11-06T20:25:05.7166559Z           <CollectDump />
2023-11-06T20:25:05.7167971Z         </Configuration>
2023-11-06T20:25:05.7169062Z       </DataCollector>
2023-11-06T20:25:05.7170326Z     </DataCollectors>
2023-11-06T20:25:05.7171718Z   </DataCollectionRunSettings>
2023-11-06T20:25:05.7172864Z   <!-- MSTest adapter -->
2023-11-06T20:25:05.7173735Z   <MSTest>
2023-11-06T20:25:05.7174906Z     <Parallelize>
2023-11-06T20:25:05.7175851Z       <Workers>1</Workers>
2023-11-06T20:25:05.7177126Z       <Scope>MethodLevel</Scope>
2023-11-06T20:25:05.7178766Z     </Parallelize>
2023-11-06T20:25:05.7179778Z   </MSTest>
2023-11-06T20:25:05.7180651Z   <LoggerRunSettings>
2023-11-06T20:25:05.7181586Z     <Loggers>
2023-11-06T20:25:05.7182653Z       <Logger friendlyName="blame" enabled="True" />
2023-11-06T20:25:05.7184883Z     </Loggers>
2023-11-06T20:25:05.7186072Z   </LoggerRunSettings>
2023-11-06T20:25:05.7186992Z </RunSettings>
2023-11-06T20:25:05.8136769Z Creating run for selected test assemblies with following parameters
2023-11-06T20:25:05.8139134Z SourceFilter: *.dll TestCaseFilter:
2023-11-06T20:25:05.8141563Z Run title: xxxxxxxxxxxxxxxxxxxxxxx - Assembly_Release-13
2023-11-06T20:25:05.8142865Z Build location: C:\a\r1\a
2023-11-06T20:25:05.8143862Z Build Id: 3333333
2023-11-06T20:25:06.0355469Z Test run with Id 9999999 associated
2023-11-06T20:25:16.7384975Z Received the command : Start
2023-11-06T20:25:16.7404361Z TestExecutionHost.ProcessCommand. Start Command handled
2023-11-06T20:25:18.6282525Z Slice with id = 66666, of type = 'Execution' received.
2023-11-06T20:25:18.8977548Z Count of test sources found: 2
2023-11-06T20:25:18.9210177Z =================================================================
2023-11-06T20:25:18.9211674Z Discovering tests from sources
2023-11-06T20:25:18.9461578Z Using new test platform for test execution
2023-11-06T20:25:18.9571175Z Microsoft.TestPlatform.VsTestConsole.TranslationLayer.VsTestConsoleWrapper instance will be created
2023-11-06T20:25:29.3985379Z DiscoveryMessage : [xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.5.3.1+6b60a9e56a (64-bit .NET 6.0.16)
2023-11-06T20:25:30.4142575Z DiscoveryMessage : [xUnit.net 00:00:00.56]   Discovering: xxxxxxxxxxxx.FunctionalTests
2023-11-06T20:25:30.8324559Z DiscoveryMessage : [xUnit.net 00:00:01.45]   Discovered:  xxxxxxxxxxxx.FunctionalTests
2023-11-06T20:25:33.1196296Z Number of testcases discovered : 707
2023-11-06T20:25:33.1395128Z Discovered tests 707 from sources
2023-11-06T20:25:33.1396036Z =================================================================
2023-11-06T20:25:33.1641445Z [RunStatistics]This execution slice with id '66666', received '1' testcases to execute out of which '0' is discovered.
2023-11-06T20:25:33.1967140Z List of test cases in slice with id: 66666
2023-11-06T20:25:33.1971615Z Source: xxxxxxxxxxxx.FunctionalTests.dll, FullyQualifiedTestName: xxxxxxxxxxxx.FunctionalTests.Features.Functional.xxxxxxxxxxxx.SAMPLETESTMETHOD
2023-11-06T20:25:33.2229981Z ##[error]ExecutionAndPublish.Run : Microsoft.VisualStudio.TestService.VstestAdapter.TestsNotFoundException: No test assemblies found on the test machine matching the source filter criteria or no tests discovered matching test filter criteria. Verify that test assemblies are present on the machine and test filter criteria is correct.
2023-11-06T20:25:33.2237947Z    at Microsoft.VisualStudio.TestService.VstestAdapter.Execution.Run(ExecutionStateContext stateModelContext, CancellationToken cancellationToken)
2023-11-06T20:25:33.2241541Z    at Microsoft.VisualStudio.TestService.VstestAdapter.ExecutionAndPublish.Run(ExecutionStateContext stateModelContext, CancellationToken cancellationToken)
2023-11-06T20:25:33.2290505Z ##[error]The slice of type 'Execution' is 'Aborted' because of the error : Microsoft.VisualStudio.TestService.VstestAdapter.TestsNotFoundException: No test assemblies found on the test machine matching the source filter criteria or no tests discovered matching test filter criteria. Verify that test assemblies are present on the machine and test filter criteria is correct.
2023-11-06T20:25:33.2309860Z    at Microsoft.VisualStudio.TestService.VstestAdapter.Execution.Run(ExecutionStateContext stateModelContext, CancellationToken cancellationToken)
2023-11-06T20:25:33.2313698Z    at Microsoft.VisualStudio.TestService.VstestAdapter.ExecutionAndPublish.Run(ExecutionStateContext stateModelContext, CancellationToken cancellationToken)
2023-11-06T20:25:37.7462112Z Received the command : Stop
2023-11-06T20:25:37.7463428Z TestExecutionHost.ProcessCommand. Stop Command handled
2023-11-06T20:25:37.7472402Z SliceFetch Aborted. Moving to the TestHostEnd phase
2023-11-06T20:25:37.7936092Z Please use this link to analyze the test run : https://dev.azure.com/ORG/PROJECT/_TestManagement/Runs#_a=resultQuery&runId=9999999&queryPath=Recent+Run%2FRun9999999
2023-11-06T20:25:37.7939786Z Test run '9999999' is in 'Aborted' state with 'Total Tests' : 1 and 'Passed Tests' : 0.
2023-11-06T20:25:37.7996602Z ##[error]Test run is aborted. Logging details of the run logs.
2023-11-06T20:25:37.8005110Z ##[error]System.Exception: The test run was aborted, failing the task.
2023-11-06T20:25:37.9039187Z ##########################################################################
2023-11-06T20:25:37.9603912Z ##[section]Finishing: VsTest - testRun

Relevant log output
2023-11-06T20:25:06.0355469Z Test run with Id 9999999 associated
2023-11-06T20:25:16.7384975Z Received the command : Start
2023-11-06T20:25:16.7404361Z TestExecutionHost.ProcessCommand. Start Command handled
2023-11-06T20:25:18.6282525Z Slice with id = 66666, of type = 'Execution' received.
2023-11-06T20:25:18.8977548Z Count of test sources found: 2
2023-11-06T20:25:18.9210177Z =================================================================
2023-11-06T20:25:18.9211674Z Discovering tests from sources
2023-11-06T20:25:18.9461578Z Using new test platform for test execution
2023-11-06T20:25:18.9571175Z Microsoft.TestPlatform.VsTestConsole.TranslationLayer.VsTestConsoleWrapper instance will be created
2023-11-06T20:25:29.3985379Z DiscoveryMessage : [xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.5.3.1+6b60a9e56a (64-bit .NET 6.0.16)
2023-11-06T20:25:30.4142575Z DiscoveryMessage : [xUnit.net 00:00:00.56]   Discovering: xxxxxxxxxxxx.FunctionalTests
2023-11-06T20:25:30.8324559Z DiscoveryMessage : [xUnit.net 00:00:01.45]   Discovered:  xxxxxxxxxxxx.FunctionalTests
2023-11-06T20:25:33.1196296Z Number of testcases discovered : 707
2023-11-06T20:25:33.1395128Z Discovered tests 707 from sources
2023-11-06T20:25:33.1396036Z =================================================================
2023-11-06T20:25:33.1641445Z [RunStatistics]This execution slice with id '66666', received '1' testcases to execute out of which '0' is discovered.
2023-11-06T20:25:33.1967140Z List of test cases in slice with id: 66666
2023-11-06T20:25:33.1971615Z Source: xxxxxxxxxxxx.FunctionalTests.dll, FullyQualifiedTestName: xxxxxxxxxxxx.FunctionalTests.Features.Functional.xxxxxxxxxxxx.SAMPLETESTMETHOD
2023-11-06T20:25:33.2229981Z ##[error]ExecutionAndPublish.Run : Microsoft.VisualStudio.TestService.VstestAdapter.TestsNotFoundException: No test assemblies found on the test machine matching the source filter criteria or no tests discovered matching test filter criteria. Verify that test assemblies are present on the machine and test filter criteria is correct.
2023-11-06T20:25:33.2237947Z    at Microsoft.VisualStudio.TestService.VstestAdapter.Execution.Run(ExecutionStateContext stateModelContext, CancellationToken cancellationToken)
2023-11-06T20:25:33.2241541Z    at Microsoft.VisualStudio.TestService.VstestAdapter.ExecutionAndPublish.Run(ExecutionStateContext stateModelContext, CancellationToken cancellationToken)
2023-11-06T20:25:33.2290505Z ##[error]The slice of type 'Execution' is 'Aborted' because of the error : Microsoft.VisualStudio.TestService.VstestAdapter.TestsNotFoundException: No test assemblies found on the test machine matching the source filter criteria or no tests discovered matching test filter criteria. Verify that test assemblies are present on the machine and test filter criteria is correct.
2023-11-06T20:25:33.2309860Z    at Microsoft.VisualStudio.TestService.VstestAdapter.Execution.Run(ExecutionStateContext stateModelContext, CancellationToken cancellationToken)
2023-11-06T20:25:33.2313698Z    at Microsoft.VisualStudio.TestService.VstestAdapter.ExecutionAndPublish.Run(ExecutionStateContext stateModelContext, CancellationToken cancellationToken)
2023-11-06T20:25:37.7462112Z Received the command : Stop
2023-11-06T20:25:37.7463428Z TestExecutionHost.ProcessCommand. Stop Command handled

Aditional info
Looks like it started to happen after the VSTest task is updated to 2.229.0. I ca see the task was running fine till when it was 2.228.0. after that the runs were failing.

Related to https://github.com/microsoft/azure-pipelines-tasks/issues/19222.
We have see it work and fail with with 2.229.0.

Possible fix is to move from VSTest@2  to VSTest@3

Possible fix is to move from VSTest@2 to VSTest@3 (Undocumented https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/vstest-v2?view=azure-pipelines)

I have a similar issue where 2.229.0 was working (found and executed 6/6 test cases in a Test Plan), but now only runs 3/6 Test Cases and leaves the remaining test cases with an Outcome of 'In Progress'.
I have just tried VSTest@3 (v3.225.0), and now all 6 test cases are executed successfully again.

Possible fix is to move from VSTest@2 to VSTest@3 (Undocumented https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/vstest-v2?view=azure-pipelines)
Wonder if the node pathing has changed as it looks for the dlls? Could be due to #19215

Upgrade won't work in our case as it will fail the Automated test run from the Test plan validation. Looks like its when we select a subset of tests to be run from test plan, choosing this release with vstest@v2 only works. Rest fails the validation and wont kick it off. Link to referenced steps from microsoft.

I did test with vstest@V3 to run entire test plan. It seems to be working with the v3 task. But unfortunately, the Automated test run validation is not allowing V3 task. Probably will need to fix that validation and we can try with the V3 task in the test run mode from Automated test run.

@qianz2 @merlynomsft @rasunkar any thoughts?

I have exactly the same setup as @sailesh89 and am experiencing the same issue.
On the afternoon of 9th November a number of tests stopped working. Now this morning (10th) those same tests are executing. No changes were made on my end at any point.

This still seems to be an issue with Version 2 of the vstest runner,
still unable to run tests from test plan with version 3
can we reopen this issue?

I stopped using VSTest it as it doesn't work on Ubuntu anyway.
We use dotnet test now and our own custom version of
https://github.com/idubnori/ParallelTestingSample-dotnet-core


text:
Unable to disable publishing to tfs

In the VsTest task - there is no option to disable the publish to TFS.  I want to be able to disable the publishing to TFS, to do a number of separate test tasks (one parallel, one not) and then merge the results via a separate publish tests task.
I've manage to easily do the same with an adapted version of this task with a boolean flag in the reporting section of the config to turn publishing on/off - cant see why similar couldn't be included in the base MS release.

wrong task

yes I adapted the task to disable to publishing..

@jklaus I reviewed the VsTest task and it is not possible to disable publishing, because the publishing itself is done by the external assemblies the tasks invokes and there is no input to skip it (it is hard coded basically).
For me the problem was that I do the publishing myself (I develop a tool, SpecSync that does that), and since the VsTest task is also publishes the results, they appear twice in the "Tests" tab of the build.
I finally tweaked the VsTest task in a way that it does not pass the build information to the compiled assembly, so the published Test Run will not be connected to the build and this way it does not appear in the "Tests" tab.
If that would help anyone, you can find this tweaked task (called "Visual Studio Test for SpecSync") in the free extension SpecSync Tools. Although "SpecSync" is in the name, you can also use it without SpecSync if this behavior is useful for you.

authors: gasparnagy peteakalad


text:
Cannot auth to Databricks provider over AZDO Federated Service Connection

Hello. We have encountered an issue with auth into Databricks workspace over Federated Service Connection.
Databricks provider configuration:
provider "databricks" {
  host                        = azurerm_databricks_workspace.data_hub_dbw.workspace_url
  azure_workspace_resource_id = azurerm_databricks_workspace.data_hub_dbw.id
  # azure_use_msi = true
}

Pipeline task .yaml
steps:
- task: ms-devlabs.custom-terraform-tasks.custom-terraform-release-task.TerraformTaskV4@4
  displayName: 'Terraform : azurerm : plan'
  inputs:
    command: plan
    workingDirectory: '$(System.DefaultWorkingDirectory)/<PathToTerraformModule>'
    commandOptions: '-var-file=./$(component)-$(environment).tfvars '
    environmentServiceNameAzureRM: '<ServiceConnection>'
    backendAzureRmUseEnvironmentVariablesForAuthentication: false
    backendAzureRmUseEntraIdForAuthentication: true

Error we are getting:
2024-11-07T14:41:17.0769966Z Error: cannot read instance pool: failed during request visitor: default auth: azure-cli: cannot get account info: exit status 1. Config: host=<DatabricksWorkspaceURL>, azure_workspace_resource_id=<ResourseID>, azure_client_id=***, azure_tenant_id=<TenantID>. Env: ARM_CLIENT_ID, ARM_TENANT_ID

Hi sorry for late reply.  is this something you know anything about @jaredfholgate ?
br
Manuel

repo: microsoft/azure-pipelines-terraform


text:
Certificate based keyvault auth

Summary
Includes AsymmetricKeyCredential/Certificate based authentication to Key Vault Boot Starter
Issue Type
New Feature
Starter Names

key vault spring boot starter

Additional Information
Currently the class com.microsoft.azure.keyvault.spring.KeyVaultEnvironmentPostProcessorHelper accepts only clientID and clientKey based authentication to KeyVault, and there is no way by which certificates can be used.
We are submitting a small code change which will allow users to use PFX certificate.
Users will have to mention the following attributes if choosing to use PFX certificate:
azure.keyvault.pfx-certificate-path
azure.keyvault.pfx-certificate-password (optional)
This is a functionality we require to have for our product using Key Vault.
Request you to please merge if found appropriate. Please suggest otherwise.
This is a continuation from https://github.com/Microsoft/azure-spring-boot/pull/272, which has been closed.

Any updates on this PR?

@erviszyka, we've upgraded our Key Vault client library which no longer uses the ADAL library to authenticate. And we've already supported the certificate way in both 2.1.x and 2.2.x. You could check the code here. And I will close this PR now.

authors: erviszyka fragmadata saragluna

repo: microsoft/azure-spring-boot


text:
Validate that listed HCIBox supported regions are aligned with region support

Is your issue related to a Jumpstart scenario, ArcBox, HCIBox, or Agora?
https://azurearcjumpstart.io/azure_jumpstart_hcibox/deployment_az
Describe the issue or the bug
Deploying to eastus fails.
To Reproduce
See https://azurearcjumpstart.io/azure_jumpstart_hcibox/deployment_az
Expected behavior

Deployment completes
Environment summary
all latest version of CLI tools.
Have you looked at the Troubleshooting and Logs section?

Screenshots
Errors from the locally run command prompt and the Azure portal.

Additional context
see issue https://github.com/microsoft/azure_arc/issues/2632 . Deploying to eastus2 doesn't work either, please advise on the best region(s) to deploy HCI Stack.

Try AustraliaEast

@LucaOtto can i plz ask to update the issue title to something more manageable and shorter?

Hi @janegilring @LucaOtto @dkirby-ms I had faced the same issue and tested in all supported regions
'australiaeast,southcentralus,eastus,westeurope,southeastasia,canadacentral,japaneast,centralindia'
Australia East is worst in terms of time, it will take 2 days for the script to complete
Other regions have other extension issues.
East US and East US 2 are currently in some form of Lock down.
Try the below two in priority

Canada Central - It will work
South East Asia

Hello @dkirby-ms , @janegilring @likamrat ,
my deployment completed in Australia East and the HCI Box is up and running now.
I then added a Kubernetes cluster this way: https://azurearcjumpstart.io/azure_jumpstart_hcibox/AKS and it is connected and working.

however I'm seeing an issue with connecting to the Kubernetes cluster , see screenshot below. I restarted the Cloud Shell multiple times, same error.

I then tried to deploy a second cluster via the portal :

upgraded the cluster to the same version of the original one and tried again with the same command but I'm getting the same error.
Any suggestions on how to fix this?

Environment deployed and running, closing issue.

authors: LucaOtto WVDAdminTF dkirby-ms likamrat


text:
Broken saved connections

Issue Type: Bug
Today's update broke all my saved connections!
Azure Data Studio version: azuredatastudio 1.10.0 (5fdb967ffcea41df0335ec17cfa396a694bb174e, 2019-08-14T18:28:10.311Z)
OS version: Windows_NT x64 10.0.17134

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz (8 x 2112)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwareoop_rasterization: disabled_offprotected_video_decode: enabledrasterization: enabledskia_deferred_display_list: disabled_offskia_renderer: disabled_offsurface_synchronization: enabled_onvideo_decode: enabledviz_display_compositor: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
31.81GB (19.10GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions: none

I'm sorry to hear this happened @aarongiust. Do you have any more information on how the connections broke?

I think I know the issue here, I'll have a fix out soon.

authors: aaomidi aarongiust anthonydresser

repo: microsoft/azuredatastudio


text:
A11y_SQLAzureDataStudio_SchemaCompare_SchemaCompareOptions_Keyboard: Keyboard focus is not shifted to the latest popped up window on the screen.

“Check out Accessibility Insights! - Identify accessibility bugs before check-in and make bug fixing faster and easier.”
GitHubTags:#A11y_SQLAzureDataStudioBenchmark;#A11yMAS;#A11ySev2;#A11yTCS;#SQL Azure Data Studio;#Benchmark; #DesktopApp;#VoiceOver;#MacOs;#MAS2.4.3;
Environment Details:
Application Name: Azure Data Studio
Version: 1.15.0-insider
Commit: 3a8b74a
Date: 2020-02-11T05:49:41.181Z
VS Code: 1.42.0
Electron: 7.1.11
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Darwin x64 19.3.0
Mac OS:10.15.3
Additional Details:
Mac OS:10.15.3
MAS References:MAS2.4.3
Screen reader: VoiceOver
Repro Steps:
1.Launch Azure Data Studio application.
2.Connect to server with windows credentials.
3.Navigate to Extensions from left menu.
4.Search & install Schema Compare extension.
5.Navigate to Connections from left menu.
6.Expand the server connected in step 2.
7.Right click an on prem database and select Schema compare from Context menu.
8.Navigate till Select Source or Select Target & hit enter.
Provide all the details for Source & Target.
9.Navigate till Ok button & hit enter.
10.Navigate till Options menu from Schema compare Menu bar.
11.After hitting enter, check if focus order is proper in order.
Actual:
The focus is not shifted to the new window that pop ups on the screen after hitting enter on the options menu.
Expected:
As soon as any new window pop ups which contains any interactive element inside it the focus should shift inside that new screen.
User Impact:
Keyboard as well as screen reader users will get confused as the focus remains on the previous screen and not shifted to the latest screen that is visible to us.
Attachment link reference:
9409_A11y_SQLAzureDataStudio_SchemaCompare_SchemaCompareOptions_Keyboard.zip

issue: newly opened UI should have the keyboard focus

Verified the issue in below environment :
Version: 1.41.1 (Universal)
Commit: 33dce95b152227c4f10f6251ab30690fe9895c0c
Date: 2023-01-28T00:49:19.454Z
VS Code: 1.67.0
Electron: 19.1.8
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: 10.2.154.15-electron.0
OS: Darwin arm64 22.3.0
The issue is fixed. Hence adding closed tag.
#Closed;

GitHubTags:#BM-TCS-SQLADS-MAC-Feb2020;

authors: alanrenmsft manaswita-chougule mstechie v-atkulk


text:
Listen to escape key to close notebook find widget

Fixes #9218.

Do we already listen on the document for esc? find in a normal document will close if you hit escape anywhere on the doc.

I was mimicking how it's implemented in the existing find widgets.

We listen to escape at the cell level, not the document level.


text:
ConfigurationBotFrameworkAuthentication should check for Configuration keys

Version
4.13.1
Describe the problem
The ConfigurationBotFrameworkAuthentication looks for auth configuration values using keys that haven't been used before.
https://github.com/microsoft/botbuilder-dotnet/blob/39b7a60a5d3078ff7f06360a1242fa344c7f53e9/libraries/integration/Microsoft.Bot.Builder.Integration.AspNet.Core/ConfigurationBotFrameworkAuthentication.cs#L38-L39
However, known keys for these values exist and are used when provisioning Web App Bots and in the SDK.
https://github.com/microsoft/botbuilder-dotnet/blob/39b7a60a5d3078ff7f06360a1242fa344c7f53e9/libraries/Microsoft.Bot.Connector/Authentication/AuthenticationConstants.cs#L48-L56

Proposed solution
Use the "ToBotFromChannelOpenIdMetadataUrl" first as it's slightly more descriptive, then fall back to AuthenticationConstants.BotOpenIdMetadataKey. (And for "OAuthUrl" and AuthenticationConstants.OAuthUrlKey)
var toBotFromChannelOpenIdMetadataUrl = configuration.GetSection("ToBotFromChannelOpenIdMetadataUrl")?.Value
     ?? configuration.GetSection(AuthenticationConstants.BotOpenIdMetadataKey)?.Value;

BotFrameworkHttpAdapter example

https://github.com/microsoft/botbuilder-js/pull/3698/files#diff-026de553b71fe01f106719bedd9153ca84f439620ef1db7f64a25634fb00500dR137-R140

repo: microsoft/botbuilder-dotnet


text:
fix: cleanup streaming high-perf logs

Fixes #6649
Specific Changes

Fixes the high performance logging in the StreamingTransportClient from using the wrong EventId.Name

Specifically _clientCompleted and _clientKeepAliveSucceed

Adds NamedPipeConnectionStarted and NamedPipeConnectionCompleted for use in CloudAdapter.ConnectNamedPipeAsync() instead of using the incorrect WebSocketConnectionStarted and WebSocketConnectionCompleted.
Minor cleanup in logs for StreamingSession and TransportHandler

Pull Request Test Coverage Report for Build 356724

0 of 0   changed or added relevant lines in 0 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.01%) to 78.979%

Files with Coverage Reduction
New Missed Lines
%

/libraries/integration/Microsoft.Bot.Builder.Integration.AspNet.Core/CloudAdapter.cs
1
77.14%

Totals

Change from base Build 355145:
0.01%

Covered Lines:
25936

Relevant Lines:
32839

💛  - Coveralls

:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Integration.AspNet.Core.dll

authors: BruceHaley coveralls stevengum