I'm using SQLite and a php application that runs in background. I have blocked the application using (Ctrl-c) and I just noticed that i have database.sqlite and database.sqlite-journal.
At the moment, How can I remove -journal file without compromising the database?
Thank you!
P.S. SQLite version 3.7.9
EDIT:
-rw-r--r--. 1 damiano damiano 51M 8 mar 18.15 test.sqlite2
-rw-r--r--. 1 damiano damiano 2,6K 8 mar 18.15 test.sqlite2-journal
[damiano#localhost backup]$ sqlite3 test.sqlite2
SQLite version 3.7.13 2012-06-11 02:05:22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite>
[damiano#localhost backup]$ ls -lh
-rw-r--r--. 1 damiano damiano 51M 8 mar 18.15 test.sqlite2
-rw-r--r--. 1 damiano damiano 2,6K 8 mar 18.15 test.sqlite2-journal
[damiano#localhost backup]$
Execute this command:
sqlite3 test.sqlite2 vacuum
It will make your database as small as possible and apply possible outstanding transactions or rollbacks in -journal file (and remove it in process). You can actually execute any other transaction that does something (but simply connect/disconnect is NOT enough), but vacuum seems like easiest approach.
Just open the database (with your program or with the sqlite3 command-line tool).
SQLite will then roll back the changes of your interrupted transaction and afterwards remove the journal.
Related
Before trying to assemble sequence data, I get a file size estimate for my raw READ1/READ2 files by running the command ls -l -h from the directory the files are in. The output looks something like this:
-rwxrwxrwx# 1 catharus2021 staff 86M Jun 11 15:03 pluvialis-dominica_JJW362-READ1.fastq.gz
-rwxrwxrwx# 1 catharus2021 staff 84M Jun 11 15:03 pluvialis-dominica_JJW362-READ2.fastq.gz
For a previous run using the identical command, but a different batch of data, the output was as such:
-rwxr-xr-x 1 catharus2021 staff 44M Mar 16 2018 lagopus_lagopus_alascensis_JJW1970_READ1.fastq.gz
-rwxr-xr-x 1 catharus2021 staff 52M Mar 16 2018 lagopus_lagopus_alascensis_JJW1970_READ2.fastq.gz
It doesn't seem to be affecting any downstream commands, but does anyone know why the strings at the very beginning (-rwxrwxrx# vs. -rwxr-xr-x) are different? I assume that they're permissions flags, but google has been less-than-informative when I try to type those in and search.
Thanks in advance for your time.
The coding describes who can access a file in which way. It is oredred:
owner - group - world
rwxr-xr-x
user can read, write and execute
group can only read and execute
world can only read and execute
This prevents that other people can overwrite your data. If you change to
rwxrwxrwx
Everybody can overwrite your data.
I am looking for a way to show the results of the file "tcp-variants-comparison.cc" under ns3 (3.28) used with Ubuntu 18.04.
I found here an old topic from 2013, but it seems not to work correctly in my current environment.
P.S: I am a newbie in ns3, so i will appreciate any help.
regards
cedkhader
Running ./waf --run "tcp-variants-comparison --tracing=1" yields the following files:
-rw-rw-r-- 1 112271415 Aug 5 15:52 TcpVariantsComparison-ascii
-rw-rw-r-- 1 401623 Aug 5 15:52 TcpVariantsComparison-cwnd.data
-rw-rw-r-- 1 1216177 Aug 5 15:52 TcpVariantsComparison-inflight.data
-rw-rw-r-- 1 947619 Aug 5 15:52 TcpVariantsComparison-next-rx.data
-rw-rw-r-- 1 955550 Aug 5 15:52 TcpVariantsComparison-next-tx.data
-rw-rw-r-- 1 38 Aug 5 15:51 TcpVariantsComparison-rto.data
-rw-rw-r-- 1 482134 Aug 5 15:52 TcpVariantsComparison-rtt.data
-rw-rw-r-- 1 346427 Aug 5 15:52 TcpVariantsComparison-ssth.data
You can use other command line arguments to generate the desired output, see list below.
Program Arguments:
--transport_prot: Transport protocol to use: TcpNewReno, TcpHybla, TcpHighSpeed, TcpHtcp, TcpVegas, TcpScalable, TcpVeno, TcpBic, TcpYeah, TcpIllinois, TcpWestwood, TcpWestwoodPlus, TcpLedbat [TcpWestwood]
--error_p: Packet error rate [0]
--bandwidth: Bottleneck bandwidth [2Mbps]
--delay: Bottleneck delay [0.01ms]
--access_bandwidth: Access link bandwidth [10Mbps]
--access_delay: Access link delay [45ms]
--tracing: Flag to enable/disable tracing [true]
--prefix_name: Prefix of output trace file [TcpVariantsComparison]
--data: Number of Megabytes of data to transmit [0]
--mtu: Size of IP packets to send in bytes [400]
--num_flows: Number of flows [1]
--duration: Time to allow flows to run in seconds [100]
--run: Run index (for setting repeatable seeds) [0]
--flow_monitor: Enable flow monitor [false]
--pcap_tracing: Enable or disable PCAP tracing [false]
--queue_disc_type: Queue disc type for gateway (e.g. ns3::CoDelQueueDisc) [ns3::PfifoFastQueueDisc]
--sack: Enable or disable SACK option [true]
in ns3.36.1 I used this command
./ns3 run examples/tcp/tcp-variants-comparison.cc -- --tracing=1
and output look like this
TcpVariantsComparison-ascii
TcpVariantsComparison-cwnd.data
TcpVariantsComparison-inflight.data
TcpVariantsComparison-next-rx.data
TcpVariantsComparison-next-tx.data
TcpVariantsComparison-rto.data
TcpVariantsComparison-rtt.data
TcpVariantsComparison-ssth.data
One of my redis servers is repeatedly going down today without any overt, diagnosable cause. My users all end up getting Error 111 connecting to unix socket: /var/run/redis/redis2.sock. Connection refused errors.
Looking into the logs at /var/log/redis, the last few lines capture nothing more nefarious than a scheduled backup:
[8248] 09 Mar 07:48:17.090 * 10 changes in 21600 seconds. Saving...
[8248] 09 Mar 07:48:17.374 * Background saving started by pid 47613
[47613] 09 Mar 07:51:02.257 * DB saved on disk
[47613] 09 Mar 07:51:02.486 * RDB: 526 MB of memory used by copy-on-write
[8248] 09 Mar 07:51:02.920 * Background saving terminated with success
The pid file still exists too. Which implies the server wasn't formally shut down, and redis was still daemonized?
I logged into my system and did sudo service redis-server restart twice to get it up and running. Apart from these logs, how else can I diagnose what might have gone wrong?
Update: I noticed that at the time of the first crash, disk swapping started taking place. This hasn't happened before. Moreover, cat /proc/sys/vm/swappiness confirms swappiness is set to 2.
free -m shows (after normal operation):
total used free shared buffers cached
Mem: 28136 27015 1120 305 80 6586
-/+ buffers/cache: 20349 7787
Swap: 1023 991 32
free -m shows (after the redis server goes down):
total used free shared buffers cached
Mem: 28136 8770 19365 305 60 441
-/+ buffers/cache: 8268 19868
Swap: 1023 1022 1
This sounds like the work of the OS' OOM killer - you can verify/discredit the hypothesis by reviewing the /var/log/syslog.
In this case, the persistence job's overhead triggered the killer. You need to provision for that by setting maxmemory and allocating enough RAM to accommodate persistence's requirements, including COW.
Note that free isn't useful after the fact - you need to monitor your resources continuously.
As for swap, if you don't care about latency then you can certainly do that.
I'm learning how to develop Kde Plasma 5 plasmoids, and testing it with a small widget, consistent of just two qmls. I read some information sources, like https://techbase.kde.org or https://api.kde.org/frameworks/ and created a package structure and sources for my test plasmoid, which looks like this:
$ ls -lR test
test:
total 8
drwxr-xr-x 3 alberto alberto 4096 nov 26 14:28 contents
-rw-r--r-- 1 alberto alberto 459 nov 26 14:28 metadata.desktop
test/contents:
total 4
drwxr-xr-x 2 alberto alberto 4096 nov 26 14:33 ui
test/contents/ui:
total 8
-rw-r--r-- 1 alberto alberto 275 nov 26 14:28 main.qml
-rw-r--r-- 1 alberto alberto 465 nov 26 14:33 RootContainer.qml
The RootContainer is just the fullRepresentation of the widget, and contains only a label with the text "prueba1". So, as i read in the documentation, i used the command plasmapkg2 to install the widget as follows:
$ plasmapkg2 --install test
pluginname: "org.matrixland.test"
Generated "/home/xxx/.local/share/plasma/plasmoids//kpluginindex.json" ( 3 plugins)
/home/xxx/Programación/proyectos/plasmoides/test instalado con éxito
Then, i can use it in the kde desktop and everything is fine. It is shown in the desktop, with the text label.
But now, if i change the text of the label, "prueba2", and i remove and reinstall the plugin as follows
$ plasmapkg2 --remove test
Constructing a KPluginInfo object from old style JSON. Please use kcoreaddons_desktop_to_json() for "" instead of kservice_desktop_to_json() in your CMake code.
Calling KPluginInfo::property("X-KDE-PluginInfo-Name") is deprecated, use KPluginInfo::pluginName() in "/usr/lib/x86_64-linux-gnu/qt5/plugins/plasma/packagestructure/plasma_packagestructure_share.so" instead.
Constructing a KPluginInfo object from old style JSON. Please use kcoreaddons_desktop_to_json() for "" instead of kservice_desktop_to_json() in your CMake code.
Calling KPluginInfo::property("X-KDE-PluginInfo-Name") is deprecated, use KPluginInfo::pluginName() in "/usr/lib/x86_64-linux-gnu/qt5/plugins/plasma/packagestructure/plasma_packagestructure_share.so" instead.
Generated "/home/xxx/.local/share/plasma/plasmoids//kpluginindex.json" ( 2 plugins)
/home/xxx/Programación/proyectos/plasmoides/test desinstalado con éxito
>xxx#eleanor:~/Programación/proyectos/plasmoides$ plasmapkg2 --install test
pluginname: "org.matrixland.test"
Generated "/home/alberto/.local/share/plasma/plasmoids//kpluginindex.json" ( 3 plugins)
/home/alberto/Programación/proyectos/plasmoides/test instalado con éxito
If now, i add it again to the desktop, i see the old text instead of the new one. I checked in the /home/xxx/.local/share/plasma/plasmoids/org.matrixland.test directory that the source is up to date and refreshed, so i can't guess why am i obtaining the old text instead of the new one.
Obviously my problem is that none of the changes i make in the qml is reflected in the widget, not only text changes. I don't know if i am doing something wrong, or if i must do anything else to update the widget. Can anybody help me with that?
This is because the old QML is "cached" still. You'll need to restart plasmashell in order to see the changes.
killall plasmashell; kstart5 plasmashell
I used this script to reinstall applets when I want to test live. When I want to test quickly though, I'll use plasmoidviewer with:
plasmoidviewer -a package -l bottomedge -f horizontal
like in this script.
How does dump create the incremental backup? It seems I should use the same file name when I create a level 1 dump:
Full backup:
dump -0aLuf /mnt/bkup/backup.dump /
and then for the incremental
dump -1aLuf /mnt/bkup/backup.dump /
What happens if I dump the level 1 to a different file:
dump -1aLuf /mnt/bkup/backup1.dump /
I am trying to understand how dump keeps track of the changes. I am using a ext3 file system.
This is my /etc/dumpdates:
# cat /etc/dumpdates
/dev/sda2 0 Wed Feb 13 10:55:42 2013 -0600
/dev/sda2 1 Mon Feb 18 11:41:00 2013 -0600
My level 0 for this system was around 11GB and then I ran level 1 today and I used the same filename and the size was around 5 GB.
I think I figured out the issue. It looks like dump adds information in the file so it knows when the previous level occurred.
Level 0 backup
# file bkup_tmp_0_20130220
bkup_tmp_0_20130220: new-fs dump file (little endian), This dump Wed Feb 20 14:29:31 2013, Previous dump Wed Dec 31 18:00:00 1969, Volume 1, Level zero, type: tape header, Label my-label, Filesystem /tmp, Device /dev/sda3, Host myhostname, Flags 3
Level 1 backup, after some change
# file bkup_tmp_1_20130220
bkup_tmp_1_20130220: new-fs dump file (little endian), This dump Wed Feb 20 14:30:48 2013, Previous dump Wed Feb 20 14:29:31 2013, Volume 1, Level 1, type: tape header, Label my-label, Filesystem /tmp, Device /dev/sda3, Host myhostname, Flags 3