> On Jan 16, 2017, at 5:01 PM, Mini Trader wrote:
>
> We definitely need:
>
> https://smartos.org/bugview/OS-5167 (and probably whatever was done before
> it).
Joyent mentioned that very bug to me earlier this afternoon. During the
bringup of LX zones, I didn't cherrypick it from illumos-jo
There are a 6 changes that have not been up streamed from:
https://github.com/joyent/illumos-joyent/commits/master/usr/src/uts/common/fs/lookup.c
We definitely need:
https://smartos.org/bugview/OS-5167 (and probably whatever was done before
it).
On Mon, Jan 16, 2017 at 3:42 PM, Jaakko Linnosaar
> On 16 Jan 2017, at 17.40, Mini Trader wrote:
>
> I used the following dtrace to get insight into what was happening (ran it
> from global zone).
>
> dtrace -n 'fbt:genunix:vnodetopath_common:entry /pid == $target/ {
> printf("%s\n",stringof(args[1]->v_path)) }' -q -x strsize=4k -p 22482
>
That is correct I am on 151020 just moved up from LTS for this feature.
Just to be clear about one thing.
If you run this on a regular directory in the LX zone there is no issue. It
only takes place if the directory being read is from the LOFS mount of a
ZFS dataset. My mount has a property of re
Thank you. I've discussed with Joyent, and they couldn't reproduce it. They
have a fix we don't, so between that and whether or not it's fixed on bloody
(you're on r151020, right mini?), I'll have to try it myself. It's possible
the Joyent fix (outside LX, not yet upstreamed) may cure what ai
1. Does not happen on native.
2. My non-global zones are under /tank/zones/
3. It uses python - but the calls are all stdlib calls, no magic they are
going directly to C. You can reproduce with same calls on C the system
will eventually return ENOENT/ERRNO=2.
4. Looks to be LX specific. I also te
Thank you for doing this! Some questions in-line:
> On Jan 16, 2017, at 10:40 AM, Mini Trader wrote:
>
> I spent a bit of time yesterday using dtrace and looking at the source. I
> believe I found why the system is falsely reporting that the current
> directory does not exist and have create
> On Jan 16, 2017, at 6:33 AM, Peter Tribble wrote:
>
> (Dan - any chance of removing the include-fixed files from the package?)
I'm afraid to touch these because doing so sometimes breaks other software
installs.
NOTE: that as of r151016 we're on gcc51, and that is what'll be shipping with
> On Jan 15, 2017, at 2:21 PM, Mini Trader wrote:
>
> Here is the strace. Which shows the underlying libc call failing. chdir
> would have failed if the directory was not there. Maybe a race condition
> going on here? Does this now become a Linux bug?
>
> I've even made a call to pwd in t
> On Jan 15, 2017, at 7:05 AM, Matjaž M wrote:
>
> Thank you!
Thank YOU for reminding me to push it back:
https://github.com/omniti-labs/illumos-omnios/commit/827e9d7a912650928136d0f1748b34df7edbcfe8
It'll hit the repos this week with a large update (say goodbye to Python2.6) of
blo
I spent a bit of time yesterday using dtrace and looking at the source. I
believe I found why the system is falsely reporting that the current
directory does not exist and have created a simple program to reproduce the
problem. The problem seems to be related to when v_path in the vnode
struct go
On Mon, Jan 16, 2017 at 8:17 AM, Rouven WEILER
wrote:
> Hi all,
>
> I want to compile something with gcc48 package in the omnios pkg repo.
> Therefore it is necessary to use the PTHREAD_STACK_MIN type which is
> defined in the system's .
> The problem: gcc uses it's own one which does not include
Hi all,
I want to compile something with gcc48 package in the omnios pkg repo.
Therefore it is necessary to use the PTHREAD_STACK_MIN type which is defined in the system's .
The problem: gcc uses it's own one which does not include this type.
Can anybody help me how to get that working?
13 matches
Mail list logo
