Добавление в автозагрузку: Добавить приложение для автоматического запуска при начальной загрузке Windows 10

Содержание

Как добавить программу в автозагрузку Windows 10

07.05.2017

Как известно, разработчики Windows 10 удалили папку «Автозагрузка» из меню «Пуск». Теперь для того чтобы добавить программу в автозагрузку необходимо совершить ряд действий, о которых и пойдет речь в данном руководстве.

Шаг 1. Открываем папку Автозагрузка

Кликаем правой кнопкой мыши по меню Пуск → выбираем Выполнить:

Далее вводим команду shell:startup и кликаем на OK:

Появится окно Автозагрузки, где отображаются все программы, которые должны запускаться при загрузке ОС:

Сейчас же эта директория остается пустой. Попробуем добавить браузер Google Chrome в эту папку.

Шаг 2. Добавляем программу в автозагрузку

Итак, открываем меню Пуск → Все приложения → ищем элемент Google Chrome в разделе G → кликаем правой кнопкой мыши по Google Chrome и выбираем в контекстном меню опцию Открыть папку с файлом:

Появится окно, где вы найдете ярлык Google Chrome. Копируем его:

И вставляем в окно Автозагрузки:

Теперь попробуем добавить еще одну программу – видеоплеер Light Alloy. Снова открываем меню Пуск → Все приложения → ищем Light Alloy и открываем папку с исполняемым файлом видеоплеера:

Копируем ярлык программы:

Вставляем его в папку Автозагрузка:

Шаг 3. Добавляем системные приложения в автозагрузку

Аналогичным образом добавляем и другие программы. В случае же с некоторыми системными приложениями (Калькулятор, Календарь или 3D Builder) необходимо самостоятельно найти их местоположение, создать ярлык исполняемого EXE-файла и скопировать его в папку Автозагрузка. Большинство этих системных программ находится в папке Windows.

Попробуем добавить приложение Калькулятор в Автозагрузку. Для этого открываем директорию C:\Windows\System32\ и находим там файл calc. exe:

Это и есть исполняемый файл приложения. Вызываем контекстное меню и выбираем Создать ярлык:

Нам предложат отправить ярлык на рабочий стол. Жмем Да:

Переходим на рабочий стол, выделяем правой кнопкой мыши ярлык Калькулятора и выбираем Вырезать:

Переносим ярлык в папку Автозагрузка:

Шаг 4. Проверяем автоматический запуск программ

Закрываем все окна и перезагружаем компьютер. После загрузки ОС запустятся 3 наших добавленных программы – Калькулятор, Google Chrome и Light Alloy:

103

5

Гость написал(а):

Спасибо большое! Очень полезная информация

Гость написал(а):

Спасибо большое!

Гость написал(а):

А если запуститься в безопасном режиме, батник всё равно будет запускаться?

Гость написал(а):

спс большое, у меня просто прога на улучшение музыки включить ппц как долго

Елена написал(а):

Спасибо большое за статью с пошаговой инструкцией! Добавила все папки и приложения, на открытие которых уходило много времени! Особенно был затык с хромом. ..

HorrorTM написал(а):

Гость

Короче, такая кул стори

…и комп вечно перезагружался, информатичка в ахуе,

несет диск с виндой, вообщем все кончилось переустановкой винды, а меня так никто и не спалил)

Шутка жестокая А по поводу переустановки винды, в моем универе поступили бы точно так же — все машины стандартные по железу, на всех стоит стандартный набор софта. У лаборантов тупо инструкция — если машина глючит, просто вставляете флешку и перегружаете, с флешки запускается система, которая автоматом трёт хард и восстанавливает эталонный образ. Проще за 20 минут всё переставить, чем вникать, в чем проблема.

Гость написал(а):

Короче, такая кул стори

Я на уроке информатики на компе создал текстовый файл с таким текстом:

@echo off

shutdown /p

и сохранил с окончанием .bat

и по вашему способу закинул в автозагрузку

(если кто не понял, этот файл при открытии выключает комп)

и комп вечно перезагружался, информатичка в ахуе,

несет диск с виндой, вообщем все кончилось переустановкой винды, а меня так никто и не спалил)

Смотреть все сообщения
Оставить комментарий

Управление автозагрузкой сервисов и скриптов в Linux

В данной статье мы рассмотрим основы управлением автозагрузкой сервисов и скриптов в Linux CentOS 7/8. В частности, разберем основы работы с демоном systemd, научимся добавлять в автозагрузку сервисы и убирать их оттуда, а также рассмотрим альтернативные варианты запуска скриптов или демонов после старта системы.

Задача статьи – научить вас быстро разобраться со списками служб и скриптов которые запускаются в Linux автоматически, добавить в автозагрузку свои службы или скрипты, или отключить автозапуск определённых программ.

Содержание:

  • Systemd: управление автозагрузкой служб в Linux
  • Автозапуска скриптов и сервисов с помощью rc.local
  • Создание собственного демона и добавление его в systemd
  • Автозапуск через cron
  • .bashrc: автозапуск скриптов при запуске терминала

Systemd: управление автозагрузкой служб в Linux

В большистве популярных современных популярных дистрибутивов Linux (CentOS 7, RHEL, Debian, Fedora и Ubuntu) в качестве демона автозагрузки вместо init.d используется systemd. Systemd – менеджер системы и служб Linux, используется для запуска других демонов и управления ими в процессе работы, использует unit-файлы из /etc/systemd/system (init.d использовал скрипты из каталога /etc/init.d/). Systemd позволяет распараллелить запуск служб в процессе загрузки ОС, тем самым ускоряя запуск.

Для управления system используется команда systemctl.

Для начала, после загрузки системы, мы проверим список юнитов, которые в данный момент добавлены в systemd:

systemctl list-units

Список unit-файлов можно получить командой:

systemctl list-unit-files

Данная команда отобразит все доступные юнит-файлы (не зависимо от того, были они загружены в systemd после загрузки ОС или нет).

Чтобы вывести список активных сервисов и их состояние, выполните:

# systemctl list-units -t service

Следующая команда выведет список юнитов, которые загрузил или пытался загрузить systemd. Так как после запуска некоторые юниты могут стать неактивными, с помощью флага —all вы получите полный список.

# systemctl list-units --all

UNIT LOAD ACTIVE SUB DESCRIPTION
proc-sys-fs-binfmt_misc.automount loaded active waiting ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
● exim.service not-found inactive dead exim.service
firewalld.service loaded active running firewalld - dynamic firewall daemon
[email protected] loaded active running Getty on tty1
● ip6tables.service not-found inactive dead ip6tables.service
● ipset.service not-found inactive dead ipset.service
● iptables.service not-found inactive dead iptables.service
Bring up/down networking
● NetworkManager-wait-online.service not-found inactive dead

Как видим из списка, здесь отображаются даже сервисы, которые не были найдены на диске «not-found».

Использую данную команду, вы можете добавить и другие флаги, например:

  • —state — используется для определения состояния демона Load, Active, Sub
  • —type — позволяет фильтровать юниты по их типу.

Примеры:

systemctl list-units --all --state=active
— выведет список только активных юнитов

systemctl list-units —type=service
— выведет список юнитов, которые являются сервисом.

Добавление сервиса в systemd

Для управления сервисами в systemd используется особый синтаксис. После имени серверсв в конце нужно указывать .service. Например:

systemctl enable nginx.service
– команда добавит в автозагрузку веб-сервер nginx

Данная команда создаст символическую ссылку на копию файла, указанного в команде сервиса, в директории автозапуска systemd.

# systemctl enable nginx.service

Created symlink from /etc/systemd/system/multi-user.target.wants/nginx.service to /usr/lib/systemd/system/nginx.service

Вывод этой команды показывает в какой директории был создан симлинк на файл сервиса.

Чтобы посмотреть добавлен тот или иной сервис в автозагрузку, можно проверить его статус:

systemctl status nginx. service

При выводе нужно обратить внимание на строку:

Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)

Значение enabled означает что данный сервис загружается автоматически (добавлен в автозагрузку). Если сервис не загружается автоматом, здесь буде указано disabled.

Удаление сервиса из systemd

Вы можете удалить сервис из автозагрузки, чтобы он не запускался после старта Linux (при этом сам сервис с сервера не удаляется). Чтобы удалить сервис из автозагрузки, выполните команду:

systemctl disable нужный_сервис

Например, чтобы удалить из автозагрузки nginx, выполните:

# systemctl disable nginx.service

Removed symlink /etc/systemd/system/multi-user.target.wants/nginx.service

После выполнения команды, симлинк на файл сервиса будет удален из директории systemd. Можно проверить, есть ли юнит в автозагрузке:

# systemctl is-enabled sshd

Systemd: маскировка юнитов

В моей практике встречались «вредные» сервисы, которые после удаления их из автозагрузки, все равно там оставались и запускались после рестарта ОС. Чтобы решить этот вопрос, можно замаскировать сервис:

systemctl mask nginx.service

И после этого, он вообще не будет запускаться, ни вручную, ни после перезагрузки ОС:

# systemctl mask nginx.service

Created symlink from /etc/systemd/system/nginx.service to /dev/null.

# service nginx restart

Redirecting to /bin/systemctl restart nginx.service
Failed to restart nginx.service: Unit is masked.

Снять маску можно командой:

# systemctl unmask nginx.service

Removed symlink /etc/systemd/system/nginx.service.

Если после маскировки сервиса, вы проверите юнит-файлы, то увидите, что сервис помечен как замаскированный (состояние masked):

Таким нехитрым способом, можно избавить себя от удаления сервиса, даже если он не удаляется из автозагрузки systemd.

Автозапуска скриптов и сервисов с помощью rc.local

Для запуска различных скриптов при загрузке Linux чаще всего используется rc. local.

Но помимо скриптов, через rc.local так же можно и запускать сервисы, даже те, которые запускаются через systemd. Не могу ответить на вопрос, для чего использовать в таком случае rc.local, если есть systemd, но пару примеров я приведу.

Начнем с того, что файл /etc/rc.local должен быть исполняемым:

chmod +x /etc/rc.local

Rc.local должен быть добавлен в автозагрузку systemd:

systemctl enable rc-local

И на примере того же nginx, мы можем добавить в rc.local команду запуска веб-сервера:

service nginx start

Но я редко использую rc.local для запуска сервисов. Чаще rc.local используется, когда нужно запустить скрипт, либо выполнить разово какую-то команду.

К примеру, я создал скрипт /root/test.sh который выполняет некоторые действия, и хочу запустить его сразу после запуска системы. Добавляем в файл rc.local строку:

sh /root/test.sh

Начиная с CentOS 7, разработчики указывают на то, что rc.local устаревший демон и осуществлять автозапуск скриптов или сервисов через него, это прошлый век. Но пока он работает, я пользуюсь им, так как он очень прост в эксплуатации.

Создание собственного демона и добавление его в systemd

Вы можете создать собственный демон, которым можно будет управлять через systemd.

Например, нам нужно запускать все тот же скрипт /root/test.sh после перезагрузки системы. Начнем с создания файла нашей будущей службы:

touch /etc/systemd/system/test-script.service
chmod 664 /etc/systemd/system/test-script.service
nano /etc/systemd/system/test-script.service

Содержимое файла будет следующее:

[Unit]
Description=Template Settings Service
After=network.target
[Service]
Type=oneshot
User=root
ExecStart=/root/test. sh
[Install]
WantedBy=multi-user.target

Основные параметры:

User – пользователь под которым будет запускаться демон

Type=oneshot — процесс будет завершен до запуска дальнейших юнитов

Проверяем и перезапускаем:
# systemctl daemon-reload
# systemctl start test-script.service
# systemctl status test-script.service

● test-script.service - Test
Loaded: loaded (/etc/systemd/system/test-script.service; disabled; vendor preset: disabled)
Active: active (running)

Если вас устроило то, как работает сервис, добавьте его в автозагрузку:

# systemctl enable test-script.service

Created symlink from /etc/systemd/system/multi-user.target.wants/test-script.service to /etc/systemd/system/test-script.service.

Таким образом, вы можете добавить любой ваш скрипт в автозагрузку через systemd.

Автозапуск через cron

Если вам с какой-то периодичностью нужно запускать скрипт или команду, вы можете воспользоваться cron-ом:

crontab -e
— открыть терминал для написания задания cron

И добавьте туда нужное вам задание, например:

* * * * * /root/test. sh
— запускать скрипт каждую минуту.

Можно написать скрипт watch-dog, который по заданию будет проверять, например, статус какого-либо сервиса и, если он не работает, запускать его. На нескольких своих проектах я использую подобную схему.

Чтобы вывести список всех заданий в крон, нужно выполнить команду:

# crontab -l

* * * * * /root/test.sh

Допустимые значения для времени запуска заданий cron по порядку:

  • Минуты от 0 до 59
  • Часы от 0 до 59
  • День месяца от 1 до 31
  • Месяц от 1 до 12
  • День недели от 0 до 7 (0 или 7 это воскресение)

В нашем задании скрипт запускается каждую минуту, поэтому там стоят «*».

Так же вы можете разместить нужный вам скрипт в директориях cron:

  • /cron.daily – выполнение скрипта ежедневно
  • /cron.hourly – выполнение скрипта ежечасно
  • /cron.monthly — выполнение скрипта ежемесячно
  • /cron.weekly — выполнение скрипта еженедельно

Скрипты в указанных директория будут запускаться согласно автоматически подготовленного расписания.

.bashrc: автозапуск скриптов при запуске терминала

Если вам требуется выполнять какие-то действия при запуске терминала ssh, вы можете добавить любую команду или выполнение скрипта в .bash_profile или .bashrc. Теоретически, вы можете добавить какое-либо действие в любой из этих файлов, оно выполнится в любом случае. Обычно все необходимое добавляется в .bashrc, а сам .bashrc запускают из .bash_profile.

Я добавил в файл .bashrc команду на рестарт веб-сервиса nginx:

service nginx restart

После этого сохранил файл и перезапустил терминал:

Как видите, при запуске терминала, веб-сервер был перезапущен. Какие действия можно выполнять при запуске терминала? Вероятно, запускать какие-то вспомогательные утилиты, например, проверка
uptime
сервера:

Или вы хотите, чтобы при запуске терминала, вы сразу попадали в нужную вам директорию и запускали mc, добавьте в . bashrc

cd /var/
mc

Надеюсь эта статья по управлению автозапуском сервисов и скриптов в LInux (статья писалась для CentOS) оказалась полезной для вас. Наверняка тем, кто только познает азы системного администрирования Linux, это информация будет кстати.

Оптимизация автозагрузчика — Composer

🏠 ГлавнаяНачало работыСкачатьДокументацияОбзор
Пакеты

  • Уровень оптимизации 1: создание карты классов

    • Как запустить?
    • Что оно делает?
    • Компромиссы
  • Уровень оптимизации 2/A: Авторитетные карты классов

    • Как запустить?
    • Что оно делает?
    • Компромиссы
  • Уровень оптимизации 2/B: кэш APCu

    • Как запустить?
    • Что оно делает?
    • Компромиссы

По умолчанию автозагрузчик Composer работает относительно быстро. Однако из-за способа
Настроены правила автозагрузки PSR-4 и PSR-0, нужно проверить файловую систему
перед окончательным разрешением имени класса. Это немного замедляет работу,
но это удобно в средах разработки, потому что при добавлении нового класса
его можно сразу обнаружить/использовать без необходимости перестраивать автозагрузчик
конфигурация.

Однако проблема заключается в том, что в производственной среде обычно требуется, чтобы все происходило как можно быстрее.
насколько это возможно, так как вы можете перестраивать конфигурацию каждый раз, когда вы развертываете и
новые классы не появляются случайным образом между развертываниями.

По этой причине Composer предлагает несколько стратегий оптимизации автозагрузчика.

Примечание: Вы не должны включать какие-либо из этих оптимизаций в разработке как
все они будут вызывать различные проблемы при добавлении/удалении классов. Производительность
достижения не стоят проблем в условиях развития.

Уровень оптимизации 1: Генерация карты классов#

Как это запустить?#

Есть несколько вариантов включения этого:

  • Установить «оптимизировать-автозагрузчик»: true внутри ключа конфигурации composer.json
  • Вызов установка или обновление с -o / --optimize-autoloader
  • Вызов дамп-автозагрузка с -o / --optimize

Что он делает?#

Генерация карты классов фактически преобразует правила PSR-4/PSR-0 в правила карты классов.
Это делает все немного быстрее, так как для известных классов карта классов
мгновенно возвращает путь, и Composer может гарантировать, что класс находится там, поэтому
проверка файловой системы не требуется.

В PHP 5.6+ карта классов также кэшируется в opcache, что улучшает инициализацию
время сильно. Если вы убедитесь, что opcache включен, то карта классов должна загрузиться
почти мгновенно, а затем загрузка классов происходит быстро.

Компромиссы#

В этом методе нет реальных компромиссов. Он всегда должен быть включен в
производство.

Единственная проблема заключается в том, что он не отслеживает промахи автозагрузки (т.е. когда
он не может найти заданный класс), поэтому они откатываются к правилам PSR-4 и все еще могут
приводит к медленным проверкам файловой системы. Чтобы решить эту проблему, две оптимизации уровня 2
варианты существуют, и вы можете включить любой из них, если у вас много
class_exists проверяет классы, которых нет в вашем проекте.

Уровень оптимизации 2/A: авторитетные карты классов#

Как это запустить?#

Есть несколько опций, чтобы включить это:

  • Установите "classmap-authoritative": true внутри конфигурационного ключа композитора .json
  • Вызов установка или обновление с -a / --classmap-authoritative
  • Вызов dump-autoload с -a / --classmap-authoritative

Что он делает?#

Включение автоматически включает оптимизацию карты класса 1-го уровня.

Эта опция говорит, что если что-то не найдено в карте классов,
то он не существует и автозагрузчик не должен пытаться искать
файловая система по правилам PSR-4.

Компромиссы#

Эта опция заставляет автозагрузчик всегда возвращаться очень быстро. С другой стороны это
также означает, что если класс по какой-либо причине генерируется во время выполнения, он будет
не допускать автозагрузки. Если ваш проект или любая из ваших зависимостей делает это
тогда вы можете столкнуться с проблемами «класс не найден» в рабочей среде. Включите это с осторожностью.

Примечание. Это нельзя сочетать с оптимизацией уровня 2/B. Вы должны выбрать один как
они решают одну и ту же проблему по-разному.

Уровень оптимизации 2/B: Кэш APCu#

Как его запустить?#

Есть несколько вариантов включения этого:

  • Установить "apcu-autoloader": true внутри конфигурационного ключа композитора. json
  • Вызовите , установите или , обновите с помощью --apcu-autoloader
  • Вызов дамп-автозагрузка с --apcu

Что он делает?#

Эта опция добавляет кэш APCu в качестве запасного варианта для карты классов. Я не буду
автоматически генерировать карту классов, поэтому вам все равно следует включить уровень 1
оптимизации вручную, если вы того пожелаете.

Независимо от того, найден класс или нет, этот факт всегда кэшируется в APCu, поэтому его можно
вернулся быстро по следующему запросу.

Компромиссы#

Для этого варианта требуется APCu, который может быть вам недоступен. Это также
использует память APCu для автозагрузки, но она безопасна в использовании и не может
привести к тому, что классы не будут найдены, как авторитетная карта классов
оптимизация выше.

Примечание. Это нельзя сочетать с оптимизацией уровня 2/A. Вы должны выбрать один как
они решают одну и ту же проблему по-разному.

Нашли опечатку? Что-то не так в этой документации?
Разветвите и отредактируйте его!

Библиотеки — Композитор

  • Каждый проект представляет собой пакет
  • Управление версиями библиотеки

    • Версии VCS
  • Заблокировать файл
  • Публикация в VCS
  • Публикация в упаковщике

В этой главе рассказывается, как сделать вашу библиотеку доступной для установки через
Композитор.

Каждый проект представляет собой пакет#

Как только у вас есть composer.json в каталоге, этот каталог является
упаковка. Когда вы добавляете в проект require , вы
создание пакета, который зависит от других пакетов. Единственная разница между
ваш проект и библиотека заключается в том, что ваш проект представляет собой пакет без имени.

Чтобы сделать этот пакет доступным для установки, вам нужно дать ему имя. Вы делаете
это путем добавления свойства name в композитор.json :

 {
    "name": "акме/привет-мир",
    "требовать": {
        "монолог/монолог": "1.0.*"
    }
}

В данном случае имя проекта — acme/hello-world , где acme — поставщик
название. Предоставление имени поставщика является обязательным.

Примечание: Если вы не знаете, что использовать в качестве имени поставщика, ваш GitHub
имя пользователя обычно является хорошей ставкой. Имена пакетов должны быть строчными, а
Соглашение состоит в том, чтобы использовать тире для разделения слов.

Управление версиями библиотеки#

В подавляющем большинстве случаев вы будете поддерживать свою библиотеку, используя некоторые
своего рода система контроля версий, такая как git, svn, hg или ископаемый. В этих случаях,
Composer выводит версии из вашей VCS, и вам не следует указывать версию
в файле composer.json . (см. статью Версии
чтобы узнать, как Composer использует ветки и теги VCS для определения версии
ограничений.)

Если вы поддерживаете пакеты вручную (т. е. без VCS), вам необходимо
указать версию явно, добавив значение версии в вашем composer.json
файл:

 {
    "версия": "1.0.0"
}

Примечание: Когда вы добавляете жестко закодированную версию в VCS, эта версия будет конфликтовать
с именами тегов. Composer не сможет определить номер версии.

VCS ​​Versioning#

Composer использует функции ветвей и тегов вашей VCS для разрешения версии
ограничения, которые вы указываете в поле , требуют для определенных наборов файлов.
При определении допустимых доступных версий Composer просматривает все ваши теги.
и ветвей и переводит их имена во внутренний список опций, которые
затем он соответствует предоставленному вами ограничению версии.

Для получения дополнительной информации о том, как Composer обрабатывает теги и ветки и как он разрешает пакеты
ограничения версии, прочитайте статью о версиях.

Lock file#

Для вашей библиотеки вы можете зафиксировать файл composer.lock , если хотите. Этот
может помочь вашей команде всегда тестировать одни и те же версии зависимостей.
Однако этот файл блокировки не окажет никакого влияния на другие проекты, зависящие от
в теме. Это влияет только на основной проект.

Если вы не хотите фиксировать файл блокировки и используете git, добавьте его в
. gitignore .

Публикация в VCS#

Если у вас есть репозиторий VCS (система контроля версий, например git), содержащий
composer.json ваша библиотека уже доступна для установки через composer. В этом
Например, мы опубликуем библиотеку acme/hello-world на GitHub под
github.com/username/hello-world .

Теперь, чтобы протестировать установку пакета acme/hello-world , мы создаем новый
проект локально. Мы назовем его акме/блог . Этот блог будет зависеть от
acme/hello-world , который, в свою очередь, зависит от monolog/monolog . Мы можем
для этого создайте где-нибудь новый каталог blog , содержащий
композитор.json :

 {
    "имя": "acme/блог",
    "требовать": {
        "acme/hello-world": "dev-мастер"
    }
}

Имя в данном случае не нужно, так как мы не хотим публиковать блог
как библиотека. Он добавлен сюда, чтобы уточнить, какой composer. json в настоящее время
описано.

Теперь нам нужно сообщить приложению блога, где найти зависимость hello-world .
Мы делаем это, добавляя спецификацию репозитория пакетов в раздел блога.
композитор.json :

 {
    "имя": "acme/блог",
    "хранилища": [
        {
            "тип": "ВКС",
            "url": "https://github.com/имя пользователя/hello-world"
        }
    ],
    "требовать": {
        "acme/hello-world": "dev-мастер"
    }
}

Дополнительные сведения о работе репозиториев пакетов и других типах
доступны, см. Репозитории.

Вот и все. Теперь вы можете установить зависимости, запустив Composer’s
установить команду !

Резюме: Любой репозиторий git/svn/hg/fossil, содержащий composer.json , может быть
добавить в свой проект, указав репозиторий пакетов и объявив
зависимость в поле требует .

Публикация в packagegist#

Итак, теперь вы можете публиковать пакеты.

Читайте также: