search for: vacuuming

Hi @ all Does anyone has some experience with PostgreSQL and RoR? Does it gives any disadvantages or problems with PostgreSQL? I have a webapplication, that manage (read/write) many records (no. 200''000 records) and I search a ideal database. Actually, I have two options: - MySQL / - PostgreSQL And now, I would like to ascertain a good solution... Thx, ribit -- Posted via

...nn:1 10.0.0.2 OK (THIS NODE) Generation:2125944281 Size:1 hash:0 lmaster:1 Recovery mode:NORMAL (0) Recovery master:1 ?> RESULTS in splitbrain, both nodes have the public ip Node 1 Log 2014/07/03 16:07:59.033170 [33243]: Starting CTDBD as pid : 33243 2014/07/03 16:07:59.036903 [33243]: Vacuuming is disabled for persistent database group_mapping.tdb 2014/07/03 16:07:59.040167 [33243]: Vacuuming is disabled for persistent database account_policy.tdb 2014/07/03 16:07:59.043457 [33243]: Vacuuming is disabled for persistent database share_info.tdb 2014/07/03 16:07:59.046547 [33243]: Vacuuming i...

On 08/12/2017 07:24 PM, Fred Smith wrote: > Well. overheating is possible... we don't live in the cleanest possible > house, AND we have cats. so, in general I open up this box twice a year > and vacuum out the house dirt and cat fuzzies. I'm probably overdue for > this task. Cleaning is a good thing to do, but not with a vacuum... the vacuum could loosen components, even

On 08/13/2017 05:18 AM, ken wrote: > Also, cowboys scoff, but I always wear a grounded wrist strap when > handling electronics. It's a good idea, especially in low-humidity climates. Also noteworthy: the air moving through a hose can cause a vacuum's hose or attachment to build up a static charge, which is another reason it can be a bad idea to use a vacuum in a computer.

...Recovery mode:NORMAL (0) Recovery master:0 The ctdb.log has: 2014/02/26 11:58:55.637024 [12452056]: Recovery lock file set to "". Disabling recovery lock checking 2014/02/26 11:58:55.648102 [6553670]: Starting CTDBD (Version 2.5.1) as PID: 6553670 2014/02/26 11:58:55.768838 [6553670]: Vacuuming is disabled for persistent database account_policy.tdb 2014/02/26 11:58:55.817376 [6553670]: Vacuuming is disabled for persistent database group_mapping.tdb 2014/02/26 11:58:55.892066 [6553670]: Vacuuming is disabled for persistent database passdb.tdb 2014/02/26 11:58:55.939510 [6553670]: Vacuum...

On Sat, Aug 12, 2017 at 05:51:33PM -0400, Steven Tardy wrote: > > > On Aug 12, 2017, at 3:50 PM, Fred Smith <fredex at fcshome.stoneham.ma.us> wrote: > > > > I had a series of kernel hardware error reports today while I was away > > from my computer: > > > > Message from syslogd at fcshome at Aug 12 10:12:24 ... > > kernel:[Hardware Error]:

Hi, I've started my own (first) package, part of which consists in listing common physical constants (Planck's constant, the speed of light in vacuum, etc). I'm wondering what would be a good way of dealing with pairs of value/unit. > constants <- list( cel = 2.99792458e8 , #m/s > Z0 = 376.730313461, #ohm > eps0 = 8.854187817e-12,#F/m > mu0 = 4*pi*1e-7,#N/A^2

...nths back. Things seemed pretty > solid for the first 2-3 weeks, but then I started getting reports of > people not being able to access files, or some times directories. It > has taken me a while to figure some stuff out, but it seems the common > denominator to this happening is vacuuming timeouts for locking.tdb in > the ctdb log, which might go on every 2 minutes and 10 seconds for > anywhere from an hour to a day and some, and then it will also add to > the logs failure to get a RECORD lock on the same tdb file. Whenever I > get a report about inaccessible files...

...gt; stack trace via gstack. In fact, even before you get the stack trace > you could check a process listing to see if the process is stuck in D > state. So, yes, I do have a process stuck in the D state. is in an smbd process. matching up the times in the logs, I see that the the "Vacuuming child process timed out for db locking.tdb" error in ctdb lines up with the user who owns the the smbd process accessing a file that has been problematic before. it is an xlsx file. > gstack basically does: > > gdb -batch -ex "thread apply all bt" -p <pid> >...

...cluster a couple months back. Things seemed pretty solid for the first 2-3 weeks, but then I started getting reports of people not being able to access files, or some times directories. It has taken me a while to figure some stuff out, but it seems the common denominator to this happening is vacuuming timeouts for locking.tdb in the ctdb log, which might go on every 2 minutes and 10 seconds for anywhere from an hour to a day and some, and then it will also add to the logs failure to get a RECORD lock on the same tdb file. Whenever I get a report about inaccessible files I find this in the c...

...ember machines with hung smbd tasks which causes them to reboot, and the cluster did not come back up consistently. We eventually got it more or less stable with two nodes out of the 3, but we're still seeing worrying messages, eg we've just noticed: 2017/04/19 12:10:31.168891 [ 5417]: Vacuuming child process timed out for db brlock.tdb 2017/04/19 12:11:39.250169 [ 5417]: Unable to get RECORD lock on database brlock.tdb for 500 seconds ===== Start of debug locks PID=9372 ===== 8084 /usr/sbin/smbd brlock.tdb.2 7044 7044 20931 /usr/libexec/ctdb/ctdb_lock_helper brlock.tdb.2 7044 7044 W 216...

On Thu, 2 Nov 2017 11:17:27 -0700, Computerisms Corporation via samba <samba at lists.samba.org> wrote: > This occurred again this morning, when the user reported the problem, I > found in the ctdb logs that vacuuming has been going on since last > night. The need to fix it was urgent (when isn't it?) so I didn't have > time to poke around for clues, but immediately restarted the lxc > container. But this time it wouldn't restart, which I had time to trace > to a hung smbd process,...

...fact, even before you get the stack trace > > you could check a process listing to see if the process is stuck in D > > state. > > So, yes, I do have a process stuck in the D state. is in an smbd > process. matching up the times in the logs, I see that the the > "Vacuuming child process timed out for db locking.tdb" error in ctdb > lines up with the user who owns the the smbd process accessing a file > that has been problematic before. it is an xlsx file. > > > gstack basically does: > > > > gdb -batch -ex "thread apply al...

CTDB Samba Team, I have a two-node cluster successfully running a GFS2 filesystem. I compiled ctdb ver 1.12 with Samba 3.6.3 for 64-bit systems. Running on RHEL 5.7. I was able to add the cluster to the domain but after I restarted CTDB, it panics right after doing a vacuum of the serverid.tdb database. The lock file is on the GFS FS so both nodes can access it. Any ideas as to what

Dr. Mikeal Hughes wrote: > Motherboard time. Netbook is probably a throw away issue. Cost more t to > repair than buy new. > >> On Jun 20, 2016, at 7:58 AM, Fred Smith <fredex at fcshome.stoneham.ma.us> >> wrote: >> >> On Mon, Jun 20, 2016 at 01:34:30PM +0300, ????????? ???????? wrote: >>>> Can anyone of you provide further hints on what I should

Hi, This occurred again this morning, when the user reported the problem, I found in the ctdb logs that vacuuming has been going on since last night. The need to fix it was urgent (when isn't it?) so I didn't have time to poke around for clues, but immediately restarted the lxc container. But this time it wouldn't restart, which I had time to trace to a hung smbd process, and between that and...

...]: 50.samba: [info] cy_samba_control monitor : 0 2015/03/19 08:09:07.054677 [vacuum-connections.tdb:21348]: /usr/local/var/ctdb/connections.tdb.0:tdb_rec_read bad magic 0x42424242 at offset=5838176 2015/03/19 08:09:07.054738 [vacuum-connections.tdb:21348]: server/ctdb_vacuum.c:772 Traverse error in vacuuming 'connections.tdb' 2015/03/19 08:09:07.054759 [vacuum-connections.tdb:21348]: server/ctdb_vacuum.c:1463 Failed to vacuum 'connections.tdb' I searched on internet and there seems no answers to the cause of the problem, the general advice is delete connections.tdb and restart samba. I...

On Thu, 2 Nov 2017 12:17:56 -0700, Computerisms Corporation via samba <samba at lists.samba.org> wrote: > hm, I stand correct on the problem solved statement below. Ip addresses > are simply not cooperating on the 2nd node. > > root at vault1:~# ctdb ip > Public IPs on node 0 > 192.168.120.90 0 > 192.168.120.91 0 > 192.168.120.92 0 > 192.168.120.93 0 > >

...fffffffffffff>] 0xffffffffffffffff So this tells you that smbd was wedged in the cluster filesystem. > [...] > It does look like we have some database corruption. > > What may have caused this, and is there any way to resolve it? The good news is that you're only seeing it in vacuuming and you're not actually seeing TDB errors in smbd. Still, it isn't something we've seen. If we figure out anything then we'll definitely let you know... peace & happiness, martin

Hi Martin, Thanks for reading and taking the time to reply >> ctdbd[89]: Unable to get RECORD lock on database locking.tdb for 20 seconds >> /usr/local/samba/etc/ctdb/debug_locks.sh: 142: >> /usr/local/samba/etc/ctdb/debug_locks.sh: cannot create : Directory >> nonexistent >> sh: echo: I/O error >> sh: echo: I/O error > > That's weird. The only