rsync toimii eri tavalla interaktiivisesti ja ei-

[ville]

Taustaa:
Mulla on Sleepwatcher ajossa iBookissa. Aina kun herätään unilta, suoritetaan käyttäj(i)än kotihakemistosta tiedosto .wakeup . Tässä tiedostossa käsketään ajaa backup-scripti jos ollaan omassa wlanissa (tutkitaan SSID:tä tämän toteamiseen). backup-tiedosto tutkii kotiverkon linux-palvelimelta, onko jo tältä päivältä varmuuskopiointihakemistoa, ja jos ei ole, jatkaa varmuuskopiointia seuraavasti: cp -al eilinen tämäpäivä.

Tämän jälkeen ajetaan rsync -ax --delete --numeric-ids /Users/ville palvelin:kohde/hakemisto/tämäpäivä .

Tuohon rsyncciin on lisätty --exclude-from -määrittely, joka sisältää mm. selaimen cache-hakemiston. Tämän ei kuitenkaan pitäisi vaikuttaa tähän ongelmaan.

Scripti toimii ja rsync ajetaan joka päivä vain kerran. Jostain syystä scripti ei-interaktiivisesti (eli ajettuna .wakeup-tiedostosta koneen herätessä unilta) ajettuna ei ollenkaan päivitä uusia tiedostoja, vain poistaa ne, mitä ei enää nykyisestä systeemistä löydy verrattuna kohdehakemistoon.

Jos ajan backup-scriptin interaktiivisena shellistä, niin tällöin sekä deletoidaan kohdehakemistosta (joka siis oli edellisen päivän hardlinkkihakemisto) vanhentuneet tiedostot että siirretään/päivitetään muuttuneet ja uudet tiedostot kohdehakemistoon.

Totesin tämän kuvion laittamalla option "v" tuolle rsyncille, jolloin näkee mitä se tekee. Logitan sen toimintoa tekstitiedostoon, joten voin siitä seurata mitä se tekee ei-interaktiivisena.

En vain ymmärrä enkä osaa keksiä, mistä homma kiikastaa. Miksi rsyncin toiminta on erilainen riippuen siitä, ajetaanko se interaktiivisena tai ei-interaktiivisena. Mä en ainakaan kyllä ymmärrä, enkä osaa asiaa selvittää enempää.

Osaisiko joku tämän forumin seuraajista?

Vihjeistä kiitollisena odotan vastauksia.

[freemem]

veikkaus ennen aamuteetä:
muistelenkohan oikein että "ei-interaktiivisena" pitää antaa rsyncin (suositttelisin jokaista komentoa varten vaikka cp tuntuisi toimivan) koko polku scriptissä.

[Kickarse]

Onkohan kyseessä miten pitkä skripti? Kehtaatko laittaa sen tänne kokonaisuudessaan niin näkisi vähän selvemmin mitä tapahtuu ja ihan mielenkiinnosta jos vaikka oppisi siitä jotain Kuulostaa nimittäin hyödylliseltä.

Tuo cp -al eilinen tämäpäivä ilmeisesti suoritetaan Linux palvelimen puolella koska ainakaan minun cp ei noita vipuja tunnistanut.

Kokeile lisätä vielä toinen -v tuohon rsyncciin niin näet vielä tarkemmin mitä siellä tapahtuu, eli laita -vv sinne.

[ville]

Polkuja komentoihin en ole laittanut, mutta hakemistoihin kyllä absoluuttiset polut. Eihän scripti tekisi mitään, jos cp tai rsynciä ei löytyisi.

Kenttätutkimus kuitenkin jatkuu. rsync -vv antaa tietysti vähän enemmän tietoa asiasta. Ja aivan totta, cp -al komento ajetaan linux-palvelimella (ssh host cp -al eilinen tämäpäivä).

Tällä tavalla se aloittaa, kun se ajetaan sleepwatcherin kautta:

Loput logista on vastaavaa kuin tämän pätkän loppu, eli /Users/ville/.jotain/jossain is uptodate. Vain pisteellä alkavat hakemistot tuo nyt listaa, ei tiedostoja ollenkaan esim. kotihakemiston juuressa. Outoa edelleen.

opening connection using ssh omatunnus.iki.fi rsync --server -vvlogDtprx --numeric-ids . /home/ville/stuff/scratch/ibook/2006-10-27
building file list ...
[sender] expand file_list to 131072 bytes, did move
[sender] excluding directory ville/darwinports because of pattern darwinports/
[sender] excluding directory ville/Desktop/downloads because of pattern downloads/
[sender] excluding directory ville/Library/Caches because of pattern Caches/
[sender] expand file_list to 262144 bytes, did move
[sender] excluding directory ville/mp3 because of pattern mp3/
done
[receiver] expand file_list to 262144 bytes, did move
delta-transmission enabled
ville/
ville/.CFUserTextEncoding is uptodate
ville/.DS_Store
ville/.MacOSX/environment.plist is uptodate

Varsinainen scripti, joka minulla operoi, on seuraavanlainen:

#!/bin/sh -x
# Modified 30.10.2004

# Based on lindi's version at http://iki.fi/lindi/backup

# You need to setup ssh keys to operate ssh from shell script!

# Are we connected to our home wlan?
SSID="`/usr/sbin/system_profiler SPAirPortDataType | awk -F": " '/Current Wireless Network/{print $2}'`"

if [ "$SSID" != "kotiwlan" ]
then
echo "We are not in our home network"
exit 1
fi

# Home directory in Mac
HOME="/Users/ville"

# Your remote machine (put username also there if they differ
SSH="omadomain.iki.fi"

#check uptime
ssh $SSH uptime

LAST_GOOD_BACKUP="`ssh $SSH find /home/ville/stuff/scratch/ibook -maxdepth 1 -name \"\?\?\?\?-\?\?-\?\?\"|sort -nr|head -1`"

if [ "$LAST_GOOD_BACKUP" == "" ]; then
echo "Couldn't find last good backup."
echo "Maybe you should run"
echo "rsync -a --delete --numeric-ids --exclude-from=excludes -e ssh /Users/ville $SSH:/backup/ibook/`date \"+%F\"`"
exit 1
fi

NEW_BACKUP="/home/ville/stuff/scratch/ibook/`date \"+%F\"`"

if [ "$LAST_GOOD_BACKUP" == "$NEW_BACKUP" ]; then
echo "backup already exists for today: $LAST_GOOD_BACKUP"
exit 1
fi

# Remove old backups until there is max 30 last backups
while [ `ssh $SSH find /home/ville/stuff/scratch/ibook/ -maxdepth 1 | wc -l` -gt 14 ]; do
OLDEST_GOOD_BACKUP="`ssh $SSH find /home/ville/stuff/scratch/ibook/ -maxdepth 1 -name \"\?\?\?\?-\?\?-\?\?\"|sort -n|head -1`"
echo ssh $SSH rm -rf $OLDEST_GOOD_BACKUP
ssh $SSH time rm -fr $OLDEST_GOOD_BACKUP

done


ssh $SSH time cp -al $LAST_GOOD_BACKUP $NEW_BACKUP

time rsync -avvx --numeric-ids --exclude-from=/Users/ville/backup/excludes /Users/ville $SSH:$NEW_BACKUP
#time rsync -avx --delete --numeric-ids --exclude-from=/Users/ville/backup/excludes /Users/ville $SSH:$NEW_BACKUP

Palvelimen rsync on versiota:
rsync version 2.6.4 protocol version 29

ibookin:
rsync version 2.6.3 protocol version 28

En käytä forkresursseja tukevaa rsynciä (pitäisi varmasti

Kokeilin ajaa rsyncin interaktiivisesti, niin tällöinkin tulee ihan sama rimpsu kuin yllä lainauksessa, siis tuon rsync-komennon osalta. Välillä --delete -vipu oli päällä ja välillä ei, joten sen puuttumista ei kannata ihmetellä.

Olen kyllä ymmälläni, toisaalta ihan hyvä, että asia tuli ilmi. Olinkin ihmetellyt välillä, että mikä ihme on ku ei ookaan palvelimella tuoreinta kauraa mitä varmasti edellispäivänä teki läppärilllä.

[Kickarse]

Selvennetääs hiukan. Eli siis interaktiivisessa moodissa tuo toimii edelleen kuten pitääkin? Tiedostot päivittyy ja kaikki pelittää? Mutta kun ajat Sleepwatcherilla niin homma ei pelitäkään ollenkaan? Eli tiedostot eivät päivity ja se oikeastaan operoi vain piilotiedostoilla? Etkä aja vain rsync-komentoa vaan ajat koko tuon skriptin molemmissa "versioissa"?

Oletko kokeillut ajaa cronista tuota skriptiä, mitä silloin tapahtuu?

Kokeileppa vaihtaa tuo ajoshell sh:sta vaikka bash:iin (pitäisi toimia ymmärtääkseni heittämällä), auttaisiko se jotain?

Eli

#!/bin/sh -x
=>
#!/bin/bash

[ville]

Cronista ajoin (kuhan ensin sain sinne työnnettyä jotain, tää halus käytettävän editoria joka editoi suoraan tiedostoa eikä pyöräytä sitä temppifilen läpi).

Kun cronista ajoi, niin se toimi niinkuin pitäisikin. En vaihtanut vielä sh=>bash, sillä en usko, että sillä on mitään merkitystä tässä tapauksessa. Mutta voin toki sen tehdä.

Cronista en vain voi pistää tätä scriptiä ajoon, koska tämä on läppäri, ja ei aina olla kotiverkossa tai muuta.

EDIT: Vaihdoin sh -> bash, ja eihän se auttanut. Edelleen vain pisteellä alkavat hakemistot vain päivitetään.

Tuolla sleepwatcherin kautta ajettuna ympäristö (ENVIRONMENT) on varmasti erilainen kuin muuten, mutta kun tietäisi mikä osa ja miksi se käyttäytyy näin rsyncin osalta.

[ville]

Selvennetääs hiukan. Eli siis interaktiivisessa moodissa tuo toimii edelleen kuten pitääkin? Tiedostot päivittyy ja kaikki pelittää? Mutta kun ajat Sleepwatcherilla niin homma ei pelitäkään ollenkaan? Eli tiedostot eivät päivity ja se oikeastaan operoi vain piilotiedostoilla? Etkä aja vain rsync-komentoa vaan ajat koko tuon skriptin molemmissa "versioissa"?

Selvennän tässä (itsenikin vuoksi):

1. Toimii edelleen interaktiivisesti, ja myös cronista niin, kuin pitääkin.

2. Kun sleepwatcherista ajetaan, niin tuo --delete -option mukaisesti poistetaan kyllä ne mitä on edellisen backupin jälkeen poistettu. Siivosin työpöytää tänään, ja nyt debugatessani tätä asiaa tuo asia näkyi selkeästi.

3. rsyncin päivitys kusee. Se koskee vain pisteellä alkaviin hakemistoihin, ja ei edes kaikkiin tiedostoihin, jotka alkavat pisteellä. Ainoita tiedostoja on joku .profile, eikä muu.

4. Ajan a backup-scriptin, se on listattu .wakeup -tiedostossa.

Kokeilen seuraavaksi pistää sinne .wakeup -tiedostoon ihan raa'an rsync-loitsun ja katsoa, mitä se tekee.

[Kickarse]

Sleepwatcher ajaa tuon .wakeup tiedoston seuraavalla tavalla, tiedä sitten josko se vaikuttaisi tuohon jotenkin:

Koodi: Valitse kaikki

unset name shell home

nigrep '^(name|home|shell)$' / /users | while read id node var val; do
        eval $var=$val
        [ "$name" -a "$shell" -a "$home" ] || continue
        if grep -q $shell /etc/shells >/dev/null; then
                if users | grep -q "\<${name:0:8}\>" >/dev/null; then
                        if [ -x "$home/.wakeup" ]; then
                                logger -t $0 "executing .wakeup of user $name"
                                su - $name -c "$home/.wakeup"
                        fi
                fi
        fi   

Tekeekö tuo "su" esimerkiksi jotain omia venkuloitaan, joka sitten vaikuttaisi rsynciin jotenkin?

Minun kohdalla tuo asettaa seuraavat muuttujat:

Koodi: Valitse kaikki

declare -x DYLD_LIBRARY_PATH="/usr/local/imagem/lib"
declare -x EDITOR="nano"
declare -x HOME="/Users/<USER>"
declare -x LD_LIBRARY_PATH="/usr/local/imagem/lib"
declare -x MAGICK_HOME="/usr/local/imagem"
declare -x OLDPWD
declare -x PATH="/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/Users/<USER>/Temp/Skriptit/Bash:/usr/local/imagem/bin"
declare -x PWD="/Users/<USER>"
declare -x SHELL="/bin/bash"
declare -x SHLVL="2"
declare -x USER="<USER>"
declare -x _="/bin/bash"

Ainoa joka tässä erottuu normaalista bashista on tuo SHLVL joka normaalitilanteessa on 1. En sitten tiedä vaikuttaa asiaan jotenkin.

Ehkä tästä ei mitään hyötyä ollut, mutta testasinpa kuitenkin Voisin itsekin tuota rsyncia jossain vaiheessa testata Sleepwatcherin kautta, kunhan jaksan nuo authentication-keyt asettaa kuntoon.

[ville]

Kokeilin ajaa ton homman näin komentorivltä:
su - ville "/Users/ville/.wakeup"

kyllä se sillon teki tarpeensa miten pitikin. :)
Koitin myös asentaa muuttujan SHLVL=2 , mutta eihän sillä ollut mitään vaikutusta asiaan.

Tämä on kyllä jo aika mielenkiintoinen ongelma :) Harmi, että se myös "vähän" vaikuttaa tähän mun varmistushässäkkään.

en kyllä lakkaa ihmettelemästä tätä. :)

[ville]

Olen vähän tutkinut lisää asiaa.

Jos laitan jonkin yksittäisen (pienemmän) hakemiston menemään rsyncillä, se onnistuu. Esim. Documents, 300Mt ja 3000 tiedostoa, ja ei mitään ongelmaa. Voisi tietysti kokeilla listata siihen useamman hakemiston, ja katsoa, missä vaiheessa alkaa tökkimään.

Laitoin piruuttain finkistä uudemman rsyncin, jos vaikka se vaikuttaisi. Jotain merkitystä sillä tuntui olevan, sillä lista oli hiukan erilainen. Enimmäkseen edelleen pisteellä alkavia, mutta joukossa vähän tiedostoja kotihakemistosta.

Jotenkin näin karvalakkituntumalta tuntuisi nyt, että sleepwatcherin kautta ajettuna tuossa voisi olla jokin rajoite, miten isoa hakemistoa tuo pystyy käsittelemään. Arvailua tietysti tämä.

[ville]

Nyt tähän ongelmaan on tulossa jotain ratkaisua.

Tutkinta on kyllä vielä kesken, mutta tällä hetkellä oletus on se, että tuo kaatuu jotenkin seuraavanlaiseen tilanteeseen:

Mulla on pari exclude-määritystä ( Caches/ , mp3/ jne), ettei ihan semmosta mikä on muuallakin tai turhaa, siirretä. Jostain syystä nuo on jääneet kummittelemaan tonne alkuperäseen varmuuskopiointisykliin, joita olen tehnyt (joka päivälle siis oma hardlink-hakemistonsa, jonka päälle ajetaan rsync).

Nämä voi nähdä tuolta pari postausta aiemmasta, excluding dir foobar/darwinports, esimerkiksi.

Mun teoria on, että koska rsync ei koske noihin, ei edes poista niitä olemassaolevia hakemistoja sieltä varmistuskohdehakemistosta tuon exclude-määrityksen vuoksi, niin se rsync jotenkin sen takia menee jouseen.

Huomasin ko. asian tässä tänään ja poistelin sieltä kohdehakemistosta käsin nuo exclude-hakemistot, ja sen jälkeen tuo rsync ei-interaktiivisesti alkoi pelittämään.

On vielä kesken siirto, kun kopioin noita exclude-hakemistoja tuonne testatakseni, toimiiko rsync senkin jälkeen. Jos teoriani osoittautuu oikeaksi, niin hyvä. Ongelma selvisi, mutta joku viisaampi saa kyllä selittää, miksi näin. :)

Palaan asiaan, kun olen siirtänyt wlanin yli n. 8Gt roinaa.

[ville]

Kokeilin vielä yhtä kikkaa. Eli ohjata stderrin myös logitiedostoon, jotta näkisin, että mitä siellä mahdollisesti tapahtuu.

Minulla on siis nyt sleepwatcherin .wakeup -tiedostossa seuraavaa, jolla stderr ohjataan logiin:
/Users/ville/backup/backup >> wakeup.log 2>&1

Mikä kummallisinta, tämän jälkeen alkoi pelittää. Samalla kerralla kokeilin finkin rsynciä, ja luulin sen olevan ensin ratkaisu. Mutta kokeiltuani finkin ja osx:n rsynciä tulokset olivat samoja. Sen lisäksi, että logitiedostoon tuli samaa mitä ajettuna komentoriviltä sama varmistustiedosto, tiedostot oikeasti myös siirtyivät.

Äskeisen postauksen testaukset eivät olleet siis ratkaisu ongelmaan, eikä sillä ollut mitään vaikutusta tässä ongelmassa.

Kokeilin monta kertaa, ilman "2>&1" ja sen kanssa, ja pakko se on uskoa, että tämä vaikuttaa. Mutta osaako joku sanoa, miten ihmeessä? Minä en ainakaan ymmärrä. Painotan siis, että näiden kokeiden välillä EN koskenut itse backup-scriptiin ollenkaan, vaan vain .wakeup -tiedostoon, josta itse backup-scripti käynnistetään.

Voisin tietysti vielä kokeilla ilman mitään tiedostoon logitusta, mitä tapahtuu. Ja kun näin tein, niin ei toimi. Jos jotain päivittää, niin ei ainakaan testi-tiedostoa Documents-hakemistossa.

Olen niin ällikällä päähän lyöty, että vaikka jotain pientä unix-maailmasta tiedän, niin tämä menee jotenkin niin ufojutuksi, ettei mitään rajaa.

Iloinen olen siitä, että rsync käytössäni taitaa vihdoin toimia siten, miten sen alunperinkin ajattelin. Nähtäväksi jää, miten käy tulevina päivinä. Toimiiko jatkossakin vai ei.