crc
crc copied to clipboard
[BUG] Openshift Local Ver.2.5.1 after every reboot of the PC a terminal window shows with some HTTP Requests
General information
- OS: Windows
- Hypervisor: Hyper-V
- Did you run
crc setup
before starting it (Yes/No)? Yes - Running CRC on: Laptop
CRC version
CRC version: 2.5.1+5b02b826
OpenShift version: 4.10.18
Podman version: 4.1.0
CRC status
CRC VM: Running
OpenShift: Running (v4.10.18)
Podman:
Disk Usage: 15.99GB of 32.74GB (Inside the CRC VM)
Cache Usage: 17.98GB
CRC config
- consent-telemetry : yes
- cpus : 6
- memory : 32256
Host Operating System
Host Name: TH-P1-W10
OS Name: Microsoft Windows 11 Enterprise
OS Version: 10.0.22000 N/A Build 22000
OS Manufacturer: Microsoft Corporation
OS Configuration: Member Workstation
OS Build Type: Multiprocessor Free
Registered Owner: Red Hat User
Registered Organization: Red Hat Inc.
Product ID: 00329-00000-00003-AA136
Original Install Date: 03/08/2022, 12:33:34
System Boot Time: 07/03/2022, 11:11:52
System Manufacturer: LENOVO
System Model: 20TJS2F40Y
System Type: x64-based PC
Processor(s): 1 Processor(s) Installed.
[01]: Intel64 Family 6 Model 165 Stepping 2 GenuineIntel ~2310 Mhz
BIOS Version: LENOVO N2VET38W (1.23 ), 02/10/2022
Windows Directory: C:\WINDOWS
System Directory: C:\WINDOWS\system32
Boot Device: \Device\HarddiskVolume4
System Locale: he;Hebrew
Input Locale: en-us;English (United States)
Time Zone: (UTC+02:00) Jerusalem
Total Physical Memory: 65,289 MB
Available Physical Memory: 24,119 MB
Virtual Memory: Max Size: 75,017 MB
Virtual Memory: Available: 30,932 MB
Virtual Memory: In Use: 44,085 MB
Page File Location(s): C:\pagefile.sys
Domain: win.redhat.com
Logon Server: \\AMS2-DC02
Hotfix(s): 4 Hotfix(s) Installed.
[01]: KB5013889
[02]: KB5007575
[03]: KB5014697
[04]: KB5014034
Network Card(s): 4 NIC(s) Installed.
[01]: Viscosity Virtual TUN Adapter
Connection Name: Tel Aviv (TLV)
Status: Hardware not present
[02]: Intel(R) Wi-Fi 6 AX201 160MHz
Connection Name: Wi-Fi
DHCP Enabled: Yes
DHCP Server: 192.168.0.1
IP address(es)
[01]: 192.168.0.104
[02]: fe80::d11b:5a94:fd02:ca5e
[03]: Hyper-V Virtual Ethernet Adapter
Connection Name: vEthernet (crc)
DHCP Enabled: Yes
DHCP Server: 255.255.255.255
IP address(es)
[01]: 169.254.109.134
[02]: fe80::800d:e8a2:1f7d:6d86
[04]: Bluetooth Device (Personal Area Network)
Connection Name: Bluetooth Network Connection
Status: Media disconnected
Hyper-V Requirements: A hypervisor has been detected. Features required for Hyper-V will not be displayed.
Steps to reproduce
- after install of CRC 2.5.1 finish the setup
- reboot the machine / Laptop
- a terminal windows with \.\pipe\crc-http popup every time
Expected
Actual
Logs
Before gather the logs try following if that fix your issue
$ crc delete -f
$ crc cleanup
$ crc setup
$ crc start --log-level debug
Please consider posting the output of crc start --log-level debug
on http://gist.github.com/ and post the link in the issue.
@Tal-Hason This terminal windows comes for short time period (flashes) because of the schedule task and we already have https://github.com/code-ready/crc/issues/3089 for tracking purpose.
Also notice after closing the terminal window the CRC is stoping by it self and in the log is shows that its running
listening vsock://00000400-FACB-11E6-BD58-64006A7986D3
Checking Windows 10 release
Checking Windows edition
Checking if crc-users group exists
Checking if Hyper-V service is enabled
Checking if vsock is correctly configured
CRC VM is running
Check internal and public DNS query...
Check DNS query from host...
Failed to query DNS from host: lookup foo.apps-crc.testing: no such host
Verifying validity of the kubelet certificates...
Starting OpenShift cluster... [waiting for the cluster to stabilize]
Operators are stable (3/3)...
but in the Hyper-V is still running
It feels like he reports this as being persistent (not closing).
in my PC it stays Open and never closes until I manually close it, and then see my comment
It feels like he reports this as being persistent (not closing).
but in the tray icon it shows that the CRC is Stopped but it actually still running
It feels like he reports this as being persistent (not closing).
yes
We never tested it with Microsoft Windows 11 Enterprise
may be something change on windows side, as a workaround please minimize it and keep using crc instead closing it because once you close the daemon process stop :(
its Red Hat CSB Windows ... :-\
I will have a look at this.
I will have a look at this.
thanks
Maybe this is the issue:
Specifies the state of the window that is used for the new process. The acceptable values for this parameter are: Normal, Hidden, Minimized, and Maximized. The default value is Normal.
**You cannot use the WindowStyle and NoNewWindow parameters in the same command.**
The parameter does not apply for non-Windows systems. When using on non-Windows systems, you never get a new window.
maybe instead of using "Windows Task Scheduler" put a script in the "shell:startup"
or create a Windows Service for the Deamon
just suggesting some ideas
You cannot use the WindowStyle and NoNewWindow parameters in the same command.
I am not sure what is currently set, but this sounds reasonable. @praveenkumar worked on this before me as a trail into the lands of Windows.
Shell:startup is not reliable enough for us, as with the Task Scheduler you can easily inspect the state.
or create a Windows Service for the Deamon
Service need permissions/password to be set to allow it to run. This adds complexity and additional maintenance for this command. Especially in a domain-joined situation this can be troublesome.
A service can ran as local system or a network service and wont need any special premissions
You can check our commit log; as this is what we did earlier. It wasn't ideal for us. We used network service and local system, but that is actually too many privileges. This is a security risk.
as you create a "task" in the task scheduler" with my logon
you can create a service to run with any user. i guess most user that install the OCP Local will have Local Admin Permissions
obj= {<accountname> | <objectname>}
A service to run as user needs credentials. These, as enforced by many policies will change over time and become invalid. Also, "Local Admin Permissions" is not a given. We mostly see this for .NET developers, but not for Java developers.
Note: account and password have to be specified as valid entries for the service runas
to work.
This might have to do with the Windows Terminal
. In a normal situation, powershell
should be run from a regular command prompt and this 'disappears'. But as I can see in the screenshot, powershell is hosted inside the Windows Terminal application.
Does a Win + R
-> powershell
also open in the Windows Terminal?
Hi , yes when running powershell via the "run command" it opens the windows terminal
changed the the setting for command line to from the windows terminal to "windows console host"
rebooting the machine and check
changed the the setting for command line to from the windows terminal to "windows console host"
rebooting the machine and check
with "windows console host" the PS windows pops and then disappear
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Perhaps this could be solved by force running powershell.exe in conhost.exe instead of allowing the OS to use the default configured console host. For example, if I run conhost powershell.exe -NoExit Get-Date
it will open in a non-Windows Terminal host. Obviously, the code would not use -NoExit
. I used that parameter to prevent the window from closing immediately. From my testing, all the parameters still get passed into the powershell executable correctly. A few changes in powershell_windows.go could have this issue addressed.
For those looking for more information, Scott Hanselman describes what conhost vs Windows Terminal host is here: https://youtu.be/tuhzVDc0Slg?t=804
It may not be worth the effort trying to determine which default console host is configured. If I recall correctly, conhost.exe is not going anywhere.
I think I found an end user work around. If you set powershell.exe to use "Windows Console Host" by default, the CRC log window does not display. This change does not require the user to change their default terminal application.
Steps:
- Run powershell.exe via conhost: Win+R and run
conhost powershell.exe -NoProfile -NonInteractive
- Right click on the title bar and choose "Properties"
- Change the" Default Terminal Application" to Windows Console Host
You can test by running powershell.exe -NoProfile -NonInteractive
using Win+R
this was fixed in #3901