Yup, saw those commits …am going through the servers and doing upgrades on them
… will report on any issues post-upgrade …
thx
On 2013-01-20, at 6:47 AM, John Baldwin wrote:
> On Sunday, January 20, 2013 01:10:29 AM Hub- Marketing wrote:
>> On 2013-01-19, at 4:57 AM, John Baldwin wrote:
>>
Hi John …
Does this help?
root@io:~ # ps auxl | grep du
root 1054 0.0 0.1 16176 6600 ?? D 3:15AM 0:05.38 du -skx
/vm/2799 0 81426 0 20 0 newnfs
root12353 0.0 0.1 16176 5104 ?? DSat03AM 0:05.41 du -skx
/vm/2799 0 91597 0 20 0 newnfs
root
|
> | Making life hard for others since 1977. PGP 4BD6C0CB |
>
> On Sat, Feb 09, 2013 at 09:29:30PM -0800, Marc Fournier wrote:
>>
>> Hi John ?
>>
>> Does this help?
>>
>> root@io:~ # ps auxl | grep du
>>
On 2013-02-10, at 4:31 PM, Rick Macklem wrote:
> Marc Fournier wrote:
>> Hi John …
>>
>> Does this help?
>>
>> root@io:~ # ps auxl | grep du
>> root 1054 0.0 0.1 16176 6600 ?? D 3:15AM 0:05.38 du -skx /vm/2799 0
>> 81426 0 20 0 newnfs
>> ro
src/sys/fs/nfsserver/nfs_nfsdserv.c
On 2013-02-10, at 4:56 PM, Marc Fournier wrote:
>
> On 2013-02-10, at 4:31 PM, Rick Macklem wrote:
>
>> Marc Fournier wrote:
>>> Hi John …
>>>
>>> Does this help?
>>>
>>> root@io:~ # ps auxl | grep du
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
Note that checking the console, there are no errors pertaining to this on it …
On 2013-02-13, at 9:26 PM, 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".
>
I don't know if this provides any benefit, but I just shut down all the VPSs on
that server, so that all the 'noise' is removed from the ps listing, which I've
attached …
On 2013-02-13, at 9:31 PM, Marc Fournier wrote:
>
> Note that checking the console, ther
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() change
On 2013-02-15, at 7:21 AM, Rick Macklem wrote:
>>
> 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 suppos
:
> Marc Fournier wrote:
>> On 2013-02-15, at 7:21 AM, Rick Macklem wrote:
>>
>>>>
>>> Righto. Thanks jhb and kib for looking at this.
>>>
>>> Btw John, PBDRY still gets set for sleeps in the sys/rpc code.
>>> However,
>>
: kernel boot file is /boot/kernel/kernel
Feb 18 12:13:55 mercury kernel: Copyright (c) 1992-2013 The FreeBSD Project.
===
On 2013-02-18, at 4:12 AM, Marc Fournier wrote:
>
> 2days, 6hrs since reboot with new kernel, server shows unreachable:
>
> # ssh mercury
> ssh_exchange
I just started to try and get VirtualBox up and running on this server .. same
configuration as another server I already have a few of them running, but after
a period of time with the install, I get the above error pop up on my remote
console, and pinging to the server itself just dies …
I'm
57 ms
64 bytes from 200.46.151.146: icmp_seq=3330 ttl=64 time=0.137 ms
64 bytes from 200.46.151.146: icmp_seq=3331 ttl=64 time=0.159 ms
64 bytes from 200.46.151.146: icmp_seq=3332 ttl=64 time=0.154 ms
64 bytes from 200.46.151.146: icmp_seq= ttl=64 time=0.204 ms
On 2013-02-24, at 12:22 AM,
Hi …
Running a kernel updated on the 24th, I just experienced a total hang of the
ethernet … the funny thing is that when I went to the remote console, the
network suddenly came up on its own, after being down for about 2 hours ...
I had originally thought it had to do with VirtualBox, sinc
15 matches
Mail list logo
