some issues with /usr/sbin/service

[Alfred Bartsch]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

we want to use this script for server administration purposes. After
doing some testing, for now there are following issues left:

1) every execution of "service -e"  casts a bunch of unnecessary
warnings into /var/log/messages:
"... /usr/sbin/service: WARNING: $_enable is not set
properly - see rc.conf(5)."
   This is caused by calling "checkyesno()", provided by /etc/subr. It
could be solved by using a local function, named "checkyes" or similar.

The following patch prohibits these annoying messages:

- --- service.orig2013-02-10 20:01:14.0 +0100
+++ service 2013-02-15 08:51:30.0 +0100
@@ -28,6 +28,28 @@

 . /etc/rc.subr
 load_rc_config 'XXX'
+#
+# checkyes var
+#   Test $1 variable.
+#   Return 0 if it's "yes" (et al), nonzero otherwise.
+#
+checkyes()
+{
+eval _value=\$${1}
+debug "checkyes: $1 is set to $_value."
+case $_value in
+
+#   "yes", "true", "on", or "1"
+[Yy][Ee][Ss]|[Tt][Rr][Uu][Ee]|[Oo][Nn]|1)
+return 0
+;;
+
+# everything else
+*)
+return 1
+;;
+esac
+}

 usage () {
echo ''
@@ -100,7 +122,7 @@
if grep -q ^rcvar $file; then
eval `grep ^name= $file`
eval `grep ^rcvar $file`
- -   checkyesno $rcvar 2>/dev/null && echo $file
+   checkyes $rcvar 2>/dev/null && echo $file
fi
done
exit 0



2) "service -e" does not show ALL enabled services, but only those who
are explicitly enabled in /etc/defaults/rc.conf or /etc/rc.conf.
Is that expected behavior?
To catch all enabled services where the _enabled variable is set
within the service procedure itself, perhaps a call like "service
 status" could help.

- -- 
Regards
Alfred Bartsch
Data-Service GmbH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlEeDUMACgkQ5QGe2JdVf3hL5QCggTK3JP9A+ZybIX/iCsuqu5Ic
bYQAn2w7Y2klRoEy7ithoxeVcl4xA2be
=QJmh
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: some issues with /usr/sbin/service

[Jeremy Chadwick]

On Fri, Feb 15, 2013 at 11:26:11AM +0100, Alfred Bartsch wrote:
> we want to use this script for server administration purposes. After
> doing some testing, for now there are following issues left:
> 
> 1) every execution of "service -e"  casts a bunch of unnecessary
> warnings into /var/log/messages:
> "... /usr/sbin/service: WARNING: $_enable is not set
> properly - see rc.conf(5)."
>This is caused by calling "checkyesno()", provided by /etc/subr. It
> could be solved by using a local function, named "checkyes" or similar.
> 
> The following patch prohibits these annoying messages:
> {snip}

Your patch, in effectively, "rewrites" checkyesno() to remove the warn()
call in cases where xxx_enable variables are set to values other than
yes/true/on/1 or no/false/off/0.

Here's a better idea:

Fix your /etc/rc.conf xxx_enable variables which contain values that
aren't permitted.  That's what the warn() is for -- to tell you to fix
them.  :-)

If there are ports (or worse, rc.d scripts) out there which recommend
xxx_enable variables with non-permitted values, then these ports need to
be fixed, not rc.subr(8) nor service(8).  Please disclose what those are
so they can be fixed.

However, "service -e" does not emit warnings on my 2 systems:

root@icarus:~ # service -e
/etc/rc.d/hostid
/etc/rc.d/zvol
/etc/rc.d/ddb
/etc/rc.d/hostid_save
/etc/rc.d/zfs
/etc/rc.d/cleanvar
/etc/rc.d/ip6addrctl
/etc/rc.d/devd
/etc/rc.d/netwait
/etc/rc.d/newsyslog
/etc/rc.d/syslogd
/etc/rc.d/named
/etc/rc.d/ntpdate
/etc/rc.d/dmesg
/etc/rc.d/virecover
/etc/rc.d/motd
/etc/rc.d/ntpd
/etc/rc.d/powerd
/usr/local/etc/rc.d/samba
/usr/local/etc/rc.d/postfix
/usr/local/etc/rc.d/mysql-server
/usr/local/etc/rc.d/apache22
/etc/rc.d/sshd
/etc/rc.d/cron
/etc/rc.d/mixer
/etc/rc.d/inetd
/etc/rc.d/gptboot

root@omake:~ # service -e
/etc/rc.d/hostid
/etc/rc.d/ddb
/etc/rc.d/hostid_save
/etc/rc.d/cleanvar
/etc/rc.d/ip6addrctl
/etc/rc.d/devd
/etc/rc.d/pflog
/etc/rc.d/pf
/etc/rc.d/netwait
/etc/rc.d/newsyslog
/etc/rc.d/syslogd
/etc/rc.d/named
/etc/rc.d/ntpdate
/etc/rc.d/dmesg
/etc/rc.d/virecover
/etc/rc.d/motd
/etc/rc.d/ntpd
/usr/local/etc/rc.d/sa-spamd
/usr/local/etc/rc.d/postfix
/usr/local/etc/rc.d/dovecot
/usr/local/etc/rc.d/apache22
/etc/rc.d/sshd
/etc/rc.d/cron
/etc/rc.d/mixer
/etc/rc.d/inetd
/etc/rc.d/gptboot

Regardless: the permitted values (see above) should be documented in
rc.conf(5) somewhere; I don't see any values other than "yes"
documented, but I'm probably overlooking it.

> 2) "service -e" does not show ALL enabled services, but only those who
> are explicitly enabled in /etc/defaults/rc.conf or /etc/rc.conf.
> Is that expected behavior?

It is the expected behaviour as I understand it per the man page.  You
should also see rc(8).

As I understand it, an "enabled service" is not a process that's
running, but something that has a yes/true/on/1 value for its
xxx_enabled variable in rc.conf/related file.  That's just how it works.
If you're used to, for example, Solaris "svcs" then yes things are
different here.

> To catch all enabled services where the _enabled variable is set
> within the service procedure itself, perhaps a call like "service
>  status" could help.

There is already "service  status".  See rc(8) (search for
"status") or try it yourself on a running service.  Example:

root@icarus:~ # service postfix status
postfix is running as pid 1378.

Can you rephrase or give an example of what you want?

-- 
| Jeremy Chadwick   j...@koitsu.org |
| UNIX Systems Administratorhttp://jdc.koitsu.org/ |
| Mountain View, CA, US|
| Making life hard for others since 1977. PGP 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 9-STABLE -> NFS -> NetAPP:

[John Baldwin]

On Thursday, February 14, 2013 10:05:56 pm Rick Macklem wrote:
> Marc Fournier wrote:
> > On 2013-02-13, at 3:54 PM, Rick Macklem  wrote:
> > 
> > >>
> > > The pid that is in "T" state for the "ps auxlH".
> > 
> > Different server, last kernel update on Jan 22nd, https process this
> > time instead of du last time.
> > 
> > I've attached:
> > 
> > ps auxlH
> > ps auxlH of just the processes that are in TJ state (6 httpd servers)
> > procstat output for each of the 6 process
> > 
> > 
> > 
> > 
> > They are included as attachments … if these don't make it through, let
> > me know, just figured I'd try and keep it compact ...
> Well, I've looked at this call path a little closer:
> 16693 104135 httpd-mi_switch+0x186 
thread_suspend_check+0x19f sleepq_catch_signals+0x1c5
>   sleepq_timedwait_sig+0x19 _sleep+0x2ca clnt_vc_call+0x763 
clnt_reconnect_call+0xfb newnfs_request+0xadb
>   nfscl_request+0x72 nfsrpc_accessrpc+0x1df nfs34_access_otw+0x56 
nfs_access+0x306 vn_open_cred+0x5a8
>   kern_openat+0x20a amd64_syscall+0x540 Xfast_syscall+0xf7 
> 
> I am probably way off, since I am not familiar with this stuff, but it
> seems to me that thread_suspend_check() should just return 0 for the
> case where stop_allowed == SIG_STOP_NOT_ALLOWED (TDF_SBDRY flag set)
> instead of sitting in the loop and doing a mi_switch(). I'm not even
> sure if it should call thread_suspend_check() for this case, but there
> are cases in thread_suspend_check() that I don't understand.
> 
> Although I don't really understand thread_suspend_check(), I've attached
> a simple patch that might be a starting point for fixing this?
> 
> I wouldn't recommend trying the patch until kib and/or jhb weigh in
> on whether it makes any sense.

I think this is the right idea, but in HEAD with the sigdeferstop() changes it 
should just check for TDF_SBDRY instead of adding a new parameter.  I think
checking for TDF_SBDRY will work even in 9 (and will make the patch smaller).  
Also, I think this is only needed for stop signals.  Other suspend requests 
will eventually resume the thread, it is only stop signals that can cause the 
thread to get stuck indefinitely (since it depends on the user sending 
SIGCONT).

Marc, are you using SIGSTOP?

Index: kern_thread.c
===
--- kern_thread.c   (revision 246122)
+++ kern_thread.c   (working copy)
@@ -795,6 +795,17 @@ thread_suspend_check(int return_instead)
return (ERESTART);
 
/*
+* Ignore suspend requests for stop signals if they
+* are deferred.
+*/
+   if (P_SHOULDSTOP(p) == P_STOPPED_SIG &&
+   td->td_flags & TDF_SBDRY) {
+   KASSERT(return_instead,
+   ("TDF_SBDRY set for unsafe thread_suspend_check"));
+   return (0);
+   }
+
+   /*
 * If the process is waiting for us to exit,
 * this thread should just suicide.
 * Assumes that P_SINGLE_EXIT implies P_STOPPED_SINGLE.

-- 
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD-9.1 would not boot on pentium3 laptop

[John Baldwin]

On Thursday, February 07, 2013 2:25:17 pm John Baldwin wrote:
> On Thursday, February 07, 2013 1:28:30 pm Mikhail T. wrote:
> > On 07.02.2013 13:16, John Baldwin wrote:
> > > Can you get pciconf -lc output?
> > Here:
> > 
> > hostb0@pci0:0:0:0:  class=0x06 card=0x
> > chip=0x11308086 rev=0x02 hdr=0x00
> >  cap 09[88] = vendor (length 4) Intel cap 15 version 1
> >  cap 02[a0] = AGP 4x 2x 1x SBA disabled
> 
> Looks like you have one of the systems the comment mentions.  Try this patch 
> to see if ichss is disabled automatically for you:

Were you able to test this patch?
 
> Index: ichss.c
> ===
> --- ichss.c   (revision 246122)
> +++ ichss.c   (working copy)
> @@ -67,7 +67,7 @@ struct ichss_softc {
>  #define PCI_DEV_82801BA  0x244c /* ICH2M */
>  #define PCI_DEV_82801CA  0x248c /* ICH3M */
>  #define PCI_DEV_82801DB  0x24cc /* ICH4M */
> -#define PCI_DEV_82815BA  0x1130 /* Unsupported/buggy part */
> +#define PCI_DEV_82815_MC 0x1130 /* Unsupported/buggy part */
>  
>  /* PCI config registers for finding PMBASE and enabling SpeedStep. */
>  #define ICHSS_PMBASE_OFFSET  0x40
> @@ -155,9 +155,6 @@ ichss_identify(driver_t *driver, device_t parent)
>* E.g. see Section 6.1 "PCI Devices and Functions" and table 6.1 of
>* Intel(r) 82801BA I/O Controller Hub 2 (ICH2) and Intel(r) 82801BAM
>* I/O Controller Hub 2 Mobile (ICH2-M).
> -  *
> -  * TODO: add a quirk to disable if we see the 82815_MC along
> -  * with the 82801BA and revision < 5.
>*/
>   ich_device = pci_find_bsf(0, 0x1f, 0);
>   if (ich_device == NULL ||
> @@ -167,6 +164,22 @@ ichss_identify(driver_t *driver, device_t parent)
>   pci_get_device(ich_device) != PCI_DEV_82801DB))
>   return;
>  
> + /*
> +  * Certain systems with ICH2 and an Intel 82815_MC host bridge
> +  * where the host bridge's revision is < 5 lockup if SpeedStep
> +  * is used.
> +  */
> + if (pci_get_device(ich_device) == PCI_DEV_82801BA) {
> + device_t hostb;
> +
> + hostb = pci_find_bsf(0, 0, 0);
> + if (hostb != NULL &&
> + pci_get_vendor(hostb) == PCI_VENDOR_INTEL &&
> + pci_get_device(hostb) == PCI_DEV_82815_MC &&
> + pci_get_revid(hostb) < 5)
> + return;
> + }
> +
>   /* Find the PMBASE register from our PCI config header. */
>   pmbase = pci_read_config(ich_device, ICHSS_PMBASE_OFFSET,
>   sizeof(pmbase));
> 

-- 
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Final Reminder: FreeBSD Quarterly Status Reports, July--December, 2012

[Gabor Pali]

Hello there,

Just a final reminder: the deadline for the reports is this Sunday.

On Sun, Feb 10, 2013 at 3:42 PM, Gabor Pali  wrote:
> Let me call your attention to the approaching deadline of the next
> set(s) of FreeBSD Quarterly Status Reports.  Please consider
> submitting a few lines on your FreeBSD-related project, we are
> counting on all of you! :-)
>
> On Sun, Jan 13, 2013 at 10:57 PM, Gabor Pali  wrote:
>>Please note that the deadline for submissions covering the period
>>between July and December 2012 is February 17th, 2013.
>
> You can find more details on submission at the Project's web site [1]
> but you are free to ask me directly (in private) if you need help with
> this.
>
> [1] http://www.freebsd.org/news/status/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 9-STABLE -> NFS -> NetAPP:

[Konstantin Belousov]

On Fri, Feb 15, 2013 at 08:44:43AM -0500, John Baldwin wrote:
> On Thursday, February 14, 2013 10:05:56 pm Rick Macklem wrote:
> > Marc Fournier wrote:
> > > On 2013-02-13, at 3:54 PM, Rick Macklem  wrote:
> > > 
> > > >>
> > > > The pid that is in "T" state for the "ps auxlH".
> > > 
> > > Different server, last kernel update on Jan 22nd, https process this
> > > time instead of du last time.
> > > 
> > > I've attached:
> > > 
> > > ps auxlH
> > > ps auxlH of just the processes that are in TJ state (6 httpd servers)
> > > procstat output for each of the 6 process
> > > 
> > > 
> > > 
> > > 
> > > They are included as attachments ??? if these don't make it through, let
> > > me know, just figured I'd try and keep it compact ...
> > Well, I've looked at this call path a little closer:
> > 16693 104135 httpd-mi_switch+0x186 
> thread_suspend_check+0x19f sleepq_catch_signals+0x1c5
> >   sleepq_timedwait_sig+0x19 _sleep+0x2ca clnt_vc_call+0x763 
> clnt_reconnect_call+0xfb newnfs_request+0xadb
> >   nfscl_request+0x72 nfsrpc_accessrpc+0x1df nfs34_access_otw+0x56 
> nfs_access+0x306 vn_open_cred+0x5a8
> >   kern_openat+0x20a amd64_syscall+0x540 Xfast_syscall+0xf7 
> > 
> > I am probably way off, since I am not familiar with this stuff, but it
> > seems to me that thread_suspend_check() should just return 0 for the
> > case where stop_allowed == SIG_STOP_NOT_ALLOWED (TDF_SBDRY flag set)
> > instead of sitting in the loop and doing a mi_switch(). I'm not even
> > sure if it should call thread_suspend_check() for this case, but there
> > are cases in thread_suspend_check() that I don't understand.
> > 
> > Although I don't really understand thread_suspend_check(), I've attached
> > a simple patch that might be a starting point for fixing this?
> > 
> > I wouldn't recommend trying the patch until kib and/or jhb weigh in
> > on whether it makes any sense.
> 
> I think this is the right idea, but in HEAD with the sigdeferstop() changes 
> it 
> should just check for TDF_SBDRY instead of adding a new parameter.  I think
> checking for TDF_SBDRY will work even in 9 (and will make the patch smaller). 
>  
> Also, I think this is only needed for stop signals.  Other suspend requests 
> will eventually resume the thread, it is only stop signals that can cause the 
> thread to get stuck indefinitely (since it depends on the user sending 
> SIGCONT).
> 
> Marc, are you using SIGSTOP?
> 
> Index: kern_thread.c
> ===
> --- kern_thread.c (revision 246122)
> +++ kern_thread.c (working copy)
> @@ -795,6 +795,17 @@ thread_suspend_check(int return_instead)
>   return (ERESTART);
>  
>   /*
> +  * Ignore suspend requests for stop signals if they
> +  * are deferred.
> +  */
> + if (P_SHOULDSTOP(p) == P_STOPPED_SIG &&
> + td->td_flags & TDF_SBDRY) {
> + KASSERT(return_instead,
> + ("TDF_SBDRY set for unsafe thread_suspend_check"));
> + return (0);
> + }
> +
> + /*
>* If the process is waiting for us to exit,
>* this thread should just suicide.
>* Assumes that P_SINGLE_EXIT implies P_STOPPED_SINGLE.

This looks correct.


pgpwJnJsA6DUs.pgp
Description: PGP signature

Re: 9-STABLE -> NFS -> NetAPP:

[Rick Macklem]

Konstantin Belousov wrote:
> On Fri, Feb 15, 2013 at 08:44:43AM -0500, John Baldwin wrote:
> > On Thursday, February 14, 2013 10:05:56 pm Rick Macklem wrote:
> > > Marc Fournier wrote:
> > > > On 2013-02-13, at 3:54 PM, Rick Macklem 
> > > > wrote:
> > > >
> > > > >>
> > > > > The pid that is in "T" state for the "ps auxlH".
> > > >
> > > > Different server, last kernel update on Jan 22nd, https process
> > > > this
> > > > time instead of du last time.
> > > >
> > > > I've attached:
> > > >
> > > > ps auxlH
> > > > ps auxlH of just the processes that are in TJ state (6 httpd
> > > > servers)
> > > > procstat output for each of the 6 process
> > > >
> > > >
> > > >
> > > >
> > > > They are included as attachments ??? if these don't make it
> > > > through, let
> > > > me know, just figured I'd try and keep it compact ...
> > > Well, I've looked at this call path a little closer:
> > > 16693 104135 httpd - mi_switch+0x186
> > thread_suspend_check+0x19f sleepq_catch_signals+0x1c5
> > >   sleepq_timedwait_sig+0x19 _sleep+0x2ca clnt_vc_call+0x763
> > clnt_reconnect_call+0xfb newnfs_request+0xadb
> > >   nfscl_request+0x72 nfsrpc_accessrpc+0x1df nfs34_access_otw+0x56
> > nfs_access+0x306 vn_open_cred+0x5a8
> > >   kern_openat+0x20a amd64_syscall+0x540 Xfast_syscall+0xf7
> > >
> > > I am probably way off, since I am not familiar with this stuff,
> > > but it
> > > seems to me that thread_suspend_check() should just return 0 for
> > > the
> > > case where stop_allowed == SIG_STOP_NOT_ALLOWED (TDF_SBDRY flag
> > > set)
> > > instead of sitting in the loop and doing a mi_switch(). I'm not
> > > even
> > > sure if it should call thread_suspend_check() for this case, but
> > > there
> > > are cases in thread_suspend_check() that I don't understand.
> > >
> > > Although I don't really understand thread_suspend_check(), I've
> > > attached
> > > a simple patch that might be a starting point for fixing this?
> > >
> > > I wouldn't recommend trying the patch until kib and/or jhb weigh
> > > in
> > > on whether it makes any sense.
> >
> > I think this is the right idea, but in HEAD with the sigdeferstop()
> > changes it
> > should just check for TDF_SBDRY instead of adding a new parameter. I
> > think
> > checking for TDF_SBDRY will work even in 9 (and will make the patch
> > smaller).
> > Also, I think this is only needed for stop signals. Other suspend
> > requests
> > will eventually resume the thread, it is only stop signals that can
> > cause the
> > thread to get stuck indefinitely (since it depends on the user
> > sending
> > SIGCONT).
> >
> > Marc, are you using SIGSTOP?
> >
> > Index: kern_thread.c
> > ===
> > --- kern_thread.c (revision 246122)
> > +++ kern_thread.c (working copy)
> > @@ -795,6 +795,17 @@ thread_suspend_check(int return_instead)
> > return (ERESTART);
> >
> > /*
> > + * Ignore suspend requests for stop signals if they
> > + * are deferred.
> > + */
> > + if (P_SHOULDSTOP(p) == P_STOPPED_SIG &&
> > + td->td_flags & TDF_SBDRY) {
> > + KASSERT(return_instead,
> > + ("TDF_SBDRY set for unsafe thread_suspend_check"));
> > + return (0);
> > + }
> > +
> > + /*
> >  * If the process is waiting for us to exit,
> >  * this thread should just suicide.
> >  * Assumes that P_SINGLE_EXIT implies P_STOPPED_SINGLE.
> 
> This looks correct.
Righto. Thanks jhb and kib for looking at this.

Btw John, PBDRY still gets set for sleeps in the sys/rpc code. However,
as far as I can tell, it just sets TDF_SBDRY when it is already set
and seems harmless. (Since this code is supposed to be generic and not
specific to NFS, maybe it should stay that way?)

Also, since PBDRY on the sleeps sets TDF_SBDRY, I think the above patch
is ok for stable/9 without your recent head patch.

Maybe Marc can test the above patch?

Thanks everyone for your help, rick
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Ipsec VPN tunnel from a Win/7 box?

[Kurt Lidl]

Hmm.

I've got IPSEC tunnels from Windows XP and Windows 7 working
to a FreeBSD 8.3 host, using NAT/T.

I'm using the Shrewsoft client: http://www.shrew.net/software

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

Re: Ipsec VPN tunnel from a Win/7 box?

[Karl Denninger]

On 2/15/2013 9:37 AM, Kurt Lidl wrote:
>
> Hmm.
>
> I've got IPSEC tunnels from Windows XP and Windows 7 working
> to a FreeBSD 8.3 host, using NAT/T.
>
> I'm using the Shrewsoft client: http://www.shrew.net/software
>
> -Kurt
> _

The goal is to do it using only the native Win/7 VPN support.

So far I've failed for IPSEC :-)

-- 
-- Karl Denninger
/The Market Ticker ®/ 
Cuda Systems LLC
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 9-STABLE -> NFS -> NetAPP:

[John Baldwin]

On Friday, February 15, 2013 10:21:11 am Rick Macklem wrote:
> Konstantin Belousov wrote:
> > On Fri, Feb 15, 2013 at 08:44:43AM -0500, John Baldwin wrote:
> > > On Thursday, February 14, 2013 10:05:56 pm Rick Macklem wrote:
> > > > Marc Fournier wrote:
> > > > > On 2013-02-13, at 3:54 PM, Rick Macklem 
> > > > > wrote:
> > > > >
> > > > > >>
> > > > > > The pid that is in "T" state for the "ps auxlH".
> > > > >
> > > > > Different server, last kernel update on Jan 22nd, https process
> > > > > this
> > > > > time instead of du last time.
> > > > >
> > > > > I've attached:
> > > > >
> > > > > ps auxlH
> > > > > ps auxlH of just the processes that are in TJ state (6 httpd
> > > > > servers)
> > > > > procstat output for each of the 6 process
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > They are included as attachments ??? if these don't make it
> > > > > through, let
> > > > > me know, just figured I'd try and keep it compact ...
> > > > Well, I've looked at this call path a little closer:
> > > > 16693 104135 httpd - mi_switch+0x186
> > > thread_suspend_check+0x19f sleepq_catch_signals+0x1c5
> > > >   sleepq_timedwait_sig+0x19 _sleep+0x2ca clnt_vc_call+0x763
> > > clnt_reconnect_call+0xfb newnfs_request+0xadb
> > > >   nfscl_request+0x72 nfsrpc_accessrpc+0x1df nfs34_access_otw+0x56
> > > nfs_access+0x306 vn_open_cred+0x5a8
> > > >   kern_openat+0x20a amd64_syscall+0x540 Xfast_syscall+0xf7
> > > >
> > > > I am probably way off, since I am not familiar with this stuff,
> > > > but it
> > > > seems to me that thread_suspend_check() should just return 0 for
> > > > the
> > > > case where stop_allowed == SIG_STOP_NOT_ALLOWED (TDF_SBDRY flag
> > > > set)
> > > > instead of sitting in the loop and doing a mi_switch(). I'm not
> > > > even
> > > > sure if it should call thread_suspend_check() for this case, but
> > > > there
> > > > are cases in thread_suspend_check() that I don't understand.
> > > >
> > > > Although I don't really understand thread_suspend_check(), I've
> > > > attached
> > > > a simple patch that might be a starting point for fixing this?
> > > >
> > > > I wouldn't recommend trying the patch until kib and/or jhb weigh
> > > > in
> > > > on whether it makes any sense.
> > >
> > > I think this is the right idea, but in HEAD with the sigdeferstop()
> > > changes it
> > > should just check for TDF_SBDRY instead of adding a new parameter. I
> > > think
> > > checking for TDF_SBDRY will work even in 9 (and will make the patch
> > > smaller).
> > > Also, I think this is only needed for stop signals. Other suspend
> > > requests
> > > will eventually resume the thread, it is only stop signals that can
> > > cause the
> > > thread to get stuck indefinitely (since it depends on the user
> > > sending
> > > SIGCONT).
> > >
> > > Marc, are you using SIGSTOP?
> > >
> > > Index: kern_thread.c
> > > ===
> > > --- kern_thread.c (revision 246122)
> > > +++ kern_thread.c (working copy)
> > > @@ -795,6 +795,17 @@ thread_suspend_check(int return_instead)
> > >   return (ERESTART);
> > >
> > >   /*
> > > + * Ignore suspend requests for stop signals if they
> > > + * are deferred.
> > > + */
> > > + if (P_SHOULDSTOP(p) == P_STOPPED_SIG &&
> > > + td->td_flags & TDF_SBDRY) {
> > > + KASSERT(return_instead,
> > > + ("TDF_SBDRY set for unsafe thread_suspend_check"));
> > > + return (0);
> > > + }
> > > +
> > > + /*
> > >* If the process is waiting for us to exit,
> > >* this thread should just suicide.
> > >* Assumes that P_SINGLE_EXIT implies P_STOPPED_SINGLE.
> > 
> > This looks correct.
> Righto. Thanks jhb and kib for looking at this.
> 
> Btw John, PBDRY still gets set for sleeps in the sys/rpc code. However,
> as far as I can tell, it just sets TDF_SBDRY when it is already set
> and seems harmless. (Since this code is supposed to be generic and not
> specific to NFS, maybe it should stay that way?)

In HEAD PBDRY is now a nop and the existing sigdeferstop() stuff should
cover the calls in sys/rpc.

> Also, since PBDRY on the sleeps sets TDF_SBDRY, I think the above patch
> is ok for stable/9 without your recent head patch.

Yep, exactly.

> Thanks everyone for your help, rick

Thanks for your debugging!

-- 
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

new jail(8) ignoring devfs_ruleset?

[Harald Schmalzbauer]

 Hello,

like already posted, on 9.1-R, I highly appreciate the new jail(8) and
jail.conf capabilities. Thanks for that extension!

Accidentally I saw that "devfs_ruleset" seems to be ignored.
If I list /dev/ I see all the hosts disk devices etc.
I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf.
  Inside the jail,
sysctl security.jail.devfs_ruleset returnes "1".
But like mentioned, I can access all devices...

Thanks for any help,

-Harry

(not subscribed to freebsd-jail@)



signature.asc
Description: OpenPGP digital signature

mount lag, umounting returns wrong "Device busy"

[Harald Schmalzbauer]

 Hello,

while playing with new jail features, I recognized that manually
umounting doesn't work as I'd expect.
After jail has been destroyed, the following mountpoint is active:
/dev/gpt/jailname1ROOT on /.jail.jailname1 (ufs, local, read-only)

There was var mounted to /.jail.jailname1/var but that sucessfully umounted.
'fstat' also shows no open files in /.jail.jailname1

But when I do 'umount /.jail.jailname' I get "Device busy" returned.
Some minutes later umounting works.
But I always have to wait some time, although nothing is open and
nothing is mounted above.

Does anybody have an idea what could cause that false "Device busy"?

-Harry



signature.asc
Description: OpenPGP digital signature

Re: mount lag, umounting returns wrong "Device busy"

[Mateusz Guzik]

On Fri, Feb 15, 2013 at 05:43:16PM +0100, Harald Schmalzbauer wrote:
>  Hello,
> 
> while playing with new jail features, I recognized that manually
> umounting doesn't work as I'd expect.
> After jail has been destroyed, the following mountpoint is active:
> /dev/gpt/jailname1ROOT on /.jail.jailname1 (ufs, local, read-only)
> 
> There was var mounted to /.jail.jailname1/var but that sucessfully umounted.
> 'fstat' also shows no open files in /.jail.jailname1
> 
> But when I do 'umount /.jail.jailname' I get "Device busy" returned.
> Some minutes later umounting works.
> But I always have to wait some time, although nothing is open and
> nothing is mounted above.
> 
> Does anybody have an idea what could cause that false "Device busy"?
> 

My guess is that the jail was not dead yet and it held a reference for
/.jail.jailname1's vnode.

jls -v should show the jail.

I don't know if this can happen, but my guess is that not-yet-expired
network connections hold reference to a jail preventing it from being
destroyed. So I would definitely checkout netstat output. There may be
other posibilities, but nothing obvious comes to my mind at the moment.


-- 
Mateusz Guzik 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: mount lag, umounting returns wrong "Device busy"

[Harald Schmalzbauer]

 schrieb Mateusz Guzik am 15.02.2013 17:50 (localtime):
> On Fri, Feb 15, 2013 at 05:43:16PM +0100, Harald Schmalzbauer wrote:
>>  Hello,
>>
>> while playing with new jail features, I recognized that manually
>> umounting doesn't work as I'd expect.
>> After jail has been destroyed, the following mountpoint is active:
>> /dev/gpt/jailname1ROOT on /.jail.jailname1 (ufs, local, read-only)
>>
>> There was var mounted to /.jail.jailname1/var but that sucessfully umounted.
>> 'fstat' also shows no open files in /.jail.jailname1
>>
>> But when I do 'umount /.jail.jailname' I get "Device busy" returned.
>> Some minutes later umounting works.
>> But I always have to wait some time, although nothing is open and
>> nothing is mounted above.
>>
>> Does anybody have an idea what could cause that false "Device busy"?
>>
> My guess is that the jail was not dead yet and it held a reference for
> /.jail.jailname1's vnode.
>
> jls -v should show the jail.
>
> I don't know if this can happen, but my guess is that not-yet-expired
> network connections hold reference to a jail preventing it from being
> destroyed. So I would definitely checkout netstat output. There may be
> other posibilities, but nothing obvious comes to my mind at the moment.

Good hint, I found out that returning the NIC (using jail with vnet)
takes some time and as soon as the NIC shows up back in the host, I also
can umount the jail's root mount point.
I have no idea about the internals of moving NICs. Is it "normal" that
it takes some time to return the NIC?
Almost every time I remove the jail (jail -r), I have to issue the
command twice. First, I see services getting stoped, but then the line:
  jail: kevent: No such process
'jail -r' cancels at that point (jls shows it active)
After the second 'jail -r' I get the following lines:
.
Terminated
gentlemail: removed
umount: unmount of /.jail.jailname1 failed: Device busy

Then 'jls' doesn't list the jail anymore, but the NIC still doesn't show
up in the hosts network stack.
And that's the cause for keeping the root mountpoint busy...
Could that be related to the wrong umount-order with 'jail -r'?

Thanks,

-Harry



signature.asc
Description: OpenPGP digital signature

Re: some issues with /usr/sbin/service

[Alfred Bartsch]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Jeremy,
thanks for your quick response. If I understand you right, you don't
see any necessity for updating /usr/sbin/service. I'll try to make my
point of view more comprehensible.


Am 15.02.2013 11:57, schrieb Jeremy Chadwick:
> On Fri, Feb 15, 2013 at 11:26:11AM +0100, Alfred Bartsch wrote:
>> we want to use this script for server administration purposes.
>> After doing some testing, for now there are following issues
>> left:
>> 
>> 1) every execution of "service -e"  casts a bunch of unnecessary 
>> warnings into /var/log/messages: "... /usr/sbin/service: WARNING:
>> $_enable is not set properly - see rc.conf(5)." This is
>> caused by calling "checkyesno()", provided by /etc/subr. It could
>> be solved by using a local function, named "checkyes" or
>> similar.
>> 
>> The following patch prohibits these annoying messages: {snip}
> 
> Your patch, in effectively, "rewrites" checkyesno() to remove the
> warn() call in cases where xxx_enable variables are set to values
> other than yes/true/on/1 or no/false/off/0.
> 

Yes, that's exactly my proposition.

> Here's a better idea:
> 
> Fix your /etc/rc.conf xxx_enable variables which contain values
> that aren't permitted.  That's what the warn() is for -- to tell
> you to fix them.  :-)

That's not the point.
To my knowledge all wrong settings of xxx_enable are reliably
discovered during system startup, where all subr procedures are called
with "start" as an argument from /etc/rc.
At least in my environment(s) there are no such reported warnings from
startup or shutdown.
"service -e" does some heuristic attempts to redetermine the
"original" startup setting of the XXX_enable variable without
executing the startup script, and thus fails in all cases where this
variable setting is done exclusively via the startup script itself.

/usr/bin/service can be run at any time, even if the variable settings
of the system startup (/etc/rc) are no longer valid.

> 
> If there are ports (or worse, rc.d scripts) out there which
> recommend xxx_enable variables with non-permitted values, then
> these ports need to be fixed, not rc.subr(8) nor service(8).
> Please disclose what those are so they can be fixed.
> 
> However, "service -e" does not emit warnings on my 2 systems:

The responsible "warn()" function emits messages to stderr and/or
syslog, but stderr is redirected to /dev/null in /usr/sbin/service, so
these messages can only be seen in /var/log/messages or
/var/log/all.log, if syslog is configured as appropriate (user.notice)
and /usr/bin/logger is executable.

> 
> root@icarus:~ # service -e /etc/rc.d/hostid /etc/rc.d/zvol 
> /etc/rc.d/ddb /etc/rc.d/hostid_save /etc/rc.d/zfs 
> /etc/rc.d/cleanvar /etc/rc.d/ip6addrctl /etc/rc.d/devd 
> /etc/rc.d/netwait /etc/rc.d/newsyslog /etc/rc.d/syslogd 
> /etc/rc.d/named /etc/rc.d/ntpdate /etc/rc.d/dmesg 
> /etc/rc.d/virecover /etc/rc.d/motd /etc/rc.d/ntpd /etc/rc.d/powerd 
> /usr/local/etc/rc.d/samba /usr/local/etc/rc.d/postfix 
> /usr/local/etc/rc.d/mysql-server /usr/local/etc/rc.d/apache22 
> /etc/rc.d/sshd /etc/rc.d/cron /etc/rc.d/mixer /etc/rc.d/inetd 
> /etc/rc.d/gptboot
> 
> root@omake:~ # service -e /etc/rc.d/hostid /etc/rc.d/ddb 
> /etc/rc.d/hostid_save /etc/rc.d/cleanvar /etc/rc.d/ip6addrctl 
> /etc/rc.d/devd /etc/rc.d/pflog /etc/rc.d/pf /etc/rc.d/netwait 
> /etc/rc.d/newsyslog /etc/rc.d/syslogd /etc/rc.d/named 
> /etc/rc.d/ntpdate /etc/rc.d/dmesg /etc/rc.d/virecover 
> /etc/rc.d/motd /etc/rc.d/ntpd /usr/local/etc/rc.d/sa-spamd 
> /usr/local/etc/rc.d/postfix /usr/local/etc/rc.d/dovecot 
> /usr/local/etc/rc.d/apache22 /etc/rc.d/sshd /etc/rc.d/cron 
> /etc/rc.d/mixer /etc/rc.d/inetd /etc/rc.d/gptboot
> 
> Regardless: the permitted values (see above) should be documented
> in rc.conf(5) somewhere; I don't see any values other than "yes" 
> documented, but I'm probably overlooking it.
> 

This may be true for all system startup scripts (/etc/rc.d) but is
definitively not true for local startup scripts (/usr/local/etc/rc.d,
...). Let us suppose you added "XXX_enable" settings for your daemons
from ports to /etc/rc.conf and did not install any other port
containing startup script(s). In this particular case there is no
warning emitted.
After installing additional ports containing rc.d scripts without
modifying /etc/rc.conf, you are able to restart your system again and
again without such warnings being emitted, in these cases XXX_enable
of these additional ports normally defaults to "NO". During execution
of "service -e", XXX_enable defaults to "" and therefore /etc/subr
emits a warning, which is IMHO at least misleading. The proposed patch
solves this issue for me, YMMV.

>> 2) "service -e" does not show ALL enabled services, but only
>> those who are explicitly enabled in /etc/defaults/rc.conf or
>> /etc/rc.conf. Is that expected behavior?
> 
> It is the expected behaviour as I understand it per the man page.
> You should also see rc(8).
> 
> As I understand it, an "enabl

Re: some issues with /usr/sbin/service

[Gary Palmer]

On Fri, Feb 15, 2013 at 02:57:10AM -0800, Jeremy Chadwick wrote:
> On Fri, Feb 15, 2013 at 11:26:11AM +0100, Alfred Bartsch wrote:
> > we want to use this script for server administration purposes. After
> > doing some testing, for now there are following issues left:
> > 
> > 1) every execution of "service -e"  casts a bunch of unnecessary
> > warnings into /var/log/messages:
> > "... /usr/sbin/service: WARNING: $_enable is not set
> > properly - see rc.conf(5)."
> >This is caused by calling "checkyesno()", provided by /etc/subr. It
> > could be solved by using a local function, named "checkyes" or similar.
> > 
> > The following patch prohibits these annoying messages:
> > {snip}
> 
> Your patch, in effectively, "rewrites" checkyesno() to remove the warn()
> call in cases where xxx_enable variables are set to values other than
> yes/true/on/1 or no/false/off/0.
> 
> Here's a better idea:
> 
> Fix your /etc/rc.conf xxx_enable variables which contain values that
> aren't permitted.  That's what the warn() is for -- to tell you to fix
> them.  :-)

It also warns if xxx_enable isn't set.  I have a number of ports installed
which I don't want to run by default but may run later, or which have
daemons but I don't want the daemon but some other functionality.  
rsync and fetchmail are two perfect examples of the latter.

If I don't have xxx_enable in /usr/local/etc/rc.conf I get the warning.
Should I really have to go through and explicitly set the xxx_enable flags
to "no"?  Or should the code be smart enough to recognise that the variable
not being present is equivalent to "no"?

If the requirement is that all installed rc.d scripts have a xxx_enable flag
set to yes or no at all times, then the current ports infrastructure is sadly
lacking as I don't have anything under /usr/local/etc/defaults/ at all (if
that is even a valid location).  And I'd prefer ports not try and automagically
frob /etc/rc.conf, /etc/rc.conf.local or /etc/defaults/rc.conf to add/remove
xxx_enable lines as that can go wrong.

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

Re: some issues with /usr/sbin/service

[Jeremy Chadwick]

On Fri, Feb 15, 2013 at 02:32:10PM -0500, Gary Palmer wrote:
> On Fri, Feb 15, 2013 at 02:57:10AM -0800, Jeremy Chadwick wrote:
> > On Fri, Feb 15, 2013 at 11:26:11AM +0100, Alfred Bartsch wrote:
> > > we want to use this script for server administration purposes. After
> > > doing some testing, for now there are following issues left:
> > > 
> > > 1) every execution of "service -e"  casts a bunch of unnecessary
> > > warnings into /var/log/messages:
> > > "... /usr/sbin/service: WARNING: $_enable is not set
> > > properly - see rc.conf(5)."
> > >This is caused by calling "checkyesno()", provided by /etc/subr. It
> > > could be solved by using a local function, named "checkyes" or similar.
> > > 
> > > The following patch prohibits these annoying messages:
> > > {snip}
> > 
> > Your patch, in effectively, "rewrites" checkyesno() to remove the warn()
> > call in cases where xxx_enable variables are set to values other than
> > yes/true/on/1 or no/false/off/0.
> > 
> > Here's a better idea:
> > 
> > Fix your /etc/rc.conf xxx_enable variables which contain values that
> > aren't permitted.  That's what the warn() is for -- to tell you to fix
> > them.  :-)
> 
> It also warns if xxx_enable isn't set.  I have a number of ports installed
> which I don't want to run by default but may run later, or which have
> daemons but I don't want the daemon but some other functionality.  
> rsync and fetchmail are two perfect examples of the latter.
> 
> If I don't have xxx_enable in /usr/local/etc/rc.conf I get the warning.
> Should I really have to go through and explicitly set the xxx_enable flags
> to "no"?  Or should the code be smart enough to recognise that the variable
> not being present is equivalent to "no"?
>
> If the requirement is that all installed rc.d scripts have a xxx_enable flag
> set to yes or no at all times, then the current ports infrastructure is sadly
> lacking as I don't have anything under /usr/local/etc/defaults/ at all (if
> that is even a valid location).  And I'd prefer ports not try and 
> automagically
> frob /etc/rc.conf, /etc/rc.conf.local or /etc/defaults/rc.conf to add/remove
> xxx_enable lines as that can go wrong.

This is the first I've heard of something called /usr/local/etc/rc.conf.
What is this file?  I don't see it mentioned as being read/used by
rc_conf_files (see /etc/defaults/rc.conf), at least not via stock.  Are
you redefining rc_conf_files or are you somehow source'ing the file
yourself?

Regardless, I can't confirm that behaviour:

root@icarus:~ # grep mysql_ /etc/rc.conf
# mysql_enable="yes"
# mysql_dbdir="/storage/mysql"

root@icarus:~ # service -e
/etc/rc.d/hostid
/etc/rc.d/zvol
/etc/rc.d/ddb
/etc/rc.d/hostid_save
/etc/rc.d/zfs
/etc/rc.d/cleanvar
/etc/rc.d/ip6addrctl
/etc/rc.d/devd
/etc/rc.d/netwait
/etc/rc.d/newsyslog
/etc/rc.d/syslogd
/etc/rc.d/named
/etc/rc.d/ntpdate
/etc/rc.d/dmesg
/etc/rc.d/virecover
/etc/rc.d/motd
/etc/rc.d/ntpd
/etc/rc.d/powerd
/usr/local/etc/rc.d/samba
/usr/local/etc/rc.d/postfix
/usr/local/etc/rc.d/apache22
/etc/rc.d/sshd
/etc/rc.d/cron
/etc/rc.d/mixer
/etc/rc.d/inetd
/etc/rc.d/gptboot

Same goes for if I removed the commented-out lines (shouldn't matter but
I tested it anyway).

System:

FreeBSD icarus.home.lan 9.1-STABLE FreeBSD 9.1-STABLE #0 r246644: Sun Feb 10 
16:55:49 PST 2013 
r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_9_amd64  amd64

root@icarus:~ # grep '$FreeBSD' /etc/rc /etc/rc.subr
/etc/rc:# $FreeBSD: stable/9/etc/rc 233943 2012-04-06 11:07:44Z ed $
/etc/rc.subr:# $FreeBSD: stable/9/etc/rc.subr 243754 2012-12-01 15:46:27Z crees 
$

I fully agree that if this were the case (having to set xxx_enable="no"
explicitly) that would be a bug.

-- 
| Jeremy Chadwick   j...@koitsu.org |
| UNIX Systems Administratorhttp://jdc.koitsu.org/ |
| Mountain View, CA, US|
| Making life hard for others since 1977. PGP 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: some issues with /usr/sbin/service

[Jeremy Chadwick]

On Fri, Feb 15, 2013 at 01:20:20PM -0800, Jeremy Chadwick wrote:
> On Fri, Feb 15, 2013 at 02:32:10PM -0500, Gary Palmer wrote:
> > On Fri, Feb 15, 2013 at 02:57:10AM -0800, Jeremy Chadwick wrote:
> > > On Fri, Feb 15, 2013 at 11:26:11AM +0100, Alfred Bartsch wrote:
> > > > we want to use this script for server administration purposes. After
> > > > doing some testing, for now there are following issues left:
> > > > 
> > > > 1) every execution of "service -e"  casts a bunch of unnecessary
> > > > warnings into /var/log/messages:
> > > > "... /usr/sbin/service: WARNING: $_enable is not set
> > > > properly - see rc.conf(5)."
> > > >This is caused by calling "checkyesno()", provided by /etc/subr. It
> > > > could be solved by using a local function, named "checkyes" or similar.
> > > > 
> > > > The following patch prohibits these annoying messages:
> > > > {snip}
> > > 
> > > Your patch, in effectively, "rewrites" checkyesno() to remove the warn()
> > > call in cases where xxx_enable variables are set to values other than
> > > yes/true/on/1 or no/false/off/0.
> > > 
> > > Here's a better idea:
> > > 
> > > Fix your /etc/rc.conf xxx_enable variables which contain values that
> > > aren't permitted.  That's what the warn() is for -- to tell you to fix
> > > them.  :-)
> > 
> > It also warns if xxx_enable isn't set.  I have a number of ports installed
> > which I don't want to run by default but may run later, or which have
> > daemons but I don't want the daemon but some other functionality.  
> > rsync and fetchmail are two perfect examples of the latter.
> > 
> > If I don't have xxx_enable in /usr/local/etc/rc.conf I get the warning.
> > Should I really have to go through and explicitly set the xxx_enable flags
> > to "no"?  Or should the code be smart enough to recognise that the variable
> > not being present is equivalent to "no"?
> >
> > If the requirement is that all installed rc.d scripts have a xxx_enable flag
> > set to yes or no at all times, then the current ports infrastructure is 
> > sadly
> > lacking as I don't have anything under /usr/local/etc/defaults/ at all (if
> > that is even a valid location).  And I'd prefer ports not try and 
> > automagically
> > frob /etc/rc.conf, /etc/rc.conf.local or /etc/defaults/rc.conf to add/remove
> > xxx_enable lines as that can go wrong.
> 
> This is the first I've heard of something called /usr/local/etc/rc.conf.
> What is this file?  I don't see it mentioned as being read/used by
> rc_conf_files (see /etc/defaults/rc.conf), at least not via stock.  Are
> you redefining rc_conf_files or are you somehow source'ing the file
> yourself?
> 
> Regardless, I can't confirm that behaviour:
> 
> root@icarus:~ # grep mysql_ /etc/rc.conf
> # mysql_enable="yes"
> # mysql_dbdir="/storage/mysql"
> 
> root@icarus:~ # service -e
> /etc/rc.d/hostid
> /etc/rc.d/zvol
> /etc/rc.d/ddb
> /etc/rc.d/hostid_save
> /etc/rc.d/zfs
> /etc/rc.d/cleanvar
> /etc/rc.d/ip6addrctl
> /etc/rc.d/devd
> /etc/rc.d/netwait
> /etc/rc.d/newsyslog
> /etc/rc.d/syslogd
> /etc/rc.d/named
> /etc/rc.d/ntpdate
> /etc/rc.d/dmesg
> /etc/rc.d/virecover
> /etc/rc.d/motd
> /etc/rc.d/ntpd
> /etc/rc.d/powerd
> /usr/local/etc/rc.d/samba
> /usr/local/etc/rc.d/postfix
> /usr/local/etc/rc.d/apache22
> /etc/rc.d/sshd
> /etc/rc.d/cron
> /etc/rc.d/mixer
> /etc/rc.d/inetd
> /etc/rc.d/gptboot
> 
> Same goes for if I removed the commented-out lines (shouldn't matter but
> I tested it anyway).
> 
> System:
> 
> FreeBSD icarus.home.lan 9.1-STABLE FreeBSD 9.1-STABLE #0 r246644: Sun Feb 10 
> 16:55:49 PST 2013 
> r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_9_amd64  amd64
> 
> root@icarus:~ # grep '$FreeBSD' /etc/rc /etc/rc.subr
> /etc/rc:# $FreeBSD: stable/9/etc/rc 233943 2012-04-06 11:07:44Z ed $
> /etc/rc.subr:# $FreeBSD: stable/9/etc/rc.subr 243754 2012-12-01 15:46:27Z 
> crees $
> 
> I fully agree that if this were the case (having to set xxx_enable="no"
> explicitly) that would be a bug.

Follow up -- I read Alfred's most recent mail.  Lo and behold, I find
this in /var/log/messages (but such did not come to my terminal):

Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $svnserve_enable is not 
set properly - see rc.conf(5).
Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $smartd_enable is not 
set properly - see rc.conf(5).
Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $rsyncd_enable is not 
set properly - see rc.conf(5).
Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $htcacheclean_enable is 
not set properly - see rc.conf(5).
Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $fetchmail_enable is 
not set properly - see rc.conf(5).

Cute.  Agreed -- this is unacceptable on two levels (as I see it):

1) These messages should be going to stdout or stderr in some way, so
honestly logger(8) should be called with the "-s" flag (IMO).

2) These messages should not be displayed at all (i.e. lack of an
xxx_enable variable should imply xxx_enable="no").

I'll file

And for our next trick (Audio problems, Envy24HT driver)

[Karl Denninger]

FreeBSD 9.1-STABLE #2 r244942M: Tue Feb  5 21:54:29 CST 2013
k...@dbms.denninger.net:/usr/obj/usr/src/sys/KSD-SMP

(custom kernel is there to support PPS for my GPS clock)

Attempting to add a generic card that claims to have a Envy24DT chipset
in it; it identifies and loads under the snd_envy24ht driver as:

pci6:  at device 0.0 (no driver attached)
pcm0:  port 0xcc00-0xcc1f,0xc880-0xc8ff irq 16
at device 0.0 on pci6
pcm0: [GIANT-LOCKED]
pcm0: system configuration
  SubVendorID: 0x1412, SubDeviceID: 0x2403
  XIN2 Clock Source: 24.576MHz(96kHz*256)
  MPU-401 UART(s) #: not implemented
  ADC #: 1 and SPDIF receiver connected
  DAC #: 4
  Multi-track converter type: AC'97(SDATA_OUT:packed)
  S/PDIF(IN/OUT): 1/1 ID# 0x00
  GPIO(mask/dir/state): 0xff/0xff/0xff

cat /dev/sndstat returns:

[root@NewFS /boot/kernel]# cat /dev/sndstat
FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64)
Installed devices:
pcm0:  at io 0xcc00:32,0xc880:128 irq 16
(1p:1v/5r:1v) default

So it appears it did attach properly.

But an attempt to output something to /dev/dsp0 looks like it is,
but nothing happens (no sound)

ie:

# sysctl -w hw.snd.verbose=2
# mpg123 some-mp3-file &
# sndstat | more

FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64)
Installed devices:
pcm0:  at io 0xcc00:32,0xc880:128 irq 16
(1p:1v/5r:1v) default
snddev flags=0x2a6
[pcm0:play:dsp0.p0]: spd 48000, fmt 0x00200010, flags
0x2108, 0x0004
interrupts 1343, underruns 0, feed 1343, ready 0
[b:16384/2048/8|bs:16384/2048/8]
channel flags=0x2108
{userland} -> feeder_mixer(0x00200010) -> {hardware}
pcm0:play:dsp0.p0[pcm0:virtual:dsp0.vp0]: spd 44100/48000, fmt
0x00200010, flags 0x112c, 0x0029, pid 18573 (mpg123)
interrupts 0, underruns 0, feed 1497, ready 65536
[b:0/0/0|bs:65536/2048/32]
channel flags=0x112c
{userland} -> feeder_root(0x00200010) ->
feeder_volume(0x00200010) -> feeder_rate(0x00200010 q:1 44100 -> 48000)
-> {hardware}

..

Says its running, and mpg123 has attached to it -- but no output.

Mixer says the volume is on:

[root@NewFS /boot/kernel]# mixer
Mixer vol  is currently set to  75:75
Mixer treble   is currently set to   0:0
Mixer synthis currently set to   0:0
Mixer pcm  is currently set to  75:75
Mixer speaker  is currently set to   0:0
Mixer line is currently set to  75:75
Mixer mic  is currently set to   0:0
Mixer cd   is currently set to   0:0
Mixer mix  is currently set to   0:0
Recording source: mic

Ideas for further troubleshooting?

-- 
-- Karl Denninger
/The Market Ticker ®/ 
Cuda Systems LLC

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

Re: some issues with /usr/sbin/service

[Jeremy Chadwick]

On Fri, Feb 15, 2013 at 01:32:57PM -0800, Jeremy Chadwick wrote:
> I'll file a PR for this.

http://www.freebsd.org/cgi/query-pr.cgi?pr=176181

-- 
| Jeremy Chadwick   j...@koitsu.org |
| UNIX Systems Administratorhttp://jdc.koitsu.org/ |
| Mountain View, CA, US|
| Making life hard for others since 1977. PGP 4BD6C0CB |

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

Re: new jail(8) ignoring devfs_ruleset?

[Jamie Gritton]

On 02/15/13 09:27, Harald Schmalzbauer wrote:

  Hello,

like already posted, on 9.1-R, I highly appreciate the new jail(8) and
jail.conf capabilities. Thanks for that extension!

Accidentally I saw that "devfs_ruleset" seems to be ignored.
If I list /dev/ I see all the hosts disk devices etc.
I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf.
   Inside the jail,
sysctl security.jail.devfs_ruleset returnes "1".
But like mentioned, I can access all devices...

Thanks for any help,

-Harry


devfs_ruleset is only used along with mount.devfs - do you also have
that set in jail.conf?

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

Re: some issues with /usr/sbin/service

[Gary Palmer]

On Fri, Feb 15, 2013 at 01:20:20PM -0800, Jeremy Chadwick wrote:
> On Fri, Feb 15, 2013 at 02:32:10PM -0500, Gary Palmer wrote:
> > On Fri, Feb 15, 2013 at 02:57:10AM -0800, Jeremy Chadwick wrote:
> > > On Fri, Feb 15, 2013 at 11:26:11AM +0100, Alfred Bartsch wrote:
> > > > we want to use this script for server administration purposes. After
> > > > doing some testing, for now there are following issues left:
> > > > 
> > > > 1) every execution of "service -e"  casts a bunch of unnecessary
> > > > warnings into /var/log/messages:
> > > > "... /usr/sbin/service: WARNING: $_enable is not set
> > > > properly - see rc.conf(5)."
> > > >This is caused by calling "checkyesno()", provided by /etc/subr. It
> > > > could be solved by using a local function, named "checkyes" or similar.
> > > > 
> > > > The following patch prohibits these annoying messages:
> > > > {snip}
> > > 
> > > Your patch, in effectively, "rewrites" checkyesno() to remove the warn()
> > > call in cases where xxx_enable variables are set to values other than
> > > yes/true/on/1 or no/false/off/0.
> > > 
> > > Here's a better idea:
> > > 
> > > Fix your /etc/rc.conf xxx_enable variables which contain values that
> > > aren't permitted.  That's what the warn() is for -- to tell you to fix
> > > them.  :-)
> > 
> > It also warns if xxx_enable isn't set.  I have a number of ports installed
> > which I don't want to run by default but may run later, or which have
> > daemons but I don't want the daemon but some other functionality.  
> > rsync and fetchmail are two perfect examples of the latter.
> > 
> > If I don't have xxx_enable in /usr/local/etc/rc.conf I get the warning.
> > Should I really have to go through and explicitly set the xxx_enable flags
> > to "no"?  Or should the code be smart enough to recognise that the variable
> > not being present is equivalent to "no"?
> >
> > If the requirement is that all installed rc.d scripts have a xxx_enable flag
> > set to yes or no at all times, then the current ports infrastructure is 
> > sadly
> > lacking as I don't have anything under /usr/local/etc/defaults/ at all (if
> > that is even a valid location).  And I'd prefer ports not try and 
> > automagically
> > frob /etc/rc.conf, /etc/rc.conf.local or /etc/defaults/rc.conf to add/remove
> > xxx_enable lines as that can go wrong.
> 
> This is the first I've heard of something called /usr/local/etc/rc.conf.

Sorry, my brain was ahead of where my fingers were and got the path
wrong.  I of course meant /etc/rc.conf.

> Regardless, I can't confirm that behaviour:

As you found, it gets logged rather than output to stdout or stderr.

Feb 15 19:21:18 desktop gpalmer: /usr/sbin/service: WARNING: $xfs_enable is not 
set properly - see rc.conf(5).
Feb 15 19:21:18 desktop gpalmer: /usr/sbin/service: WARNING: $rsyncd_enable is 
not set properly - see rc.conf(5).
Feb 15 19:21:18 desktop gpalmer: /usr/sbin/service: WARNING: $rrdcached_enable 
is not set properly - see rc.conf(5).

(etc)

I've come across something else outputing that error, but it probably
all comes from the same place.  Either the rc processor needs to treat
the flag not being set as equal to "no", or the ports infrastructure needs
to start installing something to make foo_enable="no" appear in the
defaults system somewhere

Gary

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

Re: 9-STABLE -> NFS -> NetAPP:

[Marc Fournier]

Trying the patch now … but what do you mean by using 'SIGSTOP'?  I generally do 
a 'kill -HUP' then when that doesn't work 'kill -9' … should Iuse -STOP instead 
of 9?


On 2013-02-15, at 5:44 AM, John Baldwin  wrote:

> 
> I think this is the right idea, but in HEAD with the sigdeferstop() changes 
> it 
> should just check for TDF_SBDRY instead of adding a new parameter.  I think
> checking for TDF_SBDRY will work even in 9 (and will make the patch smaller). 
>  
> Also, I think this is only needed for stop signals.  Other suspend requests 
> will eventually resume the thread, it is only stop signals that can cause the 
> thread to get stuck indefinitely (since it depends on the user sending 
> SIGCONT).
> 
> Marc, are you using SIGSTOP?
> 
> Index: kern_thread.c
> ===
> --- kern_thread.c (revision 246122)
> +++ kern_thread.c (working copy)
> @@ -795,6 +795,17 @@ thread_suspend_check(int return_instead)
>   return (ERESTART);
> 
>   /*
> +  * Ignore suspend requests for stop signals if they
> +  * are deferred.
> +  */
> + if (P_SHOULDSTOP(p) == P_STOPPED_SIG &&
> + td->td_flags & TDF_SBDRY) {
> + KASSERT(return_instead,
> + ("TDF_SBDRY set for unsafe thread_suspend_check"));
> + return (0);
> + }
> +
> + /*
>* If the process is waiting for us to exit,
>* this thread should just suicide.
>* Assumes that P_SINGLE_EXIT implies P_STOPPED_SINGLE.
> 
> -- 
> John Baldwin

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