The server is Linux and running lighttpd
The test code in "C" is like below (test.c)
#include <stdio.h>
int main ()
{
printf ("Welcome to CGI");
return 0;
}
I compiled the code to generate CGI like below
gcc test.c -o test.cgi
I put the generate test.cgi file in web/cgi-bin/ folder and it showing following error while accessing it fron browser /cgi-bin/test.cgi
500 Internal Server Error
The log file consists of
2021-01-04 04:56:32: (../../lighttpd-1.4.53/src/response.c.628) Path : /filesys/web/cgi-bin/test.cgi
2021-01-04 04:56:32: (../../lighttpd-1.4.53/src/response.c.652) -- logical -> physical
2021-01-04 04:56:32: (../../lighttpd-1.4.53/src/response.c.653) Doc-Root : /filesys/web/
2021-01-04 04:56:32: (../../lighttpd-1.4.53/src/response.c.654) Basedir : /filesys/web/
2021-01-04 04:56:32: (../../lighttpd-1.4.53/src/response.c.655) Rel-Path : /cgi-bin/test.cgi
2021-01-04 04:56:32: (../../lighttpd-1.4.53/src/response.c.656) Path : /filesys/web/cgi-bin/test.cgi
2021-01-04 04:56:32: (../../lighttpd-1.4.53/src/response.c.668) -- handling physical path
2021-01-04 04:56:32: (../../lighttpd-1.4.53/src/response.c.669) Path : /filesys/web/cgi-bin/test.cgi
2021-01-04 04:56:32: (../../lighttpd-1.4.53/src/response.c.676) -- handling subrequest
2021-01-04 04:56:32: (../../lighttpd-1.4.53/src/response.c.677) Path : /filesys/web/cgi-bin/test.cgi
2021-01-04 04:56:32: (../../lighttpd-1.4.53/src/response.c.678) URI : /cgi-bin/test.cgi
2021-01-04 04:56:32: (../../lighttpd-1.4.53/src/response.c.679) Pathinfo :
2021-01-04 04:56:32: (../../lighttpd-1.4.53/src/mod_access.c.177) -- mod_access_uri_handler called
As noted by #basile-starynkevitch, your program output is not compliant with the (very simple) CGI protocol. However, lighttpd will still handle that.
You did not share your lighttpd.conf (lighttpd -f /etc/lighttpd/lighttpd.conf -p), so I am guessing that you did not properly configure lighttpd mod_cgi to handle the request.
The user account under which the web server is running should have filesystem access to the path and files wherever your web/cgi-bin/ is located.
If this has never worked for you, then also check to see if SELinux is blocking the CGI execution.
I got it resolved, so posting the solution.
Basically, there is cross-compilation issue to execute in the target embedded device which was not compatible with GCC.
Related
HelloW!
When I went to upgrade moodle 3.10 to 3.11 and later 4.x.
I got a problem, after installing all the plugins that weren't on disk, and others that weren't found.
When proceeding, I had this image error.
Error Image Print
I use moodle in PT-BR, this is an error log:
Atualizando para nova versão
Importação de idioma: pt_br_old
Impossível achar componente
Outras informações sobre este erro
Informações de depuração: pt_br_old
Error code: cannotfindcomponent×Ignorar essa notificação
Rastreamento de pilha:
line 810 of /lib/componentlib.class.php: lang_installer_exception thrown
line 665 of /lib/componentlib.class.php: call to lang_installer->install_language_pack()
line 45 of /admin/tool/langimport/lib.php: call to lang_installer->run()
line 1741 of /lib/upgradelib.php: call to tool_langimport_preupgrade_update()
line 1856 of /lib/upgradelib.php: call to upgrade_language_pack()
line 519 of /admin/index.php: call to upgrade_core()
log in english:
Updating to new version
Language import: pt_br_old
Impossible to find component
Other information about this error
Debug info: pt_br_old
Error code: cannotfindcomponent×Ignore this notification
Stack tracking:
line 810 of /lib/componentlib.class.php: lang_installer_exception thrown
line 665 of /lib/componentlib.class.php: call to lang_installer->install_language_pack()
line 45 of /admin/tool/langimport/lib.php: call to lang_installer->run()
line 1741 of /lib/upgradelib.php: call to tool_langimport_preupgrade_update()
line 1856 of /lib/upgradelib.php: call to upgrade_language_pack()
line 519 of /admin/index.php: call to upgrade_core()
I installed all the missing plugins on the disk given in the update.
I downloaded and installed the PT-BR Moodle 3.11 language pack in the lang folder and also cleared the cache of the folders inside moodledata in my case it has another name. But i don't delete lang folder in moodledata and exist content in this folder.
path moodledata: /var/AnotherName
I updated the system, ubuntu, entered the permissions in the folder again and nothing worked until now.
I kept the config.php from the old moodle as recommended. The only warning I got in the update was about input_vars below 5000, and about the database not being in exact moodle format. But it was just warnings.
We had some 12 agents (vsts-agent-linux-x64-2.188.4) running on one Az VM (Ubuntu 20.04.2 LTS) as processes (./config.sh && screen ./run.sh). All was well..
I had to run some command related to /tmp folder but it kept showing busy and we suspected that our Agents might be using /tmp. Unfortunately instead of any other clean way of stopping the agents, we killed all processes on this VM manually, including the agents'.
After the /tmp related command ran successfully, I tried running screen ./run.sh from one of the agent directories. And I got an error:
Failed to create CoreCLR, HRESULT: 0x80004005
I also had tried :
.agent2/run.sh and I got the error :
ldd: ./bin/libcoreclr.so: No such file or directory
ldd: ./bin/System.Security.Cryptography.Native.OpenSsl.so: No such file or directory
ldd: ./bin/System.IO.Compression.Native.so: No such file or directory
ldd: ./bin/System.Net.Http.Native.so: No such file or directory
Failed to create CoreCLR, HRESULT: 0x80004005
I even downloaded a new .tar for the agent and ran a fresh ./config . But I get the same error on ./config as well
Is there a solution to this? Please help
export COMPlus_EnableDiagnostics = 0, and then running ./config from the agent directory. worked!
I had this issue when running as the non-privileged user specified in the systemd file but running as root user worked fine.
Finally used:
strace -f -o trace.log /<executable path>/<executable name>
Which led me to:
9183 mknod("/tmp/clr-debug-pipe-9183-8112345738-in", S_IFIFO|0700) = -1 EACCES (Permission denied)
This caused me to compare the /tmp directory between working and non-working boxes.
[<not-working-hostname>]$ ll /
drwxrwxr-x 7 root root 93 Jan 5 21:37 tmp
[<working-hostname>]$ ll /
drwxrwxrwt 7 root root 93 Jan 5 21:59 tmp
(Note the r-x vs rwt)
Fix:
[<hostname>]# chmod 1777 /tmp
I am using the following command in PowerShell to install Truffle's Ganache on my Windows 10 machine:
Add-AppxPackage -Path "C:\Users\mabel\Downloads\Ganache.appx"
Whenever I run that command I get the following error:
Add-AppxPackage : Deployment failed with HRESULT: 0x80073CFD, A Prerequisite for an install could not be satisfied.
Deployment Add operation with target volume C: on Package Ganache_1.0.1.0_x64__zh355ej5cj694 from: (Ganache.appx)
failed with error 0x80073CFD. See http://go.microsoft.com/fwlink/?LinkId=235160 for help diagnosing app deployment
issues.
NOTE: For additional information, look for [ActivityId] 1e4d6f55-8379-0000-3191-4d1e7983d301 in the Event Log or use
the command line Get-AppxLog -ActivityID 1e4d6f55-8379-0000-3191-4d1e7983d301
At line:1 char:1
+ Add-AppxPackage -Path "C:\Users\mabel\Downloads\Ganache.appx"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (C:\Users\mabel\Downloads\Ganache.appx:String) [Add-AppxPackage], Exceptio
n
+ FullyQualifiedErrorId : DeploymentError,Microsoft.Windows.Appx.PackageManager.Commands.AddAppxPackageCommand
I digged a bit deeper for a diagnosis and ran the command Get-AppxLog -ActivityID 1e4d6f55-8379-0000-3191-4d1e7983d301, and got the following log details:
Time ID Message
---- -- -------
1/1/2018 8:13:38 PM 301 The calling process is powershell.exe
1/1/2018 8:13:38 PM 603 Started deployment Add operation on a package with main parameter: Ganache.appx and
Options: 0. See http://go.microsoft.com/fwlink/?LinkId=235160 for help diagnosing app
deployment issues.
1/1/2018 8:13:41 PM 157 The app package signature was validated for core content of the app package published
by CN=Consensys Inc, O=Consensys Inc, L=New York, S=New York, C=US. Payload won't be
validated until the files are read.
1/1/2018 8:13:42 PM 170 The streaming reader was created successfully for app package
Ganache_1.0.1.0_x64__zh355ej5cj694.
1/1/2018 8:13:42 PM 10002 Creating Resiliency File C:\ProgramData\Microsoft\Windows\AppRepository\edc8d325-87ef-
46b9-93c2-cf029ff3f8f4_S-1-5-21-2104190792-3376611798-3824734217-1001_1.rslc for Add
Operation on Package Ganache_1.0.1.0_x64__zh355ej5cj694.
1/1/2018 8:13:42 PM 607 Deployment Add operation on package Ganache_1.0.1.0_x64__zh355ej5cj694 has been
de-queued and is running for user DESKTOP-8NHB92D\mabel.
1/1/2018 8:13:42 PM 613 Adding uri to the list of Uris: file:///C:/Users/mabel/Downloads/Ganache.appx.
1/1/2018 8:13:42 PM 605 The last successful state reached was BundleProcessed. Failure occurred before
reaching the next state Indexed.
1/1/2018 8:13:42 PM 401 Deployment Add operation with target volume C: on Package
Ganache_1.0.1.0_x64__zh355ej5cj694 from: (Ganache.appx) failed with error
0x80073CFD. See http://go.microsoft.com/fwlink/?LinkId=235160 for help diagnosing app
deployment issues.
1/1/2018 8:13:42 PM 404 AppX Deployment operation failed for package Ganache_1.0.1.0_x64__zh355ej5cj694 with
error 0x80073CFD. The specific error text for this failure is: Deployment Add
operation with target volume C: on Package Ganache_1.0.1.0_x64__zh355ej5cj694 from:
(Ganache.appx) failed with error 0x80073CFD. See
http://go.microsoft.com/fwlink/?LinkId=235160 for help diagnosing app deployment
issues.
The windows forum recommended me to make sure Windows is fully updated, the last time I updated it was an hour ago.
From the link in the error it says "A specified install prerequisite couldn't be satisfied." I have all the prerequisites to install and run testrpc/ganache cmd line. Are there any steps I need to take before installing Ganache UI?
I got the same error, because my windows version was not updated.
Open the .appx file as a zip file
In the root is a file: AppxManifest.xml
There is an optional section on prerequisites.
But before that is a dependencies entry with a minimum windows version.
<Dependencies>
<TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.14316.0" MaxVersionTested="10.0.14316.0" />
</Dependencies>
Then I checked in powershell to get my dot version:
PS C:\Users\XXXXX\> [System.Environment]::OSVersion.Version
Major Minor Build Revision
----- ----- ----- --------
10 0 10240 0
14316 > 10240, so my OS is too old.
In case you want an executable file, You will find an executable file here, named ganache-setup-1.3.0.exe
You can download a ganache source and build it by yourself
https://github.com/trufflesuite/ganache
Clone this repo
Run npm install
Run npm start
When I load a crash dump in windbg (x64), version 6.3.9600.16384, and load the sos extension for .net, the first time I run the !threads command I get this error:
c0000005 Exception in C:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos.threads debugger extension.
PC: 00007ffa`8fe6c7e3 VA: 00000000`00000000 R/W: 0 Parameter: 00000000`00000000
Subsequent times the command runs fine. Full transcript:
Loading Dump File [C:\Users\celdredge\AppData\Local\Temp\w3wp (2).DMP]
User Mini Dump File with Full Memory: Only application data is available
************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred srv*
************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred srv*
OK c:\projects\dumps\symbols
Symbol search path is: srv*;c:\projects\dumps\symbols
Executable search path is: srv*
Windows 8 Version 9600 MP (4 procs) Free x64
Product: WinNt, suite: SingleUserTS
Built by: 6.3.9600.16384 (winblue_rtm.130821-1623)
Machine Name:
Debug session time: Tue Dec 17 23:03:00.000 2013 (UTC - 5:00)
System Uptime: 0 days 9:56:04.777
Process Uptime: 0 days 0:01:41.000
................................................................
................................................................
......................................................
ntdll!NtWaitForSingleObject+0xa:
00007ffa`a1d265ba c3 ret
0:000> .loadby sos clr
0:000> !threads
c0000005 Exception in C:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos.threads debugger extension.
PC: 00007ffa`8fe6c7e3 VA: 00000000`00000000 R/W: 0 Parameter: 00000000`00000000
CLR version:
0:000> lm v mclr
start end module name
00007ffa`84450000 00007ffa`84de8000 clr (pdb symbols) C:\ProgramData\dbg\sym\clr.pdb\252574218A084BE3AFEFF8921ADADB6F2\clr.pdb
Loaded symbol image file: clr.dll
Image path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Image name: clr.dll
Browse all global symbols functions data
Timestamp: Tue Sep 10 02:54:48 2013 (522EC238)
CheckSum: 00994334
ImageSize: 00998000
File version: 4.0.30319.34003
Product version: 4.0.30319.34003
SOS version:
0:000> .chain
Extension DLL search Path:
<snip/>
Extension DLL chain:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\SOS.dll: image 4.0.30319.34003, API 1.0.0, built Tue Sep 10 02:44:16 2013
[path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos.dll]
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos: image 4.0.30319.34003, API 1.0.0, built Tue Sep 10 02:44:16 2013
[path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos.dll]
This seems to be a weird issue caused by saving an explicit workspace which remembers which extensions are loaded. If I .loadby sos clr and save the workspace, next time I open the workspace it will have sos loaded twice. However if I do .load c:\path\to\sos.dll and save the workspace, it only gets loaded once when I reopen it.
In summary, workspaces in windbg are confusing.
I am puzzled by the following sequence of commands.
sh-4.2$ pwd
/home/willard
sh-4.2$ ls -l f
-rwxr-xr-x 1 willard users 59116 Jan 23 14:54 f
sh-4.2$ file f
f: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, BuildID[sha1]=0xea0e08ff2b5a062698d45b78177acdd6bf140d1f, stripped
sh-4.2$ ./f
sh: ./f: No such file or directory
sh-4.2$ strace ./f
execve("./f", ["./f"], [/* 32 vars */]) = -1 ENOENT (No such file or directory)
write(2, "strace: exec: No such file or di"..., 40strace: exec: No such file or directory
) = 40
exit_group(1) = ?
+++ exited with 1 +++
sh-4.2$ ls -l f
-rwxr-xr-x 1 willard users 59116 Jan 23 14:54 f
sh-4.2$ uname -a
Linux xdat10 3.6.2-1-ARCH #1 SMP PREEMPT Fri Oct 12 23:58:58 CEST 2012 x86_64 GNU/Linux
How is this possible?
I found someone having the same problem (with relative explanation)
Running 32bit binary on a 64bit system
Quoting the most important sentences:
This situation often arises when you try to run a binary for the right
system (or family of systems) and superarchitecture but the wrong
subarchitecture. Here you have ELF binaries on a system that expects
ELF binaries, so the kernel loads them just fine. They are i386
binaries running on an x86_64 processor, so the instructions make
sense and get the program to the point where it can look for its
loader. But the program is a 32-bit program (as the file output
indicates), looking for the 32-bit loader /lib/ld-linux.so.2, and
you've presumably only installed the 64-bit loader
/lib64/ld-linux-x86-64.so.2 in the chroot.
You need to install the 32-bit runtime system in the chroot: the
loader, and all the libraries the programs need. On Debian amd64, the
32-bit loader is in the libc6-i386 package. You can install a bigger
set of 32-bit libraries by installing ia32-libs.
I bet there's a better way to verify this but i'd try to exec
ldd ./f
and search in the output which loader is needed to exec'it
man 2 execve:
ENOENT The file filename or a script or ELF interpreter does not
exist, or a shared library needed for file or interpreter can‐
not be found.
You could run ldd against this binary to look for libraries that could not be mapped and install them from multilib.