Cron Goreviniz Neden Calismiyor?

Cron göreviniz neden çalışmıyor

"Asla çalışmayan" bir cron görevi neredeyse her zaman çalışmıştır. Görev, sizin shell ortamınızdan farklı bir ortamda çalışmış, ilk saniyede başarısız olmuş ve hata mesajı sizin okumadığınız bir yere gitmiştir. Neredeyse tüm bildirimlerin nedeni şu beş başlıkta toplanır: arama yolu (path), yüzde işareti, yanlış crontab dosyası, posta kutusuna giden çıktı ve oturum açma gerektiren bir betik.

cron, crontab dosyalarını okuyan ve komutları bir zaman çizelgesine göre başlatan bir daemon'dır (arka plan servisi). Sizin .bashrc dosyanızı okumaz, terminal açmaz, login shell başlatmaz ve bir komut başarısız olduğunda size bildirim göndermez. Aşağıdaki tüm nedenler bu dört temel gerçeğe dayanır.

Bu maddeleri sırasıyla inceleyin ve hepsinin temelindeki şu soruyla başlayın: cron gerçekten tetiklendi mi? "cron görevi hiç başlatmadı" ve "görev başladı ancak sonlandı" ifadeleri, hiçbir ortak noktası olmayan farklı sorunlardır; bu nedenle önce bu soruyu yanıtlayın.

Cron tetiklendi mi?

Daemon, farklı dağıtım ailelerinde farklı bir birim ismine sahiptir. Her ikisini de kontrol edin ve ardından günlüğü okuyun.

systemctl status cron
systemctl status crond
journalctl -u cron --since "2 hours ago"
journalctl -u crond --since "2 hours ago"

Debian ve Ubuntu sistemlerinde birim ismi cron olarak geçer. Fedora, Rocky ve Alma sistemlerinde ise bu isim crond şeklindedir. Belirli bir makinede bu isimlerden yalnızca biri mevcuttur; dolayısıyla komutlardan birinin bilinmeyen birim hatası vermesi normaldir ve bir arıza teşkil etmez.

Kendi sisteminizin oluşturduğu kayıtları okuyun. Bir kılavuzdan kopyalanmış satırları aramayın, çünkü ifadeler cron uygulamaları ve günlük yapılandırmaları arasında farklılık gösterir. Yalnızca iki şeyi kontrol ediyorsunuz: zamanlamanızda belirttiğiniz dakikada bir kayıt var mı ve bu kayıt komutunuzu içeriyor mu? Komutunuzu içeren bir kayıt, cron'un görevini yaptığını ve hatanın komutun içinde olduğunu gösterir. Hiç kayıt olmaması, cron'un zamanlamanızı hiç almadığı anlamına gelir; bu da aşağıdaki 3. nedendir.

Bazı imajlar, cron mesajlarını journal yerine rsyslog aracılığıyla bir dosyaya gönderir. /var/log dizininde cron veya syslog adında bir dosya olup olmadığını kontrol edin ve ardından dosyanın sonunu okuyun.

ls -l /var/log
sudo tail -n 50 /var/log/syslog

Eğer ne birim ne de günlük dosyası mevcutsa, cron yüklü olmayabilir. Minimal bulut imajları ve container yapıları genellikle cron içermez.

dpkg -l cron
rpm -q cronie
sudo apt install cron
sudo dnf install cronie
sudo systemctl enable --now cron

Neden 1: cron, PATH değişkeninize sahip değil

Etkileşimli kabuğunuz PATH dosyasını /etc/profile, ~/.profile, ~/.bashrc ve bu dosyaların kaynak gösterdiği her şeyden oluşturur. Bunların hiçbiri bir cron işi için çalıştırılmaz. cron, komutu kendi kısa ortamıyla başlatır; bu nedenle standart sistem dizinlerinin dışında kalan bir program bulunamaz. /usr/local/bin, /opt altındaki herhangi bir şey, bir dil sürüm yöneticisi, bir Python sanal ortamı veya bir Go çalışma alanı bu duruma adaydır. İş ilk satırında başarısız olur ve kabuk, tam ifadesi hangi kabuğun çalıştırdığına bağlı olan "bulunamadı" türünde bir hata yazar.

İşinizin kullandığı her komutun gerçek yolunu bulun.

command -v docker
command -v node
readlink -f "$(command -v node)"

Ardından ya bu mutlak yolları işin içine yazın ya da crontab dosyasının en üstünde bir kez PATH değerini ayarlayın.

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
0 3 * * * /usr/local/bin/mytool run

Bu listeyi kendi makinenizden echo "$PATH" ile alın ve yalnızca etkileşimli bir oturum içinde var olan her şeyi çıkarın. Burada tek bir kural önemlidir: cron, bu atama satırlarındaki değişkenleri genişletmez. PATH=$PATH:/usr/local/bin, $PATH:/usr/local/bin metnini olduğu gibi saklar, bu yüzden iş sonunda hiçbir kullanılabilir dizin içermeyen bir arama yoluyla kalır. Listenin tamamını açıkça yazın.

Bir sürüm yöneticisi, bir yoldan daha fazlasına ihtiyaç duyar. nvm, pyenv, rbenv ve asdf, .bashrc dosyanızdan bir kabuk işlevi veya bir shims dizini yükler ve bir cron işi bu dosyayı asla okumaz. Sürümlü ikili dosyayı mutlak yol ile çağırın veya yöneticinin başlatma betiğini kendi betiğinizin ilk satırı olarak kaynak gösterin.

Neden 2: yüzde işareti komutunuzu sonlandırır

Bir crontab dosyasının komut alanında % sıradan bir karakter değildir. Kaçış karakteri kullanılmamış ilk % komutu sonlandırır. Bu karakterden sonra gelen her şey komuta standart girdi olarak iletilir ve sonraki her % bir satır başı karakterine dönüşür. Bu, bir programa kısa girdiler sağlamak için kullanılan gerçek bir cron özelliğidir; tarih damgalı dosya isimlerinin klasik bozuk crontab girdisi olmasının nedeni de budur.

0 3 * * * /usr/bin/tar -czf /srv/backups/site-$(date +%F).tar.gz /srv/site yazdığınızda tar hiçbir zaman biçimlendirilmiş bir tarih görmez. cron satırı ilk % karakterinde keser, bu nedenle kabuk (shell) tamamlanmamış bir komut yerleştirmesi alır ve satırınızın geri kalanı standart girdi olarak ulaşır. Her yüzde işaretini bir ters eğik çizgi ile kaçış karakteri kullanarak belirtin.

0 3 * * * /usr/bin/tar -czf /srv/backups/site-$(date +\%F).tar.gz /srv/site

İki katman bu tek satırı sırasıyla okur. \%, cron tarafından herhangi bir işlem başlatılmadan önce uygulanan bir cron kuralıdır. $(date +\%F) ise cron tarafından başlatılan kabuk tarafından daha sonra uygulanan komut yerleştirmesi işlemidir. Hangi karakterin hangi katmana ait olduğunu bilmek işin tüm püf noktasıdır.

Daha güvenli alışkanlık, mantığı tamamen crontab dosyasının dışında tutmaktır. Mantığı, yüzde işaretinin özel bir anlamı olmadığı bir betik (script) dosyasına yerleştirin.

#!/bin/bash
set -euo pipefail
stamp="$(date +%F)"
tar -czf "/srv/backups/site-${stamp}.tar.gz" /srv/site

Böylece crontab satırı yalnızca bir yol, bir yönlendirme ve başka hiçbir şey içermez. Bir bakışta okuyabildiğiniz bir crontab, hata ayıklayabildiğiniz bir crontab demektir.

Neden 3: Hangi crontab dosyasını düzenlediniz?

Tek bir crontab dosyası yoktur. Farklı sahiplere ve farklı alan sayılarına sahip birden fazla dosya bulunur; yanlış dosyaya yazılan bir iş görünmez olur.

• crontab -e komutu çalıştıran kullanıcının crontab dosyasını düzenler. sudo crontab -e ise root kullanıcısınınkini düzenler. Aynı sunucuda hata ayıklayan iki kişi genellikle iki farklı dosyayı okur.
• sudo crontab -l -u deploy başka bir kullanıcının crontab dosyasını listeler; işi çalıştırması gereken hesap için nelerin yüklü olduğunu doğrulamanın yolu budur.
• /etc/crontab ve /etc/cron.d içindeki her dosya, zamanlama ile komut arasında fazladan bir alan taşır: komutu çalıştıracak kullanıcı. Beş alanlı bir kullanıcı crontab satırını /etc/cron.d içine yapıştırırsanız, komutunuzun ilk kelimesi kullanıcı adı olarak okunur.
• /etc/cron.d içindeki dosyalar harf, rakam, alt çizgi ve tire içermelidir. backup.sh veya site.conf gibi bir dosya, sadece ismi nedeniyle atlanır. Dosyayı backup olarak yeniden adlandırın ve log kayıtlarını tekrar kontrol edin.
• /etc/cron.d içindeki dosyaların sahibi root olmalı ve grup veya diğerleri tarafından yazılabilir olmamalıdır. ls -l /etc/cron.d size her iki durumu da aynı anda gösterir.
• /etc/cron.daily ve alt dizinlerine bırakılan betikler aynı isimlendirme kuralına tabidir ve ayrıca çalıştırılabilir (execute) bitine sahip olmalıdır. Eksik bir çalıştırılabilir biti, sessiz bir atlamaya neden olur.
• /etc/cron.allow ve /etc/cron.deny dosyaları, kimin crontab yükleyebileceğine karar verir. Eğer sunucunuzda bunlardan biri varsa, kullanıcınızın yetkisi olduğunu varsaymadan önce dosyayı okuyun.

Spool dosyasını elle düzenlemek yerine kullanıcı crontab dosyasını crontab komutuyla yükleyin; çünkü crontab dosyayı yüklemeden önce ayrıştırır. Kaydettiğinizde, komutun size ne döndürdüğünü okuyun. Eğer dosyayı reddederse, önceki sürüm aktif kalır ve değişikliğiniz hiçbir zaman devreye girmez; bu durum cron sizi görmezden geliyormuş gibi görünür.

Sahip, izinleri de belirler. root crontab dosyasındaki bir iş, uygulamaların okuyamayabileceği root sahipli dosyalar oluşturur. Normal bir kullanıcının crontab dosyasındaki bir iş, sadece root tarafından erişilebilen bir dizini okuyamaz. Sahibi yapılan işe göre eşleştirin: uygulama bakımı, uygulamanın kendi hesabına aittir; WordPress wp-cron yerine sistem cron işi kullanma mantığının arkasındaki neden budur. İşinizin oluşturduğu dosyaların modu, miras aldığı umask değerinden gelir; bu değer shell'inizinkinden farklıdır, bu yüzden işin çıktısı okunamaz halde geliyorsa umask dosya izinlerini nasıl belirler konusunu okumaya değerdir.

Neden 4: Çıktı kimsenin okumadığı bir e-postaya gitti

cron, bir işin standart çıktıya ve standart hataya yazdığı her şeyi toplar. İş herhangi bir metin yazdıysa, cron bu metni yerel posta sistemine, crontab sahibine veya MAILTO içinde belirtilen adrese gönderir. Minimal bir VPS üzerinde genellikle kurulu bir MTA (posta aktarım aracısı) bulunmaz, bu nedenle hiçbir şey teslim edilmez. Hatanız bir anlığına var oldu ve ardından kayboldu. Bozuk bir işin sessiz görünmesinin tek nedeni budur.

Çıktıyı kontrol edebileceğiniz bir dosyaya yönlendirin.

0 3 * * * /usr/local/sbin/backup-site.sh >> /var/log/backup-site.log 2>&1

>>, standart çıktıyı dosyaya ekler. 2>&1, standart hatayı o an standart çıktının işaret ettiği yere yönlendirir, bu nedenle bu ifade yönlendirmeden sonra gelmelidir. 2>&1 >> file şeklinde ters yazılırsa, standart hata orijinal hedefine gitmeye devam eder ve aradığınız hata dosyaya asla ulaşmaz.

Journal, bir diğer iyi hedeftir. logger, seçtiğiniz bir etiketle syslog içine yazar.

0 3 * * * /usr/local/sbin/backup-site.sh 2>&1 | logger -t backup-site

Bunu journalctl -t backup-site ile okuyun. Bu yöntem, işin kendi çıktısını cron girdilerinin yanında tutar, böylece zaman çizelgesini takip etmek kolaylaşır. Ayrıca sunucuda hangi kullanıcının hangi komutu çalıştırdığına dair bir kayda ihtiyacınız varsa, bu ayrı bir sistemdir ve sunucunuzdaki kullanıcı komutlarını denetleme konusu bunu kapsar.

Bir crontab dosyasının en üstüne eklenen MAILTO="", altındaki işler için e-posta gönderimini kapatır. MAILTO değerini gerçek bir adrese ayarlamak, yalnızca çalışan bir MTA varsa işe yarar; bu nedenle ona güvenmeden önce e-postaların sunucudan çıktığını doğrulayın.

Hata ayıklama sırasında tek bir kural: asla > /dev/null 2>&1 eklemeyin. Bu, her crontab dosyasındaki en popüler satırdır ve elinizdeki tek kanıtı yok eder. İş düzgün çalışmaya başladığında isterseniz bunu geri ekleyebilirsiniz.

Neden 5: Betik, cron'un sağlamadığı bir ortamı varsayıyor

Komut bulunduğunda ve çıktısı yakalandığında, geriye oturumunuzun size ücretsiz olarak sunduğu diğer her şey kalır.

• Kabuk (shell) bash olmayabilir. ls -l /bin/sh ile kontrol edin. Debian ve Ubuntu üzerinde bu komut dash'e işaret eder; bu nedenle çift köşeli parantez testi, diziler ve source sözdizimi hatasıyla başarısız olur. Betiğe bir #!/bin/bash satırı ekleyip betiği çağırın veya crontab'ın en üstüne SHELL ayarını ekleyin.
• Çalışma dizini, içinde bulunduğunuz dizin değildir. Her yerde mutlak yolları kullanın veya betiğin ilk satırında ilgili dizine cd yapın. Göreceli yol kullanımı, bir işin "elle çalıştırdığımda çalışıyor" demesinin en yaygın nedenidir.
• Yerel ayarlar (locale) oturumunuzunkilerle aynı değildir. Tarih veya sayı biçimlendiren ya da metin sıralayan her şey, farklı bir LANG altında farklı çıktılar üretebilir. Eğer sonraki bir adım bu çıktıyı ayrıştırıyorsa, şansa bırakmak yerine yerel ayarları betik içinde tanımlayın.
• TTY (terminal) yoktur. Onay isteyen, düzenleyici açan veya ilerleme çubuğu çizen bir komut askıda kalabilir veya sonlanabilir. Aracın sunduğu etkileşimli olmayan (non-interactive) bayrağı ekleyin.
• SSH aracısı (agent) yoktur. SSH_AUTH_SOCK, cron'un ortamında bulunmaz; bu nedenle aracınız yüklü olduğu için çalışan bir ssh veya rsync komutu, kimlik doğrulaması yapamadığı için başarısız olur. İşe, işin kullanıcısına ait olan kendi anahtarını verin.
• Kullanıcı oturum veri yolu (session bus) yoktur, bu nedenle XDG_RUNTIME_DIR ayarlanana kadar cron işinden gelen systemctl --user başarısız olur. Sistem birimi (system unit) daha iyi bir çözümdür.

Fedora, Rocky ve Alma üzerinde bir şüpheli daha vardır. SELinux, cron işlerini kısıtlar; bu nedenle dosya izinleri doğru görünse bile beklenmedik bir etikete sahip yola erişen bir iş reddedilir. sudo ausearch -m avc -ts recent ile reddedilen işlemleri kontrol edin ve herhangi bir şeyi kapatmadan önce Sunucular için SELinux temelleri belgesini okuyun.

Cron ortamını gösteren bir dakikalık inceleme

Cron ortamında nelerin tanımlı olduğunu tahmin etmeyi bırakın ve doğrudan okuyun. Her şeyi bir dosyaya yazan bir betik oluşturun, bunu her dakika çalışacak şekilde zamanlayın, bekleyin ve ardından dosyayı okuyun.

cat > /home/deploy/cron-probe.sh <<'EOF'
#!/bin/bash
echo "=== probe ==="
date -Is
pwd
id
echo "SHELL=$SHELL"
echo "LANG=$LANG"
command -v node || echo "node is not on this PATH"
env | sort
EOF
chmod +x /home/deploy/cron-probe.sh

Gerçek işin çalıştırıldığı kullanıcının crontab dosyasına, her iki tarafta da mutlak yollar (absolute paths) kullanarak bir satır ekleyin.

* * * * * /home/deploy/cron-probe.sh >> /home/deploy/cron-probe.log 2>&1

Bir dakika bekleyin, ardından /home/deploy/cron-probe.log dosyasını okuyun ve kendi kabuğunuzda (shell) çalıştırdığınız aynı komutların çıktılarıyla karşılaştırın. PATH satırı, çalışma dizini ve yerel ayarlar (locale), genellikle hatanın nedenini tek başlarına açıklar. Kurulumla ilgili iki detaya dikkat edin: yüzde işaretleri, cron kuralının geçerli olmadığı betiğin içinde yer alır ve günlük dosyası yolu, işi çalıştıran kullanıcının yazma iznine sahip olduğu bir konumdadır.

Yanıtı aldığınız anda ilgili crontab satırını silin. Her dakika çalışan ve bir dosyaya ekleme yapan bir iş, küçük bir diski hızla dolduracaktır ve bunu sessizce yapacaktır.

Zamanlama kastettiğiniz zamanlama mı?

Bir kullanıcı crontab satırı beş alandan oluşur: dakika, saat, ayın günü, ay ve haftanın günü. Bunlardan ikisi, kullanıcıları şaşırtan bir şekilde etkileşime girer.

Ayın günü ve haftanın günü kısıtlandığında, yani ikisi de * olmadığında, cron işi her iki alandan biri eşleştiğinde çalıştırır. 0 0 13 * 5 ifadesi "ayın 13'üne denk gelen Cuma" anlamına gelmez. Bu ifade, her ayın 13'ünde gece yarısı ve her Cuma gece yarısı çalışır. Belirli bir günü hedeflemek için alanlardan birini * olarak bırakın ve diğerini betik içerisinde test edin.

cron, sistem saat dilimini kullanır. Birçok VPS imajı, UTC (eşgüdümlü evrensel zaman) ayarlı olarak gelir; bu nedenle 03:00 için zamanladığınız bir iş, öğleden sonranıza denk gelebilecek şekilde 03:00 UTC'de çalışır. timedatectl komutu, sunucunuzun fiilen hangi saat dilimini kullandığını yazdırır. Kendi dizüstü bilgisayarınızla aynı olduğunu varsaymak yerine, sunucunuzdaki değeri kontrol edin.

Zamanlama ile ilgili iki tuzak daha bilinmelidir. @reboot, cron'un kendisi başladığında tetiklenir; bu an ağın hazır olduğu anla aynı değildir. Bu nedenle DNS veya uzak bir ana makineye ihtiyaç duyan bir iş, açılışta başarısız olabilir ancak sonraki manuel çalıştırmalarda başarılı olabilir. Ayrıca, yavaş bir işin önceki kopyası hala çalışırken tekrar başlamasını engelleyen bir mekanizma yoktur. İşi bir kilit (lock) mekanizması ile sarmalayın.

*/5 * * * * /usr/bin/flock -n /tmp/backup-site.lock /usr/local/sbin/backup-site.sh >> /var/log/backup-site.log 2>&1

flock -n, kilit zaten tutuluyorsa hemen pes eder; böylece çakışan çalışma, ilkinin üzerine binmek yerine durdurulur.

systemd timer kullanımı ne zaman daha avantajlıdır

cron tek bir konuda başarılıdır: belirli bir komutu belirli bir zamanda çalıştırmak. Diğer tüm konularda yetersiz kalır. Bir timer, herhangi bir yönlendirme yapmadan journal kayıtlarına erişim, daha sonra sorgulanabilecek bir çıkış durumu, network-online.target ile sıralama ve yüzlerce sunucunun aynı saniyede çalışmasını engelleyen rastgele gecikme özelliği sunar. İşiniz bunlardan herhangi birini gerektiriyorsa, bir VPS üzerinde systemd servisi ve timer kullanmak, bir crontab satırını yönetmekten daha az zahmetlidir. Servis kısmını yazarken, cron'un asla sormadığı bir soruyla karşılaşırsınız: unit, işin gerçekten başladığını nasıl anlar? Bu nedenle öncelikle simple, forking ve notify unit tipleri için Type= parametresinin anlamı konusunu okuyun; çünkü varsayılan tip altında kendini daemon haline getiren bir script, unit'in arkasında hiçbir şey yokken aktif görünmesine neden olur. Yeniden deneme davranışları da burada tanımlanmalıdır, çünkü systemd yeniden başlatma politikaları bir hata sonrasında ne olacağına karar verir ve cron'un bu soruya verecek hiçbir yanıtı yoktur.

Küçük işler için cron kullanmaya devam edin. Bağımlılıkları olan veya yeniden deneme politikası gerektiren her şeyi bir timer'a taşıyın. Her ikisi de aynı sunucuda çalışabilir, bu nedenle bu geçişi tek seferde bitirmeniz gerekmez.

FAQ

Cron işim elle çalıştırıldığında neden cron üzerinden başarısız oluyor?

Çünkü kullandığınız kabuk (shell) ile cron'un ortamı birbirinden farklıdır. Oturum açtığınız kabuk /etc/profile ve ~/.bashrc dosyalarını okur; bu dosyalar PATH değişkenini, yerel ayarları ve aracı değişkenlerinizi tanımlar. cron ise komutu bunların hiçbiri olmadan, farklı bir çalışma dizininden ve bazen farklı bir kabuk kullanarak başlatır. Her komut için mutlak yolları (absolute paths) kullanın, ihtiyaç duyduğunuz değişkenleri crontab dosyasının en üstünde veya betiğin içinde tanımlayın. cron'un gerçek ortamını tahmin etmek yerine, env | sort, pwd ve id komutlarını bir günlük dosyasına yazdıran ve her dakika çalışan bir test işi planlayarak ortamı inceleyin.

Cron'un işimi gerçekten çalıştırıp çalıştırmadığını nasıl kontrol ederim?

Daemon'un günlük kayıtlarını okuyun. Debian ve Ubuntu üzerinde journalctl -u cron, Fedora, Rocky ve Alma üzerinde ise journalctl -u crond komutunu kullanın; bazı imajlar mesajları rsyslog aracılığıyla /var/log altındaki bir dosyaya yönlendirir. Zamanladığınız dakikaya ait bir girdi arayın ve komutunuzun adının geçip geçmediğini kontrol edin. Girdi yoksa cron zamanlamayı hiç almamış demektir, bu durumda doğru crontab dosyasını düzenlediğinizden emin olun. Girdi var ancak sonuç yoksa komut başlamış ve sonlanmış demektir; bu durumda çıktıyı bir yönlendirme ile yakalayın.

date +%Y neden crontab içinde hata veriyor?

cron, komut satırındaki % karakterini özel olarak değerlendirir. Kaçış karakteri kullanılmamış ilk % komutu sonlandırır, sonrasındaki her şey standart girdi olarak komuta iletilir ve her % karakteri yeni bir satıra dönüşür. Bu nedenle tarih formatlı bir dosya adı, yazdığınız programa asla ulaşamaz. Her yüzde işaretini \% şeklinde kaçış karakteriyle kullanın veya komutu bir betik içine taşıyıp cron üzerinden bu betiği çağırın; çünkü betik içinde yüzde işaretinin özel bir anlamı yoktur.

Cron işimin çıktısı nereye gidiyor?

Yerel posta sistemine, crontab sahibine veya MAILTO değişkeninde belirtilen adrese gönderilir. Çoğu VPS imajında bir posta aktarım aracısı (MTA) yüklü değildir, bu nedenle mesaj atılır ve iş sessiz kalmış gibi görünür. Çıktıyı >> /path/to/log 2>&1 ile bir dosyaya yönlendirin; standart hatanın standart çıktıyı takip etmesi için bu sıralamayı koruyun veya logger -t myjob üzerinden borulayıp (pipe) journalctl -t myjob ile okuyun. Hata ayıklama aşamasındayken > /dev/null 2>&1 kullanmayın.

Cron mu yoksa systemd timer mı kullanmalıyım?

Sabit bir zamanda çalışan basit bir komut için, özellikle systemd çalıştırmayan bir makineye taşıma ihtimaliniz varsa cron kullanın. Çıktının yönlendirme yapmadan doğrudan journal içinde görünmesini, sorgulanabilir bir çıkış durumunu, ağ bağlantısı sağlandıktan sonra çalışmayı, rastgele başlatma gecikmesini veya hata sonrası yeniden deneme politikasını istediğiniz durumlarda timer kullanın. Her ikisi de aynı sunucuda çalışabilir, bu nedenle işleri ihtiyaç duydukça tek tek taşıyabilirsiniz.