Re: FYI: qemu-ppc64-static and qemu-ppc-static "live-hang" when I attempt use with poudriere; qemu-arm-static and qemu-aarch64-static work

[Mark Millard]

[I show some of the target/ppc/translate.c source code
and related material this time. Not that I know enough
to patch it correctly.]

On 2017-Aug-31, at 12:13 PM, Mark Millard  wrote:

> [Turns out that the emulated program counter is not progressing
> for syscall emulation, at least for [some] syscall [failure] cases.]
> 
> On 2017-Aug-30, at 8:43 PM, Mark Millard  wrote:
> 
>> On 2017-Aug-30, at 4:32 PM, Don Lewis  wrote:
>> 
>>> On 30 Aug, Mark Millard wrote:
 On 2017-Aug-30, at 4:00 AM, Mark Linimon  wrote:
 
> On Wed, Aug 30, 2017 at 03:09:40AM -0700, Mark Millard wrote:
>> It appears that qemu-ppc64-static and qemu-ppc-static from
>> emulators/qemu-user-static are broken.
> 
> Correct, and known for some time.  (fwiw sparc64 hangs as well.)
 
 Looks like qemu-ppc64-static is stuck in a loop, calling
 repeatedly:
 
 do_freebsd_syscall (cpu_env=0x860ea3ac0, num=58, arg1=14, 
 arg2=35995509911, arg3=1024, arg4=268435904, arg5=281494784, 
 arg6=35985701568, arg7=515, arg8=35985668288)
 at 
 /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/syscall.c:210
 210
 /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/syscall.c:
  No such file or directory.
 
 Which is for:
 
 58  AUE_READLINKSTD { ssize_t readlink(char *path, char *buf, \
 size_t count); }
 
 As confirmed by (note the "callq  0x60207360 " ):
 
 (gdb) 
 lock_user_string (guest_addr=14) at 
 /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/qemu.h:508
 508
 /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/qemu.h:
  No such file or directory.
 
 (gdb) x/64i 0x60045d3e
 => 0x60045d3e :   callq  0x6004fd20 
 
 0x60045d43 :  test   %rax,%rax
 0x60045d46 :  js 0x6004b99c 
 
 0x60045d4c :  inc%rax
 0x60045d4f :  mov$0x1,%edx
 0x60045d54 :  mov%rbx,%rdi
 0x60045d57 :  mov%rax,%rsi
 0x60045d5a :  callq  0x6003c430 
 
 0x60045d5f :  test   %eax,%eax
 0x60045d61 :  jne0x6004bce4 
 
 0x60045d67 :  add0x26d91b2(%rip),%rbx 
# 0x6271ef20 
 0x60045d6e :  je 0x6004bce4 
 
 0x60045d74 :  mov$0x3,%edx
 0x60045d79 :  mov-0x2a8(%rbp),%r14
 0x60045d80 :  mov%r14,%rdi
 0x60045d83 :  mov%r12,%rsi
 0x60045d86 :  callq  0x6003c430 
 
 0x60045d8b :  test   %eax,%eax
 0x60045d8d :  jne0x6004bce4 
 
 0x60045d93 :  add0x26d9186(%rip),%r14 
# 0x6271ef20 
 0x60045d9a :  mov-0x294(%rbp),%r10d
 0x60045da1 :  mov$0xfff2,%r13
 0x60045da8 :  je 0x6004bcf2 
 
 0x60045dae :  mov$0x602b93da,%esi
 0x60045db3 :  mov%rbx,%rdi
 0x60045db6 :  callq  0x60230af0 
 0x60045dbb :  test   %eax,%eax
 0x60045dbd :  je 0x6004c566 
 
 0x60045dc3 :  mov%rbx,%rdi
 0x60045dc6 :  callq  0x60158660 
 0x60045dcb :  mov%rax,%rdi
 0x60045dce :  mov%r14,%rsi
 0x60045dd1 :  mov%r12,%rdx
 0x60045dd4 :  callq  0x60207360 
 
 But note that the "lock_user_string (guest_addr=14)" and
 "do_freebsd_syscall (cpu_env=0x860ea3ac0, num=58, arg1=14,"
 indicate that the "readlink(char *path," is using a really
 small address for the path string.
 
 
 I've not figured a way for poudriere bulk builds to leave
 behind the source code automatically. So far I've not
 looked at the qemu-bsd-user source code. I do build with
 both debug and optimization turned on via bsd.port.mk
 having:
>>> 
>>> The -w option will create a tarball of 

Re: standard locations for port files

[Lee Brown]

On Thu, Aug 31, 2017 at 12:54 PM,  wrote:

> [Default] On Thu, 31 Aug 2017 13:53:27 -0500, Adam Vande More
>  wrote:
>
> >On Thu, Aug 31, 2017 at 1:41 PM,  wrote:
> >
> >> Why wouldn't  logs be in /usr/local/var/...?  Given that all
> >> other port "stuff" is under /usr/local, what advantage is there
> >> in making logs an exception?
> >>
> >
> >Because logs shouldn't be under /usr.
>
> Why not?  The current location wasn't determined by natural law,
> it was just someone's decision, almost certainly made without
> much thought at all.  It could be re-decided just as easily.
>
>
It's in hier(7)

/usr/  contains the majority of user utilities and applications
/var/  multi-purpose log, temporary, transient, and spool files


Within local/, the general layout sketched out by hier for /usr should be
used.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: standard locations for port files

[Jonathan Chen]

On 1 September 2017 at 07:54,   wrote:
> [Default] On Thu, 31 Aug 2017 13:53:27 -0500, Adam Vande More
>  wrote:
>
>>On Thu, Aug 31, 2017 at 1:41 PM,  wrote:
>>
>>> Why wouldn't  logs be in /usr/local/var/...?  Given that all
>>> other port "stuff" is under /usr/local, what advantage is there
>>> in making logs an exception?
>>>
>>
>>Because logs shouldn't be under /usr.
>
> Why not?  The current location wasn't determined by natural law,
> it was just someone's decision, almost certainly made without
> much thought at all.  It could be re-decided just as easily.

That particular decision was made decades ago that logs are expected
to live in /var/log; and re-deciding that decision would break
predictably on all BSD based systems.

Cheers.
-- 
Jonathan Chen 
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: standard locations for port files

[Bob Eager]

On Thu, 31 Aug 2017 15:54:09 -0400
 wrote:

> [Default] On Thu, 31 Aug 2017 13:53:27 -0500, Adam Vande More
>  wrote:
> 
> >On Thu, Aug 31, 2017 at 1:41 PM,  wrote:
> >  
> >> Why wouldn't  logs be in /usr/local/var/...?  Given that all
> >> other port "stuff" is under /usr/local, what advantage is there
> >> in making logs an exception?
> >>  
> >
> >Because logs shouldn't be under /usr.  
> 
> Why not?  The current location wasn't determined by natural law,
> it was just someone's decision, almost certainly made without
> much thought at all.  It could be re-decided just as easily.  

The current hierarchy has had a lot of thought put into it. Files
in /usr generally don't constantly change (although if /home is
symlinked to /usr/home they might, I guess. Files in /var *do* change a
lot, hence its name. It's also the reason that the root file system is
separate; if it isn't written to much, it's less likely to sustain
damage.

/var is designed for files that *change* - that's why logs go there. If
you want to, by all means create /var/local and put your logs there.

A compelling reason, already mentioned, is that there are a lot of
systems that have /usr mounted read only (e.g. net booted systems, or
those that are booted from a USB stick). Such systems usually put /var
in a RAM disk, so that logs can be kept. Even if /var is on an actual
disk, it means that other parts of the file system can be kept read
only. This improves reliability and integrity, and makes recovery after
a crash a lot quicker.

All in all, /var is the *right* place.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: standard locations for port files

[Adam Weinberger]

> On 31 Aug, 2017, at 13:54,   
> wrote:
> 
> [Default] On Thu, 31 Aug 2017 13:53:27 -0500, Adam Vande More
>  wrote:
> 
>> On Thu, Aug 31, 2017 at 1:41 PM,  wrote:
>> 
>>> Why wouldn't  logs be in /usr/local/var/...?  Given that all
>>> other port "stuff" is under /usr/local, what advantage is there
>>> in making logs an exception?
>>> 
>> 
>> Because logs shouldn't be under /usr.
> 
> Why not?  The current location wasn't determined by natural law,
> it was just someone's decision, almost certainly made without
> much thought at all.  It could be re-decided just as easily.  
> 
> There are many advantages to predictability that usually go
> unappreciated because of how pervasive it is in our everyday
> lives.  To take a somewhat trivial example, we know to look for
> cream in the milk case rather than the ice-cream case even  if
> we'd never shopped in that particular supermarket before,  I'm
> sure you could come up with thousands of similar ways in which
> your life is effortlessly made easier by predictability.

It is predictable. You can predict that logs will in /var.

# Adam


-- 
Adam Weinberger
ad...@adamw.org
https://www.adamw.org

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: standard locations for port files

[scratch65535]

[Default] On Thu, 31 Aug 2017 13:53:27 -0500, Adam Vande More
 wrote:

>On Thu, Aug 31, 2017 at 1:41 PM,  wrote:
>
>> Why wouldn't  logs be in /usr/local/var/...?  Given that all
>> other port "stuff" is under /usr/local, what advantage is there
>> in making logs an exception?
>>
>
>Because logs shouldn't be under /usr.

Why not?  The current location wasn't determined by natural law,
it was just someone's decision, almost certainly made without
much thought at all.  It could be re-decided just as easily.  

There are many advantages to predictability that usually go
unappreciated because of how pervasive it is in our everyday
lives.  To take a somewhat trivial example, we know to look for
cream in the milk case rather than the ice-cream case even  if
we'd never shopped in that particular supermarket before,  I'm
sure you could come up with thousands of similar ways in which
your life is effortlessly made easier by predictability.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FYI: qemu-ppc64-static and qemu-ppc-static "live-hang" when I attempt use with poudriere; qemu-arm-static and qemu-aarch64-static work

[Mark Millard]

[Just adding Sean Bruno in case the information is new to him.
I top post a note for that.]

Sean: The below reports on what I've found for what is
happening for qemu-ppc64-static (and possibly others) when
it gets stuck eating CPU time (and leaking memory), at least
for the example I ran into (that basically blocks all use
of qemu-ppc64-static it happens very early in all(?)
attempted uses that load.

The content reflects my exploration order. The summary is:

A) I've found an example context where the emulated
pc does not progress and it ends up looping repeating
a syscall.

B) Given that is involved: I've found that env->gpr[3]
handling for failed syscall attempts contributes to the
detailed failure behaviors. (This part is, of course,
likely very powerpc specific.)


But I found (B) before finding (A) as its context and
(A) might be the only problem for all I know: having the
emulated program counter progress correctly might end
up dealing with env->gpr[3] correctly in the newly
executed code.

At this point I've no clue where the emulated PC should
be adjusted in the code or what the detailed adjustment
rules should be for the context, only that the PC is not
being adjusted now but needs to be adjusted.

===
Mark Millard
markmi at dsl-only.net

On 2017-Aug-31, at 12:13 PM, Mark Millard  wrote:

[Turns out that the emulated program counter is not progressing
for syscall emulation, at least for [some] syscall [failure] cases.]

On 2017-Aug-30, at 8:43 PM, Mark Millard  wrote:

> On 2017-Aug-30, at 4:32 PM, Don Lewis  wrote:
> 
>> On 30 Aug, Mark Millard wrote:
>>> On 2017-Aug-30, at 4:00 AM, Mark Linimon  wrote:
>>> 
 On Wed, Aug 30, 2017 at 03:09:40AM -0700, Mark Millard wrote:
> It appears that qemu-ppc64-static and qemu-ppc-static from
> emulators/qemu-user-static are broken.
 
 Correct, and known for some time.  (fwiw sparc64 hangs as well.)
>>> 
>>> Looks like qemu-ppc64-static is stuck in a loop, calling
>>> repeatedly:
>>> 
>>> do_freebsd_syscall (cpu_env=0x860ea3ac0, num=58, arg1=14, arg2=35995509911, 
>>> arg3=1024, arg4=268435904, arg5=281494784, arg6=35985701568, arg7=515, 
>>> arg8=35985668288)
>>>  at 
>>> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/syscall.c:210
>>> 210 
>>> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/syscall.c:
>>>  No such file or directory.
>>> 
>>> Which is for:
>>> 
>>> 58  AUE_READLINKSTD { ssize_t readlink(char *path, char *buf, \
>>>  size_t count); }
>>> 
>>> As confirmed by (note the "callq  0x60207360 " ):
>>> 
>>> (gdb) 
>>> lock_user_string (guest_addr=14) at 
>>> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/qemu.h:508
>>> 508 
>>> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/qemu.h:
>>>  No such file or directory.
>>> 
>>> (gdb) x/64i 0x60045d3e
>>> => 0x60045d3e :callq  0x6004fd20 
>>> 
>>> 0x60045d43 :   test   %rax,%rax
>>> 0x60045d46 :   js 0x6004b99c 
>>> 
>>> 0x60045d4c :   inc%rax
>>> 0x60045d4f :   mov$0x1,%edx
>>> 0x60045d54 :   mov%rbx,%rdi
>>> 0x60045d57 :   mov%rax,%rsi
>>> 0x60045d5a :   callq  0x6003c430 
>>> 
>>> 0x60045d5f :   test   %eax,%eax
>>> 0x60045d61 :   jne0x6004bce4 
>>> 
>>> 0x60045d67 :   add0x26d91b2(%rip),%rbx 
>>># 0x6271ef20 
>>> 0x60045d6e :   je 0x6004bce4 
>>> 
>>> 0x60045d74 :   mov$0x3,%edx
>>> 0x60045d79 :   mov-0x2a8(%rbp),%r14
>>> 0x60045d80 :   mov%r14,%rdi
>>> 0x60045d83 :   mov%r12,%rsi
>>> 0x60045d86 :   callq  0x6003c430 
>>> 
>>> 0x60045d8b :   test   %eax,%eax
>>> 0x60045d8d :   jne0x6004bce4 
>>> 
>>> 0x60045d93 :   add0x26d9186(%rip),%r14 
>>># 0x6271ef20 
>>> 0x60045d9a :   mov-0x294(%rbp),%r10d
>>> 0x60045da1 :   mov$0xfff2,%r13
>>> 0x60045da8 :   je 0x6004bcf2 
>>> 
>>> 0x60045dae :   mov$0x602b93da,%esi
>>> 0x60045db3 :   mov%rbx,%rdi
>>> 0x60045db6 :   callq  0x60230af0 
>>> 0x60045dbb :   

Re: FYI: qemu-ppc64-static and qemu-ppc-static "live-hang" when I attempt use with poudriere; qemu-arm-static and qemu-aarch64-static work

[Mark Millard]

[Turns out that the emulated program counter is not progressing
for syscall emulation, at least for syscall falure cases.]

On 2017-Aug-30, at 8:43 PM, Mark Millard  wrote:

> On 2017-Aug-30, at 4:32 PM, Don Lewis  wrote:
> 
>> On 30 Aug, Mark Millard wrote:
>>> On 2017-Aug-30, at 4:00 AM, Mark Linimon  wrote:
>>> 
 On Wed, Aug 30, 2017 at 03:09:40AM -0700, Mark Millard wrote:
> It appears that qemu-ppc64-static and qemu-ppc-static from
> emulators/qemu-user-static are broken.
 
 Correct, and known for some time.  (fwiw sparc64 hangs as well.)
>>> 
>>> Looks like qemu-ppc64-static is stuck in a loop, calling
>>> repeatedly:
>>> 
>>> do_freebsd_syscall (cpu_env=0x860ea3ac0, num=58, arg1=14, arg2=35995509911, 
>>> arg3=1024, arg4=268435904, arg5=281494784, arg6=35985701568, arg7=515, 
>>> arg8=35985668288)
>>>   at 
>>> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/syscall.c:210
>>> 210 
>>> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/syscall.c:
>>>  No such file or directory.
>>> 
>>> Which is for:
>>> 
>>> 58  AUE_READLINKSTD { ssize_t readlink(char *path, char *buf, \
>>>   size_t count); }
>>> 
>>> As confirmed by (note the "callq  0x60207360 " ):
>>> 
>>> (gdb) 
>>> lock_user_string (guest_addr=14) at 
>>> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/qemu.h:508
>>> 508 
>>> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/qemu.h:
>>>  No such file or directory.
>>> 
>>> (gdb) x/64i 0x60045d3e
>>> => 0x60045d3e :callq  0x6004fd20 
>>> 
>>>  0x60045d43 :  test   %rax,%rax
>>>  0x60045d46 :  js 0x6004b99c 
>>> 
>>>  0x60045d4c :  inc%rax
>>>  0x60045d4f :  mov$0x1,%edx
>>>  0x60045d54 :  mov%rbx,%rdi
>>>  0x60045d57 :  mov%rax,%rsi
>>>  0x60045d5a :  callq  0x6003c430 
>>> 
>>>  0x60045d5f :  test   %eax,%eax
>>>  0x60045d61 :  jne0x6004bce4 
>>> 
>>>  0x60045d67 :  add0x26d91b2(%rip),%rbx 
>>># 0x6271ef20 
>>>  0x60045d6e :  je 0x6004bce4 
>>> 
>>>  0x60045d74 :  mov$0x3,%edx
>>>  0x60045d79 :  mov-0x2a8(%rbp),%r14
>>>  0x60045d80 :  mov%r14,%rdi
>>>  0x60045d83 :  mov%r12,%rsi
>>>  0x60045d86 :  callq  0x6003c430 
>>> 
>>>  0x60045d8b :  test   %eax,%eax
>>>  0x60045d8d :  jne0x6004bce4 
>>> 
>>>  0x60045d93 :  add0x26d9186(%rip),%r14 
>>># 0x6271ef20 
>>>  0x60045d9a :  mov-0x294(%rbp),%r10d
>>>  0x60045da1 :  mov$0xfff2,%r13
>>>  0x60045da8 :  je 0x6004bcf2 
>>> 
>>>  0x60045dae :  mov$0x602b93da,%esi
>>>  0x60045db3 :  mov%rbx,%rdi
>>>  0x60045db6 :  callq  0x60230af0 
>>>  0x60045dbb :  test   %eax,%eax
>>>  0x60045dbd :  je 0x6004c566 
>>> 
>>>  0x60045dc3 :  mov%rbx,%rdi
>>>  0x60045dc6 :  callq  0x60158660 
>>>  0x60045dcb :  mov%rax,%rdi
>>>  0x60045dce :  mov%r14,%rsi
>>>  0x60045dd1 :  mov%r12,%rdx
>>>  0x60045dd4 :  callq  0x60207360 
>>> 
>>> But note that the "lock_user_string (guest_addr=14)" and
>>> "do_freebsd_syscall (cpu_env=0x860ea3ac0, num=58, arg1=14,"
>>> indicate that the "readlink(char *path," is using a really
>>> small address for the path string.
>>> 
>>> 
>>> I've not figured a way for poudriere bulk builds to leave
>>> behind the source code automatically. So far I've not
>>> looked at the qemu-bsd-user source code. I do build with
>>> both debug and optimization turned on via bsd.port.mk
>>> having:
>> 
>> The -w option will create a tarball of the work directory if the
>> package build fails.  I also often use the testport -i option I want to
>> poke around in the WRKDIR after a build.
> 
> I've been using -w right along. But I'd not used testport at all.
> 
> It looks to me like the syscall errno handling is messed
> 

Re: standard locations for port files

[Adam Weinberger]

> On 31 Aug, 2017, at 12:41, scratch65...@att.net wrote:
> 
> Why wouldn't  logs be in /usr/local/var/...?  Given that all
> other port "stuff" is under /usr/local, what advantage is there
> in making logs an exception?
> 
> [Default] On Thu, 31 Aug 2017 09:16:20 -0600, Adam Weinberger
>  wrote:
> 
>>> On 31 Aug, 2017, at 9:07, Ernie Luzar  wrote:
>>> 
>>> Lets say I have a product that I want to port to Freebsd.
>>> 
>>> Were is the standard location for the log file and PID file.
>>> 
>>> Would it be in
>>> /usr/local/etc/product/product.log
>>> /usr/local/etc/product/product.pid
>>> 
>>> or
>>> 
>>> /var/log/product.log
>>> /var/run/product.pid
>> 
>> It should be in /var. Many users keep /usr/local mounted read-only.

... because many users keep /usr/local mounted read-only.

# Adam


-- 
Adam Weinberger
ad...@adamw.org
https://www.adamw.org


>> 
>> # Adam
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: standard locations for port files

[Adam Vande More]

On Thu, Aug 31, 2017 at 1:41 PM,  wrote:

> Why wouldn't  logs be in /usr/local/var/...?  Given that all
> other port "stuff" is under /usr/local, what advantage is there
> in making logs an exception?
>

Because logs shouldn't be under /usr.

man hier

-- 
Adam
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: standard locations for port files

[scratch65535]

Why wouldn't  logs be in /usr/local/var/...?  Given that all
other port "stuff" is under /usr/local, what advantage is there
in making logs an exception?

[Default] On Thu, 31 Aug 2017 09:16:20 -0600, Adam Weinberger
 wrote:

>> On 31 Aug, 2017, at 9:07, Ernie Luzar  wrote:
>> 
>> Lets say I have a product that I want to port to Freebsd.
>> 
>> Were is the standard location for the log file and PID file.
>> 
>> Would it be in
>> /usr/local/etc/product/product.log
>> /usr/local/etc/product/product.pid
>> 
>> or
>> 
>> /var/log/product.log
>> /var/run/product.pid
>
>It should be in /var. Many users keep /usr/local mounted read-only.
>
># Adam
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: standard locations for port files

[Mathieu Arnold]

Le 31/08/2017 à 17:25, Ernie Luzar a écrit :
> Adam Weinberger wrote:
>>> On 31 Aug, 2017, at 9:07, Ernie Luzar  wrote:
>>>
>>> Lets say I have a product that I want to port to Freebsd.
>>>
>>> Were is the standard location for the log file and PID file.
>>>
>>> Would it be in
>>> /usr/local/etc/product/product.log
>>> /usr/local/etc/product/product.pid
>>>
>>> or
>>>
>>> /var/log/product.log
>>> /var/run/product.pid
>>
>> It should be in /var. Many users keep /usr/local mounted read-only.
>>
>> # Adam
>>
>>
> Lets say /usr/local/etc/product/ is chrooted and the only thing in it
> is the product.conf. Is there any security benefit for chrooting that
> directory path?
>

The etc directory is for configuration files and scripts, that is, files
that almost never changes. Do *not* put pid or log files in there.


-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: standard locations for port files

[Eugene Grosbein]

31.08.2017 22:07, Ernie Luzar wrote:
> Lets say I have a product that I want to port to Freebsd.
> 
> Were is the standard location for the log file and PID file.
> 
> Would it be in
> /usr/local/etc/product/product.log
> /usr/local/etc/product/product.pid
> 
> or
> 
> /var/log/product.log
> /var/run/product.pid

FreeBSD cleans /var/run at boot time, so /var/run/product.pid is guaranteed to 
not exist
when "product" is first started that time.

On the other hand, /usr/local/etc/product/product.pid can (and will) exist after
unclean system reboot and it can contain a PID of already running another 
process,
so that simple check for double-start would fail.

So, use /var/run for PID files to be safe.

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: standard locations for port files

[Ernie Luzar]

Adam Weinberger wrote:

On 31 Aug, 2017, at 9:07, Ernie Luzar  wrote:

Lets say I have a product that I want to port to Freebsd.

Were is the standard location for the log file and PID file.

Would it be in
/usr/local/etc/product/product.log
/usr/local/etc/product/product.pid

or

/var/log/product.log
/var/run/product.pid


It should be in /var. Many users keep /usr/local mounted read-only.

# Adam


Lets say /usr/local/etc/product/ is chrooted and the only thing in it is 
the product.conf. Is there any security benefit for chrooting that 
directory path?

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: standard locations for port files

[Miroslav Lachman]

Ernie Luzar wrote on 2017/08/31 17:07:

Lets say I have a product that I want to port to Freebsd.

Were is the standard location for the log file and PID file.

Would it be in
/usr/local/etc/product/product.log
/usr/local/etc/product/product.pid

or

/var/log/product.log
/var/run/product.pid


The later is more correct and most of the ports do this. Let's see 
Apache as example:


/var/run/httpd.pid
/var/log/httpd-error.log

Miroslav Lachman

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: standard locations for port files

[Adam Weinberger]

> On 31 Aug, 2017, at 9:07, Ernie Luzar  wrote:
> 
> Lets say I have a product that I want to port to Freebsd.
> 
> Were is the standard location for the log file and PID file.
> 
> Would it be in
> /usr/local/etc/product/product.log
> /usr/local/etc/product/product.pid
> 
> or
> 
> /var/log/product.log
> /var/run/product.pid

It should be in /var. Many users keep /usr/local mounted read-only.

# Adam


-- 
Adam Weinberger
ad...@adamw.org
https://www.adamw.org

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

standard locations for port files

[Ernie Luzar]

Lets say I have a product that I want to port to Freebsd.

Were is the standard location for the log file and PID file.

Would it be in
/usr/local/etc/product/product.log
/usr/local/etc/product/product.pid

or

/var/log/product.log
/var/run/product.pid
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: somebody typed the USES setting in /usr/ports/sysutils/screen?

[Randy Bush]

>> psg.com:/usr/ports/sysutils/screen# make config
>> make: "/usr/ports/Mk/Uses/ncurses.mk" line 84: USES=ncurses only accept 'port
>> ' and 'base' as arguments, got ports
> 
> I'm sorry about that. Fixed in r449031.

thanks!

randy
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: somebody typed the USES setting in /usr/ports/sysutils/screen?

[Cy Schubert]

In message , Randy Bush writes:
> up to date 10.3
> up to date ports
> 
> psg.com:/usr/ports/sysutils/screen# make config
> make: "/usr/ports/Mk/Uses/ncurses.mk" line 84: USES=ncurses only accept 'port
> ' and 'base' as arguments, got ports

I'm sorry about that. Fixed in r449031.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

FreeBSD ports you maintain which are out of date

[portscout]

Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
graphics/opencollada| 1.6.47  | v1.6.59
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

Thanks.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Synth and circular dependencies

[Thomas Mueller]

> On 31 August 2017 at 17:59, Thomas Mueller  wrote:
> > Now I've been busy, selecting port options to include in
> > /usr/local/etc/synth/LiveSystem-make.conf

> > but when I run "synth status gnumeric", I get

> > Configuration invalid: [D] Port options directory: /var/db/ports

> > so without a directory like /var/db/ports showing options derived from the 
> > ports dialog, synth seems not to work.

> The directory *must* be there, but it can be empty.

> > Is there any dialog-free way to use synth?

> Yup, I'm using it with the LiveSystem-make.conf.

> Cheers.

> Jonathan Chen 

I tried setting the port options directory to 
/usr/local/etc/synth/LiveSystem-make.conf, but I guess that was not good enough.

Maybe it had to be a directory, not a file?

I will try again when I get back into that installation.

I also wonder about the future of synth with John Marino banished from FreeBSD, 
don't want to go to DragonFlyBSD because of incompatibility problems not 
relating to dports.

Tom

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

somebody typed the USES setting in /usr/ports/sysutils/screen?

[Randy Bush]

up to date 10.3
up to date ports

psg.com:/usr/ports/sysutils/screen# make config
make: "/usr/ports/Mk/Uses/ncurses.mk" line 84: USES=ncurses only accept 'port' 
and 'base' as arguments, got ports

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Synth and circular dependencies

[Jonathan Chen]

On 31 August 2017 at 17:59, Thomas Mueller  wrote:
> Now I've been busy, selecting port options to include in
> /usr/local/etc/synth/LiveSystem-make.conf
>
> but when I run "synth status gnumeric", I get
>
> Configuration invalid: [D] Port options directory: /var/db/ports
>
> so without a directory like /var/db/ports showing options derived from the 
> ports dialog, synth seems not to work.

The directory *must* be there, but it can be empty.

> Is there any dialog-free way to use synth?

Yup, I'm using it with the LiveSystem-make.conf.

Cheers.
-- 
Jonathan Chen 
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Synth and circular dependencies

[Thomas Mueller]

Now I've been busy, selecting port options to include in 
/usr/local/etc/synth/LiveSystem-make.conf

but when I run "synth status gnumeric", I get

Configuration invalid: [D] Port options directory: /var/db/ports

so without a directory like /var/db/ports showing options derived from the 
ports dialog, synth seems not to work.

Is there any dialog-free way to use synth?

Synth has been ported to pkgsrc where there is no dialog, so maybe there is a 
way?

Or maybe synth does not run with pkgsrc?  Synth seems to be falling into 
desuetude there.

Tom

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"