Попробуй тогда «Можжевеловый эль» от пивоварни «Сурок», может тоже понравится.

В научных кругах чаще используется термин «чёрный ящик», - понятно, что на входе, понятно, что на выходе, но совершенно непонятно - что внутри.

Именно, он самый. Мне приходилось править инитскрипты, там все просто и понятно - опция старт запускает бинарик с такими-то ключами, стоп, релоад, и т.д, простой баш, любой может разобраться, можно подправить, если очень необходимо. Я конечно понимаю, что меня отправят фонады на ртфм, но зачем ломать то, что работало и работает?

Поэтому у systemd как минимум несколько сторон, ты рассмотрел одну, я показал другую и это не предел.

Я не говорил, что других сторон нет. Но пока эта штука в активной разработке, и заменяет своим ...гм... часто нехорошим кодом - стабильные и работающие решения. Более того - сам стиль разработки этого продукта, и возгласы его автора о том, что поглоченные этим продуктом компоненты специально делаются несовместимыми с не-systemd дистрибутивами (на примере udev), причем выглядит это так, как будто автор показывает сообществу язык и бросает ему вызов «а ну-ка, гентушнички, сделайте что-нибудь теперь, бе-бе-бе, это вам сигнальчик»... Напоминает поведение моего малолетнего сынули - это и смешно и печально, что большой и серьезный проект просто не должен позволять себе иметь подобного «лидера». Но это третья - этическая сторона отношения одних разработчиков к другим.

уметь найти в плюсах минусы, а в минусах плюсы и не бояться их обсуждать и делиться ими, тогда всё будет более-менее объективно.

Это четвертая сторона, и также - этическая. Юношеский максимализм не даёт трезво мыслить апологетам этого решения. Все несогласные с ними - должны, как минимум, умереть. А как максимум - адски страдать при жизни.

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

Но это моя позиция, как потребителя. С позиции же заказчика этого цирка - всё идёт «как надо». Все обоснованно недовольные объявляются «хейтерами» и их мнение приравнивается к мнению собаки в подворотне. Вплоть до того, что когда разработчики ядра Linux рапортуют баг о том, что мол, «ребята, ваш чудесный продукт перехватывает наш отладочный флаг и система прекращает грузиться из-за того, что ваш продукт гадит в наш поток сообщений миллионами соощений в наносекунду», а этот баг закрывается как «это не баг, ищите проблему у себя», его переоткрывают, начинается срач, Линуз блокирует патчи для ядра, отправленные одним из девелоперов этого... Замечательный продукт, что тут скажешь. Прекрасные люди его разрабатывают, этичные, вежливые, пишущие прекрасный код, о гнекоторых участках которого сами в своей группе договориться не могут... Прелесть.

Давай-ка мы не будем его обсуждать? Хорошо? 8)

зачем ломать то, что работало и работает?

Самоцитируюсь, пардон: «Заставить клиентов переучивать своих админов, срубить на этом денег, выпусить новые мануалы, и, наконец - понизить порог входа для начинающих. Ребята думают о будущем - кто будет приносить им деньги, когда мы умрём? Сакральные знания мы унесём с собой, а новое поколение обучаться способно с трудом - этот продукт создаётся для них, а не для нас.»

Centos 7

Что то не совсем понятно на сайте присутствует версия 7 и 6.8 , у 7 версии LTS до 2024 года , получается она более свежая ? или я что то упустил ?

Упустили. Выход Red Hat Enterprise Linux 15 лет назад. 6.x и 7.x - это разные ветки.

В рабочем порядке обновилось сегодня на нетбуке (ASUS EeePC 1001PX) - полет нормальный

И чем заменить btrfs? У меня эта файловая система монтируется ночью, делается ro снапшот и производится на эту фс бэкап измененых за сутки файлов, кроме логов, на диск перезаписывается даже не весь файл, а только измененые в файле блоки. Таким образом у меня есть бэкапы на любой день за последние n лет с десятков серверов, при том, что размер хранилища бэкапов даже в 1.5 раз не превышает размера саммих данных в продакшине. И все это в продакшине, и проблем именно в этой функциональности не было. И что мне теперь пытается все это на ZoL переносить? Если я скажу, что отныне, мне надо хранилище в 10-ки раз больше для тех же бэкапов, я понимания не найду.

А попробуй ядро своё собрать и пакет btrfs-tools. Или поставить последнее старое ядро с btrfs и залочить обновление ядра, если не очень критично конечно в плане безопасности.

Хотя в идеале конечно патчик и на каждый новый релиз его применять и пересобирать.

Но вообще да, печально вышло

В тестовом окружении обновился, btrfs работает. Видимо, просто обновлений для btrfs не будет.

(//...и какой дебил придумывал раскладку на макбуках... трындец... уж унифицировали бы с вендовой, чтоли..., - там где запятая - вопросик, со слешом, ё вобще возле энтера... трындец//)

Менять не пробовали? Там их как и на онтопике >одной

Просто с такой логикой можно вообще любой более-менее удачный компонент назвать вирусом

Вот здесь коренное слово «удачный» к xxxxD оно не имеет никакого отношения.

Да он сам еще даже из статуса беты (по сугубо моему мнению) не вышел, учитывая как бурно его кроят и перекраивают, - не бывает таких релизных продуктов в продакше, ну не бывает.

Это не только «по сугубо моему мнению», я его поддерживаю.

.... потому что до systemd был полный хаос.....

Где закупаетесь? System V и bsd init это «хаос» ? А «systemd» нет? Я что-то не то курю походу...

Оно конечно работает, но такое ощущение, что это какой-то ящик пандоры.

man NetworkManager избавит от этого ощущения.

btrfs
бэкап
за последние n лет с десятков серверов

Вы явно что-то делаете нетак, при учете что btrfs (Experimental) до сих пор, а уж вводить это «n лет» назад как систему бэкапа... ну ну...
Вы случайно не из тех кто «уже делает бэкапы, но еще не проверяет?»

Вот здесь коренное слово «удачный» к xxxxD оно не имеет никакого отношения.

это твоё субъективное мнение и оно имеет право на существование :)

Мелькнула та же самая мысль. Видать «за последние n лет» было «небольшим» преувеличением :)

(сорь что на ты, со мной тоже лучше на ты плз)
System V и BSD init - ты назвал лишь один компонент systemd. Возможно ты не в курсе что помимо системы инициализации systemd это унифицированный инструмент для кучи всяких других вещей.
Плиз, осиль этот док (желательно максимально отстранённо): https://wiki.archlinux.org/index.php/Systemd_(Русский) и посмотри сколько всего умеет эта штука. С каждой новой версией кол-во настроек и фич увеличивается. И всё это работает абсолютно одинаково на всех системах.

Возможно для кого-то Поттеринг невоспитанный говнюк, осуждать не возьмусь, вполне вероятно что есть косяки в процессе разработки (в взаимодействии с другими разработчиками, своеобразной монополии), но идея положена очень неплохая. Сначала я был противником systemd, особенно когда оно только-только появилось в арче и дико глючило, потом глючить перестало, но я продолжал называть systemd говном по привычке и за кампанию + мне было лень в нём разобраться. Как только я себя заставил и прочитал пару довольно объёмных мануалов, покрутил в живую всё это - понял что ошибался, признал это и забрал все свои слова обратно.
Ну и плюс то что очень многие дистрибы, в том числе Ubuntu/Debian перешли на systemd тоже о многом говорит. Всё же там не такие глупые люди сидят. По крайней мере не более глупые чем мы :)

Спасибо за инфу, довольно интересно, не знал про эти нюансы ранее.
Окей, закрыли тему :)

Хочу привести пару примеров, чтобы заинтриговать.

Ранее всегда было гемором настраивать ACPI без всяких кедогномов (реакция на закрытие крышки, спящий режим, етц). От версии к версии что-то менялось и скрипты написанные в /etc/acpi постоянно отваливались. Сейчас же это всё работает везде и со всем где есть systemd через файлик /etc/systemd/logind.conf, где достаточно раскоментить нужную строчку и вписать нужное значение.

Поехали далее. Бинарные логи. Ух как же это круто! Хотя раньше я бы подумал что такое может придумать только человек под веществами. Но сейчас я понимаю насколько это гениальное решение!
Во-первых текстовые логи можно подредактировать, чем очень успешно пользуются злоумышленники, попавшие на сервер и получившие привилегии. С бинарными логами почистить ничего не получится (исправьте кто нибудь, если ошибаюсь).
Во-вторых рулить journalctl одно удовольствие. Ранее логи были разбросаны по разным файлам, везде по своему. Сейчас всё в одном месте и очень гибко сортируется и парсится.
Показать последние сообщения за 20 минут? Не проблема:

# journalctl --since "20 min ago"

# journalctl /usr/lib/systemd/systemd

# journalctl _PID=1

# systemd-analyze blame

# systemd-analyze plot > plot.svg

Настройка сети, настройка времени и его синхронизация и многое другое - всё приведено к одному стандартизованному виду и зная базу systemd ты сможешь рулить одинаково круто как дебианами, убунтами, так и редхатами и другими системами. Короч советую откинуть стереотипы, моду обкладывать х...ми systemd, попробовать и применять этот мощный инструмент.

А, ну это другое дело. А то я уж испугался, потому что такие радикальные методы в столь старом и ещё долго поддерживаемом дистрибе были бы совсем неуместны.

сритесь в отведенном для этого месте [1], пожалуйста

1. Релиз systemd 230

(реакция на закрытие крышки, спящий режим, етц)

Так, понятно, Вы похоже о десктопе.

Во-первых текстовые логи можно подредактировать, чем очень успешно пользуются злоумышленники, попавшие на сервер и получившие привилегии. С бинарными логами почистить ничего не получится (

wtmp - бинарный. Что не мешает его редактировать, просто надо быть немножко «хакиром», почти уверен что такое же можно провернуть и с ненужноД.

Ну и плюс то что очень многие дистрибы, в том числе Ubuntu/Debian перешли на systemd тоже о многом говорит. Всё же там не такие глупые люди сидят. По крайней мере не более глупые чем мы :)

Патрикоугодный нет, Вот это как раз говорит о том что глупые скорее там «Ubuntu/Debian/etc» :)

А вот вопросец, не совсем в тему просто может кто сталкивался ?

Из за последнего обновления самбы все ХП отвалились от самба-PDC, в 6.7 я самбу заисклюдил в юме :((( Что теперь так и дальше тянуть ?

Все очень просто. Бэкапы были перенесеня с ленточек на btrfs (на самом деле через ext3 и rsync с предыдущей скопированной лентой и так по циклу, но не суть). Некоторые дни, недели были утеряны, так как пару-тройку ленточек не смогли нормально считать. Сейчас файловый бэкап btrfs на ленточки делается раз месяц. И да, наверное мы из таких, кто не пробовал из этих бэкапов полностью все восстановить. Но проблем btrfs не показывает при копировании подтомов с бэкапами на ленту. Частично данные из bttfs восстанавливать приходится, проблем не было.

Из за последнего обновления самбы все ХП отвалились от самба-PDC

Поищите здесь, недавно тема была: хрень->обновление_самбы

Ну и ладно, успехов вам до первого «факапа». А уж при учете что экономим на летнах то вообще ссзб. ( Это не в обиду, а только констатация факта)

На лентах экономить смешно. Но: Ленты могут не читаться; Бэкап на ленты долго, а если две копии делать, с надеждой, что какая-то одна из двух уж точно считается/не испортится то ночи не хватит. Купить крутую библиотеку многопоточную, дорого. Нормальное ПО для не ручной работы с ленточками и руления этой тру библиотекой, то же дорого, в итоге поиск в ручную нужных данных при необходимости частичного восстановления и само восстановление этих данных занимает уж очень много времени. Надеюсь факапа не будет, но если что-то случится с btrfs есть бэкап на ленточке месячной давности и актуальные данные на серверах. Плохо будет если одновременно btrfs порушится и raid на серверах развалится. Даже не знаю какая вероятность такого события.

Спасибо.

Вот нашел : http://serverfault.com/questions/771163/update-to-samba-3-6-23-30-on-redhat-s...

И как раз только в 6.8 появился пакет : samba-3.6.23-35 видать в нем проблема уже исправлена...

Короч фанатизм на лицо и ноль аргументов (слака - вообще не аргумент, где она а где дебиан в процентном соотношении на серверах, хорошо если на 0.001% серверов). Ну и ладненько. Не вижу смысла далее вести диалог :)

СЧастья вам на остальных процентах.
А вот слака неплохо себя почему-то чувствует например в технологии, ичсх не жалуется. :)

Так, понятно, Вы похоже о десктопе.

По барабану, хоть о Linux на тостере

wtmp - бинарный. Что не мешает его редактировать, просто надо быть немножко «хакиром», почти уверен что такое же можно провернуть и с ненужноД.

Тут вопрос не в том «можно», или «не можно» (в конце-концов любой лог можно за'shred'ить и удалить, или вообще всю систему снести к чёртовой матери), а в том что в большинстве случаев никто не будет с этим заморачиваться и скорее забьёт на затирание следов.

Тут вопрос не в том «можно», или «не можно» (в конце-концов любой лог можно за'shred'ить

Ну, ну... для начала wtmp научитесь чистить, ох не легкая это тема.

... а в том что в большинстве случаев никто не будет с этим заморачиваться и скорее забьёт на затирание следов.

Ну и тогда о чем речь Карл?!? В чем профит бинарныеVSтекстовые?

Это можно сравнить с эволюцией и ГМО продуктами. Мо ... ития были бы люди, если бы не она?

Бла-бла-бла... Рассуждаешь как средне статистическое быдло. Твое место у параши пацан.

Ну, ну... для начала wtmp научитесь чистить, ох не легкая это тема.

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

# fwtmp < wtmp.mmdd > wtmp.new
# vi wtmp.new
# fwtmp -ic < wtmp.new > wtmp

чертовски сложная процедура, вот тут я с тобой полностью соглашусь!

... а в том что в большинстве случаев никто не будет с этим заморачиваться и скорее забьёт на затирание следов [у бинарных логов].

Ну и тогда о чем речь Карл?!? В чем профит бинарныеVSтекстовые?

Прочти плз внимательно ещё раз моё цитируемое сообщение и потом попробуй его сопоставить со своим.

Да, ведь нужно заставить себя в гугле ввести редактирование wtmp

Во блина «до чего техника дошла». Каюсь, я лох. Живу воспоминаниями многих лет назад, тогда пришлось прогрумулину на сях ради этого писать.

Во блина «до чего техника дошла». Каюсь, я лох.

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

Лан, предлагаю трубку мира! Каждому - своё и systemd не исключение :)

помимо системы инициализации systemd это унифицированный инструмент для кучи всяких других вещей

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

Следующая штука совершенно не связана с systemd, просто пример неочевидного поведения софта, которое «пьёт кровь» в продакшене (а предмет нашего обсуждения этим изобилует): однажды, у одного клиента, внезапно перестал работать DNS. Обновления системы происходили ежедневно, ставились апдейты, а конфиги подтягивались из SVN. И вот, внезапно, после очередного mass update перестал работать DNS - он запускался, но никаких данных не отдавал. ОКАЗАЛОСЬ, что в очередном апдейте bind'а втихаря решили, что в конце файла-зоны должна быть пустая строка, содержащая '\n'. При этом - все предыдущие ревизии бинда работали прекрасно и без нее. При этом бинд просто ругался на то, что «зона ему не нравится» и он ее игнорирует, без объяснения причин - «почему»... А ведь DNS - это всего-навсего один из множества не-системных серверов. Что же будет, если разрабы systemd в очередной раз включат подобную «фичу» в свой продукт, и вся система (а не один её компонент) перестанет функционировать? Отвалится сеть, например, или fsck наглухо повиснет при попытке проверить сменившийся uuid диска, замененый udev'ом, или случится еще что-то непредсказуемое? Что делать админу в продакшене, когда он расчитывает, что его сервера будут работать и тогда, когда он на работе, и тогда, когда он спит? Не спать, и ждать, что в любой момент раздастся звонок разъяренного заказчика, у которого что-то случилось?

Уж лучше CentOS6, чем такое...

Если один из компонентов этой монолитной системы «встанет в позу известного членистоногого» - вся система накроется медным тазом.

Но почему, если systemd многокомпонентный? Ну допустим у тебя поломается systemd-timesync - как это скажется на работе всего остального? Ведь точно так же может навернуться ntpdate

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

Ты уверен что это был не какой-нибудь арч линукс? Я очень сомневаюсь что с этими же багами встречаются пользователи redhat'а. Возможно потому что там используются не последние версии systemd, а хорошо проверенные. Но у меня в голове не укладывается что редхатовцы могут допускать регулярно подобного рода баги у себя в 7-ке. А поскольку ты на центоси, то по логике можно смело переходить на 7-ку, если загвоздка только в этом.

Что же будет, если разрабы systemd в очередной раз включат подобную «фичу» в свой продукт, и вся система (а не один её компонент) перестанет функционировать? Отвалится сеть, например, или fsck наглухо повиснет при попытке проверить сменившийся uuid диска, замененый udev'ом, или случится еще что-то непредсказуемое?

А что будет если Линус пропустит критический баг, который поломает всем загрузку системы при очередном обновлении ядра? Ядро уж точно более монолитный и больший по объёму компонент нежели systemd...
Так ведь можно абсолютно к любому разработчику придраться. Мне кажется тут нужно больше боятся за пофигизм разработчиков дистрибутивов, ведь их задача состоит как раз в том, чтобы не допустить проникновение в стабильные ветви плохо проверенные и нетабильные компоненты. Если арч со скоростью света штампует билды новых программ не успев их особо протестить - это не проблема программ, это проблема тех кто не выделяет достаточное кол-во времени на их проверку у себя в системе.

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

Ты уверен что это был не какой-нибудь арч линукс?

На серверах в critical zone - стоит RHEL6. На серверах попроще - цент-6. На некритичных серверах - раньше (до перехода на systemd) иногда случался debian, - вполне неплохо работал, кстати. Ставить arch на прод?! Я может и всеядный линуксоид, но не до такой же степени, чтобы «жрать что мимо проплывает». 8)

На специфичном железе у меня, как ни странно, тоже rhel, заточенный под это самое железо. А вот embedded железяки - мелкие роутеры, «планшетики», медиа-кубики - имеют уже свои дистрибы: где-то openwrt, где-то - void linux, где-то вобще «кастом» (там где цикл жизни продукта ограничен, и поддерживать его никто не будет).

А вот у клиентов на десктопах и сторонних заказах (даже в проде) было много разного - от неплохих дистров (gentoo), до полного мусора (sourceror). - У некоторых заказчиков приходилось работать с тем, что поставили «до нашего прихода», - а вот там «сон разума» цветет буйным цветом. Каких только «чудес» я не видел в продакше! И гибридные дистры, слепленные из redhat6.3+ubuntu 6.10, и полудебианы-полугенту, и полностью кастомные дистры - админы изголялись кто на что горазд... ужос. И как я представлю, что к этому зоопарку теперь добавится еще и прослойка на systemd, которую, ради обратной совместимости какой-нибудь... специалист... срастит со старыми sysvinit скриптами через предлагаемый systemd альтернативный костыль (а такие любители найдутся, я уверен!), - у меня волосы по всему телу дыбом становятся...

Менять не пробовали? Там их как и на онтопике >одной

На онтопике у меня клавиатура IBM Model M («ещё та»), без всякого русского языка на клавишах. И на тошибовском ноуте под линем со светящимися кнопками. И на соньке... А на макбуке, хоть под линем, хоть под макосью - долбаная русская раскладка светится в темноте наравне с английской, - слепой ввод для этой недоклавы - неактуален, - у клавиатуры макбука раскладка не вполне стандартная (даже для US/UK; + русский, как назло, - на клавиатуре «прямо с завода») - ремап только всё запутает. Уж лучше пусть она будет идиотской, но видимой, чем искать - куда ты на этой недоклаве замапил те или иные символы...

И вобще, это к сабжу данного треда не имеет отношения. Это я так, мысли вслух выразил...

//И как линуз работает на макбуке, - непонятно... да еще и хвалит...//

Ставить arch на прод?! Я может и всеядный линуксоид, но не до такой же степени, чтобы «жрать что мимо проплывает». 8)

Не-не, я ж и не предлагал арч в прод, а в пример привёл где бы systemd мог вполне себе глючить :)

Так а конкретно с семёркой дело имел? Неужели там всё так плохо из-за systemd? Что-то мне подсказывает что всё это стереотипы и связанные с ними боязни. Ну и да, я не про переход продакшна с 6-ки на 7-ку (тут полюбому проблемы какие-то будут, особенно если костыли всякие применялись), а поднятие новых серверов на семёрке.

Да, я тоже много жести видал, к сожалению :( Честно говоря не знаю почему люди порой так извращаются, возможно просто не осилили в полной мере мощь дистриба который поставили, или неудачный для конкретной цели дистриб выбрали...

что в конце файла-зоны должна быть пустая строка, содержащая '\n'.

Я вас возможно разочарую, но этой проблеме парсинга текстовых конфигов «миллион» лет уже и все о ней знают, поэтому «ентер вконце конфига» всю жизнь был обязателен на всякий случай (я не про бинд, а вообще про все, на винде так же было, да и осталось наверное)
Так что если у вас этого не было, то виноваты в этом только вы сами и ваша не опытность.

//И как линуз работает на макбуке, - непонятно... да еще и хвалит...//

Вы по аккуратнее, модераторы рядом :)
Реально меня не парит раскладка мака, все дело привычки. Скорее когда на расширенной приходиться работать больше не удобств получаешь.

эм, а так: https://packages.debian.org/jessie/libreoffice

после обновления на 6.8 имеем kernel panic's проявляется только на i386 на x86_64 всё норм. баг замечен под vmware esxi, nic vmxnet3 на e1000 полёт нормальный

------------[ cut here ]------------ WARNING: at kernel/softirq.c:159 local_bh_enable+0x59/0x90() (Not tainted) Hardware name: VMware Virtual Platform Modules linked in: autofs4 vsock(U) ppdev parport_pc parport microcode vmware_balloon vmci(U) i2c_piix4 sg ext4 jbd2 mbcache be2iscsi bnx2i cnic uio cxgb4i iw_cxgb4 iw_cm sd_mod cxgb4 crc_t10dif cxgb3i sr_mod cdrom libcxgbi iw_cxgb3 ib_core vmxnet3 ib_addr ipv6 cxgb3 mdio libiscsi_tcp vmw_pvscsi qla4xxx iscsi_boot_sysfs pata_acpi libiscsi ata_generic scsi_transport_iscsi ata_piix vmwgfx ttm drm_kms_helper drm i2c_core dm_mirror dm_region_hash dm_log dm_mod [last unloaded: mperf] Pid: 1978, comm: zabbix_agentd Not tainted 2.6.32-642.1.1.el6.i686 #1 Call Trace: [<c04624b9>] ? warn_slowpath_common+0x89/0xe0 [<c0469e79>] ? local_bh_enable+0x59/0x90 [<c046252b>] ? warn_slowpath_null+0x1b/0x20 [<c0469e79>] ? local_bh_enable+0x59/0x90 [<c07bc3a6>] ? skb_copy_bits+0x126/0x210 [<c07bcf0e>] ? __pskb_pull_tail+0x6e/0x2b0 [<c04343a5>] ? smp_apic_timer_interrupt+0x35/0x50 [<f93af164>] ? vmxnet3_xmit_frame+0xba4/0xef0 [vmxnet3] [<c05d1796>] ? selinux_ip_postroute+0x56/0x320 [<c045dbf2>] ? enqueue_entity+0x102/0x460 [<c044d89b>] ? check_preempt_wakeup+0x16b/0x220 [<c0448c2a>] ? check_preempt_curr+0x5a/0x70 [<c0456656>] ? try_to_wake_up+0x206/0x3c0 [<c07ca77d>] ? dev_hard_start_xmit+0x1dd/0x400 [<c07c2dba>] ? __netdev_pick_tx+0x16a/0x1b0 [<c07e27f3>] ? sch_direct_xmit+0x113/0x180 [<c07cabb5>] ? dev_queue_xmit+0x1b5/0x290 [<c07fc172>] ? ip_finish_output+0x152/0x2d0 [<c07fb7c5>] ? ip_local_out+0x15/0x20 [<c07fbc25>] ? ip_queue_xmit+0x145/0x3b0 [<c04cbc54>] ? __rcu_process_callbacks+0x44/0x2f0 [<c04cbf35>] ? rcu_process_callbacks+0x35/0x40 [<c0469b5e>] ? __do_softirq+0xce/0x1f0 [<c080f257>] ? tcp_transmit_skb+0x447/0x860 [<c04343a5>] ? smp_apic_timer_interrupt+0x35/0x50 [<c087b6e5>] ? apic_timer_interrupt+0x31/0x38 [<c08114a6>] ? tcp_write_xmit+0x1c6/0xa40 [<c0811fb1>] ? __tcp_push_pending_frames+0x31/0xe0 [<c0802be1>] ? sk_stream_alloc_skb+0x91/0xe0 [<c08048d3>] ? tcp_sendmsg+0x613/0x970 [<c07b677e>] ? sock_aio_write+0x13e/0x190 [<c087af58>] ? _spin_lock_bh+0x8/0x30 [<c0543945>] ? do_sync_write+0xd5/0x120 [<c0485be0>] ? autoremove_wake_function+0x0/0x40 [<c05c49fc>] ? security_file_permission+0xc/0x10 [<c0543b16>] ? rw_verify_area+0x66/0xe0 [<c0543d08>] ? vfs_write+0x178/0x190 [<c05447eb>] ? sys_write+0x4b/0xa0 [<c0409bbf>] ? sysenter_do_call+0x12/0x28 ---[ end trace 28603d7a288456a7 ]---