Re: svn commit: r240165 - head/usr.sbin/pc-sysinstall/backend
On Thu, Sep 6, 2012 at 7:59 AM, Josh Paetzel jpaet...@freebsd.org wrote:
Modified: head/usr.sbin/pc-sysinstall/backend/functions-bsdlabel.sh
==
--- head/usr.sbin/pc-sysinstall/backend/functions-bsdlabel.sh Thu Sep 6
13:54:01 2012(r240164)
+++ head/usr.sbin/pc-sysinstall/backend/functions-bsdlabel.sh Thu Sep 6
14:59:53 2012(r240165)
...
FOUNDPARTS=1
+ USEDAUTOSIZE=0
# Lets read in the config file now and setup our partitions
if [ ${_pType} = gpt ] ; then
@@ -245,7 +278,15 @@ setup_gpart_partitions()
if [ $SIZE = 0 ]
then
-SOUT=
+ if [ $USEDAUTOSIZE -eq 1 ] ; then
Style question: if $USEDAUTOSIZE is treated as a boolean value, why not use
`true' and `false' instead of `1' and `0'? No need to make shell code look
like C code. That way one can write:
if $USEDAUTOSIZE; then
Jos
--
Jos Backus
jos at catnook.com
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r230869 - head/usr.sbin/daemon
On Sun, Feb 12, 2012 at 12:41 PM, Andrey Zonov and...@zonov.org wrote: On 13.02.2012 0:02, Pawel Jakub Dawidek wrote: On Sun, Feb 12, 2012 at 09:06:55PM +0200, Mikolaj Golub wrote: AZ Check return code from pidfile_write() function. I saw many times AZ when pid could not be written because of there is not enough free AZ space (but file was created). Unfortunately, I have no suggestions AZ how to handle this properly. We could return with error in this case (for me this almost the same as if we don't create file at all). But if we check pidfile_write() status we should resign the pidfile_write() feature that allows to pass NULL pidfh and check if pidfile option is used. Something like in this patch: http://people.freebsd.org/~trociny/daemon/daemon.pidfile_write.1.patch Not sure I should commit this though. Please don't. Even if you can't write the pidfile, you should run the service. The same as for pidfile_open() failure as documented in example. Feel free to warn about problem with writing to pidfile, but don't treat it as critial error. The problem is the following you cannot stop such a service with standard rc.d script and empty pidfile. Right. So why not add a Unix socket listener to daemon(8) so the rc.d script can send commands over the socket instead of using the pidfile? This is what supervise/svc let you do today. I don't understand why this solution isn't obvious once you are committed to running daemon(8) for each service anyway. And then you don't need pidfiles because now you have a much better, standard control interface (sending commands to daemon(8) and gathering responses). Jos We can also add such a warning to the example in the manual page. -- Andrey Zonov ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org -- Jos Backus jos at catnook.com ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r230869 - head/usr.sbin/daemon
On Feb 12, 2012 1:32 PM, Mikolaj Golub troc...@freebsd.org wrote: On Sun, 12 Feb 2012 12:56:58 -0800 Jos Backus wrote: JB Right. So why not add a Unix socket listener to daemon(8) so the rc.d JB script can send commands over the socket instead of using the pidfile? JB This is what supervise/svc let you do today. JB I don't understand why this solution isn't obvious once you are JB committed to running daemon(8) for each service anyway. And then you JB don't need pidfiles because now you have a much better, standard JB control interface (sending commands to daemon(8) and gathering JB responses). Why do you think one is committed to running daemon(8) for each service? daemon(8) is for a program that can't daemonize itself and you want an easy way to run it detached from a terminal. And have an easy way to integrate it in rc(8) using rc.subr(8). And rc.subr(8) knows about pidfiles but knows nothing about unix sockets. I realize that. But ISTR someone mentioned earlier keeping daemon(8) running to keep the pidfile open or something to that effect. Although I don't say that the idea to use a socket file for monitoring and control is bad in general. Right. This approach has a number of benefits. I emailed the daemontools- encore author about including it in FreeBSD but so far he hasn't responded. Jos -- Mikolaj Golub ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r230869 - head/usr.sbin/daemon
Hi Pawel, On Feb 5, 2012 1:48 PM, Pawel Jakub Dawidek p...@freebsd.org wrote: On Sun, Feb 05, 2012 at 11:27:10PM +0200, Mikolaj Golub wrote: Ok, using hastd code as a reference :-) here is my implementation. - I'd not pass selected signals to the child. The parent can still be killed with a whole bunch of different signals that are not passed or cannot be caught or the child process handle them gracefully. Signals should be send to the PID from the pidfile anyway. If someone is sending signals to the parent he has no right to expect well behaviour from the parent. - Now that we handle the pidfile fully in the parent, I'd move dropping provileges after fork(2) and pidfile_write(3). This way pidfiles will always be created with root privileges and we can forget about all the mess with pid directories, etc. - With the above you can wait for child to exit with simple wait(2). If you are going to wait for the child anyway, you are doing almost everything supervise does. All you now need is a Unix domain socket interface so you can receive commands in daemon(1), and run daemon(1) at boot. AND you can remove all the pidfile code :) Jos ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
