I’m running few inline scripts at the end of each vagrant up .
And I get this in my logs:
From what I’ve been finding out so far — it should be something in the Ubuntu configuration, not Vagrant itself. I’ve found and tried this solution with no success: https://github.com/mitchellh/vagrant/issues/7368
However, if relevant — I’m running latest Vagrant 1.8.7 and macOS Sierra.
2 Answers 2
Perhaps it’s too late for an answer on this question, but as this may help somebody else, it’s good to share what I tried:
So as you can see in the commented line above — the «mesg: ttyname failed Inappropriate ioctl for device» has been prevented from the laravel team.
Most developers would like to avoid errors/warnings when we do development, so it seems like the fix we needed.
Important note: I haven’t tested this solution too much, but the box starts without the «mesg: ttyname failed Inappropriate ioctl for device» error! You are free to try it and if you experience any problems, just drop a comment to save somebody else’s time!
When using this snippet (inline shell provisioner):
It looks like that other people have found this issue as well. Does anybody know how to solve it?
6 Answers 6
I noticed that even this message was shown as an error (in RED colour), the script was executed successfully! A few days later I saw a possible fix and I posted an answer on SO. The «fix» is:
Maybe you just don’t need it, but you can try it and use it if it works for you.
As you can see in the commented line above — the «mesg: ttyname failed Inappropriate ioctl for device» has been prevented from the laravel team. Thanks for this one!
Most developers would like to avoid errors/warnings when we do development, so it seems like the fix (a possible fix) we needed.
Important note: I haven’t tested this solution too much, but the box starts without the «mesg: ttyname failed Inappropriate ioctl for device» error! You are free to try it and if you experience any problems, just drop a comment to save somebody else’s time!
1) open /root/.profile
2) remove the offensive line
3) replace it with:
Happy linuxing and a merry new year.
George Hart, LSU
It looks like this is caused by an interaction between the default vagrant configuration of config.ssh.shell to be bash -l (which simulates a login shell, thus processing login-related configuration files such as .profile ) with a line in the /root/.profile file on at least some distributions of Linux (including, e.g., the one in the ubuntu/xenial64 vagrant box), which has:
A better option for this line in that file would probably be to have it say:
Мне нужно запустить Xubuntu в качестве пользователя root для автономной демонстрационной системы.
Я использую функцию автоматического входа из lightdm или при входе в систему через «Другое» > «root» при запросе, я всегда получаю следующий ответ:
ПослеочисткивсплывающегоокнавышесистемавыполняеткакожидалосьспользователемROOT.
В большинстве форумов указано, что это сообщение ошибочно и не должно отображаться. Нужно ли вообще запускать Xubuntu как root, избегая этого ошибочного всплывающего окна?
1 ответ
Конечная причина в том, что Xubuntu явно не ожидал, что кто-либо выполнит графический вход в корневую учетную запись, поэтому файл default .profile по умолчанию генерирует ложную ошибку в этой ситуации. Если вы посмотрите на последнюю строку файла /root/.profile, вы найдете:
Это значит, что программы, такие как talk , не записываются на консоль. Это особенно важно, если вы вошли в систему с помощью текстового сеанса (su от xterm, ssh и т. Д.), Поскольку эти сообщения могут загромождать экран.
Бит || true должен предотвратить завершение сценария оболочки, если mesg должен завершиться неудачно (поскольку он здесь не работает), но это не мешает ему генерировать сообщения об ошибках, когда они терпят неудачу, которые вы видите.
Причиной проблемы является то, что, поместив строку в .profile, она запускается каждый раз, когда выполняется bash, даже когда она запускается из сеанса без устройства tty (например, во время самых ранних частей графического входа) поэтому вы видите ошибку. Это безобидно, потому что mesg будет бессмысленным при запуске из сеанса без TTY в любом случае, но рабочий стол не знает этого и отображает сообщение.
Одно решение (как комментарий в вопросе, на который вы ссылались ), заключается в том, чтобы изменить строку, чтобы она не попробуйте вызвать mesg , если TTY не существует:
Это говорит о том, что не пытаться вызвать mesg , когда нет TTY, но будет по-прежнему вызывать его, когда есть TTY (например, из входа SSH).
