[9fans] acme crash recovery

[9fans] acme crash recovery

[Sascha Retzki]

Hi guys,

I had to hard-reboot my machine because of hardware-issues (my mouse gone wild :/), and I did not yet Put a source-file I was working on. Now, it is empty.

I once heared about acme crash recovery, something along the lines of acme stores everything in some file or something 'on a crash'. Does that apply here? Pointers to docs?

Furthermore, this is a default-value fossil-only installation, any chances there is a dump of yesterday? 9fs dump seems to exit file, yet /n/dump/ is still empty.


This is a distress call, it was four days of work ^^



Mfg, Sascha 

Re: [9fans] acme crash recovery

[geoff]

acme, like sam, keeps a log of changes in /tmp/*acme.  I believe that
such a file contains enough to reconstruct acme's state when (or
shortly before) it crashed, but I don't know of an automated means of
doing so.

Re: [9fans] acme crash recovery

[Charles Forsyth]

>> Furthermore, this is a default-value fossil-only installation, any chances there is a dump of yesterday? 9fs dump seems to exit file, yet /n/dump/ is still empty.

it won't do dumps if there isn't a venti to archive them, but
try 9fs snap and see if there is anything in /n/snap.
you might be lucky.

Re: [9fans] acme crash recovery

[Robert Raschke]

Sorry to hear of your disaster, Sascha.

Whenever I manage to "kill" my acme accidentally, I end up with a file
called 'acme.dump' in the directory where I started it.  If you have
the acme.dump file, you can get back the contents of all your open
panes.

Admittedly I start it by loading the dump file like so:
acme -l acme.dump
So I'm not sure if acme _always_ writes this file upon panicking or
only if it has been started by loading a dump file.  The Dump command
in acme also creates a dump file explicitly.

I think one of the few times acme doesn't write this file is when you
just turn off the power.

Robby

Re: [9fans] acme crash recovery

[erik quanstrom]

sorry to hear that.

wily, the acme clone, does automatic saves.  acme does not.  
however, you can force acme to  dump it's state manually with 
the Dump command.

i don't think that the default fossil setup does snapshots.  but i don't know.

- erik

On Sun Aug  6 11:00:26 CDT 2006, sretzki@gmx.de wrote:
> Hi guys,
> 
> I had to hard-reboot my machine because of hardware-issues (my mouse gone wild :/), and I did not yet Put a source-file I was working on. Now, it is empty.
> 
> I once heared about acme crash recovery, something along the lines of acme stores everything in some file or something 'on a crash'. Does that apply here? Pointers to docs?
> 
> Furthermore, this is a default-value fossil-only installation, any chances there is a dump of yesterday? 9fs dump seems to exit file, yet /n/dump/ is still empty.
> 
> 
> This is a distress call, it was four days of work ^^
> 
> 
> 
> Mfg, Sascha 

[9fans] DNS and ICMP

[Sha0lin]

Hello, 

I have installed a plan9 in qemu,
i can conect to google via telnet to tcp/80 and with hget tool
but i cannot ping to google, and i cannot resolve google name, 

i have not changed the /lib/ndb/local, but my /net/ndb is ok i have the 
dns=<my dns> directive. 

The cs daemon is started, i don't know what happens.
i can conect via telnet to my dns server to tcp/53 and linux resolves the 
names ok  with this nameserver. 

what i am doing wrong? 

sha0

Re: [9fans] DNS and ICMP

[ISHWAR RATTAN]

Qemu runs as a single process under host, ping needs an
internet node etc.

-ishwar

On Tue, 8 Aug 2006, Sha0lin wrote:

> Hello, 
> I have installed a plan9 in qemu,
> i can conect to google via telnet to tcp/80 and with hget tool
> but i cannot ping to google, and i cannot resolve google name, 
> i have not changed the /lib/ndb/local, but my /net/ndb is ok i have the 
> dns=<my dns> directive. 
> The cs daemon is started, i don't know what happens.
> i can conect via telnet to my dns server to tcp/53 and linux resolves the 
> names ok  with this nameserver. 
> what i am doing wrong? 
> sha0
>

Re: [9fans] DNS and ICMP

[erik quanstrom]

i think that ndb/dns may not realize that your machine is associated with
the dns server you specified.

here's what i use:

local:

database=
	file=/lib/ndb/local
	file=/lib/ndb/quanstro.net
	file=/lib/ndb/common
	file=/lib/ndb/root-servers

quanstro.net:

ipnet=ottawanat ip=192.168.0.0 ipmask=255.255.0.0
	dns=192.168.0.4
	dnsdomain=quanstro.net

substitute your ipnet, ip, ipmask, dns and dnsdomain.

the root-servers file wouldn't be used unless you're serving your own dns.

- erik

On Tue Aug  8 09:35:28 CDT 2006, Sha0@badchecksum.com wrote:
> Hello, 
> 
> I have installed a plan9 in qemu,
> i can conect to google via telnet to tcp/80 and with hget tool
> but i cannot ping to google, and i cannot resolve google name, 
> 
> i have not changed the /lib/ndb/local, but my /net/ndb is ok i have the 
> dns=<my dns> directive. 
> 
> The cs daemon is started, i don't know what happens.
> i can conect via telnet to my dns server to tcp/53 and linux resolves the 
> names ok  with this nameserver. 
> 
> what i am doing wrong? 
> 
> sha0

Re: [9fans] DNS and ICMP

["Nils O. Selåsdal"]

Sha0lin wrote:
> Hello,
> I have installed a plan9 in qemu,
> i can conect to google via telnet to tcp/80 and with hget tool
> but i cannot ping to google, and i cannot resolve google name,
> i have not changed the /lib/ndb/local, but my /net/ndb is ok i have the 
> dns=<my dns> directive.
> The cs daemon is started, i don't know what happens.
> i can conect via telnet to my dns server to tcp/53 and linux resolves 
> the names ok  with this nameserver.
> what i am doing wrong?
> sha0
You need to run the dns resolver too,
ndb/dns -r
usually.

Re: [9fans] acme crash recovery

[rog]

> acme, like sam, keeps a log of changes in /tmp/*acme.  I believe that
> such a file contains enough to reconstruct acme's state when (or
> shortly before) it crashed, but I don't know of an automated means of
> doing so.

i've done this, with mixed results, on a couple of occasions. it's almost
always more hassle than it's worth.

for a start acme doesn't keep all its state in the /tmp/*acme files, only that
which has been flushed out of memory. i looked into this, but can't
now remember what the criteria are. anyway, the temp file doesn't hold
all the metadata necessary for its reconstruction - it's just used as an external
adjunct to main memory. so you tend to get old and new versions of fragments
of text in different parts of the file. also, it's worth noting that
the characters in the file are held as two-byte runes (local endian). luckily they're
all two-byte aligned, otherwise things would be even harder.

i modified strings(1) to dump rune-based strings with no length restriction.
this provides a start, but more often than not the text you're looking for
is not in the file.

the most successful technique was when my mouse was unplugged (plugging it in
did not cause it to start working again). typing enough text in the current
window caused the text to be flushed to the temp file, enabling its retrieval
from another terminal, assuming you're using a remote fs.

acme does dump when it catches a note, but depending on the
circumstances sometimes just truncates the dump file, which can erase whatever
stuff you already had!

a couple of changes i've long contemplated:
  - if you restored acme from a given dump file, it should dump to the same file.
  - dumping should be "safe" - i.e. it should create the file under another name and dump to it
    before moving the original out of the way, moving the new file to the dump file and finally removing the original.
    less chance of erasing precious data this way.
  - an option to get acme to do an automatic dump every so often. (e.g. to acme.backup.dump)

but i'm also aware that these changes might be anathema to purists...

Re: [9fans] acme crash recovery

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 15-Aug-06, at 11:20 AM, rog@vitanuova.com wrote:
> but i'm also aware that these changes might be anathema to purists...

But then again, so is an acme crash/accidental kill.  I'd rather be  
able to get my state back.

Paul

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFE4hQ8pJeHo/Fbu1wRAkDkAJ9eoChINdfXiE/paMC3k14OXqaYTACfeZM/
xkDUMBUsE68R/aUJA+L9rWU=
=witP
-----END PGP SIGNATURE-----

Re: [9fans] acme crash recovery

[Sascha Retzki]

> acme, like sam, keeps a log of changes in /tmp/*acme.  I believe that
> such a file contains enough to reconstruct acme's state when (or
> shortly before) it crashed, but I don't know of an automated means of
> doing so.

Yes, that is what fgb told me to look for, too. Thanks.

Acme possibly never got a kill-note, tho - I rebooted via Ctrl+Alt+Del. Other possibilities include that I fire up acme on startup, so maybe acme cleans up /tmp ;)

No matter which one is right, there wasn't a /tmp/$number.$useracme-file containing my sources.


I tried a grep over things like /tmp, /sys/, /acme/, /usr, etc for function-names, so I am pretty sure the source-file is gone. Next version probably contains less design flaws, I am back up in the mood to (re)write it. 


> it won't do dumps if there isn't a venti to archive them, but
> try 9fs snap and see if there is anything in /n/snap.
> you might be lucky.

tried 9fs snap, too. Did not work, too.



Thanks for your time, Sascha