[UNIX / LINUX] taak opstarten onder een andere naam

[elgringo]

Ik heb een applicatie, die voor het gemak even 'test' heet. Deze moet een taat simuleren die 'applicatie' heet.

Nu kan ik 'applicatie' backuppen, 'test' copieren naar 'applicatie' en weer terug. Voor 1 taak is dit te doen, echter heb ik een aantal taken en eigenlijk zou ik 'test' willen laten starten met een andere naam.

Is dit mogelijk? Kan dit vanuit een shell, of alleen vanuit de code (C++ of C)?

[lamko]

Staat er wel heel beroerd en waarom als je test kopieert waarom wil je hem dan terugzetten

[thegve]

Wat Lamko zegt, kun je dit iets beter uitleggen, snap der helemaal niks van. Als je test onder een andere naam wilt uitvoeren, kun je 'mv test anderenaam' doen, of 'cp test anderenaam'. En dan uitvoeren, dan heb je hetzelfde commando onder een andere naam.

-- Maar ik neem aan dat je dat niet bedoeld

[elgringo]

Ik heb een lijst met taken, alle met een andere naam, alle gebruiken een onderdeel wat ik wil testen. Ik wil alleen dat onderdeel testen en niet de rest van de taak.

Dit onderdeel doet communicatie en data afhandeling binnen meerdere processen en ik wil data die deze taken generen simuleren of dezelfde data te versturen. Zo kan ik monitoren waar bottlenecks zitten.

Dus heb ik een taak gemaakt die de communicatie en data afhandeling simuleert. Echter wordt er gecommuniceerd met een taaknaam. Dus wil ik mijn simulatietaak laten opstarten als een andere taak zodat de communicatie wel naar de juiste taak gaat.

Bijv. orgineel heb ik taak1 tm 10. Deze communiceren alle met elkaar. Dit wil ik simuleren door 10 test taken te starten, met de taaknaam 1 tm 10. Zo heb exact hetzelfde communicatie path, maar die de andere overhead van de taken. Daarom wil ik 'tes't starten als taak1 .... taak10

[Keeper of the Keys]

Ik dacht dat de communicatie meestal ging met pids en niet met namen (al kun je natuurlijk een pid verkrijgen via de naam)...

Al klinkt wat je beschrijft hoe dan ook meer alsof je een library waar naar is gelinkt door andere versie wilt vervangen...

De communicatie zelf hangt af van het IPC mechanisme dat wordt gebruikt.

[Mijzelf]

Volgens mij kun je gewoon symlinks gebruiken. Ik kan me niet herinneren dat ik ooit op een embedded systeem 'busybox' in de takenlijst zag staan.

[Sprite_tm]

Taak? Applicatie? Wat bedoel je? Heb je het hier over een executable, een running process, een thread, een daemon, ...? Waarom zou je 'test' willen starten met een andere naam, is je code zo... interessant... geprogrammeerd dat de processnaam daadwerkelijk uitmaakt?

Sorry, maar zoals je het nu opschrijft valt er geen touw aan vast te knopen. Gebruik de juiste terminologie (of geef een wat minder summierre beschrijving) en we komen al een heel eind verder gok ik zo.

[elgringo]

Alle taken zijn applicaties. Executables dit stand-alone gestart kunnen worden vanuit de shell

Een applicate maakt gebruikt van een statisch gelinkt lib die communicatie en dataoverdahct regelt. Hier wordt ook adminstratie per applicaitenaam (taaknaam dus op een sun) bijgehouden. Deze adminstratie gaat natuurlijk niet kloppen als alle applicatie hetzelfde heten. Daarom wil ik de test applicatie, die alleen communcatie doet en geen andere dingen (die de orginele taken deden ie. GUI update, seriele poort communicatie, etc.) doet.

Dus moeten er taken komen die alleen communiceren (met de juiste naam) en verder allemaal exact hetzelfde zijn. Implemenatie is dus hetzelfde, behalve de naam. Ideaal zou zijn als ik bijv een taak op kan starten en een andere naam geven.

Zo een beetje duidelijk?

[elTigro]

Als je alleen onderscheid wilt maken in het aantal en wanneer runnende taken ofzo, kun je dan niet met het processid aan de gang? of is mijn interpretatie van jouw case te simpel?

[Sprite_tm]

Heb je hier wat aan?
Edit: Nm, werkt niet onder Solaris zie ik net.
Edit2: Hmm, dat ligt er natuurlijk maar net aan hoe je library inelkaarzit. Je zou eens in je testprogrammaatje een 'strcpy(argv[0],"blaat");' kunnen zetten voordat de lib initialiseert; als de veranderde naam in de accounting van je libdinges verschijnt kan je bovenstaande oplossing waarschijnlijk wel gebruiken.

[ Voor 82% gewijzigd door Sprite_tm op 10-12-2010 12:20 ]

[elTigro]

Sprite_tm schreef op vrijdag 10 december 2010 @ 12:15:

Edit2: Hmm, dat ligt er natuurlijk maar net aan hoe je library inelkaarzit. Je zou eens in je testprogrammaatje een 'strcpy(argv\[0],"blaat");' kunnen zetten voordat de lib initialiseert;

Moet je je programma niet iets als tool noemen of prog oid

[Sprite_tm]

Fair nuf, die strcpy-hack werkt alleen als hetgene waar je de naam in verandert even klein of kleiner is dan de oorspronkelijke naam. Als dat niet zo is kan je de code beschreven in het linkje gebruiken, maar dit leek me makkelijker als test.

[Osiris]

Gewoon per taak een symlink maken naar de originele applicatie? Heb je wel een zooi symlinkjes, maar who cares

[elTigro]

die symlink truuk werkt goed. busybox had allemaal linkjes naar 1 tool die anders uitgevoerd werd naar aanleiding van zijn aanroep ja.

Op zich ben ik wel voor hacken, maar het voorbeeld achter de link was best fraai, en aardig veilig ook, dus ik had zoiets van daar gaan we effe op stangen.
Overigens noem ik heel vaak mijn scripts gewoon scriptje, en moet je vooral aan de dir zien waar het instaat wat er precies gebeurd. Descriptive dirnames ftw

Bonus: ze hebben wel altijd een -d optie om debugging aan te zetten

[mace]

Mijn scripts heten altijd doeiets.sh ofzo, lekker duidelijk

[elgringo]

Osiris schreef op vrijdag 10 december 2010 @ 12:33:
Gewoon per taak een symlink maken naar de originele applicatie? Heb je wel een zooi symlinkjes, maar who cares

Dat was ook mijn eerste ingeving. args[0] aanpassen dacht ik dat niet zou werken, schijnbaar wel. Beide is wel mee te werken.

Ik ga iig even testen wat het beste (en snelste) werkt.

[Osiris]

Eventueel zou je natuurlijk ook kunnen hardlinken, wat je leuker vindt Maar symlinkjes vind ik vaak wat overzichterlijker in een `ls -l` staan Hardlinken lijkt me minder "overhead" hebben, omdat je OS verder eigenlijk niet doorheeft dat het één en dezelfde file is en hoeft verder ook niets extra's te doen. Toevallig wijzen ze gewoon naar hetzelfde stukje op je schijf Bij een symlinkje zal 't OS eerst de symlink 'lezen' neem ik aan om vervolgens de destination van dat linkje te openen et cetera blabla, moeilijk moeilijk (Geeft vást wat overhead..)

[ Voor 58% gewijzigd door Osiris op 10-12-2010 13:11 ]

[deadinspace]

Osiris schreef op vrijdag 10 december 2010 @ 13:09:
Eventueel zou je natuurlijk ook kunnen hardlinken, wat je leuker vindt Maar symlinkjes vind ik vaak wat overzichterlijker in een `ls -l` staan

Daar ben ik het over het algemeen mee eens

Hardlinken lijkt me minder "overhead" hebben, omdat je OS verder eigenlijk niet doorheeft dat het één en dezelfde file is en hoeft verder ook niets extra's te doen. Toevallig wijzen ze gewoon naar hetzelfde stukje op je schijf Bij een symlinkje zal 't OS eerst de symlink 'lezen' neem ik aan om vervolgens de destination van dat linkje te openen et cetera blabla, moeilijk moeilijk (Geeft vást wat overhead..)

Helemaal correct. Maar de overhead van het volgen van één symlink valt in het niet vergeleken bij wat het kost om een executable op te starten, dus meestal is dat geen belangrijke overweging

[Osiris]

deadinspace schreef op vrijdag 10 december 2010 @ 15:55:
[...]

Helemaal correct. Maar de overhead van het volgen van één symlink valt in het niet vergeleken bij wat het kost om een executable op te starten, dus meestal is dat geen belangrijke overweging

Ik had al zo'n flauw vermoeden Maar die conclusie liet ik over aan de TS zelf ter oefening ofzo