/etc/init/ttyAMA0.conf causes endless tty spewage if ttyAMA does not exist

[Martin Pitt]

I created an LXC container with the current armhf cloud images on a Calxeda node. Due to /etc/init/ttyAMA0.conf, I get these lines written into the terminal every few seconds:

<4>init: ttyAMA0 main process (3035) terminated with status 1
<4>init: ttyAMA0 main process ended, respawning

This makes working in a terminal rather hard and also clutters logs. Can the job please be fixed to only start up if there actually is a /dev/ttyAMA*?

$ uname -a
Linux trusty-cloud 3.11.0-15-generic #23-Ubuntu SMP Mon Dec 9 18:18:34 UTC 2013 armv7l armv7l armv7l GNU/Linux
$ ls -l /dev/ttyA*
ls: cannot access /dev/ttyA*: No such file or directory

[Robert C Jennings (rcj)]

The problem can be mitigated by deleting /etc/init/ttyAMA0.conf or editing to contain the following:

# ttyAMA0 - getty
#
# This service maintains a getty on ttyAMA0 from the point the system is
# started until it is shut down again.

start on stopped rc RUNLEVEL=[2345] and (
            not-container or
            container CONTAINER=lxc or
            container CONTAINER=lxc-libvirt)

stop on runlevel [!2345]

pre-start script
    # getty will not be started if the serial console is not present
    stty -F /dev/ttyAMA0 -a 2> /dev/null > /dev/null || { stop ; exit 0; }
end script

respawn
script
    exec /sbin/getty -L ttyAMA0 115200 vt102
end script
# written by cloud image build process

[Ben Howard (darkmuggle-deactivatedaccount)]

Martin,

Can you confirm the contents of /etc/cloud/build.info? New cloud images have a test to make sure that this sort of thing shouldn't happen. Also I am a bit concerned that this might be an issue with upstart determiniing if its in a container. The previous version should have prevented the job from running within a container.

[Martin Pitt (pitti)]

Ah, thanks for pointing out /etc/cloud/build.info. In said chroot that says

build_name: server
serial: 20131219.1

Note that I created this container last Thursday (2014-01-23), I already wondered why there were a gazillion packages to dist-upgrade right after I created it with

  sudo lxc-create -t ubuntu-cloud -n trusty-cloud -- -r trusty

but I created that on saucy, with trusty's cloud-image-utils (as saucy's doesn't find the armhf images). Perhaps that was the reason why it picked up an ancient cloud image. Is it possible to get a recent one with saucy's lxc-create, or should I upgrade the whole box to current trusty?

[Martin Pitt (pitti)]

Another observation: I still see these messages today after dist-upgrading to container to latest trusty. But *only* with lxc-start, *not* with lxc-start-ephemeral. In the latter case, the job still gets started:

$ sudo status ttyAMA0
ttyAMA0 start/running, process 769

but I don't see the spewage. With "ps aux|grep ttyAMA" I still see the job constantly being respawned, but it doesn't appear at the terminal any more (that might be an LXC quirk/feature/bug, probably unrelated to the cloud image itself).

[Stéphane Graber (stgraber)]

lxc-start-ephemeral doesn't attach to /dev/console but to /dev/tty1 which is why you don't see the boot messsages or that error.

Unfortunately there isn't a great deal we can do about this in LXC, the best fix is to change the upstart job to only start with "and not-container". A better fix would be to check whether things can be written to the device but that's trickier to do right and obviously the best fix would be to have a device namespace so we wouldn't have that kind of problem to begin with.

Closing the lxc task.

[Martin Pitt (pitti)]

Yes, I never thought of it as an LXC bug in the first place. Whatever installs that job (cloud-init? our cloud image build process?) ought to change the upstart job to only start up if such a device exists in the first place.

[Robert C Jennings (rcj)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

This is added by the cloud image build process and should be resolved
in the next build. Fix was committed to
lp:~ubuntu-on-ec2/vmbuilder/automated-ec2-builds revision #578 and
#579. With this change the getty will only be started if 'stty -F
/dev/ttyAMA0' returns without error (device is present).

On 02/01/2014 07:39 AM, Martin Pitt wrote:
> Yes, I never thought of it as an LXC bug in the first place.
> Whatever installs that job (cloud-init? our cloud image build
> process?) ought to change the upstart job to only start up if such
> a device exists in the first place.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJS8/UzAAoJEHQMPZ7t8u1zrjUP/0PUAuQaaGAreZmYW7BZqHL/
gg9Hyi/WcelNTuKf6nsbCdwoQEEEZuTYxfLZSz6M40R8XAyLX53u23YBqab7z5/Z
wxPqk+kohRqJVeAG600dqk31N5nwH187wUiu4y7QZkPOQz0U5wZD/hG+MoCRXpNs
Al94OuG4EwBeGhY5+7vwpgltvd0JJMXDA4uIAhpd7bUaaiU22gETdhL8reNLw5ls
38Y6H4w43ec8eTF6LHuYeeznUlxUYaiajNW1l0XKxHPKsO1wGBDxOHjz6OmhKK2w
AVwf8K6m4GI3EXuyvtEevIZJmeXxluaSkJ54/v8PPCHovcZy0/Fh6T8sNva3h0vO
w7r/qPjmDzxQ1iI1Hq8e/LFpJeZeDeGtqiltbtC4hyrNzYAQDP1oxAZKWJihUOLW
PKR+3cEp/e7clbfU64A3dvEuLerHiXEZJ7SFuOGH2cShnAnLYZ0MAszeHLZPE5A2
HgmAHmzrq7mABLguGCakF9K2SGK6Xiyd+OS15jPAYuFRyQI3Jw1JGgsfkQD7wf9n
GlQoFgsTR6wgucffvFn3NzLxw3Ec3gg0grwdLi+LorR2on8800F4/YK/sU1eaOeS
RbyTmBm0sgMJahY/ui4hXQaEyFxjRmRr5NPISf7lRNaBTpgbITN/0bod7oI6sdrc
o0ZRYGvowfU9p7RrO4ue
=vhas
-----END PGP SIGNATURE-----

[Robert C Jennings (rcj)]

Fix is included in 20140125 daily build of raring.

[Martin Pitt (pitti)]

Thanks for the fix!

Robert C Jennings [2014-02-06 20:57 -0000]:
> Fix is included in 20140125 daily build of raring.

I presume/hope you mean trusty here :-)

[Robert C Jennings (rcj)]

Martin Pitt [02/06/2014 11:18 PM]
> Robert C Jennings [2014-02-06 20:57 -0000]:
>> Fix is included in 20140125 daily build of raring.
>
> I presume/hope you mean trusty here :-)

Yes, trusty too. :)