Here is the code. It will run just fine with Debian 8.6 or OmniOS. It
will fail on the LX zone with Debian. The only way for it to fail is for
the stat call to fail and this seems to happen because the system doen't
know what directory it is in. The files being looked at are static so not
a
Could you provide some of your telemetry and background here? There might be a
reasonable explanation, or a quick fix.
/dale
> On Jan 13, 2017, at 3:12 PM, Mini Trader wrote:
>
> I have a small program that will reproduce the issue. Where should the bug
> be sent?
I have a small program that will reproduce the issue. Where should the bug
be sent? It's pretty serious. The system is forgetting the location of
the current working directory in a recursive call.
On Fri, Jan 13, 2017 at 9:30 AM, Nahum Shalman wrote:
> Have you tried
1.) I'm interested in the dump (even with no cycles to deeply inspect it
currently).
2.) You should upgrade to 020 anyway, there were very few changes in SCSI and
iSCSI (it's likely the bug is in iSCSI, not scsi_vhci... iSCSI probably
prematurely freed or something-else an object that
Have you tried simply tracing the lx-syscall probes?
On Fri, Jan 13, 2017 at 9:24 AM, Mini Trader
wrote:
> I followed these instructions prior to my post and my zone would not boot
> after doing the mod to add the flag to the file.
>
>
> On Fri, Jan 13, 2017 at 8:55 AM
I followed these instructions prior to my post and my zone would not boot
after doing the mod to add the flag to the file.
On Fri, Jan 13, 2017 at 8:55 AM Nahum Shalman wrote:
> The short answer is yes.
>
> My experience debugging LX was on SmartOS and there are some notes
The short answer is yes.
My experience debugging LX was on SmartOS and there are some notes on
https://wiki.smartos.org/display/DOC/LX+Branded+Zones#LXBrandedZones-Debugging
Some of the details on that page are Specific to SmartOS, but some of it is
generic to LX.
-Nahum
On Fri, Jan 13, 2017