I am installing k8s and vsphere CPI/CSI following the instructions located here
My setup:
2x centos 7.7 vSphere VM's (50g hd/16g ram), 1 master & 1 node in k8s cluster.
Made it to the part where I create the storageClass (near the end) when I discovered this github issue exactly. OP of the linked issue just started from scratch and their issue went away, so the report was closed. This has not been the case for me as I've redeployed my k8s cluster from scratch a bunch of times now and always hit this wall. Below is the error if you don't want to check the linked github issue.
Anyone have ideas on what I can try to get past this? I've checked my hd and ram and plenty there.
# kubectl -n kube-system logs pod/vsphere-csi-controller-0 vsphere-csi-controller
I0127 18:49:43.292667 1 config.go:261] GetCnsconfig called with cfgPath: /etc/cloud/csi-vsphere.conf
I0127 18:49:43.292859 1 config.go:206] Initializing vc server 132.250.31.180
I0127 18:49:43.292867 1 controller.go:67] Initializing CNS controller
I0127 18:49:43.292884 1 virtualcentermanager.go:63] Initializing defaultVirtualCenterManager...
I0127 18:49:43.292892 1 virtualcentermanager.go:65] Successfully initialized defaultVirtualCenterManager
I0127 18:49:43.292905 1 virtualcentermanager.go:107] Successfully registered VC "132.250.31.180"
I0127 18:49:43.292913 1 manager.go:60] Initializing volume.volumeManager...
I0127 18:49:43.292917 1 manager.go:64] volume.volumeManager initialized
time="2020-01-27T18:50:03Z" level=info msg="received signal; shutting down" signal=terminated
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x128 pc=0x867dc7]
goroutine 10 [running]:
google.golang.org/grpc.(*Server).GracefulStop(0x0)
/go/pkg/mod/google.golang.org/grpc#v1.23.0/server.go:1393 +0x37
github.com/rexray/gocsi.(*StoragePlugin).GracefulStop.func1()
/go/pkg/mod/github.com/rexray/gocsi#v1.0.0/gocsi.go:333 +0x35
sync.(*Once).Do(0xc0002cc8fc, 0xc000380ef8)
/usr/local/go/src/sync/once.go:44 +0xb3
github.com/rexray/gocsi.(*StoragePlugin).GracefulStop(0xc0002cc870, 0x21183a0, 0xc000056018)
/go/pkg/mod/github.com/rexray/gocsi#v1.0.0/gocsi.go:332 +0x56
github.com/rexray/gocsi.Run.func3()
/go/pkg/mod/github.com/rexray/gocsi#v1.0.0/gocsi.go:121 +0x4e
github.com/rexray/gocsi.trapSignals.func1(0xc00052a240, 0xc000426990, 0xc000426900)
/go/pkg/mod/github.com/rexray/gocsi#v1.0.0/gocsi.go:502 +0x143
created by github.com/rexray/gocsi.trapSignals
/go/pkg/mod/github.com/rexray/gocsi#v1.0.0/gocsi.go:487 +0x107
Ok turns out this SIGSEGV was a bug or something and it was caused by a network timeout, making this error kind of a red herring.
Details: My vsphere-csi-controller-0 pod was (and still is actually) unable to reach the vsphere server which caused the container in the pod to timeout and trigger this SIGSEV fault. The CSI contributers updated some libraries and the fault is now gone but the timeout remains. Timeout appears to be my problem and not related to CSI but that's a new question :)
If you want the details of what was fixed in the CSI check the github link in the question.
Related
I have followed this instructions to setup the latest version of NEOS:
https://docs.neos.io/cms/installation-development-setup/manual-installation-with-a-web-server
https://docs.neos.io/cms/installation-development-setup/running-the-setup-tool
After i log into the CMS i get the following error:
Xdebug has detected a possible infinite loop, and aborted your script with a stack depth of '256' frames
Exception Code 0
Exception Type Error
Thrown in File Packages/Framework/Neos.Flow/Classes/ObjectManagement/ObjectManager.php
Line 539
My local environment:
PHP Version 7.3.26-1+ubuntu20.04.1+deb.sury.org+1
XDebug 3.0.2
what's going wrong here?
this solves my problem
20-xdebug.ini
[xdebug]
xdebug.max_nesting_level=512
php.ini
max_execution_time = 600
This solves my problem:
"Xdebug has detected a possible infinite loop, and aborted your script with a stack depth of '256' frames"
Add to file:
/etc/php/8.1/apache2/conf.d/20-xdebug.ini
xdebug.max_nesting_level=512
And restart the server
When loading OBJs into an MDLAsset using the MDLAsset(url:) initializer (to eventually get the model into SceneKit), the operation fails frequently and inconsistently on iOS14. This operation works fine for these same files on previous iOS versions. I've also observed the bug on iPadOS, although maybe less frequently. Not sure if it's relevant, but these OBJs are pulled from server and stored locally. But this bug is occurring after files are already downloaded. Sometimes the same file will fail multiple times before randomly working, and vice versa.
The console output seems to indicate a failure to communicate with ModelIO XPC service. I tried restarting my device, but the bug continues to occur. Console output:
connection to com.apple.ModelIO.AssetLoader was interrupted
AssetLoader.loadURL errorHandler: Error Domain=NSCocoaErrorDomain Code=4097 "connection to service on pid 0 named com.apple.ModelIO.AssetLoader" UserInfo={NSDebugDescription=connection to service on pid 0 named com.apple.ModelIO.AssetLoader}
Couldn’t communicate with a helper application.
connection to com.apple.ModelIO.AssetLoader was interrupted
Has anyone else run into this issue on iOS14?
Alternatively, are there any workarounds anyone has tried in the meantime? As far as I know, loading an OBJ (that is downloaded from server) into SceneKit can only be done through ModelIO, without writing an OBJ parser myself.
This seems to be fixed in 14.3.
2020-10-13 18:31:36.989282+0300 Studia3D Viewer[1452:348335] connection to com.apple.ModelIO.AssetLoader was interrupted
2020-10-13 18:31:36.989368+0300 Studia3D Viewer[1452:347676] AssetLoader.loadURL errorHandler: Error Domain=NSCocoaErrorDomain Code=4097 “connection to service on pid 0 named com.apple.ModelIO.AssetLoader” UserInfo={NSDebugDescription=connection to service on pid 0 named com.apple.ModelIO.AssetLoader}
2020-10-13 18:31:36.989404+0300 Studia3D Viewer[1452:348332] connection to com.apple.ModelIO.AssetLoader was interrupted
2020-10-13 18:31:36.997352+0300 Studia3D Viewer[1452:347676] Не удалось установить связь с приложением-помощником.
The same thing happens with local files
No solution yet
I am using zeppelin from the last 3 months and noticed this strange problem recently. Everyday morning I had to restart zeppelin for it to work or else the paragraph execution will go to pending state and never run. I tried to dig deeper to check what is the problem. The state of the zeppelin application in yarn is finshed. I tried to check the log and it shows the below error. Couldn't make out anything out of it.
2017-06-28 22:04:08,986 INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.monitor.ContainersMonitorImpl: Memory usage of ProcessTree 56876 for container-id container_1498627544571_0001_01_000002: 1.2 GB of 4 GB physical memory used; 4.0 GB of 20 GB virtual memory used
2017-06-28 22:04:08,995 INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.monitor.ContainersMonitorImpl: Memory usage of ProcessTree 56787 for container-id container_1498627544571_0001_01_000001: 330.2 MB of 1 GB physical memory used; 1.4 GB of 5 GB virtual memory used
2017-06-28 22:04:09,964 WARN org.apache.hadoop.yarn.server.nodemanager.DefaultContainerExecutor: Exit code from container container_1498627544571_0001_01_000002 is : 1
2017-06-28 22:04:09,965 WARN org.apache.hadoop.yarn.server.nodemanager.DefaultContainerExecutor: Exception from container-launch with container ID: container_1498627544571_0001_01_000002 and exit code: 1
ExitCodeException exitCode=1:
at org.apache.hadoop.util.Shell.runCommand(Shell.java:545)
at org.apache.hadoop.util.Shell.run(Shell.java:456)
at org.apache.hadoop.util.Shell$ShellCommandExecutor.execute(Shell.java:722)
at org.apache.hadoop.yarn.server.nodemanager.DefaultContainerExecutor.launchContainer(DefaultContainerExecutor.java:211)
at org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.ContainerLaunch.call(ContainerLaunch.java:302)
at org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.ContainerLaunch.call(ContainerLaunch.java:82)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
2017-06-28 22:04:09,972 INFO org.apache.hadoop.yarn.server.nodemanager.ContainerExecutor: Exception from container-launch.
2017-06-28 22:04:09,972 INFO org.apache.hadoop.yarn.server.nodemanager.ContainerExecutor: Container id: container_1498627544571_0001_01_000002
2017-06-28 22:04:09,972 INFO org.apache.hadoop.yarn.server.nodemanager.ContainerExecutor: Exit code: 1
I am the only user in that environment and no one else is using it. There isn't any process running at that time as well. Couldn't understand why it is happening.
I'm trying to figure out why an WPF-app won't exit imediately on closing it. Using Process Explorer I hade found out that WerFault.exe is started while exiting which seem to indicate that something crashes during the teardown, perhaps some destructor or dispose that fails. This started happening when I recently switched to VS2015. I am running Windows 8.
My question is: How can I find out what the real problem is? Any way of finding a crash log for WerFault.exe? I have hundreds of destructors and dispose-methods so it's a bit hard to put breakpoints in all of them. Any other way of capturing these kinds of errors in VS?
The exit code is -1073740791 which "indicate a bug in the executed software that causes stack overflow, leading to abnormal termination of the software". But where?
Some more info from the event log:
Faulting module name: ucrtbase.DLL, version: 10.0.10240.16390, time stamp: 0x55a5b718
Exception code: 0xc0000409
Fault offset: 0x0000000000065a4e
You could try enabling user mode dumps:
Create the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
Within LocalDumps, create a key that is the name of your executable
Within the key you just created, set the values of DumpFolder, DumpCount, DumpType, and CustomDumpFlags as needed (you should definitely set DumpType to 2 for full dumps, otherwise I don't think that enough information will be captured to debug a managed dump).
Once you have done this, whenever your executable crashes a dump file will be created in the folder specified by DumpFolder (or %LOCALAPPDATA%\CrashDumps by default).
I tried to get PHP4 working on WampServer, but whenever I started WampServer, the icon would go to orange but not all the way to green, because Apache wasn't starting.
I've explained how I got it working below. Hopefully this helps someone.
Here's how I got it working:
Install PHP 4.4.9 from http://www.wampserver.com/en/#addons-php
Install Apache 2.0.63 from http://www.wampserver.com/en/#addons-apache
Left click the WampServer tray icon, then Apache→Version→2.0.63, wait a minute, then PHP→Version→4.4.9
Test Apache by opening the command line and running C:\wamp\bin\apache\Apache2.0.63\bin\apache.exe. Fix any error reported, and repeat until you don't get any errors.
Icon→Apache→Service→Install Service
Icon→Restart All Services
In my case, the Apache errors were:
Syntax error on line 22 of C:/wamp/alias/phpmyadmin.conf: The specified IP address is invalid.
Syntax error on line 22 of C:/wamp/alias/sqlbuddy.conf: The specified IP address is invalid.
Syntax error on line 22 of C:/wamp/alias/webgrind.conf: The specified IP address is invalid.
The lines with errors were all the same: Allow from ::1. I commented them out to #Allow from ::1, which seemed to fix the error.
If you have trouble switching back to php5:
Open C:\Wamp\bin\php\php5.4.16\wampserver.conf.
Add the following lines:
$phpConf['apache']['2.4']['LoadModuleName'] = 'php5_module';
$phpConf['apache']['2.4']['LoadModuleFile'] = 'php5apache2_4.dll';
$phpConf['apache']['2.4']['AddModule'] = '';
Exit WampServer then start it again.