I'm trying to run a background process.
my idea is, execute a command in php which in turn run the console Yii2.
$result = exec('php yii controller/action param param > result.log &');
In Localhost everything works great, but the server does not work :(
shows me the message: "Unable to verify the data sent", this should not make sense since it is running from the console.
When I run the command directly from the console, everything is going well, but when the command is launched at runtime does not work.
Friends, thank you very much collaboration.
"This was translated from Spanish"
Related
I have tried to implement - https://github.com/Autodesk-Forge/forge-bim360-data.connector.dashboard
I have updated this part - npm install set FORGE_CLIENT_ID=<<YOUR CLIENT ID FROM DEVELOPER PORTAL>> set FORGE_CLIENT_SECRET=<<YOUR CLIENT SECRET>> set FORGE_CALLBACK_URL=<<your callback url of Forge e.g. http://localhost:3000/oauth/callback>> set DC_CALLBACK_URL=<<"your ngrok address here: e.g. http://abcd1234.ngrok.io/job/callback">>
I am getting the error that 400-Unknown or invalid client_id
Firstly, I rarely used Windows OS now. I simply copied the guideline of setting environment variables from other samples, while most time, I tried with debug mode (setting environment variables in launch.json) .
checking the Readme again, I found the wording is:
Windows (use Node.js command line from Start menu)
i.e. it asks to input those commands to command line of Node.js, instead of terminal of VSCode! That is why it always reports the error of client id is not defined because the variables are not set to environment at all.
The correct way is to open the command line of Node.js, and run the commands. This is a screenshot.
Im trying to test out this demo on my own windows machine: https://github.com/Autodesk-Forge/forge-bim360-clashissue
Ive successfully started had the template running with these commands.
npm install
set FORGE_CLIENT_ID=<<YOUR CLIENT ID FROM DEVELOPER PORTAL>>
set FORGE_CLIENT_SECRET=<<YOUR CLIENT SECRET>>
set FORGE_CALLBACK_URL=<<YOUR CALLBACK URL>>
npm run nodemon
Ive added a new app within the Forge My Apps interface.
Ive added the provisions for the the BIM 360 Account interface.
I can connect to my localhost, and when i press ALLOW to try to authenticate and login to the autodesk account, i get redirected to the following website with the following error:
http://localhost:3000/api/forge/oauth/callback?code=TOAq...
Cannot GET /api/forge/oauth/callback
How can i get past this error?
It looks like a configuration mismatch. You have configured the callback to be http://localhost:3000/api/forge/oauth/callback but according to https://github.com/Autodesk-Forge/forge-bim360-clashissue/blob/master/server/endpoints/oauth.endpoints.js#L72 your server actually expects the callback on a different URL: http://localhost:3000/api/forge/callback/oauth.
I have a PowerShell script that sends an email via SMTP. The script runs fine inside Powershell ISE, but fails in Task Scheduler. I am on Windows Server 2012. I have other Powershell scripts that I run on this server using the exact same setup, but those scripts do not send an email. The return code I see in Task Scheduler is (0xFFFD0000) and I cannot find any information on this. I have the task set to run with highest privileges and I have checked that the executionpolicy is RemoteSigned. Anybody run into this before?
Here is the command in the task:
powershell -f "c:\scripts\EmailTest.ps1"
Here is the script:
$EmailFrom = "user#domain.com"
$EmailTo = "someone#somewhere.com"
$Subject = "Email Subject"
$Body = #"
Person,
Some message here
Thanks,
User
"#
$SMTPServer = "smtp.domain.com"
$SMTPClient = New-Object Net.Mail.SmtpClient($SmtpServer, 25)
$SMTPClient.Credentials = New-Object System.Net.NetworkCredential("user#domain.com", "password");
$SMTPClient.Send($EmailFrom, $EmailTo, $Subject, $Body)
Update:
I was able to resolve the issue. Apparently I had an additional line in the script that was commented out. I'm not sure why this would cause an error but once I removed that commented out line it ran fine in Task Scheduler. the comment looked like this and was just below the other $EmailTo declaration in the above script:
#$EmailTo = "someone#somewhere.com"
I found another possible issue while looking at a similar problem. I was unable to execute a PowerShell script as a Task Scheduler action, even though the script ran correctly when logged into Windows as the target user and running within PowerShell.
Task Scheduler would consistently display the 0xFFFD0000 error when I nominated the script in the task's action arguments using what I believed to be normal PowerShell quoting rules:
-ExecutionPolicy Bypass -File 'D:\full path\to\script.ps1'
PowerShell acquiesced and Task Scheduler fired off the task immediately and without issue when I changed the quotes I used from single to double:
-ExecutionPolicy Bypass -File "D:\full path\to\script.ps1"
Dropping to a command prompt and executing the full command immediately revealed the problem:
D:\>C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -File 'D:\full path\to\script.ps1'
Processing -File ''D:\full path\to' failed: The given path's format is not supported. Specify a valid path for the -File parameter.
Notice the strange use of two single quotes before the path and one single quote after.
The moral of the story: When feeding the full path of a script to PowerShell as a command line parameter, use double quotes!
I was receiving the same error and ultimately I had a different issue - the optional start in directory setting wasn't applied.
Essentially, I was running a .bat file - c:\tasks\process.bat
This .bat file referenced multiple ps1 scripts that were in the tasks directory and the references were just by file name (not the full directory). On the action tab in task scheduler, there is a Start in (optional) field that I had not populated. Setting it to c:\tasks allowed the references to function properly.
First of all you have to check "ExecutionPolicy" configured on your machine. to do so, check default values by following this link https://technet.microsoft.com/en-us/library/hh847748.aspx
I fixed my probleme by using this command:
On "Add arguments" option I put:
"-Executionpolicy Bypass -command "& 'T:\deleteOldMessages.ps1' "
and
I am using wshsell to call icacls to change a folder's permission. And it returns the following error:
C:\Windows\System32\icacls.exe C:\test\test1 /T /grant:r
IFC\ailen123staff-002:R
Successfully processed 0 files; Failed processing 1 files
C:\test\test1: The handle is invalid.
This same command works if i put it in DOS prompt to run it. But it fails on my asp script. I gave anonymous user as Administrator and it still fails. Any idea?
It used to work , but it suddenly stop working.
I figure it out. It was the application pool user. I changed the application pool user to administrator and the problem goes away.
I have a webapp that segfaults when the database in restarted and it tries to use the old connections. Running it under gdb --args apache -X leads to the following output:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1212868928 (LWP 16098)]
0xb7471c20 in mysql_send_query () from /usr/lib/libmysqlclient.so.15
I've checked that the drivers and database are all up to date (DBD::mysql 4.0008, MySQL 5.0.32-Debian_7etch6-log).
Annoyingly I can't reproduce this with a trivial script:
use DBI;
use Test::More tests => 2;
my $dbh = DBI->connect( "dbi:mysql:test", 'root' );
sub test_db {
my ($number) = $dbh->selectrow_array("select 1 ");
return $number;
}
is test_db, 1, "connected to db";
warn "restart db now";
getc;
is test_db, 1, "connected to db";
Which gives the following:
ok 1 - connected to db
restart db now at dbd-mysql-test.pl line 23.
DBD::mysql::db selectrow_array failed: MySQL server has gone away at dbd-mysql-test.pl line 17.
not ok 2 - connected to db
# Failed test 'connected to db'
# at dbd-mysql-test.pl line 26.
# got: undef
# expected: '1'
This behaves correctly, telling me why the request failed.
What stumps me is that it is segfaulting, which it shouldn't do. As it only appears to happen when the whole app is running (which uses DBIx::Class) it is hard to reduce it to a test case.
Where should I start to look to debug this? Has anyone else seen this?
UPDATE: further prodding showed that it being under mod_perl was a red herring. Having reduced it to a simple test script I've now posted to the DBI mailing list. Thanks for your answers.
What this probably means is that there's a difference between your mod_perl environment and the one you were testing via your script. Some things to check:
Was your mod_perl compiled with the same version of Perl
Are the #INC's the same for both
Are you using threads in your mod_perl setup? I don't believe DBD::mysql is completely thread-safe.
I've seen this problem, but I'm not sure it had the same cause as yours. Are you by chance using a certain module for sending mails (forgot the name, sorry) from your application? When we had the problem in a project, after days of debugging we found that this mail module was doing strange things with open file descriptors, then forked off another process which called the console tool sendmail, which again did strange things with file descriptors. I guess one of the file descriptors it messed around with was the connection to the database, but I'm still not sure about that. The problem disappeared when we switched to another module for sending mails. Maybe it's worth a look for you too.
If you're getting a segfault, do you have a core file greated? If not, check ulimit -c. If that returns 0, your system won't create core files and you'll have to change that. If you do have a core file, you can use gdb or similar tools to debug it. It's not particularly fun, but it's possible. The start of the command will look something like:
gbd /usr/bin/httpd core
There are plenty of tutorials for debugging core files scattered about the Web.
Update: Just found a reference for ensuring you get core dumps from mod_perl. That should help.
This is a known problem in old DBD::mysql. Upgrade it (4.008 is not up to date).
There's a simple test script attached to https://rt.cpan.org/Public/Bug/Display.html?id=37027
that will trigger this bug.