Re: sockstat tcp/udp switches
On Fri, 2006-Nov-03 15:50:10 -0800, Josh Carroll wrote: >I'm not sure if the method used to parse out the protocol is "up to >snuff" for the FreeBSD project, but I'm welcome to >suggestions/advice/etc. I suggest you use /etc/protocols rather than hard code the protocols. This will make the code future-proof. See getprotoent(3) for the correct way to read /etc/protocols. -- Peter Jeremy pgp2viCUWiyY6.pgp Description: PGP signature
Re: sockstat tcp/udp switches
Below is an initial attempt at the -P argument implementation.
I'm not sure if the method used to parse out the protocol is "up to
snuff" for the FreeBSD project, but I'm welcome to
suggestions/advice/etc.
I tested the previous behavior and given the exact command line,
sockstat works the same prior to the patch and with the patch. So the
-P option is additive only (so as not to break legacy
scripts/automation that may parse the sockstat output).
I included a limitation on the maximum length of a proto (mostly to
avoid buffer overflows) and 20 is probably way too large, so I can
lower that if need be. The -P argument also will sense and ignore
multiple commas, e.g.:
-P tcp,,udp
Will still just detect tcp and udp. I implemented the protocols with a
sort of lookup table for the protocol types for arguments to -P. So
adding another protocol should be as easy as adding a #define,
incrementing the #defined for NUM_PROTOS and updating the
add_proto_type function to recognize and properly store the new
protocol type. Again, I'm open to any feedback on this particular
approach.
Thanks again for everyone's attetion on this. It's a nice little
project to get me ramped back up into C and I do appreciate all the
feedback!
Regards,
Josh
--- sockstat.c.orig Thu Nov 2 15:04:39 2006
+++ sockstat.c Fri Nov 3 15:25:34 2006
@@ -66,8 +66,15 @@
static int opt_u; /* Show Unix domain sockets */
static int opt_v; /* Verbose mode */
+#define NUM_PROTOS 2
+#define MAX_PROTO_LEN 20
+#define TCP_PROTO 0
+#define UDP_PROTO 1
+static int *protos;/* protocols to use */
+
static int *ports;
+
#define INT_BIT (sizeof(int)*CHAR_BIT)
#define SET_PORT(p) do { ports[p / INT_BIT] |= 1 << (p % INT_BIT); } while (0)
#define CHK_PORT(p) (ports[p / INT_BIT] & (1 << (p % INT_BIT)))
@@ -105,6 +112,97 @@
}
static void
+clear_protos(void)
+{
+ int i;
+
+ for(i=0; i <= NUM_PROTOS; i++)
+ protos[i] = 0;
+
+}
+
+static void
+init_protos(void)
+{
+ int i;
+
+ if((protos = calloc(NUM_PROTOS, sizeof(int))) == NULL)
+ err(1, "calloc()");
+
+ for(i=0; i <= NUM_PROTOS; i++)
+ protos[i] = 0;
+
+}
+
+
+/* this function needs to be updated to reflect additional protocols
+ that are to be supported */
+static int
+add_proto_type(const char *proto)
+{
+ int found = 0;
+
+ if(strlen(proto) == 0)
+ return 0;
+
+ if(strncmp(proto, "tcp", 3) == 0) {
+ protos[TCP_PROTO] = 1;
+ found = 1;
+ }
+ else if(strncmp(proto, "udp", 3) == 0) {
+ protos[UDP_PROTO] = 1;
+ found = 1;
+ } else {
+ printf("Invalid protocol: %s\n", proto);
+ }
+
+ return found;
+}
+
+static int
+parse_protos(const char *protospec)
+{
+ const char *p;
+ char curr_proto[MAX_PROTO_LEN];
+ int proto_index = 0;
+ int protos_defined = 0;
+
+ p = protospec;
+ while(*p != '\0') {
+ if(*p == ',') {
+ curr_proto[proto_index] = '\0';
+ protos_defined += add_proto_type(curr_proto);
+ proto_index = 0;
+ } else {
+ curr_proto[proto_index++] = *p;
+ }
+ p++;
+ if(*p == '\0' && proto_index != 0) {
+ curr_proto[proto_index] = '\0';
+ protos_defined += add_proto_type(curr_proto);
+ }
+ if(proto_index == MAX_PROTO_LEN) {
+ printf("Warning: truncating protocol\n");
+ curr_proto[proto_index] = '\0';
+ protos_defined += add_proto_type(curr_proto);
+
+ /* need to seek to the next , or \0 now */
+ while(*p != ',' && *p != '\0')
+ p++;
+
+ /* if we're at a proto boundary (comma), move on */
+ if(*p == ',')
+ p++;
+
+ proto_index = 0;
+ }
+ }
+
+ return protos_defined;
+}
+
+
+static void
parse_ports(const char *portspec)
{
const char *p, *q;
@@ -576,16 +674,24 @@
static void
usage(void)
{
- fprintf(stderr, "Usage: sockstat [-46clu] [-p ports]\n");
+ fprintf(stderr, "Usage: sockstat [-46clu] [-p ports] [-P protos]\n");
exit(1);
}
int
main(int argc, char *argv[])
{
+ /* if protos_defined remains -1, no -P was provided, sowe avoid
+ attempting to read from that int array later */
+ int protos_defined = -1;
+
int o;
- while ((o = getopt(argc, argv, "46clp:uv")) != -1)
+ /* initialize all protos to 0, if they're all still unset later
+ then -P wasn't use and the default is to display all of them */
+ init_protos();
+
+ while ((o = getopt(argc
Re: Panic on 6.1-RELEASE-p3
John Baldwin <[EMAIL PROTECTED]> writes: > On Thursday 02 November 2006 15:19, Anthony Chavez wrote: >> freebsd-hackers: >> >> I have attached the backtraces of 17 core dumps from one of my >> machines. I have several deployments of this same FreeBSD version in >> the wild, and this is the only machine exhibiting this behavior. >> >> Initially, the cause of these panics seemed to be related to some >> component in the FreeBSD toolchain, as they would occur when >> attempting to install a port. net/samba3 was the one we'd usually >> test with, but the system would panic with most other larger packages >> as well. >> >> However, the system is panicking at irrgeular intervals, ranging >> between 1-3 weeks apart. This is mostly happening in the off-hours >> when no human users are actively using the machine, but there have >> been 1 or 2 incidences where the machine has panicked during prime >> time. > > Have you ran a memory checker or other diags to check for failing hardware? I ran sysutils/memtest twice. Both times, it failed to panic the system. I have yet to bring the system down and boot into a "real" memory/hardware checker, however. I usually just go with ultimatebootcd.com when testing, but if you have other suggestions for tools, I'd welcome your input before we schedule to do the testing. Thanks! -- Anthony Chavez http://anthonychavez.org/ mailto:[EMAIL PROTECTED] jabber:[EMAIL PROTECTED] pgpUk85xiUWr2.pgp Description: PGP signature
Re: [patch] rm can have undesired side-effects
At 11:02 PM -0600 11/2/06, Craig Boston wrote: On Thu, Nov 02, 2006 at 10:52:19AM +, Jan Grant wrote: > This is, I reckon, the only sensible suggestion thus far: if the > FS doesn't help you then you are implicitly depending on the FS > implementation to ensure you are writing over the original data > blocks anyway. And you may very well not be. If the underlying FS is say for example journaled or snapshotted, your new data blocks may go to a completely different part of the disk. For UFS today -P may work most of the time, assuming no snapshots or other events moving the file. With gjournal and gvirtstor coming who knows if that will remain true. That doesn't even take into account things like unionfs or other VFS stacking. If writing zeros or whatever to a file (that may or may not overwrite the previous contents on disk) is really what you want to do, dd works just fine for the task. /me votes for removing the -P misfeature altogether I'm inclined to agree that the option should be removed. We can't seem to agree on how it should work with links. We can't guarantee that it will work even if we agreed on when it should work. And putting the feature in 'rm' does no good at all when it is some other command (such as 'mv') which is going to unlink() the filename. I think this is a case where we should have stuck with the idea that separate features should be implemented in separate commands. 'rm' is just not a good command to write a lot of data into a file. In this case, we're not even interested in writing "to the file", but what we really want is to write to specific sectors of a disk. -- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute; Troy, NY; USA ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Java
On Fri, Nov 03, 2006 at 07:53:16PM +1100, Peter Jeremy wrote: > On Thu, 2006-Nov-02 19:27:04 -0700, [EMAIL PROTECTED] wrote: > >I never said it was broken, just that the jre in the ports collection was. > >It seems to be looking for something other than itself when you attempt a > >make. Under the circumstances it seems it should be removed? > > ports/java/jre is Java 1.1.8 - which is positively ancient. It is no > longer possible to build it because it depends on FreeBSD 3.x binaries > which in turn rely on the compax3x port which is forbidden due to > multiple security vulnerabilities. > > Yes, it probably should be deleted. There are a number of ports in > a similar condition and they are being cleansed as a low-priority > task by at least one committer. All JDK/JREs earlier than 1.3 need to die. I just haven't had the time to do it yet. -- Greg Lewis Email : [EMAIL PROTECTED] Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Java
On Thu, 2006-Nov-02 19:27:04 -0700, [EMAIL PROTECTED] wrote: >I never said it was broken, just that the jre in the ports collection was. >It seems to be looking for something other than itself when you attempt a >make. Under the circumstances it seems it should be removed? ports/java/jre is Java 1.1.8 - which is positively ancient. It is no longer possible to build it because it depends on FreeBSD 3.x binaries which in turn rely on the compax3x port which is forbidden due to multiple security vulnerabilities. Yes, it probably should be deleted. There are a number of ports in a similar condition and they are being cleansed as a low-priority task by at least one committer. -- Peter Jeremy pgp3JNiVFPB1y.pgp Description: PGP signature
