macOS ekosisteminde arka plan g\u00f6revlerini ve otomasyon s\u00fcre\u00e7lerini y\u00f6netmek, do\u011fru ara\u00e7larla olduk\u00e7a verimli olabilir. Bu ara\u00e7lar\u0131n ba\u015f\u0131nda \u015f\u00fcphesiz macOS i\u015fletim sisteminin kalbinde yer alan \u00d6ncelikle, G\u00f6revleri y\u00f6netmek i\u00e7in kullan\u0131lan ana komut sat\u0131r\u0131 arac\u0131 ise Otomasyonun amac\u0131, i\u015fleri h\u0131zland\u0131rmak ve insan m\u00fcdahalesini azaltmakt\u0131r. Ancak bazen, bir Bir Peki, bu t\u00fcr sistem donmalar\u0131ndan nas\u0131l ka\u00e7\u0131nabiliriz? \u0130lk ve en \u00f6nemli ad\u0131m, g\u00f6revlerinizi m\u00fcmk\u00fcn oldu\u011funca atomik ve k\u0131sa s\u00fcreli tutmakt\u0131r. Uzun s\u00fcrmesi beklenen g\u00f6revleri daha k\u00fc\u00e7\u00fck par\u00e7alara b\u00f6lmek, her bir par\u00e7an\u0131n kendi i\u00e7inde ba\u015far\u0131l\u0131 olup olmad\u0131\u011f\u0131n\u0131 kontrol etmeyi kolayla\u015ft\u0131r\u0131r. Ayr\u0131ca, g\u00f6revlerinizi \u00e7al\u0131\u015ft\u0131ran betiklerde (script) harici kaynaklara eri\u015firken mutlaka zaman a\u015f\u0131m\u0131 (timeout) mekanizmalar\u0131 kullanmal\u0131s\u0131n\u0131z. macOS’ta yerle\u015fik olarak bulunan Yukar\u0131daki \u00f6rnekte, Terminalde \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131zda, kabuk (shell) (\u00f6rne\u011fin Bash veya Zsh) ba\u015flang\u0131\u00e7 dosyalar\u0131n\u0131z\u0131 ( Bu sorunu \u00e7\u00f6zmenin birka\u00e7 yolu vard\u0131r. En basit ve en g\u00fcvenilir y\u00f6ntem, betiklerinizde veya Ancak, her komut i\u00e7in tam yolu belirtmek pratik olmayabilir, \u00f6zellikle karma\u015f\u0131k betiklerde. Bu durumda, Yukar\u0131daki \u00f6rnekte, Bu y\u00f6ntem, karma\u015f\u0131k betiklerde Otomasyon g\u00f6revleri genellikle arka planda sessizce \u00e7al\u0131\u015f\u0131r ve kullan\u0131c\u0131 aray\u00fcz\u00fc ile do\u011frudan etkile\u015fim kurmaz. Bu durum, her \u015fey yolunda gitti\u011finde harikad\u0131r, ancak bir sorun ortaya \u00e7\u0131kt\u0131\u011f\u0131nda, g\u00f6revin neden ba\u015far\u0131s\u0131z oldu\u011funu anlamak ger\u00e7ek bir ba\u015f a\u011fr\u0131s\u0131na d\u00f6n\u00fc\u015febilir. “Gizemli Hatalar” olarak adland\u0131rd\u0131\u011f\u0131m\u0131z bu durum, Bir betik veya program \u00e7al\u0131\u015ft\u0131r\u0131ld\u0131\u011f\u0131nda, normalde konsola bilgi mesajlar\u0131 ( Bu tuzaktan ka\u00e7\u0131nman\u0131n anahtar\u0131, Yukar\u0131daki \u00f6rnekte, g\u00f6revin normal \u00e7\u0131kt\u0131lar\u0131 Loglama stratejisi olu\u015ftururken dikkat edilmesi gereken bir di\u011fer nokta ise log rotasyonudur. Zamanla log dosyalar\u0131 \u00e7ok b\u00fcy\u00fcyebilir ve disk alan\u0131n\u0131 t\u00fcketebilir. macOS, Bir Bir g\u00f6revi yanl\u0131\u015f kategoriye yerle\u015ftirmek veya g\u00f6revin \u00e7al\u0131\u015ft\u0131r\u0131ld\u0131\u011f\u0131 kullan\u0131c\u0131 ile eri\u015fmeye \u00e7al\u0131\u015ft\u0131\u011f\u0131 dosyalar\u0131n sahibi\/izinleri aras\u0131nda bir uyumsuzluk olmas\u0131, izin problemlerine yol a\u00e7ar. \u00d6rne\u011fin, Bu tuzaktan ka\u00e7\u0131nmak i\u00e7in, \u00f6ncelikle g\u00f6revinizin hangi kullan\u0131c\u0131 ba\u011flam\u0131nda \u00e7al\u0131\u015fmas\u0131 gerekti\u011fini net bir \u015fekilde belirlemelisiniz. Kullan\u0131c\u0131ya \u00f6zel g\u00f6revler i\u00e7in E\u011fer bir Bu yakla\u015f\u0131m, \u00d6rne\u011fin, bir g\u00f6revin her 5 dakikada bir \u00e7al\u0131\u015fmas\u0131n\u0131 istersiniz ve Bu zamanlama karma\u015fas\u0131ndan kurtulmak i\u00e7in a\u015fa\u011f\u0131daki noktalara dikkat etmelisiniz:<\/p>\n Zamanlama anahtarlar\u0131n\u0131n ince farklar\u0131n\u0131 anlamak ve bunlar\u0131 do\u011fru senaryolarda kullanmak, Otomasyon g\u00f6revlerinizin Bu ileri d\u00fczey ipu\u00e7lar\u0131 ve en iyi uygulamalar, launchd<\/code> gelir. Ancak, g\u00fc\u00e7l\u00fc bir ara\u00e7 olmas\u0131yla birlikte, launchd<\/code>‘nin kendine \u00f6zg\u00fc zorluklar\u0131 ve tuzaklar\u0131 da mevcuttur. \u00d6zellikle yirmi alt\u0131 otomasyon g\u00f6revi gibi karma\u015f\u0131k senaryolarla u\u011fra\u015f\u0131rken, sistem donmalar\u0131, PATH de\u011fi\u015fkeni sorunlar\u0131 ve beklenmedik davran\u0131\u015flar can s\u0131k\u0131c\u0131 hale gelebilir. Bu makalede, launchd<\/code> ile \u00e7al\u0131\u015f\u0131rken s\u0131k\u00e7a kar\u015f\u0131la\u015f\u0131lan be\u015f kritik sorunu detayl\u0131ca inceleyecek, bu tuzaklardan nas\u0131l ka\u00e7\u0131naca\u011f\u0131n\u0131z\u0131 ve otomasyon s\u00fcre\u00e7lerinizi nas\u0131l daha sorunsuz hale getirece\u011finizi ad\u0131m ad\u0131m a\u00e7\u0131klayaca\u011f\u0131z. Haz\u0131r olun, \u00e7\u00fcnk\u00fc otomasyonun karanl\u0131k y\u00fcz\u00fcn\u00fc ayd\u0131nlatmaya ba\u015fl\u0131yoruz!<\/p>\nlaunchd Nedir ve Neden Otomasyon \u0130\u00e7in \u00d6nemlidir?<\/h2>\n
launchd<\/code>, sistemin ba\u015flat\u0131lmas\u0131ndan itibaren \u00e7al\u0131\u015fan t\u00fcm s\u00fcre\u00e7leri, servisleri ve kullan\u0131c\u0131ya \u00f6zel arka plan g\u00f6revlerini y\u00f6neten evrensel bir hizmet y\u00f6netim \u00e7er\u00e7evesidir (service management framework). Geleneksel Unix sistemlerindeki init<\/code>, inetd<\/code> ve cron<\/code> gibi farkl\u0131 bile\u015fenlerin g\u00f6revlerini tek bir \u00e7at\u0131 alt\u0131nda toplayarak modern macOS ortam\u0131nda otomasyonun temelini olu\u015fturur. Peki, bu kadar merkezi bir rol oynayan launchd<\/code> neden bu kadar \u00f6nemlidir?<\/p>\nlaunchd<\/code> esneklik sunar. Bir g\u00f6revi belirli bir zamanda (StartCalendarInterval<\/code>), belirli aral\u0131klarla (StartInterval<\/code>), bir dosya veya dizin de\u011fi\u015fti\u011finde (WatchPaths<\/code>), hatta bir uygulama ba\u015flat\u0131ld\u0131\u011f\u0131nda veya sonland\u0131r\u0131ld\u0131\u011f\u0131nda tetikleyebilir. Bu, geli\u015ftiricilere ve sistem y\u00f6neticilerine, sistemin ihtiya\u00e7lar\u0131na g\u00f6re dinamik ve reaktif otomasyon \u00e7\u00f6z\u00fcmleri olu\u015fturma imkan\u0131 tan\u0131r. \u00d6rne\u011fin, bir web sunucusunun her zaman \u00e7al\u0131\u015f\u0131r durumda olmas\u0131n\u0131 sa\u011flamak, belirli bir klas\u00f6re yeni bir dosya eklendi\u011finde otomatik bir yedekleme ba\u015flatmak veya her sabah belirli bir raporu olu\u015fturmak gibi senaryolar launchd<\/code> ile kolayca hayata ge\u00e7irilebilir.<\/p>\nlaunchd<\/code> g\u00f6revleri, genellikle XML format\u0131nda yaz\u0131lm\u0131\u015f .plist<\/code> (Property List) dosyalar\u0131 arac\u0131l\u0131\u011f\u0131yla tan\u0131mlan\u0131r. Bu dosyalar, g\u00f6revin ne yapaca\u011f\u0131n\u0131 (Program<\/code> veya ProgramArguments<\/code>), ne zaman \u00e7al\u0131\u015faca\u011f\u0131n\u0131, hangi ortam de\u011fi\u015fkenlerini kullanaca\u011f\u0131n\u0131 (EnvironmentVariables<\/code>), \u00e7\u0131kt\u0131lar\u0131n\u0131n nereye y\u00f6nlendirilece\u011fini (StandardOutPath<\/code>, StandardErrorPath<\/code>) ve daha bir\u00e7ok yap\u0131land\u0131rma bilgisini i\u00e7erir. Bu .plist<\/code> dosyalar\u0131, kullan\u0131c\u0131n\u0131n kendi g\u00f6revleri i\u00e7in ~\/Library\/LaunchAgents\/<\/code> dizininde, sistem genelindeki g\u00f6revler i\u00e7in ise \/Library\/LaunchAgents\/<\/code> veya \/Library\/LaunchDaemons\/<\/code> dizinlerinde saklan\u0131r.<\/p>\nlaunchctl<\/code>‘dir. Bu komut sayesinde yeni g\u00f6revleri y\u00fckleyebilir (load<\/code>), mevcut g\u00f6revleri listeden kald\u0131rabilir (unload<\/code>), g\u00f6revlerin durumunu kontrol edebilir (list<\/code>) ve hatta an\u0131nda \u00e7al\u0131\u015ft\u0131rabilirsiniz (start<\/code>). launchd<\/code>‘nin sa\u011flad\u0131\u011f\u0131 bu merkezi y\u00f6netim ve esneklik, macOS \u00fczerinde sa\u011flam ve g\u00fcvenilir otomasyon \u00e7\u00f6z\u00fcmleri geli\u015ftirmek i\u00e7in vazge\u00e7ilmez bir ara\u00e7 olmas\u0131n\u0131 sa\u011flar. Ancak, bu g\u00fcc\u00fcn beraberinde getirdi\u011fi karma\u015f\u0131kl\u0131k, bazen beklenmedik sorunlara yol a\u00e7abilir. \u015eimdi, bu sorunlar\u0131n en kritik be\u015f tanesine yak\u0131ndan bakal\u0131m.<\/p>\n1. Tuzak: Uzun S\u00fcren G\u00f6revler ve Sistem Donmalar\u0131 (A 4-Minute Freeze)<\/h2>\n
launchd<\/code> g\u00f6revi beklenenden \u00e7ok daha uzun s\u00fcrebilir ve hatta t\u00fcm sistemi ge\u00e7ici olarak dondurabilir. “A 4-Minute Freeze” olarak adland\u0131r\u0131lan bu durum, genellikle bir g\u00f6revin sonsuz bir d\u00f6ng\u00fcye girmesi, a\u011f kaynaklar\u0131n\u0131 beklerken tak\u0131l\u0131 kalmas\u0131 veya a\u015f\u0131r\u0131 kaynak t\u00fcketimi nedeniyle sistemin kilitlenmesiyle ortaya \u00e7\u0131kar. Bu, \u00f6zellikle birden fazla otomasyon g\u00f6revinin e\u015f zamanl\u0131 \u00e7al\u0131\u015ft\u0131\u011f\u0131 ve her birinin potansiyel olarak sisteme y\u00fck bindirebilece\u011fi senaryolarda ciddi bir sorun haline gelir.<\/p>\nlaunchd<\/code> g\u00f6revinin uzun s\u00fcre tak\u0131l\u0131 kalmas\u0131n\u0131n k\u00f6k nedenleri \u00e7e\u015fitlilik g\u00f6sterebilir. \u00d6rne\u011fin, bir betik (script) harici bir API’ye ba\u011flanmaya \u00e7al\u0131\u015f\u0131rken a\u011f ba\u011flant\u0131s\u0131 sorunlar\u0131 ya\u015fayabilir ve varsay\u0131lan bir zaman a\u015f\u0131m\u0131 (timeout) mekanizmas\u0131 olmad\u0131\u011f\u0131 i\u00e7in s\u00fcresiz bekleyebilir. Veya, bir dosya i\u015flemi beklenenden daha b\u00fcy\u00fck bir dosya \u00fczerinde \u00e7al\u0131\u015f\u0131rken veya disk I\/O’su (giri\u015f\/\u00e7\u0131k\u0131\u015f) yo\u011fun oldu\u011funda tak\u0131labilir. Bu t\u00fcr durumlar, launchd<\/code>‘nin kendisini veya ili\u015fkili s\u00fcre\u00e7leri bloklayarak sistemin genel yan\u0131t verme h\u0131z\u0131n\u0131 d\u00fc\u015f\u00fcrebilir, hatta tamamen durma noktas\u0131na getirebilir. \u00d6zellikle KeepAlive<\/code> anahtar\u0131n\u0131n yanl\u0131\u015f kullan\u0131lmas\u0131, tak\u0131l\u0131 kalan bir g\u00f6revin s\u00fcrekli yeniden ba\u015flat\u0131lmas\u0131na ve sorunun daha da b\u00fcy\u00fcmesine neden olabilir.<\/p>\ntimeout<\/code> komutu, belirli bir s\u00fcre sonra bir komutu otomatik olarak sonland\u0131rmak i\u00e7in harika bir yoldur.<\/p>\n\n <key>ProgramArguments<\/key>\n <array>\n <string>\/usr\/bin\/timeout<\/string>\n <string>300<\/string> <!-- 300 saniye = 5 dakika -->\n <string>\/path\/to\/your\/long_running_script.sh<\/string>\n <\/array>\n <\/code><\/pre>\n<\/div>\nlong_running_script.sh<\/code> beti\u011fi 300 saniyeden (5 dakika) fazla \u00e7al\u0131\u015f\u0131rsa otomatik olarak sonland\u0131r\u0131lacakt\u0131r. Bu, g\u00f6revin sistemi sonsuza dek bloke etmesini engeller. Ayr\u0131ca, betiklerinizin arka planda \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flamak i\u00e7in komutun sonuna &<\/code> eklemek de faydal\u0131 olabilir, ancak bu, launchd<\/code>‘nin g\u00f6revin ba\u015far\u0131yla tamamland\u0131\u011f\u0131n\u0131 do\u011fru bir \u015fekilde izlemesini zorla\u015ft\u0131rabilir. Bu nedenle, timeout<\/code> kullan\u0131m\u0131 daha g\u00fcvenli bir yakla\u015f\u0131md\u0131r. Son olarak, launchd<\/code>‘nin ThrottleInterval<\/code> anahtar\u0131n\u0131 kullanarak bir g\u00f6revin ba\u015far\u0131s\u0131z olduktan sonra \u00e7ok s\u0131k yeniden ba\u015flat\u0131lmas\u0131n\u0131 engelleyebilirsiniz. Bu anahtar, bir g\u00f6revin yeniden ba\u015flat\u0131lmas\u0131 aras\u0131nda beklenecek minimum s\u00fcreyi saniye cinsinden belirtir, b\u00f6ylece sistem kaynaklar\u0131n\u0131n a\u015f\u0131r\u0131 t\u00fcketilmesinin \u00f6n\u00fcne ge\u00e7ilir.<\/p>\n2. Tuzak: Kay\u0131p Komutlar ve Yanl\u0131\u015f PATH De\u011fi\u015fkeni (A Dead PATH)<\/h2>\n
launchd<\/code> ile otomasyon g\u00f6revleri geli\u015ftirirken kar\u015f\u0131la\u015f\u0131lan en yayg\u0131n ve kafa kar\u0131\u015ft\u0131r\u0131c\u0131 sorunlardan biri, terminalde sorunsuz \u00e7al\u0131\u015fan bir komutun launchd<\/code> g\u00f6revi alt\u0131nda “command not found” (komut bulunamad\u0131) hatas\u0131 vermesidir. Bu duruma genellikle “A Dead PATH” (\u00f6l\u00fc bir PATH) denir ve k\u00f6k nedeni, launchd<\/code>‘nin g\u00f6revleri \u00e7al\u0131\u015ft\u0131rd\u0131\u011f\u0131 ortam\u0131n, sizin terminalde al\u0131\u015fk\u0131n oldu\u011funuz ortamdan farkl\u0131 olmas\u0131d\u0131r. \u00d6zellikle PATH<\/code> ortam de\u011fi\u015fkeni, bu farkl\u0131l\u0131\u011f\u0131n en belirgin g\u00f6stergesidir.<\/p>\n.bashrc<\/code>, .zshrc<\/code>, .profile<\/code> vb.) y\u00fckler. Bu dosyalar genellikle PATH<\/code> de\u011fi\u015fkeninize \u00f6zel dizinler (\u00f6rne\u011fin, Homebrew ile y\u00fcklenen ara\u00e7lar\u0131n dizinleri \/usr\/local\/bin<\/code> gibi) ekler. Ancak launchd<\/code>, g\u00f6revleri do\u011frudan bir kabuk ortam\u0131nda de\u011fil, minimalist bir ortamda \u00e7al\u0131\u015ft\u0131r\u0131r. Bu minimalist ortam\u0131n PATH<\/code> de\u011fi\u015fkeni genellikle yaln\u0131zca \/usr\/bin<\/code> ve \/bin<\/code> gibi temel sistem dizinlerini i\u00e7erir. Dolay\u0131s\u0131yla, bu dizinlerde bulunmayan \u00f6zel komutlar\u0131n\u0131z veya Homebrew ile y\u00fckledi\u011finiz ara\u00e7lar\u0131n\u0131z launchd<\/code> taraf\u0131ndan bulunamaz.<\/p>\nlaunchd<\/code>‘nin ProgramArguments<\/code> anahtar\u0131nda \u00e7al\u0131\u015ft\u0131raca\u011f\u0131n\u0131z her komutun tam yolunu belirtmektir. \u00d6rne\u011fin, python<\/code> yerine \/usr\/local\/bin\/python3<\/code> veya node<\/code> yerine \/usr\/local\/bin\/node<\/code> kullanmak gibi. Bu, komutun nerede oldu\u011funa bak\u0131lmaks\u0131z\u0131n her zaman do\u011fru y\u00fcr\u00fct\u00fclebilir dosyay\u0131 bulmas\u0131n\u0131 sa\u011flar.<\/p>\nlaunchd<\/code>‘nin EnvironmentVariables<\/code> anahtar\u0131n\u0131 kullanarak g\u00f6revinize \u00f6zel bir PATH<\/code> ortam de\u011fi\u015fkeni tan\u0131mlayabilirsiniz. Bu anahtar, g\u00f6reviniz i\u00e7in ge\u00e7erli olacak ortam de\u011fi\u015fkenlerini belirlemenizi sa\u011flar. Kendi PATH<\/code>‘inizi tan\u0131mlayarak, g\u00f6revinizin ihtiya\u00e7 duydu\u011fu t\u00fcm dizinleri ekleyebilirsiniz.<\/p>\n\n <key>EnvironmentVariables<\/key>\n <dict>\n <key>PATH<\/key>\n <string>\/usr\/local\/bin:\/usr\/bin:\/bin:\/usr\/sbin:\/sbin<\/string>\n <\/dict>\n <key>ProgramArguments<\/key>\n <array>\n <string>\/path\/to\/your\/script.sh<\/string>\n <\/array>\n <\/code><\/pre>\n<\/div>\nPATH<\/code> de\u011fi\u015fkenine Homebrew’un varsay\u0131lan kurulum dizini olan \/usr\/local\/bin<\/code> eklenmi\u015ftir. Kendi terminalinizin PATH<\/code> de\u011fi\u015fkenini echo $PATH<\/code> komutuyla \u00f6\u011frenip, ihtiyac\u0131n\u0131z olan t\u00fcm dizinleri buraya eklemelisiniz. Alternatif olarak, g\u00f6revinizi bir kabuk beti\u011fi (\u00f6rne\u011fin, .sh<\/code> dosyas\u0131) arac\u0131l\u0131\u011f\u0131yla \u00e7al\u0131\u015ft\u0131rabilir ve bu beti\u011fin ba\u015f\u0131nda kendi PATH<\/code>‘inizi ayarlayabilirsiniz. Bu beti\u011fi launchd<\/code>‘ye Program<\/code> veya ProgramArguments<\/code> ile g\u00f6stererek, beti\u011fin i\u00e7indeki PATH<\/code> ayarlar\u0131n\u0131n ge\u00e7erli olmas\u0131n\u0131 sa\u011flayabilirsiniz. \u00d6rne\u011fin:<\/p>\n\n #!\/bin\/bash\n export PATH=\"\/usr\/local\/bin:\/usr\/bin:\/bin:\/usr\/sbin:\/sbin\"\n \/usr\/local\/bin\/my_custom_command arg1 arg2\n # Di\u011fer komutlar...\n <\/code><\/pre>\n<\/div>\nPATH<\/code> sorunlar\u0131n\u0131 y\u00f6netmek i\u00e7in olduk\u00e7a etkilidir. Hangi y\u00f6ntemi se\u00e7erseniz se\u00e7in, launchd<\/code> g\u00f6revlerinizin do\u011fru PATH<\/code> ortam\u0131na sahip oldu\u011fundan emin olmak, “command not found” hatalar\u0131n\u0131 ortadan kald\u0131rman\u0131n anahtar\u0131d\u0131r.<\/p>\n3. Tuzak: Gizemli Hatalar ve \u00c7\u0131k\u0131\u015f Yollar\u0131n\u0131n Y\u00f6netimi<\/h2>\n
launchd<\/code> g\u00f6revlerinin herhangi bir \u00e7\u0131kt\u0131 veya hata mesaj\u0131 \u00fcretmeden sessizce \u00e7\u00f6kmesiyle karakterizedir. Geli\u015ftiriciler genellikle “G\u00f6revim \u00e7al\u0131\u015fm\u0131yor ama hi\u00e7bir hata mesaj\u0131 da g\u00f6rm\u00fcyorum!” sitemiyle kar\u015f\u0131la\u015f\u0131rlar. Bu durumun temel nedeni, launchd<\/code> g\u00f6revlerinin varsay\u0131lan olarak standart \u00e7\u0131kt\u0131lar\u0131n\u0131 (stdout<\/code>) ve standart hata \u00e7\u0131kt\u0131lar\u0131n\u0131 (stderr<\/code>) bir yere y\u00f6nlendirmemesidir.<\/p>\nstdout<\/code>) veya hata mesajlar\u0131 (stderr<\/code>) yazar. Terminalde bu mesajlar\u0131 do\u011frudan g\u00f6r\u00fcr\u00fcz. Ancak launchd<\/code>, bu ak\u0131\u015flar\u0131 otomatik olarak bir dosyaya y\u00f6nlendirmez. Sonu\u00e7 olarak, g\u00f6reviniz i\u00e7inde bir hata olu\u015ftu\u011funda veya bekledi\u011finiz bir \u00e7\u0131kt\u0131 \u00fcretilmedi\u011finde, bu bilgiler kaybolur ve hata ay\u0131klama s\u00fcreci adeta karanl\u0131kta el yordam\u0131yla ilerlemeye benzer. Bu durum, \u00f6zellikle karma\u015f\u0131k veya d\u0131\u015f ba\u011f\u0131ml\u0131l\u0131klar\u0131 olan g\u00f6revlerde ciddi zaman kay\u0131plar\u0131na yol a\u00e7abilir.<\/p>\nlaunchd<\/code>‘nin StandardOutPath<\/code> ve StandardErrorPath<\/code> anahtarlar\u0131n\u0131 do\u011fru bir \u015fekilde yap\u0131land\u0131rmakt\u0131r. Bu anahtarlar, g\u00f6revinizin standart \u00e7\u0131kt\u0131 ve hata ak\u0131\u015flar\u0131n\u0131 belirtilen dosya yollar\u0131na y\u00f6nlendirmesini sa\u011flar. Bu sayede, g\u00f6reviniz her \u00e7al\u0131\u015ft\u0131\u011f\u0131nda, t\u00fcm loglar ve hata mesajlar\u0131 bu dosyalara yaz\u0131l\u0131r ve siz de g\u00f6revinizin i\u00e7 i\u015fleyi\u015fi hakk\u0131nda de\u011ferli bilgiler edinirsiniz.<\/p>\n\n <key>StandardOutPath<\/key>\n <string>\/var\/log\/my_automation_job.log<\/string>\n <key>StandardErrorPath<\/key>\n <string>\/var\/log\/my_automation_job_error.log<\/string>\n <key>ProgramArguments<\/key>\n <array>\n <string>\/path\/to\/your\/script.sh<\/string>\n <\/array>\n <\/code><\/pre>\n<\/div>\n\/var\/log\/my_automation_job.log<\/code> dosyas\u0131na, hata \u00e7\u0131kt\u0131lar\u0131 ise \/var\/log\/my_automation_job_error.log<\/code> dosyas\u0131na yaz\u0131lacakt\u0131r. Log dosyalar\u0131n\u0131 d\u00fczenli olarak kontrol etmek (\u00f6rne\u011fin tail -f \/var\/log\/my_automation_job_error.log<\/code> komutuyla), g\u00f6revinizin sa\u011fl\u0131k durumunu izlemenin ve sorunlar\u0131 an\u0131nda tespit etmenin en etkili yoludur. Log dosyalar\u0131 i\u00e7in ~\/Library\/Logs\/<\/code> veya \/var\/log\/<\/code> gibi standart dizinleri kullanmak, y\u00f6netim kolayl\u0131\u011f\u0131 sa\u011flar.<\/p>\nlogrotate<\/code> gibi yerle\u015fik ara\u00e7lar sunar, ancak betiklerinizde veya sistem genelinde log rotasyonunu manuel olarak yap\u0131land\u0131rmak da m\u00fcmk\u00fcnd\u00fcr. \u00d6rne\u011fin, belirli bir boyuta ula\u015ft\u0131\u011f\u0131nda eski loglar\u0131 s\u0131k\u0131\u015ft\u0131rmak veya silmek gibi. Bu, disk alan\u0131n\u0131 y\u00f6netmenize ve sadece en g\u00fcncel bilgilere odaklanman\u0131za yard\u0131mc\u0131 olur. Unutmay\u0131n, iyi bir loglama stratejisi, launchd<\/code> otomasyonunuzun g\u00fcvenilirli\u011fini ve s\u00fcrd\u00fcr\u00fclebilirli\u011fini do\u011frudan etkiler. Loglar\u0131n\u0131z, g\u00f6revinizin karanl\u0131kta kalm\u0131\u015f s\u0131rlar\u0131n\u0131 ayd\u0131nlatan birer fenerdir.<\/p>\n4. Tuzak: \u0130zin Problemleri ve Kullan\u0131c\u0131 Farkl\u0131l\u0131klar\u0131<\/h2>\n
launchd<\/code> g\u00f6revinin d\u00fczg\u00fcn \u00e7al\u0131\u015fmamas\u0131n\u0131n en sinir bozucu nedenlerinden biri, genellikle g\u00f6zden ka\u00e7an izin (permission) sorunlar\u0131d\u0131r. Terminalde kendi kullan\u0131c\u0131 hesab\u0131n\u0131zla sorunsuz bir \u015fekilde \u00e7al\u0131\u015ft\u0131rd\u0131\u011f\u0131n\u0131z bir betik veya komut, launchd<\/code> alt\u0131nda “Permission denied” (\u0130zin reddedildi) hatas\u0131 verebilir veya belirli dosyalara\/dizinlere eri\u015femeyebilir. Bu durum, launchd<\/code> g\u00f6revlerinin farkl\u0131 kullan\u0131c\u0131 ba\u011flamlar\u0131nda \u00e7al\u0131\u015fabilmesi ve her ba\u011flam\u0131n kendine \u00f6zg\u00fc dosya eri\u015fim yetkilerine sahip olmas\u0131 ger\u00e7e\u011finden kaynaklan\u0131r.<\/p>\nlaunchd<\/code>, g\u00f6revleri \u00fc\u00e7 ana kategoriye ay\u0131r\u0131r:<\/p>\n\n
~\/Library\/LaunchAgents\/<\/code> dizininde bulunurlar. Bu g\u00f6revler, ilgili kullan\u0131c\u0131n\u0131n dosya eri\u015fim izinlerine sahiptir.<\/li>\n\/Library\/LaunchAgents\/<\/code> dizininde bulunurlar. Yine, belirli bir kullan\u0131c\u0131 ba\u011flam\u0131nda \u00e7al\u0131\u015f\u0131rlar.<\/li>\nroot<\/code> kullan\u0131c\u0131s\u0131 alt\u0131nda \u00e7al\u0131\u015fan g\u00f6revlerdir. Genellikle \/Library\/LaunchDaemons\/<\/code> dizininde bulunurlar. Bu g\u00f6revler, sistemin en y\u00fcksek yetkilerine sahiptir.<\/li>\n<\/ol>\n~\/Library\/LaunchAgents\/<\/code> alt\u0131na koydu\u011funuz bir g\u00f6rev, \/var\/www\/html<\/code> gibi root<\/code> veya _www<\/code> kullan\u0131c\u0131s\u0131na ait bir dizine yazmaya \u00e7al\u0131\u015ft\u0131\u011f\u0131nda izin hatas\u0131 alacakt\u0131r. Benzer \u015fekilde, \/Library\/LaunchDaemons\/<\/code> alt\u0131na koydu\u011funuz bir g\u00f6rev, root<\/code> olarak \u00e7al\u0131\u015faca\u011f\u0131 i\u00e7in, kullan\u0131c\u0131ya \u00f6zel bir dizine (\u00f6rne\u011fin ~\/Documents\/<\/code>) yazmak i\u00e7in \u00f6zel izinlere ihtiya\u00e7 duyabilir veya bu t\u00fcr bir eri\u015fim g\u00fcvenlik riski olu\u015fturabilir.<\/p>\nUser Agents<\/code>, sistem genelinde ve root<\/code> yetkileriyle \u00e7al\u0131\u015fmas\u0131 gereken g\u00f6revler i\u00e7in ise System Daemons<\/code> kullan\u0131n. \u0130kinci olarak, g\u00f6revinizin eri\u015fmeye \u00e7al\u0131\u015ft\u0131\u011f\u0131 t\u00fcm dosya ve dizinlerin izinlerini (chmod<\/code>) ve sahipliklerini (chown<\/code>) kontrol edin. G\u00f6revi \u00e7al\u0131\u015ft\u0131ran kullan\u0131c\u0131n\u0131n (veya root<\/code> ise t\u00fcm kullan\u0131c\u0131lar\u0131n) ilgili dosya ve dizinlere okuma, yazma veya y\u00fcr\u00fctme izinlerine sahip oldu\u011fundan emin olun.<\/p>\n\n # Beti\u011fin y\u00fcr\u00fctme iznine sahip oldu\u011fundan emin olun\n chmod +x \/path\/to\/your\/script.sh\n\n # Beti\u011fin veya eri\u015fti\u011fi dosyalar\u0131n sahibini kontrol edin\n ls -l \/path\/to\/your\/script.sh\n <\/code><\/pre>\n<\/div>\nSystem Daemon<\/code> olu\u015fturuyorsan\u0131z ve g\u00f6revin belirli bir kullan\u0131c\u0131 alt\u0131nda \u00e7al\u0131\u015fmas\u0131n\u0131 istiyorsan\u0131z, UserName<\/code> anahtar\u0131n\u0131 kullanabilirsiniz. Bu, root<\/code> olarak ba\u015flayan daemon’\u0131n belirli bir kullan\u0131c\u0131 kimli\u011fine ge\u00e7mesini sa\u011flar ve b\u00f6ylece g\u00fcvenlik risklerini azalt\u0131r:<\/p>\n\n <key>UserName<\/key>\n <string>your_username<\/string>\n <key>ProgramArguments<\/key>\n <array>\n <string>\/path\/to\/your\/script.sh<\/string>\n <\/array>\n <\/code><\/pre>\n<\/div>\nroot<\/code> yetkilerini gerektirmeyen ancak sistem genelinde olmas\u0131 gereken g\u00f6revler i\u00e7in idealdir. \u0130zin sorunlar\u0131 genellikle log dosyalar\u0131nda a\u00e7\u0131k\u00e7a belirtilir, bu y\u00fczden 3. tuzakta bahsetti\u011fimiz loglama stratejisi burada da hayati \u00f6nem ta\u015f\u0131r. Do\u011fru izinleri ve kullan\u0131c\u0131 ba\u011flamlar\u0131n\u0131 anlamak, launchd<\/code> otomasyonunuzun sorunsuz \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flaman\u0131n temelidir.<\/p>\n5. Tuzak: Zamanlama Karma\u015fas\u0131 ve Beklenmedik Davran\u0131\u015flar<\/h2>\n
launchd<\/code>‘nin en g\u00fc\u00e7l\u00fc \u00f6zelliklerinden biri, g\u00f6revleri \u00e7e\u015fitli tetikleyicilerle zamanlama yetene\u011fidir. Ancak bu esneklik, ayn\u0131 zamanda “Zamanlama Karma\u015fas\u0131” ad\u0131 verilen bir tuza\u011fa da yol a\u00e7abilir. G\u00f6revlerin hi\u00e7 ba\u015flamamas\u0131, beklenenden \u00e7ok daha s\u0131k \u00e7al\u0131\u015fmas\u0131 veya tamamen yanl\u0131\u015f bir zamanda tetiklenmesi, geli\u015ftiricilerin launchd<\/code> ile ya\u015fad\u0131\u011f\u0131 yayg\u0131n sorunlard\u0131r. Bu durum genellikle StartInterval<\/code>, StartCalendarInterval<\/code>, RunAtLoad<\/code> ve WatchPaths<\/code> gibi zamanlama anahtarlar\u0131n\u0131n yanl\u0131\u015f anla\u015f\u0131lmas\u0131ndan veya birbiriyle \u00e7eli\u015fen kullan\u0131mlar\u0131ndan kaynaklan\u0131r.<\/p>\nStartInterval<\/code> anahtar\u0131n\u0131 300<\/code> saniyeye ayarlars\u0131n\u0131z. Ancak g\u00f6reviniz bir t\u00fcrl\u00fc ba\u015flamaz. Bu, g\u00f6revinizi launchctl load<\/code> ile y\u00fckledi\u011finizde RunAtLoad<\/code> anahtar\u0131n\u0131n true<\/code> olarak ayarlanmam\u0131\u015f olmas\u0131ndan kaynaklanabilir; bu durumda g\u00f6rev, sistem yeniden ba\u015flat\u0131lana kadar veya manuel olarak ba\u015flat\u0131lana kadar \u00e7al\u0131\u015fmaz. Ya da, g\u00f6revinizi StartInterval<\/code> ile ayarlars\u0131n\u0131z, ancak g\u00f6revin \u00e7al\u0131\u015fmas\u0131 uzun s\u00fcrer ve bir sonraki aral\u0131k gelmeden \u00f6nce tamamlanmaz, bu da \u00e7ak\u0131\u015fmalara veya kaynak t\u0131kan\u0131kl\u0131\u011f\u0131na yol a\u00e7abilir.<\/p>\nStartInterval<\/code>, g\u00f6revin son tamamlanmas\u0131ndan belirli bir s\u00fcre sonra yeniden ba\u015flat\u0131lmas\u0131n\u0131 sa\u011flar. Ancak g\u00f6revin \u00e7al\u0131\u015fmas\u0131 bu s\u00fcreyi a\u015farsa, bir sonraki \u00e7al\u0131\u015fma gecikebilir. StartCalendarInterval<\/code> ise daha \u00e7ok cron<\/code> benzeri bir davran\u0131\u015f sunar; g\u00f6revin belirli bir takvim zaman\u0131nda (\u00f6rne\u011fin, her g\u00fcn sabah 9’da, her Pazartesi) \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flar, g\u00f6revin s\u00fcresinden ba\u011f\u0131ms\u0131z olarak. Bu, \u00f6zellikle d\u00fczenli raporlama veya bak\u0131m g\u00f6revleri i\u00e7in idealdir.<\/p>\n\n <!-- Her 5 dakikada bir \u00e7al\u0131\u015f\u0131r (son tamamlanmadan sonra) -->\n <key>StartInterval<\/key>\n <integer>300<\/integer>\n\n <!-- Her g\u00fcn sabah 9'da \u00e7al\u0131\u015f\u0131r -->\n <key>StartCalendarInterval<\/key>\n <dict>\n <key>Hour<\/key>\n <integer>9<\/integer>\n <key>Minute<\/key>\n <integer>0<\/integer>\n <\/dict>\n <\/code><\/pre>\n<\/div>\nWatchPaths<\/code> anahtar\u0131 ise tamamen farkl\u0131 bir tetikleme mekanizmas\u0131 sunar: belirli bir dosya veya dizinde de\u011fi\u015fiklik oldu\u011funda g\u00f6revi tetikler. Bu, otomatik yedekleme veya dosya i\u015fleme g\u00f6revleri i\u00e7in \u00e7ok kullan\u0131\u015fl\u0131d\u0131r. Ancak, izlenen dizinde \u00e7ok s\u0131k de\u011fi\u015fiklik olmas\u0131 durumunda g\u00f6revin a\u015f\u0131r\u0131 s\u0131k tetiklenmesine yol a\u00e7abilir, bu da sistem kaynaklar\u0131n\u0131 gereksiz yere t\u00fcketir.<\/p>\n\n
StartInterval<\/code> veya StartCalendarInterval<\/code>, olay tabanl\u0131 g\u00f6revler i\u00e7in WatchPaths<\/code>.<\/li>\nRunAtLoad<\/code> Kullan\u0131m\u0131:<\/strong> G\u00f6revinizin sisteme y\u00fcklendi\u011finde (veya kullan\u0131c\u0131 oturumu a\u00e7t\u0131\u011f\u0131nda) bir kez \u00e7al\u0131\u015fmas\u0131n\u0131 istiyorsan\u0131z, RunAtLoad<\/code> anahtar\u0131n\u0131 true<\/code> olarak ayarlay\u0131n.<\/li>\nKeepAlive<\/code> Dikkatli Kullan\u0131m\u0131:<\/strong> KeepAlive<\/code> anahtar\u0131, g\u00f6revinizin her zaman \u00e7al\u0131\u015f\u0131r durumda olmas\u0131n\u0131 sa\u011flar ve beklenmedik bir \u015fekilde sonland\u0131\u011f\u0131nda otomatik olarak yeniden ba\u015flat\u0131r. Ancak, sonsuz d\u00f6ng\u00fcye giren veya s\u0131k s\u0131k \u00e7\u00f6ken bir g\u00f6revle birlikte kullan\u0131ld\u0131\u011f\u0131nda sistemi a\u015f\u0131r\u0131 y\u00fckleyebilir. Yaln\u0131zca ger\u00e7ekten s\u00fcrekli \u00e7al\u0131\u015fmas\u0131 gereken servisler i\u00e7in kullan\u0131n.<\/li>\nlaunchctl list<\/code> ile Durum Kontrol\u00fc:<\/strong> G\u00f6revlerinizin durumunu d\u00fczenli olarak launchctl list | grep \"your.label\"<\/code> komutuyla kontrol edin. Bu, g\u00f6revin y\u00fckl\u00fc olup olmad\u0131\u011f\u0131n\u0131, \u00e7al\u0131\u015f\u0131p \u00e7al\u0131\u015fmad\u0131\u011f\u0131n\u0131 ve PID (Process ID) bilgisini g\u00f6rmenizi sa\u011flar.<\/li>\nlaunchd<\/code> otomasyonunuzun \u00f6ng\u00f6r\u00fclebilir ve g\u00fcvenilir olmas\u0131n\u0131 sa\u011flar. Planl\u0131 bir yakla\u015f\u0131mla, launchd<\/code>‘nin sundu\u011fu t\u00fcm zamanlama g\u00fcc\u00fcnden faydalanabilirsiniz.<\/p>\n\u0130leri D\u00fczey \u0130pu\u00e7lar\u0131 ve En \u0130yi Uygulamalar<\/h2>\n
launchd<\/code> ile temel tuzaklardan ka\u00e7\u0131nmay\u0131 \u00f6\u011frendikten sonra, otomasyon s\u00fcre\u00e7lerinizi daha da optimize etmek ve karma\u015f\u0131k senaryolar\u0131 y\u00f6netmek i\u00e7in baz\u0131 ileri d\u00fczey ipu\u00e7lar\u0131 ve en iyi uygulamalar\u0131 benimsemek faydal\u0131 olacakt\u0131r. Bu uygulamalar, hem hata ay\u0131klama s\u00fcrecinizi kolayla\u015ft\u0131racak hem de launchd<\/code> g\u00f6revlerinizin s\u00fcrd\u00fcr\u00fclebilirli\u011fini art\u0131racakt\u0131r.<\/p>\nplist Dosyas\u0131 Do\u011frulamas\u0131 ve Temizli\u011fi<\/h3>\n
launchd<\/code> plist dosyalar\u0131, XML format\u0131nda yaz\u0131ld\u0131\u011f\u0131ndan, s\u00f6zdizimi hatalar\u0131 (syntax errors) g\u00f6revinizin hi\u00e7 y\u00fcklenmemesine neden olabilir. Bu t\u00fcr hatalar\u0131 elle bulmak zor olabilir. Neyse ki, macOS’ta plutil<\/code> ad\u0131nda bir ara\u00e7 bulunur. Bu ara\u00e7, plist dosyalar\u0131n\u0131z\u0131 do\u011frulamak ve hatta XML’den JSON’a veya tersine d\u00f6n\u00fc\u015ft\u00fcrmek i\u00e7in kullan\u0131labilir. G\u00f6revinizi y\u00fcklemeden \u00f6nce her zaman plutil -lint \/path\/to\/your\/job.plist<\/code> komutuyla dosyan\u0131z\u0131 do\u011frulay\u0131n. Ayr\u0131ca, gereksiz anahtarlar\u0131 (key) ve yorumlar\u0131 (comment) temiz tutarak plist dosyalar\u0131n\u0131z\u0131 okunabilir ve y\u00f6netilebilir hale getirin.<\/p>\n\n plutil -lint ~\/Library\/LaunchAgents\/com.example.myjob.plist\n <\/code><\/pre>\n<\/div>\nlaunchctl ile Geli\u015fmi\u015f Hata Ay\u0131klama<\/h3>\n
launchctl<\/code> komutu, sadece g\u00f6revleri y\u00fckleyip listelemekten \u00e7ok daha fazlas\u0131n\u0131 yapabilir. \u00d6zellikle hata ay\u0131klama (debugging) i\u00e7in g\u00fc\u00e7l\u00fc se\u00e7enekler sunar:<\/p>\n\n
launchctl debug<\/code>:<\/strong> Bu komut, bir g\u00f6revin ba\u015flat\u0131lmas\u0131n\u0131 duraklatman\u0131za ve ona bir hata ay\u0131klay\u0131c\u0131 (debugger) eklemenize olanak tan\u0131r. Karma\u015f\u0131k g\u00f6revlerin i\u00e7 i\u015fleyi\u015fini anlamak i\u00e7in paha bi\u00e7ilmezdir.<\/li>\nlaunchctl blame <label><\/code>:<\/strong> Bir g\u00f6revin neden ba\u015far\u0131s\u0131z oldu\u011funu veya beklenenden farkl\u0131 davrand\u0131\u011f\u0131n\u0131 anlamak i\u00e7in bu komutu kullanabilirsiniz. Genellikle bir hata kodu veya k\u0131sa bir a\u00e7\u0131klama sa\u011flar.<\/li>\nlaunchctl procinfo <pid><\/code>:<\/strong> \u00c7al\u0131\u015fan bir s\u00fcrecin ayr\u0131nt\u0131l\u0131 bilgilerini (ortam de\u011fi\u015fkenleri, kaynak limitleri vb.) g\u00f6rmek i\u00e7in PID (Process ID) ile birlikte kullan\u0131labilir.<\/li>\n<\/ul>\nS\u00fcr\u00fcm Kontrol\u00fc ve Mod\u00fclerlik<\/h3>\n
.plist<\/code> dosyalar\u0131n\u0131 ve ili\u015fkili betiklerini (script) bir s\u00fcr\u00fcm kontrol sistemi (\u00f6rne\u011fin Git) alt\u0131nda tutmak, de\u011fi\u015fiklikleri izlemenizi, geri alman\u0131z\u0131 ve ekip i\u00e7inde i\u015fbirli\u011fi yapman\u0131z\u0131 sa\u011flar. Ayr\u0131ca, g\u00f6revlerinizi mod\u00fcler hale getirmeye \u00e7al\u0131\u015f\u0131n. B\u00fcy\u00fck, karma\u015f\u0131k betikler yerine, her biri tek bir i\u015flevi yerine getiren daha k\u00fc\u00e7\u00fck betikler olu\u015fturun ve bunlar\u0131 launchd<\/code> ile zincirleyin veya ayr\u0131 ayr\u0131 y\u00f6netin. Bu, hata ay\u0131klamay\u0131 ve bak\u0131m\u0131 b\u00fcy\u00fck \u00f6l\u00e7\u00fcde basitle\u015ftirir.<\/p>\nKaynak Limitleri ve G\u00fcvenlik<\/h3>\n
launchd<\/code>, g\u00f6revleriniz i\u00e7in kaynak limitleri (SoftResourceLimits<\/code>, HardResourceLimits<\/code>) belirlemenize olanak tan\u0131r. Bu, bir g\u00f6revin sistem kaynaklar\u0131n\u0131 (CPU, bellek, dosya tan\u0131mlay\u0131c\u0131lar\u0131 vb.) a\u015f\u0131r\u0131 t\u00fcketmesini engelleyerek sistemin genel stabilitesini korumaya yard\u0131mc\u0131 olur. G\u00fcvenlik a\u00e7\u0131s\u0131ndan, g\u00f6revlerinizi m\u00fcmk\u00fcn olan en d\u00fc\u015f\u00fck yetki seviyesiyle \u00e7al\u0131\u015ft\u0131r\u0131n. E\u011fer root<\/code> yetkileri gerekmiyorsa, User Agent<\/code> olarak veya System Daemon<\/code> ise UserName<\/code> anahtar\u0131yla belirli bir kullan\u0131c\u0131 alt\u0131nda \u00e7al\u0131\u015ft\u0131r\u0131n.<\/p>\nlaunchd<\/code> ile \u00e7al\u0131\u015f\u0131rken kar\u015f\u0131la\u015f\u0131lan zorluklar\u0131 a\u015fman\u0131za ve daha sa\u011flam, g\u00fcvenilir ve y\u00f6netilebilir otomasyon \u00e7\u00f6z\u00fcmleri olu\u015fturman\u0131za yard\u0131mc\u0131 olacakt\u0131r. Unutmay\u0131n, iyi planlanm\u0131\u015f ve d\u00fczenli olarak bak\u0131m\u0131 yap\u0131lan bir otomasyon altyap\u0131s\u0131, uzun vadede size b\u00fcy\u00fck zaman ve \u00e7aba kazand\u0131racakt\u0131r.<\/p>\n