Opnieuw connecten terwijl de server stopt?

[hans erik]

Ik besprak vandaag met een van de beheerders van een klant de verschillende beheersopties van Filemaker Server (console <> CLI) en toen zei hij dat ze de server wel eens stopten wanneer die 'vastliep', maar dat gebruikers toch opnieuw aanlogden terwijl het aflsuiten al bezig was. Dat kan toch niet? Volgens mijn informatie kun je wel een aantal minuten instellen vooordat gebruikers die niet zelf afloggen, losgekoppeld worden. Maar vanaf het moment dat je de stop-procedure in gang zet, blokkeert FileMaker Server toch alle nieuwe connecties?

 

Dus als dit wel gebeurt, wat kan er dan aan de hand zijn?

[Peter Wagemans]

In de admin concole portal kan je zien dat de file de status "closing" krijgt terwijl hij probeert om de clients van die file buiten te werken.

Ik kan mij ook niet voorstellen dat FileMaker iemand laat inloggen op een file die de "closing" status heeft.

Misschien legt hij het niet goed uit.

Als je met verschillende bestanden werkt, dan kan het natuurlijk zijn dat file A file B nodig heeft. Misschien loopt er daar iets fout.

 

Bij deze nieuwe versie 14 zie ik de optie om de files niet automatisch te openen als de server start. Hoera FileMaker. Nog even en het is helemaal goed. Nu nog de optie om de server niet beschikbaar te maken tot alle files geopend zijn. In de andere richting: alle bestanden tegelijkertijd de closing state geven kan, gewoon door ze allemaal tegelijkertijd te sluiten. Ik maak de goeie gewoonte om dat eerst te doen vooraleer de server te stoppen. Bij een request om de server component te stoppen zonder dit manueel eerst zelf te doen, gaat de fms dit wel voor zijn rekening pakken, maar heb je geen feedback meer.

Bij een Mac server sluit ik eerst alle files, en als dat gebeurd is doe ik "sudo launchctl stop com.filemaker.fms" vanuit de terminal, alvorens de machine volledig te herstarten.

Dat scheelt 'm nogal in herstart tijd.

[hans erik]

Juist. Ik heb het overigens ook geprobeerd op mijn eigen ontwikkelserver. Zodra je de server stopt (het schuifje in de console van I naar O, ofwel het fmsadmin STOP SERVER), kunnnen de bestanden niet meer geopend worden, noch door nieuwe klanten, noch door bestaande klanten die een script activeren ofzo.

Je krijgt gewoon 'Bestand xxx kon niet gevonden worden' of iets in de bekende FileMaker trant.

 

En dat is logisch, want anders zou je ook allemaal problemen gaan krijgen met lokale caches enzovoorts.

 

Het rare is alleen dat er over de hele gang van zaken niet zoveel informatie te vinden is. De manuals en white papers komen niet verder dan een syntax van fmsadmin STOP SERVER of CLOSE DATABASE, maar wat FMS daarna precies gaat doen is niet duidelijk.

 

Er is zoiets als een referance manual die ik gemist heb?

 

HE

[SuperWimmie]

...Ik maak de goeie gewoonte om dat eerst te doen vooraleer de server te stoppen....

 

Ik ook.Zelf werk ik al jaren onder Windows.

Met name versie 6 had (en heb) ik uitstaan bij klanten, met Server 2008 er op.

Haal het niet in je hoofd om de server te herstarten, zonder in Filemaker de bestanden gesloten te hebben.

Server was eerder sneller uitgeschakeld dan Filemaker haar bestanden gesloten kreeg.

Met corrupted bestanden tot gevolg.

 

Hoe de afsluitingsprocedure in FM14 gaat... volgens mij is dat wel verbetert.

Ik merk Server 2008R2 heel duidelijk aangeeft dat hij Filemaker Server aan het stoppen is bij een herstart.

Maar ik durf het niet te testen... iets te veel ervaringen opgedaan.

[hans erik]

Ja, ik denk dat de afsluitprocedure bij FMS14 wel beter gaat, en dat de server pas stopt als alle bestanden netjes zijn gesloten en gebruikers afgekoppeld.

 

Maar nog een keer mijn stokpaardje: het staat nergens fatsoenlijk gedocumenteerd, althans niet op een manier die voor mij toegankelijk is. Het wordt echt hoog tijd dat FMI hier eens iets aan doet, en dat we niet meer afhankelijk zijn van de enkele expert die toevallig iemand bij FMI kent of er gewerkt heeft.

 

Als ik met mijn testserver (MacMini, FMS13, OSX) in de Finder 'Restart' kies (de 'botte bijl methode'), lijkt alles ook op een normale geordende manier afgewerkt te worden: eerst stopt FMServer, dat op zijn beurt de gebruikers afkoppelt en de bestanden sluit, en dan pas restart OSX. FMS stuurt naar de aangesloten clients een melding: er verschijnt een 'Close File' dialoog waarin de bestanden worden getoond die je open hebt staan, en de melding Stopping FileMaker Database Engine...

Reageer je niet, dan word je na een seconde of 10 afgekoppeld. Dus ik denk dat FMS het proces netjes afhandelt. Je moet dus met je takken van de Aan/uit knop afblijven en ook Ctrl-Alt-Del e.d. zijn geen goede opties.

Het Event log laat ook een keurige sequentie van events zien, en bij het opnieuw openen geen integrity checks oid.

 

Maar of WindowsServer 2008 het bij een softwarematige restart ook zo netjes afhandelt zou ik niet kunnen zeggen.

[Peter Wagemans]

Maar nog een keer mijn stokpaardje: het staat nergens fatsoenlijk gedocumenteerd, althans niet op een manier die voor mij toegankelijk is. Het wordt echt hoog tijd dat FMI hier eens iets aan doet, en dat we niet meer afhankelijk zijn van de enkele expert die toevallig iemand bij FMI kent of er gewerkt heeft.

Dat is inderdaad zo. En even nog een ander aspect toelichten van FileMaker NON-documentatie. Zo is het bijvoorbeeld mogelijk om de webserver ( op OSX ) te herstarten via het fmsadmin commando. Maar de documentatie slaat dat gewoon over:

    Valid server TYPEs:
       ADMINSERVER     Stops then starts the Admin Server.
       SERVER          Stops then starts the Database Server.

   Valid process TYPEs:
       FMSE            Restarts the FileMaker Script Engine process.
       FMSIB           Restarts the Server Progressive Backup process.
       XDBC            Restarts the ODBC/JDBC listener process.
       WPE             Restarts all Web Publishing processes.

 

Ik veronderstel dat het op Windows niet werkt, ik heb hier direct een PC opstelling om dit te proberen. Maar gebruik "httpserver" als process type op een OSX machine en hops, werkt ook.

De werking van al die processen is dan weer mijn stokpaardje. Server start altijd FMSE op, willen of niet. XDBC kan afgezet worden in de web interface, maar kan dan niet meer gestart worden met fmsadmin, want het is een "disabled" switch. De httpserver start altijd op, of je het nu wil of niet, en is een component die alleen nodig is als je WPE start. Plug-ins kunnen alleen voor FMSE in- en uitgeschakeld worden... en ga zo maar door. Begrijpe wie begrijpe kan...

Ikzelf draai regelmatig FileMaker Server vanop m'n eigen MacBook, zeker als ik offline databases moet bouwen. De server geeft me de zekerheid dat alles constant gebackupt wordt terwijl ik werk. Maar als je FIleMaker Server installeert op je eigen machine, dan gaat fms_helperdaemon in de clinch met je FileMaker client applicatie, omdat hij de 5003 poort wil hebben. Maar zonder terminal commando's kom je hier niet uit.

Daarom ook ben ik al een tijdje aan het bouwen aan een tooltje met grafische user interface dat dit voor mij regelt.

[bigbadwolf]

Het zou zo mooi zijn als het allemaal feilloos werkt... maar natuurlijk is niets minder waar.

De interface van de server is wat mijn betreft altijd een ondergeschoven kind geweest en gebleven. Met name de onbetrouwbaarheid van zowel de interface als de server zelf. Het komt bij ons regelmatig voor dat de Script Engine onderuit gaat. En als deze dan niet gestart kan worden omdat de terminal de volgende medling geeft:

 

MacMiniServer:~ admin$ fmsadmin restart fmse

-bash: fmsadmin: command not found

 

dan wordt ik daar niet blij van, want de enige remedie is nu de server herstarten...

[Banach]

/Library/Filemaker\ Server/Database\ Server/bin/fmsadmin restart fmse

[Peter Wagemans]

Inderdaad, dat is de beste manier om fmsadmin op te roepen als je OSX terminal niet meer weet waar fmsadmin staat - wat op zichzelf wel een raar fenomeen is.

Type het volgende in de terminal:

echo $PATH

Het is een goeie manier om te kijken waar OSX gaat zoeken naar je fmsadmin commando.

Je ziet dan bijvoorbeeld staan ( ik neem hier even mijn eigen OSX servertje om testen )

/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/Server.app/Contents/ServerRoot/usr/bin:/Applications/Server.app/Contents/ServerRoot/usr/sbin

Eerste reactie: tiens, geen path naar de FileMaker Server bin folder… maar kijk eens in de /usr/local/bin folder en je ziet 2 symbolic links staan:

ls -la /usr/local/bin
total 16
drwxr-xr-x  4 root  wheel  136 May 18 16:13 .
drwxr-xr-x  4 root  wheel  136 Nov 22  2015 ..
lrwxr-xr-x  1 root  wheel   54 May 18 16:13 fmsadmin -> /Library/FileMaker Server/Database Server/bin/fmsadmin
lrwxr-xr-x  1 root  wheel   59 May 18 16:13 fmsgetpasskey -> /Library/FileMaker Server/Database Server/bin/fmsgetpasskey

Zijn die symbolic links verdwenen, dan werkt het dus niet meer. Je kan ze echter terug aanmaken. En je ondertussen afvragen waarom die links er niet meer waren, me dunkt.

 

lectuur:

http://www.cyberciti.biz/faq/appleosx-bash-unix-change-set-path-environment-variable/

http://apple.stackexchange.com/questions/115646/how-can-i-create-a-symbolic-link-in-terminal

 

Op Windows wordt alles geregeld via de environment variables.

Lees eerst dit hier:

https://lsdbtech.wordpress.com/2015/05/28/windows-server-2012-r2-change-environment-variables/

De environment variables

FMS_HOME

moet bestaan en heeft de waarde

C:\Program Files\FileMaker\FileMaker Server\

Er staan "NEW" en "Edit" knopjes, dus dit is (iets) gebruikvriendelijker dan op OSX.

Als ik me niet vergis moet je echter wel herstarten om die variabelen te initialiseren, ik kan me echter vergissen, de laatste keer dat ik hiermee gestoeid heb was in Windows 2000.