Re: Renaming killall and forever symlinking the old name to the new name
Jason Spiro jasonspiro4 at gmail.com writes: [snip] You could rename killall to something else, and update the manpage to show the new name, then symlink or hard link killall to the new name forever. This would encourage people to use the new name, but it would never force them to. Xin, what do you think? Since Xin and I CC'ed each other so often in this thread, Gmail automatically added us to each others' Gtalk instant-messenger contact lists. Since it'd been more than a month and Xin still hadn't replied to this message, I instant messaged him the idea and asked him what he thought. He replied that, in his opinion, this new idea is pointless: nobody would notice the renaming, and it would just cause confusion. I asked, what if the tool would show a hint onscreen if you called it using the old name? He said no. He said people can just use pkill. I hope Eitan Adler's patch[1], which adds a verbose option to pkill, will get accepted, and that a similar patch will get accepted into the Linux pkill, maintained by Albert Calahan. ^ [1]. http://thread.gmane.org/gmane.os.freebsd.devel.hackers/38636 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RFC] [patch] pkill verbose option
jhell jhell at DataIX.net writes: [snip] Now pkill -v sleep on my system actually causes my Xserver to exit with a unexpected signal 15. Yes. pkill -v sleep kills all your own processes except for sleep. As root, it kills all processes running on your machine except for sleep. -V is not a good choice of letter for this option: it's too easy to write -v instead by accident. -l (dash-ell), as jhell has suggested elsewhere in this thread, would be ideal, since it's lowercase and easy to type. If you don't like -l, you could choose to make it -D (for Debug) instead. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RFC] [patch] pkill verbose option
This patch hijacks pgrep's -l
Index: pkill.1
===
--- pkill.1 (revision 203347)
+++ pkill.1 (working copy)
@@ -168,9 +168,9 @@
If used in conjunction with
.Fl f ,
print the process ID and the full argument list for each matching process.
-This option can only be used with the
-.Nm pgrep
-command.
+If used in conjunction with the
+.Nm pkill
+command, it lists the signal sent as well.
.It Fl n
Select only the newest (most recently started) of the matching processes.
.It Fl o
Index: pkill.c
===
--- pkill.c (revision 203347)
+++ pkill.c (working copy)
@@ -182,7 +182,7 @@
pidfilelock = 0;
execf = coref = _PATH_DEVNULL;
- while ((ch = getopt(argc, argv,
DF:G:ILM:N:P:SU:ad:fg:ij:lnos:t:u:vx)) != -1)
+ while ((ch = getopt(argc, argv,
DF:G:ILM:N:P:SU:ad:fg:ilj:lnos:t:u:vx)) != -1)
switch (ch) {
case 'D':
debug_opt++;
@@ -245,8 +245,6 @@
criteria = 1;
break;
case 'l':
- if (!pgrep)
- usage();
longfmt = 1;
break;
case 'n':
@@ -528,16 +526,26 @@
/*
* Take the appropriate action for each matched process, if any.
*/
+ int didAction = 0;
for (i = 0, rv = 0, kp = plist; i nproc; i++, kp++) {
if (PSKIP(kp))
continue;
if (selected[i]) {
+ if (longfmt)
+ {
+ didAction = 1;
+ printf(kill -%d %d\n,signum,kp-ki_pid);
+ }
if (inverse)
continue;
} else if (!inverse)
continue;
rv |= (*action)(kp);
}
+ if (!didAction !pgrep)
+ {
+ printf(No matching processes belonging to you were
found\n);
+ }
exit(rv ? STATUS_MATCH : STATUS_NOMATCH);
}
On Thu, Feb 4, 2010 at 11:24 AM, Jason Spiro jasonspi...@gmail.com wrote:
jhell jhell at DataIX.net writes:
[snip]
Now pkill -v sleep on my system actually causes my Xserver to exit with a
unexpected signal 15.
Yes. pkill -v sleep kills all your own processes except for sleep. As
root,
it kills all processes running on your machine except for sleep.
-V is not a good choice of letter for this option: it's too easy to write
-v
instead by accident. -l (dash-ell), as jhell has suggested elsewhere in
this
thread, would be ideal, since it's lowercase and easy to type. If you
don't
like -l, you could choose to make it -D (for Debug) instead.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Unique process id (not pid) and accounting daemon
Hello, I am trying to create an accounting daemon that would be more precise than usual BSD system accounting. It should read the whole process tree from time to time (say, every 10 seconds) and log changes in usage of CPU, I/O operations and memory per process. There is a problem: it is not always possible to link a process in a process tree against matching process in an accounting file. Only command name, user/group id and start time will match... Have you looked at audit(4)? Yes, but I did not see how it can help to measure cpu usage/io operations for long running processes and to sync between process list and accounting file. -- // cronfy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] Support for thresholds in du(1)
On (25/02/2009 17:24), Mel wrote:
Hi,
attached is a small patch to add threshold support to du(1). I've been using
it on 7-STABLE machines for a while, cause I got tired of the noise I get
when sorting and then reformatting to human-readable. Especially since
sorting isn't part of the equasion I'd like to see all dirs exceeding a
given size.
I've not updated the manpage on -STABLE yet, should be the same as HEAD.
Example usage:
# du -xht 20m .
29M./contrib/binutils
52M./contrib/gcc
237M./contrib
35M./crypto
28M./lib
20M./share
55M./sys/dev
139M./sys
545M.
I'll file a PR for it, if there's no objections to this feature /
implementation, the style(9) or the usage of -t.
--
Mel
Hi,
I've cleaned up original patch:
* fixed style and some bugs
* as suggested changed it to use expand_number
* implemented support for negative threshold values
I find the patch very useful. Does it look ok to be commited, or should
I file a PR so it won't get lost once again.
Example usage:
src/sys/crypto % du -ht 100k
137K./des
482K.
src/sys/crypto % du -A -ht +100k
129K./des
446K.
src/sys/crypto % du -ht -100k
56K./camellia
11K./salsa20
38K./sha2
9.0K./rc4
68K./des/arch/i386
70K./des/arch
88K./rijndael
37K./via
8.0K./hmac
36K./blowfish/arch/i386
37K./blowfish/arch
85K./blowfish
diff --git a/usr.bin/du/du.1 b/usr.bin/du/du.1
index af2ff84..b0e1748 100644
--- a/usr.bin/du/du.1
+++ b/usr.bin/du/du.1
@@ -42,7 +42,7 @@
.Nm
.Op Fl A
.Op Fl H | L | P
-.Op Fl a | s | d Ar depth
+.Op Fl a | s | d Ar depth | t Ar threshold
.Op Fl c
.Op Fl l
.Op Fl h | k | m | B Ar blocksize
@@ -107,6 +107,14 @@ This option exists solely for conformance with
Display an entry for each specified file.
(Equivalent to
.Fl d Li 0 )
+.It Fl t Ar threshold
+Display only entries for which size exceeds
+.Ar threshold .
+If
+.Ar threshold
+is negative, display only entries for which size is less then absolute
+value of
+.Ar threshold .
.It Fl d Ar depth
Display an entry for all files and directories
.Ar depth
diff --git a/usr.bin/du/du.c b/usr.bin/du/du.c
index 63677f5..ff62c5b 100644
--- a/usr.bin/du/du.c
+++ b/usr.bin/du/du.c
@@ -90,6 +90,7 @@ main(int argc, char *argv[])
FTS *fts;
FTSENT *p;
off_t savednumber, curblocks;
+ int64_t threshold, threshold_sign;
int ftsoptions;
int listall;
int depth;
@@ -106,12 +107,14 @@ main(int argc, char *argv[])
save = argv;
ftsoptions = 0;
savednumber = 0;
+ threshold = 0;
+ threshold_sign = 1;
cblocksize = DEV_BSIZE;
blocksize = 0;
depth = INT_MAX;
SLIST_INIT(ignores);
- while ((ch = getopt(argc, argv, AB:HI:LPasd:chklmnrx)) != -1)
+ while ((ch = getopt(argc, argv, AB:HI:LPasd:chklmnrt:x)) != -1)
switch (ch) {
case 'A':
Aflag = 1;
@@ -179,6 +182,14 @@ main(int argc, char *argv[])
break;
case 'r':/* Compatibility. */
break;
+ case 't' :
+ if (expand_number(optarg, threshold) != 0 ||
+ threshold == 0) {
+ warnx(invalid threshold: %s, optarg);
+ usage();
+ } else if (threshold 0)
+ threshold_sign = -1;
+ break;
case 'x':
ftsoptions |= FTS_XDEV;
break;
@@ -248,6 +259,10 @@ main(int argc, char *argv[])
blocksize /= DEV_BSIZE;
}
+ if (threshold != 0)
+ threshold = howmany(threshold / DEV_BSIZE * cblocksize,
+ blocksize);
+
rval = 0;
(void)signal(SIGINFO, siginfo);
@@ -271,7 +286,9 @@ main(int argc, char *argv[])
p-fts_parent-fts_bignum += p-fts_bignum +=
curblocks;
- if (p-fts_level = depth) {
+ if (p-fts_level = depth threshold =
+ threshold_sign * howmany(p-fts_bignum *
+ cblocksize, blocksize)) {
if (hflag) {
prthumanval(p-fts_bignum);
(void)printf(\t%s\n, p-fts_path);
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Weekend PR smashing
[adding freebsd-bugbusters@ to the Cc:] I'm sorry I didn't respond to your earlier message. I am currently way behind on tasks that I've already promised people. The KDE howto that you cited (http://quality.kde.org/develop/howto/howtobugs.php) is quite a good one. Our pr-guidelines document isn't as thorough. Part of the problem is that we don't have enough metadata in GNATS to capture some of the things that we would like bugbusters to do, e.g., as they suggest: - attempting to reproduce an 'unconfirmed' bug and change it to 'new' The closest that we have is the 'analyzed' state, which we have used in the past to indicate 'confirmed'. If you can indeed reproduce a bug, it's fair enough to let bugmeister@ know and we can change the state. Alternatively, you can submit a followup and suggest that. Several of the folks on the bugbusting team (e.g. people who have GNATS access) monitor the mailing lists and try to track followups. (I personally track bugs@, ports-bugs@, and a few of the others, but not some of the specialty ones like n...@.) - check if a report is a duplicate Reports that are duplicates indicate that various users are being affected by one underlying problem. At one point I was trying to gather them all into a page. I was hoping more people would do the analysis and send me additions for it. However, it looks as though the script that generates that page has rotted. I'll re-add it to my list of things-to-do ... http://people.freebsd.org/~linimon/studies/prs/well_known_prs.html At this point it may be easier to look at the template that I grind up to produce that page: http://people.freebsd.org/~linimon/wellknown.prs It's clearly over a year stale, and could thus use a new set of eyes. - add '(regression)' to the title if indicated I think we've done a fairly good job of getting '[regression]' (our styling of the same idea) into the existing ones, and keeping up with new ones as they come in. Similarly, we've done pretty well with '[patch]' AFAIK. That's my reaction to some specifics on the the KDE page. Now for some more general comments. We have more kern/ PRs than any other category. This category is overloaded to mean both kernel, libraries, networking, and device drivers. http://people.freebsd.org/~linimon/studies/prs/pr_tag_index.html makes this much more tractable. (I have other ideas about how to do much better, but see below.) Whether or not existing PRs are still relevant seems to vary a bit by sub-category. There would also a slightly different way of looking at things, the ones with '[panic]' in the Synopsis. Hmm, I thought there was such a page, but it doesn't seem so. I'll put it on my list to create one. As for the bin/ PRs, you'd be surprised at how many of them are still relevant, even after several years. I've resisted the suggestion that others have made in the past just to close them for this reason. (In the past I have made an effort to contact submitters and ask them if they are still experiencing the problem, but portmgr duties have kept me away from that for a long time. This is something else where we need help.) The i386 and amd64 PRs are more likely to be can't install/run on a particular piece of hardware, and generally require the most interaction with users to isolate the problem (e.g. to ACPI interacting badly with a buggy BIOS; irq problems; devices not being supported by our current drivers; and so forth.) To work with these people need to have a bit of experience with low-level debuggers and how to examine stack traces. one of the things that concerns me is the sheer number of PRs with patches that either have been committed without the PRs being updated Well, that's a task that needs more people working on. You can start by looking at: http://people.freebsd.org/~linimon/studies/prs/prs_possibly_committed.html which is PRs that have had followups appended to their Audit-Trail by the checkin scripts. If these changes have already been merged to all the relevant -stable branches, they should be closed; otherwise, if they are not already set to 'patched', then they should be, and assigned to the committer who made the change. or the patches are simply sitting idly in PRs. There are certainly a large number of these. IWBNI we could get more of them into the 'analyzed' state to claim 'we think this patch might solve the problem'. The list by the bugbusters waiting for committers to check them out is pretty huge as well: Yes, I'm well aware of that, since I set it up :-) This goes to the more general problem that it's more fun to add new things than it is to fix existing things. FreeBSD has traditionally done much better at adding new features than in the more mundane maintenance work. This is a problem not just with FreeBSD or even open source projects in general, but all software. What's interesting is that this situation is slowly changing (again IMHO). Over the past year we have seen several
Re: [RFC] [patch] pkill verbose option
On Thu, Feb 04, 2010 at 12:01:26PM +0200, Eitan Adler wrote: This patch hijacks pgrep's -l I'd like to paint the bikeshed with little -p's ;-) pgpnxCW9VgVDg.pgp Description: PGP signature
Re: Spin down HDD after disk sync or before power off
Warren Block wrote: Oliver Fromme wrote: Alexander Best wrote: imo this patch takes good care of the problem. would be nice to have it in HEAD. No -- *Please* make sure that the disks are only spun down upon an actual power-off command (i.e. when reboot() is called with the RB_POWEROFF flag). In all other cases the disks should keep running. It's not good to have the disks spin down and then immediately spin up again on every reboot. Could you elaborate a little on why that's bad? It seems like it would be similar to a standby/resume action. While notebook disks are usually optimized to handle a high number of start/stop cycles, this isn't true for normal desktop or server disks, especially ones that are meant for continuous operation (24/7). This varies greatly between vendors and models, though. The point is that I defintitely wouldn't want to waste a start/stop cycle when it's not necessary. Also, it would be nice to have a way to disable the STANDBY command alltogether for people who don't want it. This could easily be implemented with a sysctl. Are there any other device drivers that differentiate the reboot and poweroff actions that could be used as inspiration or simply shamelessly copied in modifying ata-disk? I'm sorry, I don't know. If the ad_shutdown() function doesn't have easy access to the boot howto variable, maybe the information could be stored in a kenv variable? Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd I suggested holding a Python Object Oriented Programming Seminar, but the acronym was unpopular. -- Joseph Strout ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: Spin down HDD after disk sync or before power off
From: owner-freebsd-hack...@freebsd.org [owner-freebsd-hack...@freebsd.org] On
Behalf Of Warren Block [wbl...@wonkity.com]
Sent: Wednesday, February 03, 2010 7:43 PM
To: Erich Dollansky
Cc: freebsd-hackers@freebsd.org
Subject: Re: Spin down HDD after disk sync or before power off
On Thu, 4 Feb 2010, Erich Dollansky wrote:
In case of a reboot, it is already known when the command is given that the
machine will restart without being powered of.
If you spin-down the disk, you lose one start cycle.
It is not that important but if it can be done with just one if, please, just
do it.
AFAICT ad_shutdown can't tell whether it's called for a reboot or a
poweroff, it's just told to shut down. So maybe it's one if, but it's
somewhere above ata-disk.c but below reboot(RB_POWEROFF).
-Warren Block * Rapid City, South Dakota USA
You can register for a shutdown even that *does* get to know the howto
variable; we do this quite a bit on some of our platforms that need special
handling at power-off versus halt.
extern void jsrxnle_poweroff_devices(void *junk, int howto);
/* Registering power-off handler to be called at the system shutdown */
EVENTHANDLER_REGISTER(shutdown_final, jsrxnle_poweroff_devices, NULL,
SHUTDOWN_PRI_LAST + 10);
The howto argument can be checked for RB_POWEROFF:
if (howto RB_POWEROFF) {
/* Spin Down */
}
--
Andrew Duane Juniper Networks
978-589-0551 10 Technology Park Dr
adu...@juniper.net Westford, MA 01886-3418
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RFC] [patch] pkill verbose option
On Thu, 4 Feb 2010 05:01, eitanadlerlist@ wrote:
This patch hijacks pgrep's -l
[cut]
This particular section of the patch should probably be left out until its
worked over in a way that it does not print the info message if a process
has been found and killed already.
if (!didAction !pgrep)
{
printf(No matching processes belonging to you were found\n);
}
Thanks for the re-patch, quick and resourceful... ;)
--
jhell
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RFC] [patch] pkill verbose option
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 4 Feb 2010 07:10, lars.engels@ wrote: On Thu, Feb 04, 2010 at 12:01:26PM +0200, Eitan Adler wrote: This patch hijacks pgrep's -l I'd like to paint the bikeshed with little -p's ;-) If it is a bikeshed then maybe we should make it '-bs' but then again you might just confuse that for 'bullshit'. - -- jhell -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLau/6AAoJEJBXh4mJ2FR+wbYIAJ6Aw9iMCsdNDVFxyksDWxXH iJoSDE3MRC7IUCR/y8CpCfJxKVuXmoIALoMZXE1v8b9SOAyaSydnMcOTd7b6bvEg LMh1hC3KsHp84lWgzu2fra9BBSWQXFkeb1vgunWjwYbV1AM2XnTKJ1eGlWvVK2Pt BxovnoZhOStiSolTUPPhSDcRjHhkZ0906PfvbX2/oWv/qFonXt7aI3t0rj5Y4anF +TcmtCFIvxgvu7LwPriO+0M5Ud99bqMX4UZSeLMTukWZ96tS9KTisfxliZmixG0H OrBzo4IudUr6HLGvZDClhT6RJtlheeUv88GbGCXtOJg5tmH+IpsQD0+e8t09uGo= =HFpu -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Does getc(3) use the read(2) syscall?
Thank you all for your wonderful replies! I should have known it was a macro, thank you. Very informative help from you Oliver. 2010/2/3 Daniel Molina Wegener d...@coder.cl On Wednesday 03 February 2010, Marc Olzheim z...@zlo.nu wrote: On Wed, Feb 03, 2010 at 10:23:50AM -0300, Daniel Molina Wegener wrote: I'm having trouble looking this function up in the source tree, the trail seems to end at __sys_read which has a bunch of prototypes but i can't find the actual function code. Well, you can try cscope --- IMO the best option to search for symbols in the source tree. Also you have well done front-ends like cbrowser, codelite and emacs plus cscope mode. Works wonders in vim as well. :-) Sure, vim supports cscope since 2000 and possibly before that, indeed vim was my first programming editor in FreeBSD and Linux. Then I've learned emcas, and now I use both editors --- the first available on the machine that I'm working on --- also emacs requires a lot of configurations, but is my primary editor on my FreeBSD boxes. So my question is primarily, does getc use the read system call eventually? No, certainly not. Take a look on stdio.h and libc implementation on lib/libc/stdio/getc.c. Mainly on the __sgetc(f) macro. If you follow macros long enough, you'll find that it obviously does use the read system call. read, readv, pread, preadv are basicly the system calls through which all normal reads take place. That's right, but cscope or even etags should help a lot finding those simbols, most for large source trees like the FreeBSD base system ;) Marc Best regards, -- Daniel Molina Wegener dmw [at] coder [dot] cl Software Architect, System Programmer Web Developer Phone: +1 (510) 629-4267 | Blog: http://coder.cl/ -- Med vänliga hälsningar / With kind regards Stefan Midjich http://swehack.se/cv https://www.swehack.se/cv ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RFC] [patch] pkill verbose option
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Content-ID: alpine.bsf.2.00.1002041147050.27...@pragry.qngnvk.ybpny
On Thu, 4 Feb 2010 11:01, jhell@ wrote:
On Thu, 4 Feb 2010 05:01, eitanadlerlist@ wrote:
This patch hijacks pgrep's -l
[cut]
This particular section of the patch should probably be left out until its
worked over in a way that it does not print the info message if a process has
been found and killed already.
if (!didAction !pgrep)
{
printf(No matching processes belonging to you were found\n);
}
Thanks for the re-patch, quick and resourceful... ;)
The attached patch is for stable/7 and does not have the above printf for
no matching processes. It also cleans up the formatting a little following
the rest of the code and adds the -l flag to the usage statement.
This is only the patch for pkill itself and not for the manual page.
;-)
- --
jhell
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)
iQEcBAEBAgAGBQJLavsEAAoJEJBXh4mJ2FR+WMwH/1FQY4+FV5xLd6Lg2xgjcbG0
ptDjfr5EdIowWeE2EckcmkZGHZa6Z9WL3zcgOHBfJbsm7pchKUoAjzihlk2iW76u
yBHknDs0Wysv7g0y2nA5sDmjAzzJV8xF8W7aGps+eRJYp1dSDQh9h5zRLAKqZXQ+
hmc43ZUOTYsOoMdPcHJUm48og5Q7IiVeh4B7T6PeMaFdolwW8wGwJuXjOzRw4+UH
A6g+bBctFNrLIxj6eb39oxhIXoDv7unwM+JONJKJvtKWOmbVD22VVYSMeNKSOeqX
9SelPiwdBj9ulJfTuRmrpfuPw/J7CpkrIwKsifPqP3DYuKQ8qLiBO/jRJwLNkpA=
=PD/9
-END PGP SIGNATURE-Index: pkill.c
===
--- pkill.c (revision 193627)
+++ pkill.c (working copy)
@@ -182,7 +182,7 @@
pidfilelock = 0;
execf = coref = _PATH_DEVNULL;
- while ((ch = getopt(argc, argv,
DF:G:ILM:N:P:SU:ad:fg:ij:lnos:t:u:vx)) != -1)
+ while ((ch = getopt(argc, argv,
DF:G:ILM:N:P:SU:ad:fg:ilj:lnos:t:u:vx)) != -1)
switch (ch) {
case 'D':
debug_opt++;
@@ -245,8 +245,6 @@
criteria = 1;
break;
case 'l':
- if (!pgrep)
- usage();
longfmt = 1;
break;
case 'n':
@@ -528,10 +526,15 @@
/*
* Take the appropriate action for each matched process, if any.
*/
+ int didAction = 0;
for (i = 0, rv = 0, kp = plist; i nproc; i++, kp++) {
if (PSKIP(kp))
continue;
if (selected[i]) {
+ if (longfmt) {
+ didAction = 1;
+ printf(kill -%d %d\n,signum,kp-ki_pid);
+ }
if (inverse)
continue;
} else if (!inverse)
@@ -550,7 +553,7 @@
if (pgrep)
ustr = [-LSfilnovx] [-d delim];
else
- ustr = [-signal] [-ILfinovx];
+ ustr = [-signal] [-ILfilnovx];
fprintf(stderr,
usage: %s %s [-F pidfile] [-G gid] [-M core] [-N system]\n
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
devfs panic w/INVARIANTS
I've got a commercial driver that uses device cloning.
At unload time, the driver calls clone_cleanup(). When I unload
the driver when the kernel is built with INVARIANTS, I'll see a
panic in devfs_populate_loop(). This happens in 6-stable,
as well as 8-stable.
From what I can see the clone has been freed, but it
remains on the devfs cdevp_list. Then the next time
devfs_populate_loop() is called, it trips over the bad
entry (cdp-cdp_dirents points to 0xdeadc0dedeadc0de)
See appended kgdb session.
If I trace the code path, it looks like clone_cleanup()
calls destroy_devl(). And destroy_devl() will eventually
call devfs_free() if the si_refcnt is zero. But I don't
see anything which will get the cdev removed from
the cdevp_list prior to it being freed.
The only code I see which will get the cdev removed from
the cdevp_list() seems to be the GC any lingering devices
block in devfs_populate_loop
What am I missing?
Thanks,
Drew
Fatal trap 9: general protection fault while in kernel mode
cpuid = 1; apic id = 01
instruction pointer = 0x8:0x803e8780
stack pointer = 0x10:0xade623b0
frame pointer = 0x10:0xade62400
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 896 (ps)
Dumping 510 MB (2 chunks)
Dumping 510 MB (2 chunks)
Dumping 510 MB (2 chunks)
chunk 0: 1MB (156 pages) ... ok
chunk 1: 510MB (130528 pages) 494 478 462 446 430 414 398 382 366 350
334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46
30 14
#0 doadump () at pcpu.h:172
172 __asm __volatile(movq %%gs:0,%0 : =r (td));
(kgdb) bt
#0 doadump () at pcpu.h:172
#1 0x801b8d91 in db_fncall (dummy1=0, dummy2=0, dummy3=0,
dummy4=0x0) at ../../../ddb/db_command.c:493
#2 0x801b91e5 in db_command_loop () at
../../../ddb/db_command.c:408
#3 0x801bb0ed in db_trap (type=-1377427040, code=0) at
../../../ddb/db_main.c:222
#4 0x80468b99 in kdb_trap (type=9, code=0,
tf=0xade62300) at ../../../kern/subr_kdb.c:473
#5 0x806c5d14 in trap_fatal (frame=0xade62300,
eva=18446742974557577824)
at ../../../amd64/amd64/trap.c:660
#6 0x806c62eb in trap (frame=
{tf_rdi = -2136471632, tf_rsi = -2136471656, tf_rdx =
-2401050962867404578, tf_rcx = 1, tf_r8 = -2136471624, tf_r9 =
-1099151973792, tf_rax = 0, tf_rbx = -1099307447040, tf_rbp =
-1377426432, tf_r10 = 0, tf_r11 = 4, tf_r12 = 0, tf_r13 =
-1099086652928, tf_r14 = -1099307447040, tf_r15 = 86032452, tf_trapno =
9, tf_addr = 0, tf_flags = -2143029088, tf_err = 0, tf_rip =
-2143385728, tf_cs = 8, tf_rflags = 66071, tf_rsp = -1377426496, tf_ss =
16}) at ../../../amd64/amd64/trap.c:470
#7 0x806ad84b in calltrap () at
../../../amd64/amd64/exception.S:168
#8 0x803e8780 in devfs_populate_loop (dm=0xff000c2b8d00,
cleanup=0) at ../../../fs/devfs/devfs_devs.c:370
#9 0x803e8beb in devfs_populate (dm=0xff000c2b8d00) at
../../../fs/devfs/devfs_devs.c:486
#10 0x803eafab in devfs_lookup (ap=0x0) at
../../../fs/devfs/devfs_vnops.c:587
#11 0x80724a2e in VOP_LOOKUP_APV (vop=0x80948600,
a=0xade62630) at vnode_if.c:99
#12 0x804aadb2 in lookup (ndp=0xade629c0) at vnode_if.h:56
#13 0x804abb66 in namei (ndp=0xade629c0) at
../../../kern/vfs_lookup.c:216
#14 0x804c1be2 in vn_open_cred (ndp=0xade629c0,
flagp=0xade6290c, cmode=0,
cred=0xff09ac00, fdidx=3) at ../../../kern/vfs_vnops.c:183
#15 0x804b8d64 in kern_open (td=0xff00156fe260,
path=0xmode=373490024) at ../../../kern/vfs_syscalls.c:1016
#16 0x804b9455 in open (td=0x80a807b0,
uap=0xade62bc0) at ../../../kern/vfs_syscalls.c:971
#17 0x806c6b52 in syscall (frame=
{tf_rdi = 4218321, tf_rsi = 0, tf_rdx = 0, tf_rcx = 0, tf_r8 =
140737488348272, tf_r9 = 0, tf_rax = 5, tf_rbx = 5300224, tf_rbp =
4218321, tf_r10 = 0, tf_r11 = 5300224, tf_r12 = 4218321, tf_r13 = 0,
tf_r14 = 140737488348272, tf_r15 = 6, tf_trapno = 12, tf_addr = 5300224,
tf_flags = 0, tf_err = 2, tf_rip = 34369309420, tf_cs = 43, tf_rflags =
514, tf_rsp = 140737488347528, tf_ss = 35}) at
../../../amd64/amd64/trap.c:807
#18 0x806ada48 in Xfast_syscall () at
../../../amd64/amd64/exception.S:287
#19 0x000800920aec in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) frame 7
#7 0x806ad84b in calltrap () at
../../../amd64/amd64/exception.S:168
168 calltrap
Current language: auto; currently asm
(kgdb) up
#8 0x803e8780 in devfs_populate_loop (dm=0xff000c2b8d00,
cleanup=0) at ../../../fs/devfs/devfs_devs.c:370
370 if ((cleanup || !(cdp-cdp_flags CDP_ACTIVE))
Current language: auto; currently c
Re: Weekend PR smashing
Mark Linimon wrote: [adding freebsd-bugbusters@ to the Cc:] http://people.freebsd.org/~linimon/studies/prs/well_known_prs.html You also might find the following script that wraps all of Mark's work a tiny bit a little better to get a lot of information on one page. I use it for ports but should translate over to src quite well. http://people.freebsd.org/~pgollucci/myprs.pl.txt which in its current state makes this http://people.freebsd.org/~pgollucci/myprs.html -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 VP Apache Infrastructure; Member, Apache Software Foundation Committer,FreeBSD Foundation Consultant, P6M7G8 Inc. Sr. System Admin, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] Support for thresholds in du(1)
On Thu, 4 Feb 2010 06:55, gleb.kurtsou@ wrote: On (25/02/2009 17:24), Mel wrote: Hi, attached is a small patch to add threshold support to du(1). I've been using it on 7-STABLE machines for a while, cause I got tired of the noise I get when sorting and then reformatting to human-readable. Especially since sorting isn't part of the equasion I'd like to see all dirs exceeding a given size. I've not updated the manpage on -STABLE yet, should be the same as HEAD. Example usage: # du -xht 20m . 29M./contrib/binutils 52M./contrib/gcc 237M./contrib 35M./crypto 28M./lib 20M./share 55M./sys/dev 139M./sys 545M. I'll file a PR for it, if there's no objections to this feature / implementation, the style(9) or the usage of -t. -- Mel Hi, I've cleaned up original patch: * fixed style and some bugs * as suggested changed it to use expand_number * implemented support for negative threshold values I find the patch very useful. Does it look ok to be commited, or should I file a PR so it won't get lost once again. Example usage: src/sys/crypto % du -ht 100k 137K./des 482K. src/sys/crypto % du -A -ht +100k 129K./des 446K. src/sys/crypto % du -ht -100k 56K./camellia 11K./salsa20 38K./sha2 9.0K./rc4 68K./des/arch/i386 70K./des/arch 88K./rijndael 37K./via 8.0K./hmac 36K./blowfish/arch/i386 37K./blowfish/arch 85K./blowfish I like it!. This certainly reduces some piping but as long as it is not integrated upstream it will only become more of a responsibility on FreeBSD's behalf to maintain it. If someone has the original authors email address I would say lets include him on this and see what he thinks. This would probably be the same for the pkill thread that I am involved in to. CC'ing responsible party for that thread. Best regards. This message was supposed to arrive 9 hours ago but there was some ISP problems that prevented me from sending it. -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] Support for thresholds in du(1)
On Thu, 4 Feb 2010 06:55, gleb.kurtsou@ wrote: On (25/02/2009 17:24), Mel wrote: Hi, attached is a small patch to add threshold support to du(1). I've been using it on 7-STABLE machines for a while, cause I got tired of the noise I get when sorting and then reformatting to human-readable. Especially since sorting isn't part of the equasion I'd like to see all dirs exceeding a given size. I've not updated the manpage on -STABLE yet, should be the same as HEAD. Example usage: # du -xht 20m . 29M./contrib/binutils 52M./contrib/gcc 237M./contrib 35M./crypto 28M./lib 20M./share 55M./sys/dev 139M./sys 545M. I'll file a PR for it, if there's no objections to this feature / implementation, the style(9) or the usage of -t. -- Mel Hi, I've cleaned up original patch: * fixed style and some bugs * as suggested changed it to use expand_number * implemented support for negative threshold values I find the patch very useful. Does it look ok to be commited, or should I file a PR so it won't get lost once again. Example usage: src/sys/crypto % du -ht 100k 137K./des 482K. src/sys/crypto % du -A -ht +100k 129K./des 446K. src/sys/crypto % du -ht -100k 56K./camellia 11K./salsa20 38K./sha2 9.0K./rc4 68K./des/arch/i386 70K./des/arch 88K./rijndael 37K./via 8.0K./hmac 36K./blowfish/arch/i386 37K./blowfish/arch 85K./blowfish I would recommend generating this patch as a unified diff or a svn or cvs diff whichever version you checked out your tree with. -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] Support for thresholds in du(1)
On Thu, 4 Feb 2010 06:55, gleb.kurtsou@ wrote:
On (25/02/2009 17:24), Mel wrote:
Hi,
attached is a small patch to add threshold support to du(1). I've been using
it on 7-STABLE machines for a while, cause I got tired of the noise I get
when sorting and then reformatting to human-readable. Especially since
sorting isn't part of the equasion I'd like to see all dirs exceeding a
given size.
I've not updated the manpage on -STABLE yet, should be the same as HEAD.
Example usage:
# du -xht 20m .
29M./contrib/binutils
52M./contrib/gcc
237M./contrib
35M./crypto
28M./lib
20M./share
55M./sys/dev
139M./sys
545M.
I'll file a PR for it, if there's no objections to this feature /
implementation, the style(9) or the usage of -t.
--
Mel
Hi,
I've cleaned up original patch:
* fixed style and some bugs
* as suggested changed it to use expand_number
* implemented support for negative threshold values
I find the patch very useful. Does it look ok to be commited, or should
I file a PR so it won't get lost once again.
Example usage:
src/sys/crypto % du -ht 100k
137K./des
482K.
src/sys/crypto % du -A -ht +100k
129K./des
446K.
src/sys/crypto % du -ht -100k
56K./camellia
11K./salsa20
38K./sha2
9.0K./rc4
68K./des/arch/i386
70K./des/arch
88K./rijndael
37K./via
8.0K./hmac
36K./blowfish/arch/i386
37K./blowfish/arch
85K./blowfish
Also not to be picky but I can see this being raised in another email at a
later time.
For Each
du -ht +1.5{M,G,T,P}
Would be something nice to compliment this so you do not have to revert
back to say 1440k when wanting to say 1.5m and so on for larger sizes.
Also I think to be fully supportive it should have the capability to do at
the least -N bits +-N bytes.
Thanks for the work that you have done on this.
--
jhell
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
pmake .ORDER bug with -j 1 or misuse?
Hi hackers,
I'm getting used to pmake after using GNU make for the past couple
years, and I'm used to `in-order prerequisites', where if I specified
a list of targets a specific way, then it would execute the targets
serially in-order.
I tried to do the following with .ORDER, but it doesn't appear to
be working as I expect it to:
[gcoo...@optimus /scratch]$ make
do
something
[gcoo...@optimus /scratch]$ cat BSDmakefile
.ORDER: something do
all: do something
do something:
@echo ${.TARGET}
[gcoo...@optimus /scratch]$ make -j 2
something
do
It does function as I expect it to via -j 2 (executes the
`something', then `do' goals), but not with -j 1 -- could someone help
me understand what behavior is correct so I can adjust my behavior
and/or get a fix started?
Thanks!
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] Support for thresholds in du(1)
On Thu, Feb 4, 2010 at 9:30 PM, jhell jh...@dataix.net wrote: I like it!. It looks like a really useful option. Though if you really need to free up a lot of space, try a Freshmeat search[1] for [ disk usage ]. It reveals many tools that look even better, including ncdu[2] which doesn't require Xorg. But I doubt that any of them ship with FreeBSD by default. I think the du manpage[3]'s SEE ALSO section should be revised to include ncdu(1), xdiskusage(1), baobab(1), and kdirstat(1). (Baobab requires Gnome, and KDirStat requires KDE.) What do you think? This certainly reduces some piping but as long as it is not integrated upstream it will only become more of a responsibility on FreeBSD's behalf to maintain it. If someone has the original authors email address I would say lets include him on this and see what he thinks. This would probably be the same for the pkill thread that I am involved in to. CC'ing responsible party for that thread. What do you mean? Do you mean that maintaining half a dozen lines of extra code added to pkill(1) would be a burden for the FreeBSD team? :) ^ [1]. http://freshmeat.net/search/?q=disk+usage ^ [2]. http://freshmeat.net/projects/ncdu ^ [3]. http://www.freebsd.org/cgi/man.cgi?query=dumanpath=FreeBSD+9.0-CURRENT ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] Support for thresholds in du(1)
On Thu, Feb 4, 2010 at 8:51 PM, Jason A. Spiro jasonspi...@gmail.com wrote: On Thu, Feb 4, 2010 at 9:30 PM, jhell jh...@dataix.net wrote: I like it!. It looks like a really useful option. Though if you really need to free up a lot of space, try a Freshmeat search[1] for [ disk usage ]. It reveals many tools that look even better, including ncdu[2] which doesn't require Xorg. But I doubt that any of them ship with FreeBSD by default. I think the du manpage[3]'s SEE ALSO section should be revised to include ncdu(1), xdiskusage(1), baobab(1), and kdirstat(1). (Baobab requires Gnome, and KDirStat requires KDE.) What do you think? This certainly reduces some piping but as long as it is not integrated upstream it will only become more of a responsibility on FreeBSD's behalf to maintain it. If someone has the original authors email address I would say lets include him on this and see what he thinks. This would probably be the same for the pkill thread that I am involved in to. CC'ing responsible party for that thread. What do you mean? Do you mean that maintaining half a dozen lines of extra code added to pkill(1) would be a burden for the FreeBSD team? :) Shouldn't, but as I've learned before a few times -- it only takes one line of code to fubar a one man-rockfight (or screw up a system :)...)... Cheers, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] Support for thresholds in du(1)
On Thu, 4 Feb 2010 23:51, jasonspiro4@ wrote: On Thu, Feb 4, 2010 at 9:30 PM, jhell jh...@dataix.net wrote: I like it!. It looks like a really useful option. Though if you really need to free up a lot of space, try a Freshmeat search[1] for [ disk usage ]. It reveals many tools that look even better, including ncdu[2] which doesn't require Xorg. But I doubt that any of them ship with FreeBSD by default. I think the du manpage[3]'s SEE ALSO section should be revised to include ncdu(1), xdiskusage(1), baobab(1), and kdirstat(1). (Baobab requires Gnome, and KDirStat requires KDE.) What do you think? To me it is a annoyance when I see a man page reference something that is not already installed on the system especially if it does not reference a URL. Back end utilities should really only list their friends in see also and not friends of friends and their friends. ;) My favorite that can run on anything that can run java jre/jdk is sysutils/jdiskreport. Although certain WM's do not work well with java this is a very portable utility. This certainly reduces some piping but as long as it is not integrated upstream it will only become more of a responsibility on FreeBSD's behalf to maintain it. If someone has the original authors email address I would say lets include him on this and see what he thinks. This would probably be the same for the pkill thread that I am involved in to. CC'ing responsible party for that thread. What do you mean? Do you mean that maintaining half a dozen lines of extra code added to pkill(1) would be a burden for the FreeBSD team? :) Yeah. I am more of a lean practitioner so I try to always look for the best way or if you will the least hands on way of managing things. In this case the less code that has to be merged upon update the better and more time that is available to developers to work on much needed other tasks. Five minutes not opening a editor and merging code could better be used getting a cup of coffee to stay awake while hacking on ZFS or utmpx rather than pkill or du. ;) ^ [1]. http://freshmeat.net/search/?q=disk+usage ^ [2]. http://freshmeat.net/projects/ncdu ^ [3]. http://www.freebsd.org/cgi/man.cgi?query=dumanpath=FreeBSD+9.0-CURRENT -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
