I'm using symfony 4, What does error stands for ?
Warning: SessionHandler::read(): open(/var/lib/php/sessions/sess_634q91mh896b6aa4jpjvlihmar, O_RDWR) failed: Permission denied (13)
When a user logs into a Symfony application, session information is stored on the web server. By default Symfony uses the native PHP session mechanism, storing session info in a file in /var/lib/php/sessions/ on Linux systems. Your error message is output by PHP and means it got a permissions error creating or re-opening a session file.
The error appears only intermittently because PHP removes old session files randomly about every 1/100th or 1/1000th page load. (On some Linux variants, old session files are removed by a cron job instead.)
https://symfony.com/doc/current/session.html says:
"some session expiration related options may not work as expected if other applications that write to the same directory have short max lifetime settings."
Try to avoid having multiple processes writing to the same sessions directory. I think I got the error message because both an Apache web server and php bin/console server:start were running at the same time. One process may have removed the other process's session file.
See PHP manual and Symfony manual for how to configure writing to separate directories. For example, I changed {Symfony directory}/config/packages/framework.yaml:
# Enables session support. Note that the session will ONLY be started if you read or write from it.
# Remove or comment this section to explicitly disable session support.
session:
# handler_id: ~
cookie_secure: auto
cookie_samesite: lax
handler_id: 'session.handler.native_file'
save_path: '%kernel.project_dir%/var/sessions/%kernel.environment%'
gc_probability: 100 # Run garbage collection always for
gc_divisor: 100 # investigating this problem only.
Another possibility is a problem in your Symfony code can cause the error message. The Symfony documentation says not to call the PHP session functions like session_start() directly since Symfony classes call them. A bug in my code caused an exception which I speculate caused the error message.
Related stack overflow questions: cleanup-php-session-files and how-does-php-know-when-to-delete-a-session
For those familiar with C code, see the PHP interpreter source code line that prints the error here
Hope this helps!
Not related to symfony 4, but you have to fix permissions in your /var/lib/php/sessions/ directory
Related
I am trying to establish an event subscription via zmq from my locally running sawtooth network. As soon as I start my event-subscriber container, I get the error "interrupted system call".
I am following the example from here https://github.com/danintel/sawtooth-cookiejar/tree/master/events/go
I have tried using validatorUrl as tcp://localhost:4004 tcp://validator-0:4004
note: validator-0 is my local container name for the validator
Also, have tried with the direct IP of the validator container tcp://<IP>:4004
zmqConnection.RecvMsgWithId() is throwing the error.
The error I am getting is exactly at this line https://github.com/danintel/sawtooth-cookiejar/blob/master/events/go/src/events_client.go#L105
Can someone please help for the probable reasons or the way I can debug this one?
I do not know, but one possible cause is this example was recently updated to a new version of Go, 1.11 (from 1.9) after your posting:
https://github.com/danintel/sawtooth-cookiejar/pull/9
Because of this error:
Loading input failed: unsupported version of go: exit status 2: flag provided but not defined: -compiled
The issue was related to inter-pod communication. So the issue was, my event subscriber client was in a completely different pod than the pod where the validator container was running. In that case, we need to used the FQDN of that pod. Refer to the link below.
https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-s-hostname-and-subdomain-fields
I am using google mod_pagespeed in Magento 1.9 and I have found what appears to be a very large collection of cache data from mod_pagespeed for this site found under:
/var/cache/mod_pagespeed/v3/
/var/cache/mod_pagespeed/v3/ - has some 14million inodes and due to that I am getting this Error message
E_WARNING: Unknown: Failed to write session data (files). Please
verify that the current setting of session.save_path is correct
(/var/lib/php/session).
Is it safe to delete these inodes?
My Windows Store app keeps getting rejected from certification testing and I managed to reproduce a consequent crash when running appverif's LuaPriv-check. I get this output though:
AVRF: failed to create verifier log file \??\C:\Users\xx\AppVerifierLogs\yy.exe.0.dat (status C0000022)
Process Monitor tells me yy.exe got ACCESS DENIED on a CreateFile operation in this folder. I have set full access to all users (the user reported in the log was the same as the owner of the folder). I am running Visual Studio and Application Verifier as Administrator, but this does not seem to apply. What is the correct way of giving user xx full access to this folder on win8? I have attempted to use different log folders for appverify but with no success. Anyone else able to use this tool with Store-apps?
This post describes similar issues. Attempting to run AppVerif –sppath C:\MyLogsLocation as in the suggested workaround gives AVRF: Error: Incorrect image name: <
So does running appverif -enable handles locks -for myapp.exe -sppath c:\MyLogsLocation
It might be a bug in app verifier.
Have a look at these links:
http://social.technet.microsoft.com/Forums/en-US/5ed560c0-76af-401d-8150-8cd1e69d0b8a/why-app-verifier-can-not-create-log-file?forum=windowssdk
http://blogs.msdn.com/b/dougste/archive/2010/01/11/generating-application-verifier-logs-for-web-applications.aspx
0xc000022 is STATUS_ACCESS_DENIED. The process doesn't actually have write permissions, even if it looks like it should. This MSDN blog explains there is a bug in App Verifier so even if you specify -sppath the value won't be honoured unless you first delete the %WINDIR%\system32\config\AppVerifierLogs\ folder.
API Store is throwing errors when I try to create or edit an application
java.sql.SQLException: Can't call commit when autocommit=true
I've added the setting of
init-command='set autocommit=0'
to the my.cnf file
I've also added the flag:
?relaxAutoCommit=true
to the connection string but to no avail. I continue to get this error.
I am using the same mysql database for both the WSO2_CARBON_DB and teh WSO2AM_DB plus I have a single publisher node and two separate store nodes all pointing to the same mysql datasource.
I notice the application edit is saved (or the new application is created) but the exception is still thrown in the console and an error message appears in the user interface (as per the error at the top of this question).
Is there some other setting, within the WSO2 conf files that I have to tweak in order to get this to work properly?
Add both autoReconnect and relaxAutoCommit flags to the jdbc url of your defined "WSO2AM_DB" datasource in master-datasources.xml file. This will resolve your issue.
<configuration>
<url>jdbc:mysql://localhost:3306/AM_DB?autoReconnect=true&relaxAutoCommit=true</url>
<username>xxxx</username>
<;password>xxxxx</password>
EDIT: I updated the url to reflect the correct syntax for escaping the ampersand.
just for the sake of completeness, the JDBC URL shoud be
jdbc:mysql://localhost:3306/WSO2CARBON_DB?autoReconnect=true&relaxAutoCommit=true
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.