Re: [smartos-discuss] Smartos bhyve support on AMD Sun Fire X4140

[Patrick Mooney]

There's additional porting work which needs to be done before
bhyve-on-SmartOS supports AMD hardware, regardless of its age.  I don't
have any test hardware at the moment, but I'm hoping to acquire some in the
relatively near future.

On 3 July 2018 at 16:46, Fred Liu  wrote:

> Even Ryzen-based ?
>
> Thanks
>
> Fred
>
>
>
>
> On Wed, Jul 4, 2018 at 1:56 AM +0800, "Jorge Schrauwen" <
> sjorge...@blackdot.be> wrote:
>
> Yeah, no support as of yet. Although there does seem to be some interest
>> in adding it eventually. (Based on conversations on IRC)
>>
>> July 3, 2018 6:38 PM, "Ján Poctavek" > >
>> wrote:
>>
>> Hi,
>>
>> Just to be sure - so no AMD support again?
>> Jan
>> On 3. 7. 2018 11:42, Jorge Schrauwen wrote:
>>
>> For now bhyve support on SmartOS requires VMX and EPT to work.
>> So older intel CPU without EPT or AMD CPU that use SVM are not support.
>>
>> Regards
>>
>> Jorge
>>
>> July 3, 2018 11:15 AM, "Paolo Marcheschi" > >
>> wrote:
>>
>> Hi
>>
>> Today I tried to run a bhyve VM on the latest Smartos:
>>
>> SunOS 5.11 joyent_20180629T143106Z i86pc i386 i86pc
>>
>> The server is an AMD Opteron Sun Fire X4140 :
>>
>> psrinfo -vp The physical processor has 6 virtual processors (0-5) x86 
>> (AuthenticAMD 100F80 family 16 model 8 step 0 clock 2200 MHz) Six-Core AMD 
>> Opteron(tm) Processor 2427 [ Socket: F(1207) ] The physical processor has 6 
>> virtual processors (6-11) x86 (AuthenticAMD 100F80 family 16 model 8 step 0 
>> clock 2200 MHz) Six-Core AMD Opteron(tm) Processor 2427 [ Socket: F(1207) ]
>>
>> when I try to create a bhyve VM I get:
>> #vmadm create -f centos.json
>> Bhyve not supported
>> Why ?
>> Thank you
>> Paolo
>>
>>
>>
>>
>>
>> *smartos-discuss* | Archives
>  | Modify
>  Your Subscription
> 
>



---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
Modify Your Subscription: https://www.listbox.com/member/?member_id=25769125
Powered by Listbox: http://www.listbox.com

[smartos-discuss] [FLAG-DAY] OS-6678 need bhyve modules in name_to_major

[Patrick Mooney]

Hi folks,

If you don't build platform images, you can ignore this message.

I just put back OS-6678, in which the bhyve-related kernel modules are
made available.  Those modules themselves are shipped from
'illumos-joyent.git', but the configuration that activates them is
shipped from 'smartos-live.git'.

If you update your "smartos-live.git", you will need to make sure you
are similarly current with "illumos-joyent.git".


Cheers.

-Patrick Mooney


---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

[smartos-discuss] Flag day: illumos-extra build requires py27-sqlite3 and nasm

[Patrick Mooney]

Sent on Hans' behalf:

If you don't build SmartOS platform images, you can skip this message.

The fix for:

https://smartos.org/bugview/OS-6416

requires py27-sqlite3 and nasm on the build system. The configure script in
smartos-live has been updated to install it with this change:

https://smartos.org/bugview/OS-6660

You can either update smartos-live and rerun configure, or install the
package manually with the following command:

# pkgin install py27-sqlite3 nasm


Regards,

Hans Rosenfeld


---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

[smartos-discuss] [minor flag day] OS-6400 and illumos-kvm

[Patrick Mooney]

If you do not build SmartOS from source, you can ignore this message.

The integration of OS-6400 in illumos-joyent and illumos-kvm poses a
minor flag day.  I recommend that both projects/illumos and
projects/local/kvm are updated to #master if you're building
smartos-live.

The KVM change requires the new interface exposed in illumos-joyent.
Conversely, the new illumos-joyent interface is likely to be utilized
for  advisory HVM exclusion in the near future, making the KVM changes
necessary.


With regards,

--
Patrick Mooney


---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

Re: [smartos-discuss] Asterisx on native zone?

[Patrick Mooney]

I ran Asterisk out of pkgsrc in a native zone on SmartOS.  It worked
adequately well for the simple PBX duties I tasked it with.

On 5 May 2017 at 10:03, Humberto Ramirez  wrote:

> Not what you're looking for,  but Mark Slatem has been running FreeSwitch
> on native zones for a long time, take a look:
>
> https://youtu.be/vpGP_d_ED7Y
>
> Asterisk should work...
>
>
>
>
>
> On May 4, 2017 9:07 PM, "Rob Seastrom"  wrote:
>
>> 
>> Haven't seen anyone here ask about Asterisk in a couple of years.
>> 
>> Our situation is that we're running a very long in the tooth release of
>> Astlinux on even more long in the tooth (PC Engines ALIX) hardware...
>> oddly enough that platform is still supported.
>> 
>> Needs are modest.  Only a handful of users.  No DAHDI - it's VoIP in,
>> VoIP out.
>> 
>> I see that the Asterisk release in pkgsrc for native zones is fairly
>> modern *and* is 1.8 branch, which would minimize my pain factor for the
>> migration.
>> 
>> Anyone running Asterisk in a native zone?  An LX zone?  Happy with it?  I
>> want to get rid of the little ALIX boxes.  Worst case I could spin up some
>> KVM zones and just put Astlinux in them, but I feel that's a step in the
>> wrong direction.  Astlinix reputedly works just fine under Proxmox, which
>> is a fancy wrapper around KVM.
>> 
>> Thanks,
>> 
>> -r
>> 
> *smartos-discuss* | Archives
> 
>  |
> Modify
> 
> Your Subscription 
>



---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

[smartos-discuss] Re: SmartOS release-20161124

[Patrick Mooney]

A regression regarding ZFS property reporting was found after the
release last week.  The fix has been backported with a release respin
placed in Manta:

/Joyent_Dev/public/SmartOS/20161129T003638Z

https://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/smartos.html#20161129T003638Z

On 24 November 2016 at 10:50, Patrick Mooney <patrick.moo...@joyent.com> wrote:
> Hello All,
>
> The latest bi-weekly "release" branch build of SmartOS is up:
>
> curl -C - -O
> https://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/smartos-latest.iso
> curl -C - -O
> https://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/smartos-latest-USB.img.bz2
> curl -C - -O
> https://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/smartos-latest.vmwarevm.tar.bz2
>
> A generated changelog is here:
>
> 
> https://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/smartos.html#20161123T215301Z
>
> The full build bits directory, for those interested, is here in Manta:
>
> /Joyent_Dev/public/SmartOS/20161123T215301Z/
>
>
> # General Info
>
> Every second Thursday we roll a "release-MMDD" release branch and
> builds for SmartOS (and Triton DataCenter and Manta, as well).
>
> Cheers,
> Patrick Mooney, on behalf of the SmartOS developers
> https://smartos.org


---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

[smartos-discuss] SmartOS release-20161124

[Patrick Mooney]

Hello All,

The latest bi-weekly "release" branch build of SmartOS is up:

curl -C - -O
https://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/smartos-latest.iso
curl -C - -O
https://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/smartos-latest-USB.img.bz2
curl -C - -O
https://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/smartos-latest.vmwarevm.tar.bz2

A generated changelog is here:


https://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/smartos.html#20161123T215301Z

The full build bits directory, for those interested, is here in Manta:

/Joyent_Dev/public/SmartOS/20161123T215301Z/


# General Info

Every second Thursday we roll a "release-MMDD" release branch and
builds for SmartOS (and Triton DataCenter and Manta, as well).

Cheers,
Patrick Mooney, on behalf of the SmartOS developers
https://smartos.org


---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

Re: [smartos-discuss] SmartOS release-20161110

[Patrick Mooney]

Many do so for development purposes, such as VMware Fusion on a laptop.

-Patrick

On 10 November 2016 at 17:08, Gjermund Gusland Thorsen
 wrote:
> Doesn't it defeat the purpose of ZFS to run SmartOS as a VM in ESXi/VMware?
>
> G
>
> On 11 Nov, 2016, at 0:02, Trent Mick  wrote:
>
> Hello All,
>
> The latest bi-weekly "release" branch build of SmartOS is up:
>
> curl -C - -O
> https://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/smartos-latest.iso
> curl -C - -O
> https://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/smartos-latest-USB.img.bz2
> curl -C - -O
> https://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/smartos-latest.vmwarevm.tar.bz2
>
> A generated changelog is here:
>
>
> https://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/smartos.html#20161110T013148Z
>
> The full build bits directory, for those interested, is here in Manta:
>
> /Joyent_Dev/public/SmartOS/20161110T013148Z
>
>
> # General Info
> 
> Every second Thursday we roll a "release-MMDD" release branch and
> builds for SmartOS (and Triton DataCenter and Manta, as well).
> 
> Cheers,
> Trent, on behalf of the SmartOS developers
> https://smartos.org
> 


---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

Re: [smartos-discuss] SmartOS release-20161027

[Patrick Mooney]

One additional regression, OS-5756
(https://smartos.org/bugview/OS-5756), was found in the release.
Platform images have been re-spun to include the backported fix.

The new changelog is posted here:

https://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/smartos.html#20161101T004406Z

On 1 November 2016 at 00:16, Paul Sture  wrote:
> The latest release I see now is 20161101T004406Z (released 5 hours ago)
>
> Changelog:
>
> https://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/smartos.html#20161101T004406Z
>
> On 1 Nov 2016, at 0:16, Trent Mick wrote:
>
>> All,
>>
>> A new build of SmartOS was done for last Thursday's release to fix:
>> - https://smartos.org/bugview/OS-5750
>> - https://smartos.org/bugview/OS-5748
>>
>> The new changelog is here:
>>
>> https://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/smartos.html#20161027T222644Z
>>
>> Cheers,
>> -- Trent
>>
>> On Thu, Oct 27, 2016 at 11:26 AM, Trent Mick 
>> wrote:
>>
>>> Hello All,
>>>
>>> The latest bi-weekly "release" branch build of SmartOS is up:
>>>
>>> curl -C - -O https://us-east.manta.joyent.c
>>> om/Joyent_Dev/public/SmartOS/smartos-latest.iso
>>> curl -C - -O https://us-east.manta.joyent.c
>>> om/Joyent_Dev/public/SmartOS/smartos-latest-USB.img.bz2
>>> curl -C - -O https://us-east.manta.joyent.c
>>> om/Joyent_Dev/public/SmartOS/smartos-latest.vmwarevm.tar.bz2
>>>
>>> A generated changelog is here:
>>>
>>> https://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/s
>>> martos.html#20161027T005159Z
>>>
>>> The full build bits directory, for those interested, is here in Manta:
>>>
>>> /Joyent_Dev/public/SmartOS/20161027T005159Z
>>>
>>>
>>> # Highlights
>>>
>>> - The secflags work from illumos is part of this release. See the
>>>   security-flags(5) man page for details.
>>>
>>>
>>> # General Info
>>>
>>> Every second Thursday we roll a "release-MMDD" release branch and
>>> builds for SmartOS (and Triton DataCenter and Manta, as well).
>>>
>>> Cheers,
>>> Trent, on behalf of the SmartOS developers
>>> https://smartos.org
>>>
> 
> 


---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

Re: [smartos-discuss] Threads from zlogin

[Patrick Mooney]

When using zlogin, the entire process is moved into the zone.  It will
reside there until it exits, yielding its return value to the caller in the
global zone. (The parent/child relationship is not broken by zone_enter.)

On 7 October 2016 at 16:54, David Preece  wrote:

> Hi,
>
> If I launch a thread into a zone using zlogin, is that thread then
> protected by the zone's mechanisms? Does the thread, at some point, return
> to the global zone? In short, I'm trying to work out the security
> implications of doing this...
>
> Thanks,
>
> Dave
>
>
> *smartos-discuss* | Archives
> 
>  |
> Modify
> 
> Your Subscription 
>
>



---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

Re: [smartos-discuss] build failure related to python version

[Patrick Mooney]

Additional fixes are inbound, pending testing and review.  I would expect
them to land within a few hours.

On 30 September 2016 at 15:01, Youzhong Yang  wrote:

> I am trying to build SmartOS today, pulling illumos-joyent from github.com,
> here is what I encountered:
>
> nightly.log:
> sh: line 1: /root/smartos-live/projects/illumos/usr/src/tools/proto/
> root_i386-nd/opt/onbld/bin/hdrchk: not found
> *** Error code 127
>
> # head -1 /root/smartos-live/projects/illumos/usr/src/tools/proto/
> root_i386-nd/opt/onbld/bin/hdrchk
> #!/opt/local/bin/python2.6
>
> It seems the two OS-5688 commits didn't fix the issue.
>
> Thanks,
>
> --Youzhong
>
> *smartos-discuss* | Archives
> 
>  |
> Modify
> 
> Your Subscription 
>



---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

Re: [smartos-discuss] debian-8: apt-get install gitlab-ce takes hours: ext4 extents

[Patrick Mooney]

If you're looking to run gitlab under debian-8, you may want to
consider using the LX image instead.
I've run it under the LX CentOS image and it seemed to function
reasonably well.  Just make sure that the zone has some headroom
between max_physical_memory and max_swap.

(Gitlab will size itself according to physical memory, but relies on
the Linux over-commit behavior.  Additional swap will help with that.)

On 10 August 2016 at 13:36, Paul Sture  wrote:
> On 9 Aug 2016, at 15:31, Stefan wrote:
>
>> Dear List,
>>
>> with
>>
>>SmartOS Live Image v0.147+ build: 20160428T170316Z
>>image: 2f56d126-20d0-11e5-9e5b-5f3ef6688aba (Debian 8)
>
>
> That's debian-8 version 20150702, a KVM image.
>
>> the installation (particularly the unpacking) of gitlab
>>
>># curl
>> https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh
>> | bash
>># apt-get install gitlab-ce
>>
>> takes literally hours whereas installing under
>>
>>d8d81aee-20cf-11e5-8503-2bc101a1d577 (Debian 7)
>
>
> debian-7version 20150702, also a KVM image
>
>>
>> runs as fast as expected (< 5 minutes).  We figured out that if the
>> software is installed on an ext4 fs without extents
>>
>># umount /data
>># mkfs.ext4 -O^extents /dev/vdb1
>># mount /data
>># mkdir /data/opt
>># mount --bind /data/opt /opt
>>(then continue as stated above)
>>
>> the installation is as fast as under Debian 7.  Any sugestions what can be
>> done about that issue?
> 
> 
> There were quite a few changes from Debian 7 to Debian 8 (e.g the kernel
> moving from 3.2 to 3.16)
> 
> See
> http://arstechnica.com/information-technology/2015/05/debian-8-linuxs-most-reliable-distro-makes-its-biggest-change-since-1993/2/
> where in the "Kernel" section it says:
> 
> "There's also been a ton of work put into filesystem improvements with ext4
> support getting a lot of attention "
> 
> Did any ext4 defaults change from Debian-7 to Debian-8?
> 
> If you have the resources, it may be worth checking to see if a similar
> problem exists with Debian 8 on a standalone system (no SmartOS involved)
> and also with the native SmartOS version e.g. SmartOS image
> 3da6330e-388d-11e6-b41b-d766707c6c3d - debian-8 version 20160622
> 
> Also see this thread "Debian 8.1 ext4 directory sizes", which reports
> performance problems:
> 
> https://groups.google.com/forum/?_escaped_fragment_=topic/linux.debian.user/BxEKSHaCfQc#!topic/linux.debian.user/BxEKSHaCfQc
> 


---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

Re: [smartos-discuss] "Fast" machine inexplicably slow

[Patrick Mooney]

That syscall trace is useful.  It turns out that the emulation for
lseek(2) still resides in the brand library, rather than the kernel
module.  While it may not represent the entire differential in
performance, it's a place to start.  I've filed OS-5583 to that end.

On 9 August 2016 at 03:24, Ian Collins  wrote:
> On 08/ 9/16 01:46 AM, Robert Mustacchi wrote:
>>
>> On 8/7/16 2:40 , Ian Collins wrote:
>>>
>>>
>>> One thing that did surprise me testing on his box is the software builds
>>> significantly faster in a KVM than in an LX zone.  The difference is
>>> most noticeable with linking where one target takes well over twice as
>>> long in the zone.
>>>
>>> KVM:
>>>
>>> $ time ninja bin/Posix_Debug/Tests
>>> [1/1] LINK bin/Posix_Debug/Tests
>>> real1m3.693s
>>> user0m55.470s
>>> sys0m7.772s
>>>
>>> Zone:
>>>
>>> $ time ninja bin/Posix_Debug/Tests
>>> [1/1] LINK bin/Posix_Debug/Tests
>>> real2m45.004s
>>> user1m35.427s
>>> sys 1m7.567s
>>>
>> Well, I'd probably start with two angles. The first is where do the
>> microstates say you're spending your time during the link. Let's make
>> sure there's no LAT on the scene. Otherwise, I might do something like
>> profile where we're spending our SYS time and try and break that down
>> further. Maybe just running the individual link command with ptime -m
>> would be a good start.
>
>
>PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG
> PROCESS/LWPID
>  30176 1005  84  16 0.0 0.0 0.0 0.0 0.0 0.0   0 452 .1M   0
> x86_64-linux/1
>
> Lots of system calls.
>
> Using dtrace for a couple of seconds:
>
> # dtrace -n 'lx-syscall:::entry { @num[pid,execname] = count(); }'
> dtrace: description 'lx-syscall:::entry ' matched 676 probes
> ^C
>
> 30090 x86_64-linux-gnu 4019849
>
> Over the run time of the link (top few):
>
> # dtrace -n 'lx-syscall:::entry { @num[probefunc] = count(); }'
> dtrace: description 'lx-syscall:::entry ' matched 676 probes
> ^C
> mmap 87
> stat 334
> close 1299
> open 1407
> fstat 1834
> fcntl 2414
> brk 15685
> write 627589
> read 3185104
> lseek 13520417
> 
> Which is what I'd expect for a link that consumes 3.5GB of RAM...
> 
> --
> Ian.
> 


---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

Re: [smartos-discuss] gdb in LX zones

[Patrick Mooney]

Ian,
Thanks for bringing this to our attention.  I've reproduced what I
believe to be similar circumstances on my local test machine.  Once I
have more details, I will follow up.

-Patrick

On 3 August 2016 at 01:28, Ian Collins  wrote:
> On 08/ 3/16 05:37 PM, Robert Mustacchi wrote:
>
>> You can run impitool -I lanplus -H  -U ADMIN -P
>> ADMIN chassis power diag to generate one. You may need to change the
>> user name / password if you've changed them.
> 
> 
> You had me going for a moment Robert... "ipmitool" :)
> 
> OK, I have a nice fresh crash dump, what would you like me to look for?
> 
> Cheers,
> 
> --
> Ian.
> 


---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

Re: [smartos-discuss] clock_gettime() causes sporadic segmentation fault

[Patrick Mooney]

With the fix for OS-5515 merged, this should be solved.

Thanks for bringing it to our attention.

On 18 July 2016 at 08:50, Youzhong Yang <youzh...@gmail.com> wrote:

> Thanks for the quick turnaround ..
>
>
> On Sat, Jul 16, 2016 at 9:18 PM, Patrick Mooney <patrick.moo...@joyent.com
> > wrote:
>
>> I was able to reproduce the issue locally and have located the issue.
>> The initial analysis is here: https://smartos.org/bugview/OS-5515.  More
>> detail will be added as the problem is addressed.
>>
>> On 16 July 2016 at 20:00, Patrick Mooney <patrick.moo...@joyent.com>
>> wrote:
>>
>>> What version of the platform image do you have installed (uname -v)?
>>> Would you be willing to make the core file available?
>>>
>>> On 16 July 2016 at 19:54, Youzhong Yang <youzh...@gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> We've been using mbuffer for years, recently after upgrading SmartOS to
>>>> the latest version, mbuffer crashes sporadically inside clock_gettime():
>>>>
>>>> # mdb core.mbuffer.28346
>>>> Loading modules: [ libc.so.1 ld.so.1 ]
>>>> > ::status
>>>> debugging core file of mbuffer (64-bit) from batfs9920
>>>> initial argv: ./mbuffer
>>>> threading model: native threads
>>>> status: process terminated by SIGSEGV (Segmentation Fault),
>>>> addr=fd7fff390018
>>>> > $C
>>>> fd7ffe63dec0 libc.so.1`__cp_can_gettime+0xd(fd7fff39)
>>>> fd7ffe63df00 libc.so.1`__clock_gettime+0x3a(4, fd7ffe63df50)
>>>> fd7ffe63df20 libc.so.1`clock_gettime+0x15(4, fd7ffe63df50)
>>>> fd7ffe63dfb0 inputThread+0x3d()
>>>> fd7ffe63dfe0 libc.so.1`_thrp_setup+0x8a(fd7ffe7e0a40)
>>>> fd7ffe63dff0 libc.so.1`_lwp_start()
>>>> > ::walk thread | ::findstack -v
>>>> stack pointer for thread 1: fd7fffdfd190
>>>> [ fd7fffdfd190 libc.so.1`__pollsys+0xa() ]
>>>>   fd7fffdfd2b0 libc.so.1`pselect+0x1cb(5, fd7fffdfd480, 0, 0,
>>>> fd7fffdfd2c0, 0)
>>>>   fd7fffdfd300 libc.so.1`select+0x5a(5, fd7fffdfd480, 0, 0,
>>>> fd7fffdfd370)
>>>>   fd7fffdff4b0 statusThread+0xe6()
>>>>   fd7fffdffb90 main+0xdbb()
>>>>   fd7fffdffba0 _start+0x6c()
>>>> stack pointer for thread 2: fd7ffe9eeec0
>>>> [ fd7ffe9eeec0 libc.so.1`__lwp_park+0x17() ]
>>>>   fd7ffe90 libc.so.1`sema_wait+0x13(421a20)
>>>>   fd7ffe9eefb0 outputThread+0x222()
>>>>   fd7ffe9eefe0 libc.so.1`_thrp_setup+0x8a(fd7ffe7e0240)
>>>>   fd7ffe9eeff0 libc.so.1`_lwp_start()
>>>> stack pointer for thread 3: fd7ffe63dec0
>>>> [ fd7ffe63dec0 libc.so.1`__cp_can_gettime+0xd() ]
>>>>   fd7ffe63df00 libc.so.1`__clock_gettime+0x3a(4, fd7ffe63df50)
>>>>   fd7ffe63df20 libc.so.1`clock_gettime+0x15(4, fd7ffe63df50)
>>>>   fd7ffe63dfb0 inputThread+0x3d()
>>>>   fd7ffe63dfe0 libc.so.1`_thrp_setup+0x8a(fd7ffe7e0a40)
>>>>   fd7ffe63dff0 libc.so.1`_lwp_start()
>>>> >
>>>>
>>>> To reproduce, just run ,/mbuffer, sometimes it works, sometimes it
>>>> crashes.
>>>>
>>>> Is this a bug?
>>>>
>>>> Thanks,
>>>>
>>>> -Youzhong
>>>>
>>>>
>>>
>> *smartos-discuss* | Archives
>> <https://www.listbox.com/member/archive/184463/=now>
>> <https://www.listbox.com/member/archive/rss/184463/25077300-734ee1ca> |
>> Modify
>> <https://www.listbox.com/member/?;>
>> Your Subscription <http://www.listbox.com>
>>
>
>



---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

Re: [smartos-discuss] clock_gettime() causes sporadic segmentation fault

[Patrick Mooney]

I was able to reproduce the issue locally and have located the issue.  The
initial analysis is here: https://smartos.org/bugview/OS-5515.  More detail
will be added as the problem is addressed.

On 16 July 2016 at 20:00, Patrick Mooney <patrick.moo...@joyent.com> wrote:

> What version of the platform image do you have installed (uname -v)?
> Would you be willing to make the core file available?
>
> On 16 July 2016 at 19:54, Youzhong Yang <youzh...@gmail.com> wrote:
>
>> Hi,
>>
>> We've been using mbuffer for years, recently after upgrading SmartOS to
>> the latest version, mbuffer crashes sporadically inside clock_gettime():
>>
>> # mdb core.mbuffer.28346
>> Loading modules: [ libc.so.1 ld.so.1 ]
>> > ::status
>> debugging core file of mbuffer (64-bit) from batfs9920
>> initial argv: ./mbuffer
>> threading model: native threads
>> status: process terminated by SIGSEGV (Segmentation Fault),
>> addr=fd7fff390018
>> > $C
>> fd7ffe63dec0 libc.so.1`__cp_can_gettime+0xd(fd7fff39)
>> fd7ffe63df00 libc.so.1`__clock_gettime+0x3a(4, fd7ffe63df50)
>> fd7ffe63df20 libc.so.1`clock_gettime+0x15(4, fd7ffe63df50)
>> fd7ffe63dfb0 inputThread+0x3d()
>> fd7ffe63dfe0 libc.so.1`_thrp_setup+0x8a(fd7ffe7e0a40)
>> fd7ffe63dff0 libc.so.1`_lwp_start()
>> > ::walk thread | ::findstack -v
>> stack pointer for thread 1: fd7fffdfd190
>> [ fd7fffdfd190 libc.so.1`__pollsys+0xa() ]
>>   fd7fffdfd2b0 libc.so.1`pselect+0x1cb(5, fd7fffdfd480, 0, 0,
>> fd7fffdfd2c0, 0)
>>   fd7fffdfd300 libc.so.1`select+0x5a(5, fd7fffdfd480, 0, 0,
>> fd7fffdfd370)
>>   fd7fffdff4b0 statusThread+0xe6()
>>   fd7fffdffb90 main+0xdbb()
>>   fd7fffdffba0 _start+0x6c()
>> stack pointer for thread 2: fd7ffe9eeec0
>> [ fd7ffe9eeec0 libc.so.1`__lwp_park+0x17() ]
>>   fd7ffe90 libc.so.1`sema_wait+0x13(421a20)
>>   fd7ffe9eefb0 outputThread+0x222()
>>   fd7ffe9eefe0 libc.so.1`_thrp_setup+0x8a(fd7ffe7e0240)
>>   fd7ffe9eeff0 libc.so.1`_lwp_start()
>> stack pointer for thread 3: fd7ffe63dec0
>> [ fd7ffe63dec0 libc.so.1`__cp_can_gettime+0xd() ]
>>   fd7ffe63df00 libc.so.1`__clock_gettime+0x3a(4, fd7ffe63df50)
>>   fd7ffe63df20 libc.so.1`clock_gettime+0x15(4, fd7ffe63df50)
>>   fd7ffe63dfb0 inputThread+0x3d()
>>   fd7ffe63dfe0 libc.so.1`_thrp_setup+0x8a(fd7ffe7e0a40)
>>   fd7ffe63dff0 libc.so.1`_lwp_start()
>> >
>>
>> To reproduce, just run ,/mbuffer, sometimes it works, sometimes it
>> crashes.
>>
>> Is this a bug?
>>
>> Thanks,
>>
>> -Youzhong
>>
>> *smartos-discuss* | Archives
>> <https://www.listbox.com/member/archive/184463/=now>
>> <https://www.listbox.com/member/archive/rss/184463/26937779-40cf8a10> |
>> Modify
>> <https://www.listbox.com/member/?;>
>> Your Subscription <http://www.listbox.com>
>>
>
>



---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

Re: [smartos-discuss] clock_gettime() causes sporadic segmentation fault

[Patrick Mooney]

What version of the platform image do you have installed (uname -v)?
Would you be willing to make the core file available?

On 16 July 2016 at 19:54, Youzhong Yang  wrote:

> Hi,
>
> We've been using mbuffer for years, recently after upgrading SmartOS to
> the latest version, mbuffer crashes sporadically inside clock_gettime():
>
> # mdb core.mbuffer.28346
> Loading modules: [ libc.so.1 ld.so.1 ]
> > ::status
> debugging core file of mbuffer (64-bit) from batfs9920
> initial argv: ./mbuffer
> threading model: native threads
> status: process terminated by SIGSEGV (Segmentation Fault),
> addr=fd7fff390018
> > $C
> fd7ffe63dec0 libc.so.1`__cp_can_gettime+0xd(fd7fff39)
> fd7ffe63df00 libc.so.1`__clock_gettime+0x3a(4, fd7ffe63df50)
> fd7ffe63df20 libc.so.1`clock_gettime+0x15(4, fd7ffe63df50)
> fd7ffe63dfb0 inputThread+0x3d()
> fd7ffe63dfe0 libc.so.1`_thrp_setup+0x8a(fd7ffe7e0a40)
> fd7ffe63dff0 libc.so.1`_lwp_start()
> > ::walk thread | ::findstack -v
> stack pointer for thread 1: fd7fffdfd190
> [ fd7fffdfd190 libc.so.1`__pollsys+0xa() ]
>   fd7fffdfd2b0 libc.so.1`pselect+0x1cb(5, fd7fffdfd480, 0, 0,
> fd7fffdfd2c0, 0)
>   fd7fffdfd300 libc.so.1`select+0x5a(5, fd7fffdfd480, 0, 0,
> fd7fffdfd370)
>   fd7fffdff4b0 statusThread+0xe6()
>   fd7fffdffb90 main+0xdbb()
>   fd7fffdffba0 _start+0x6c()
> stack pointer for thread 2: fd7ffe9eeec0
> [ fd7ffe9eeec0 libc.so.1`__lwp_park+0x17() ]
>   fd7ffe90 libc.so.1`sema_wait+0x13(421a20)
>   fd7ffe9eefb0 outputThread+0x222()
>   fd7ffe9eefe0 libc.so.1`_thrp_setup+0x8a(fd7ffe7e0240)
>   fd7ffe9eeff0 libc.so.1`_lwp_start()
> stack pointer for thread 3: fd7ffe63dec0
> [ fd7ffe63dec0 libc.so.1`__cp_can_gettime+0xd() ]
>   fd7ffe63df00 libc.so.1`__clock_gettime+0x3a(4, fd7ffe63df50)
>   fd7ffe63df20 libc.so.1`clock_gettime+0x15(4, fd7ffe63df50)
>   fd7ffe63dfb0 inputThread+0x3d()
>   fd7ffe63dfe0 libc.so.1`_thrp_setup+0x8a(fd7ffe7e0a40)
>   fd7ffe63dff0 libc.so.1`_lwp_start()
> >
>
> To reproduce, just run ,/mbuffer, sometimes it works, sometimes it crashes.
>
> Is this a bug?
>
> Thanks,
>
> -Youzhong
>
> *smartos-discuss* | Archives
> 
>  |
> Modify
> 
> Your Subscription 
>



---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

Re: [smartos-discuss] zfs send internal error

[Patrick Mooney]

If I'm not mistaken, this was fixed by "6980 6902 causes zfs send to
break due to 32-bit/64-bit struct mismatch".

On 6 July 2016 at 10:13, Robert Mustacchi  wrote:
> On 7/5/16 20:15 , Ian Collins wrote:
>> [I did send this to the illumos-zfs list, but it appears to be dead?]
>>
>> Running on a recent (joyent_20160516T183627Z) SmartOS I'm trying to send
>> a snapshot to another system but zfs send is failing:
>>
>> zfs send zones/de444e31-7764-67c6-c6d5-e4408c4b0a64-disk0@toMove >
>> /var/tmp/zz
>> internal error: Invalid argument
>> Abort (core dumped)
> 
> Where is the core dump blowing up? Do you have a stack trace by chance?
> 
> Robert
> 


---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

Re: [smartos-discuss] SmartOS release-20160526

[Patrick Mooney]

A regression was found in this release regarding readv(2) behavior under LX.
The fix has been back-ported and new platform images have been built here:
http://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/20160603T232338Z/index.html

Cheers,
Patrick, on behalf of the SmartOS developers
https://smartos.org



---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

Re: [smartos-discuss] USB pass through to zone needed

[Patrick Mooney]

John,
Device passthrough into an LX zone is not likely to achieve the result
you desire.  We do not provide meaningful emulation of the device
interfaces which UPS-related Linux programs would expect.  This
includes aspects such as ioctls, major/minor numbering, and
appropriate entries in devfs/procfs/sysfs.

I believe that some folks drop a minimal pkgsrc footprint into the GZ
in order to install some of the UPS-interfacing software which is
available.  That may be the best approach.

With regards,

--Patrick


On 3 June 2016 at 22:40, John Croix  wrote:
> I'm currently sitting in the dark in my house without power, pondering the 
> need for an automatic means to shutdown my SmartOS server. When power went 
> off, I raced upstairs to manually shut it down prior to draining the UPS, and 
> I'd like to avoid a repeat scenario.
> 
> It seems like the best way to do this might be to have a dedicated LX zone 
> that runs the APC UPS daemon software. I can use it to touch a file when 
> required, and, in the global zone, monitor the file system for the presence 
> of that file. When the file appears, a power off command is issued. I just 
> need to be able to have the local zone access the UPS via USB connection. 
> Access to the LX file system from the global zone for monitoring is obviously 
> not an issue.
> 
> In short, I need to find out how to do the following:
>   Determine which device in the global zone the UPS is attached to via USB 
> cable
>   Pass the device down to a local zone (I assume via some zonecfg commands)
>   Determine which device to point the daemon to in the local zone
> Can anybody provide some info concerning the above issues?
> 
> Thanks in advance,
> John
> 
> Sent from my iPad
> 


---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

Re: [smartos-discuss] Java in LX brand

[Patrick Mooney]

It was probably due to the race conditions which were eliminated from the
LX vfork emulation.  The JVM was a frequent victim of those issues, being
commonly multi-threaded and using vfork for spawned child processes.

On 3 June 2016 at 19:22, Peter Toth  wrote:

> We have a few Java applications which used to fail in LX zones. The latest
> platform image however (end of May) seem to work just fine.
>
> Is anyone aware of any outstanding showstoppers with Java apps in LX
> containers?
>
> P
> *smartos-discuss* | Archives
> 
>  |
> Modify
> 
> Your Subscription 
>
>



---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

Re: [smartos-discuss] SmartOS release-20160526

[Patrick Mooney]

I would like to add one item to the release highlights:
Dramatic speed increase for clock_gettime()

This release features the addition of the "comm page", a mechanism similar
in function to the OSX facility of the same name and the Linux vDSO.  On
native SmartOS, it enables clock_gettime(2) to be performed entirely in
userspace using the x86 TSC.  The comm page is also leveraged by the LX
vDSO emulation, similarly accelerating calls to gettimeofday(2),
clock_gettime(2), time(2), and getcpu(2).  On typical server-class
hardware, I observed a 5X speedup for clock_gettime(2) calls.  (From ~250ns
to ~40ns)

On 27 May 2016 at 16:48, Trent Mick  wrote:

> Hello All,
>
> The latest bi-weekly "release" branch build of SmartOS is up:
>
> curl -C - -O
> https://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/smartos-latest.iso
> curl -C - -O
> https://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/smartos-latest-USB.img.bz2
> curl -C - -O
> https://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/smartos-latest.vmwarevm.tar.bz2
>
> A generated changelog is here:
>
>
> https://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/smartos.html#20160527T033529Z
>
> The full build bits directory, for those interested, is here in Manta:
>
> /Joyent_Dev/public/SmartOS/20160527T033529Z
>
>
> # Highlights
>
> DTrace security fixes.
>
>
> # General Info
>
> Every second Thursday we roll a "release-MMDD" release branch and
> builds for SmartOS (and SmartDataCenter and Manta, as well).
>
> Cheers,
> Trent, on behalf of the SmartOS developers
> https://smartos.org
>
> *smartos-discuss* | Archives
> 
>  |
> Modify
> 
> Your Subscription 
>



---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

Re: [smartos-discuss] LX binaries in a native zone.

[Patrick Mooney]

Dave,

An LX-branded zone instantiates a significant amount of brand-specific data
in order to "impersonate" the Linux syscall interface for the processes it
contains.  It is possible to run native binaries inside a branded zone
thanks to a hook in the elfexec logic which causes the branding to be
removed for that specific process.  Doing the reverse outside a branded
zone would mean instantiating an entire branded environment on exec, which
is not particularly feasible.

-Patrick

On 16 May 2016 at 17:49, David Preece  wrote:

>
> On 17 May 2016 at 10:46:12 AM, Ian Collins (i...@ianshome.com) wrote:
>
> On 05/17/16 10:39 AM, David Preece wrote:
>
> If we can run native binaries in an LX zone, can we run LX binaries in a
> native zone?
>
>
> No!
>
> Why? And why does it not apply in the opposite direction?
>
> -Dave
>
> *smartos-discuss* | Archives
> 
>  |
> Modify
> 
> Your Subscription 
>
>



---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

Re: [smartos-discuss] A deadlock issue of epoll_wait when used in branded zone environment

[Patrick Mooney]

Thanks for the detailed report.  I have written up a ticket
(https://smartos.org/bugview/OS-5222) and will be working on it today.

-Patrick

On 8 March 2016 at 01:21, 王靖  wrote:
> Hi ALL,
> Recently, we found a bug in SmartOS version 20160121 lx branded zone (UUID
> 1abb405a-d6a4-11e5-9bb8-bbe3fd09fb3c) system call epoll_wait, triggered by
> setting the timeout parameter of epoll_wait to -1. In this case, epoll_wait
> cannot return anything in some condition.
>
> Below is our test case:
>


---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

Re: [smartos-discuss] cgroups - state of the art

[Patrick Mooney]

Dave,
The cgroups emulation present in LX is very rudimentary.  It was
designed to get systemd off the ground and little more.  None of the
functionality for the cgroup resource constraints is implemented at
this time.

-Patrick

On 7 March 2016 at 13:32, David Preece  wrote:
> Hi,
> 
> Using the debian8 lx linux there's a /sys/fs/cgroup/systemd/ but not the rest 
> of the cgroup hierarchy - no cgroup/cpu for example. Is this a question of 
> 'pass these parameters to X' or am I way, way off?
> 
> -Dave
> 


---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

Re: [smartos-discuss] Chrome or Chromium in an LX zone?

[Patrick Mooney]

IIRC, Chrome uses namespaces and seccomp-bpf for its sandboxing
functionality on Linux.  Neither of those systems are implemented yet on LX.

On 29 February 2016 at 14:05, David Pacheco  wrote:

> On Sun, Feb 28, 2016 at 6:45 AM, Jorge Schrauwen 
> wrote:
>
>> Not exactly sure why chrome fails as I never dug into that.
>> Firefox is failing because splice (
>> http://man7.org/linux/man-pages/man2/splice.2.html)
>>
>> Overall I'd say LX is pretty stable and mature if you are looking at the
>> server side of things. Desktops and X11 Apps are another thing though. e.g.
>> x2go needs SHM disabled or it segfaults, ...
>>
>> This is to be expected as the focus of SDC/SmartOS is mostly on the
>> server side of things.
>>
>
>
> For what it's worth, I've been interested to try Chrome on LX because in
> theory we could use mdb_v8 to debug memory leaks in web applications.  I
> have not gotten around to trying this out.
>
> -- Dave
> *smartos-discuss* | Archives
> 
>  |
> Modify
> 
> Your Subscription 
>



---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

Re: [smartos-discuss] SmartOS host crashing while stracing a python-process inside an lx-branded centos6-zone

[Patrick Mooney]

Paul,

I believe that behavior is covered by OS-4937, which was fixed back in
November.  (See https://smartos.org/bugview/OS-4937 for more detail.)
Please consider updating to the latest platform image.

Thanks

-Patrick

On 25 February 2016 at 06:50, Paul Dunkler  wrote:
> Hi there,
> 
> yesterday, our smartos host-system crashed while doing an strace of a python
> process inside an lx-branded zone (centos-6). Details following.
> 
> I searched the bugview but couldn't find any commit which solved this
> specific issue.
> Anyway it seems like this is not happening anymore in the latest iso-file
> (just tried that an hour ago).
> Still i would like somebody with more knowledge to have a short look on the
> problem to see if there is still some flaw in the code which should be
> fixed.
> 
> Crash Screenshot
> 
> https://cloud.githubusercontent.com/assets/460126/13319717/01ac381a-dbc4-11e5-89ae-02cb72a8d523.png
> 
> Complete strace output
> 
> http://pastebin.com/e24BMv0D
> 
> System
> 
> Smartos Image:smartos-20151029T053122Z
> 
> LX Image:centos-6 (232ddfaa-c87f-11e5-9a3a-7bc6a36a1bfd)
> 
> LX Image:centos-6 (1abb405a-d6a4-11e5-9bb8-bbe3fd09fb3c)
> 
> How to reproduce
> 
> 1.  Create any lx branded zone using the image stated above
>  yum install epel-release && yum install strace python-pip
>  curl -O
> https://raw.githubusercontent.com/mzupan/nagios-plugin-mongodb/b49e830e37ddfd0baa12bf2c7e1ceb65a0be6c54/check_mongodb.py
>  pip install pymongo
>  strace -f python check_mongodb.py -H 8.8.8.8 --action=connect
> 
> Observations:
> 
> -  If pymongo is not installed, the strace works without crashing the host
> system.
> 
> Best Regards
> —
> Paul Dunkler
> 


---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

Re: [smartos-discuss] Registering LX zone host names with DNS server

[Patrick Mooney]

John,

This behavior is related to how LX are configured for networking.  Native
illumos network utilities are used to bring up zone interface(s), including
acquisition of DHCP leases.  No advanced configuration is generated for
dhcpagent, so it operates with defaults which do not send the hostname when
requesting an address.  A ticket has been opened (I don't have it handy) to
address the inability to specify DHCP options for dhcpagent in LX zones.
This issue could probably be rolled into that ticket.

On 8 February 2016 at 23:12, John Croix  wrote:

> I’m running SmartOS at home, and I have a Raspberry PI running dnsmasq as
> my DHCP and DNS server. My DHCP-configured computers will give their
> hostname back to dnsmasq so that I can look up the computer by name instead
> of IP address. I can’t seem to make that work for an Ubuntu LX zone that I
> create in SmartOS. For example, here’s the JSON for a Ubuntu 14.04 LTS zone
> that I created:
>
> {
>"brand": "lx",
>"kernel_version": "3.13.0",
>"dataset_uuid": "52be84d0-6b06-11e5-a4c0-9f0c52fa368a",
>"resolvers": ["192.168.1.2","8.8.8.8", "8.8.4.4"],
>"max_physical_memory": 4096,
>"autoboot": true,
>"alias": "owncloud",
>"hostname": "owncloud",
>"zonename": "owncloud",
>"nics": [
>{
>   "nic_tag": "admin",
>   "ip": "dhcp",
>   "primary": true
>}
>]
> }
>
> The DHCP IP address assigned is 192.168.1.160. If I do a “dig -x
> 192.168.1.160”, I won’t get the hostname that I’ve given to this zone. In
> fact, I won’t get anything in the form of a name. The LX zone, though,
> knows its hostname, and I’ve verified that it is correct.
>
> Is there a way to get the hostname registered with dnsmasq for a LX zone?
> It happens automatically for Linux systems that are running Ubuntu, but not
> for LX Ubuntu images.
>
> Thanks,
> John
>
>
>
> *smartos-discuss* | Archives
> 
>  |
> Modify
> 
> Your Subscription 
>



---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com