search for: vacuum

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]: Vacuumin...

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 make them disappear. Much better would be to use a blower or bellows of some kind. Also, cowboys scoff, but I alway...

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]: Vac...

...oes that really mean? > *shrug*, could be firmware/drivers/overheating/poor-CPU-seating/DIMM-seating/faulty-motherboard/faulty-CPU/faulty-DIMM. 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. This is the first one of these I've had. Hope it's the last. but a little PM is in order either way. thanks for the reply. Fred > > Hope that doesn't confuse too much. (: > _________________________...

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 > G = 6.67428e-11 # m^3 kg-1 s-2 > ) I thought I could i...

...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 fil...

...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 th...

...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...

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 proces...

...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...

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 could cause this? Thanks in advance. -------- smb.conf -------------------------- [global] workgroup = MYDOMAIN clustering = Yes netbios name = apollo re...

...vide further hints on what I should be looking >>>> for or at? >>> >>> Is it trying to hibernate? >> >> gosh, I hope not! I was in the middle of using it, playing solitaire >> and moving the mouse around a lot. >> Have you checked the PSU? Maybe vacuum it out (or open up the back of the laptop, and vacuum the whole thing)? mark

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...

...it run into problems. log.ctdb increased very quickly and consumed 100% of the disk space, the log is full of message like: 2015/03/19 08:09:06.070897 [26053]: 00.ctdb: OPERATION: monitor 2015/03/19 08:09:06.278859 [26053]: 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....

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 > >

...d 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:37:19.547636 [vacuum-locking.tdb: 3790]: tdb(/var/lib/ctdb/locking.tdb.2): tdb_oob len 541213780 beyond eof at 55386112 > 2017/04/19 12:37:19.547694 [vacuum-locking.tdb: 3790]: tdb(/var/lib/ctdb/locking.tdb.2): tdb_free: left offset read failed at 541213776 > 2017/04/19 12:37:19.547709 [vacuum-locking.tdb: 3790]:...

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