View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002062||Xdebug||Documentation||public||2022-02-17 12:06||2022-07-20 15:49|
|Platform||Linux||OS||Ubuntu||OS Version||21.10 (impish)|
|Fixed in Version||3.2.0alpha1|
|Summary||0002062: Profiler can't able to write cachegrind file at /tmp|
The reason is the system unit is set to true for the config PrivateTmp which results in profile cachegrind file not generated and no error at all in xdebug.log which leads to confusion. I know this is not controlled by xdebug shared object binary. What I'm planned to suggest is adding a hint or few lines about PrivateTmp may be the reason even you set mode bits to 1777 for /tmp directory but the profiler not writing the cachegrind therefore change the output directory to somewhere where you can provide write permission to apache user.
For further reading about PrivateTmp:
|Tags||No tags attached.|
If the system is configured with PrivateTmp, then when Xdebug writes to "/tmp", it is actually redirected to the configured PrivateTmp directory. Because it can write there, you won't get any warnings. Unfortunately when I checked in the past to see how I can find that PrivateTmp is enabled, I found no way to do so. Otherwise I would have added such a warning already.
However, I don't think the issue here is "Profiler can't write cachegrind file", but rather that it shows up in a directory that you didn't expect. Can you confirm that?
Yes, you're correct. I expected it have to be at "/tmp" but found the cachegrind file at private temp directory like "/tmp//systemd-private-6ff598b83ece420295c55c310ace4e20-apache2.service-a8yDRu/tmp/cachegrind.out.31644". But when I invoke the function "xdebug_info()" it shows the wrong path as in the attached image. So adding extra information about this would be helpful.
I agree, but so far I have not yet found a way on how to detect this, and give you the right file name there. From the PHP process (and hence Xdebug's) point of view, the file is written to /tmp, it's just that the OS sneakily has changed what /tmp meant to some private tmp directory.
I've made a PR to warn when/if this happens:
Fixed for Xdebug 3.2.0 (coming out in a few months). Please try GitHub's latest from the master branch, if you want to try it out!
Thanks for your help and the clarification. Will try Xdebug 3.2.0 sooner.
|2022-02-17 12:06||vijayan||New Issue|
|2022-02-21 10:05||derick||Assigned To||=> derick|
|2022-02-21 10:05||derick||Status||new => feedback|
|2022-02-21 10:05||derick||Note Added: 0006204|
|2022-02-21 12:14||vijayan||Note Added: 0006207|
|2022-02-21 12:14||vijayan||File Added: Screenshot from 2022-02-21 17-41-07.png|
|2022-02-21 12:14||vijayan||Status||feedback => assigned|
|2022-03-02 13:54||derick||Note Added: 0006224|
|2022-03-02 14:11||derick||Status||assigned => confirmed|
|2022-03-04 11:07||derick||Status||confirmed => assigned|
|2022-03-04 11:07||derick||Note Added: 0006227|
|2022-03-04 14:15||derick||Status||assigned => closed|
|2022-03-04 14:15||derick||Resolution||open => fixed|
|2022-03-04 14:15||derick||Fixed in Version||=> 3.2dev|
|2022-03-04 14:15||derick||Note Added: 0006228|
|2022-03-04 14:35||vijayan||Note Added: 0006229|
|2022-07-20 15:49||derick||Fixed in Version||3.2dev => 3.2.0alpha1|