Junos OS

Expand all | Collapse all

this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

  • 1.  this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

    Posted 10-25-2019 10:16

    I have a sample of 236(!!)  EX2300C switches in a test setup waiting for deployment. 

    In investigating occurences of Swizzle Reboot (> show chassis routing-engine)  and plain zombification (PR1442376), 

    I have started turning on messages displays (`monitor start messages) from time to time. 

    If I monitor let's say 20 of them, I am bound to find a couple with the following messages occurring. 

    this goes on forever !!!!!!! it clog the messages files ...

    I used to see these doing forensic on switches that had rebooted , but I start now seeing it on live switches.

    what is it ?

    • all the switches are on the same vlan, with only one port connected for the moment.
    • They all share the same basic config, except for indvidual host-names ans IP addresses.
    • We have disconnected the VMware VM running Junos Space and Network Director for now
    • what is causing this ???????? this can not be good

    I already have service request opened with JTAC.  I'll keep the forum posted if anything is found. 

    thanks for your help,

    Michel Lapointe

    Oct 25 13:01:19  cslt-bearn-01-BYPASS init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs
    Oct 25 13:01:49  cslt-bearn-01-BYPASS getty[76714]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:01:50  cslt-bearn-01-BYPASS getty[76895]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:01:50  cslt-bearn-01-BYPASS getty[76896]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:01:50  cslt-bearn-01-BYPASS getty[76903]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:01:51  cslt-bearn-01-BYPASS getty[76904]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:01:51  cslt-bearn-01-BYPASS init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs
    Oct 25 13:02:21  cslt-bearn-01-BYPASS getty[76905]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:02:21  cslt-bearn-01-BYPASS getty[77086]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:02:22  cslt-bearn-01-BYPASS getty[77087]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:02:22  cslt-bearn-01-BYPASS dc-pfe: Version 18.3R2-S2.1 by builder on 2019-09-26 14:10:08 UTC
    Oct 25 13:02:22  cslt-bearn-01-BYPASS fpc0 Version 18.3R2-S2.1 by builder on 2019-09-26 14:10:08 UTC 
    Oct 25 13:02:22  cslt-bearn-01-BYPASS getty[77092]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:02:22  cslt-bearn-01-BYPASS getty[77095]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:02:22  cslt-bearn-01-BYPASS init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs
    Oct 25 13:02:53  cslt-bearn-01-BYPASS getty[77096]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:02:53  cslt-bearn-01-BYPASS getty[77275]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:02:53  cslt-bearn-01-BYPASS getty[77278]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:02:54  cslt-bearn-01-BYPASS getty[77283]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:02:54  cslt-bearn-01-BYPASS getty[77284]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:02:54  cslt-bearn-01-BYPASS init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs
    Oct 25 13:03:24  cslt-bearn-01-BYPASS getty[77287]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:03:25  cslt-bearn-01-BYPASS getty[77466]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:03:25  cslt-bearn-01-BYPASS getty[77469]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:03:25  cslt-bearn-01-BYPASS getty[77474]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:03:26  cslt-bearn-01-BYPASS getty[77475]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:03:26  cslt-bearn-01-BYPASS init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs
    Oct 25 13:03:56  cslt-bearn-01-BYPASS getty[77478]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:03:56  cslt-bearn-01-BYPASS getty[77657]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:03:57  cslt-bearn-01-BYPASS getty[77660]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:03:57  cslt-bearn-01-BYPASS getty[77665]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:03:57  cslt-bearn-01-BYPASS getty[77666]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:03:57  cslt-bearn-01-BYPASS init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs
    Oct 25 13:04:28  cslt-bearn-01-BYPASS getty[77667]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:04:28  cslt-bearn-01-BYPASS getty[77848]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:04:28  cslt-bearn-01-BYPASS getty[77851]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:04:29  cslt-bearn-01-BYPASS getty[77856]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:04:29  cslt-bearn-01-BYPASS getty[77857]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:04:29  cslt-bearn-01-BYPASS init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs
    Oct 25 13:05:00  cslt-bearn-01-BYPASS getty[77860]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:05:00  cslt-bearn-01-BYPASS /usr/sbin/cron[78040]: (root) CMD (   /usr/libexec/atrun)
    Oct 25 13:05:00  cslt-bearn-01-BYPASS getty[78042]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:05:00  cslt-bearn-01-BYPASS getty[78045]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:05:01  cslt-bearn-01-BYPASS getty[78050]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:05:01  cslt-bearn-01-BYPASS getty[78051]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:05:01  cslt-bearn-01-BYPASS init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs
    Oct 25 13:05:31  cslt-bearn-01-BYPASS getty[78052]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:05:32  cslt-bearn-01-BYPASS getty[78233]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:05:32  cslt-bearn-01-BYPASS getty[78234]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:05:32  cslt-bearn-01-BYPASS getty[78241]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:05:32  cslt-bearn-01-BYPASS getty[78242]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:05:32  cslt-bearn-01-BYPASS init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs


  • 2.  RE: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

     
    Posted 10-25-2019 20:31

    Hi,

     

    This is poiting out for a console port side issue, 

    Please check for any interupts on console port, try swapping the console cable or the peer side port 

     

    Thank you

    Prabin

    Please mark the solution accepted, if this solution helped you

     



  • 3.  RE: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

    Posted 10-26-2019 19:34

    hello Prabin, 

    this was also the first answer from JTAC.

    Unfortunately, none of the 236 switches are connected to console port. for the test before deployment, Only port 11 is connected. Console port was last touched in early september. 

    Michel



  • 4.  RE: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

    Posted 10-28-2019 11:04

    this is getting interesting .

    • 2 of my sick switches went into swizzle reboot and were fine after. 
    • no rj45 or miniusb console port are connected to any switch. If I take a healthy switch and connect to both console port, I can open putty sessions on each BUT...
    • If I try the same thing on a sick switches, mini-usb does not communicate
    • I can take a sick switch and issue a port  set system ports auxiliary port-type rj45 disable and the getty error messages disappear
    • rollback brings the getty error messages back. It has to be a rollback: just set system ports auxiliary port-type rj45  leave the ports in disable state. In fact, I can't find a command to brign that port out of disdable !!!

    show system ports
    auxiliary {
    port-type rj45;
    disable;
    }

    not sure what to make of all this.... 

    Michel

     



  • 5.  RE: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

     
    Posted 10-28-2019 20:21

    I'm not sure what 'set system ports auxiliary port-type rj45' is supposed to do since that would seemingly conflict with the console port, which defaults to rj-45. There is no auxillary port anyway, so the whole configuration process makes no sense.

     

    If you want both the rj-45 and usb console ports to be active at the same time the following works, at least on my 2300-C running 19.2R1.

     

    delete system ports
    set system ports auxiliary port-type mini-usb


  • 6.  RE: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

    Posted 10-29-2019 05:22

    Bonjour Smicker,  thanks for pitching in. 

    I am not sure myself what this command is supposed to do! I am still trying to understand 

    the miniusb- RJ45 thing and also the auxiliary / console difference that I still can't figure. 

    All I know for (almost) sure is that:

    • a normal switch can be accessed through both it's console port: RJ45 and miniusb simultenously with it,s basic configuration
    • a switch vomiting getty statements stop communicating through it's miniusb port. The connection come up (my portable see a new COM port number) but no communications take place. two signs that this can not be good.
    • set system ports auxiliary port-type rj45 disable stop the vomiting
    • the switch is now in this configuration  
      show system ports
      auxiliary {
      port-type rj45;
      disable;
      }
    • I was expecting to undo this by issuing set system ports auxiliary port-type rj45. the command is accepted and committed but show system port still show the same state.!!! (that's bizarre ...)
    • I have to do a rollback  to get back to auxiliary port-type rj45 state. (that alone is peculiar...)
    • the switch will then start vomiting again
    • a switch vomiting is almost sure to end up doing a swizzle reboot eventually. this my experience so far.
    •  if disabling the miniusb port cure it, I will gladly do it on all my switches, but I want to understand what I am doing first. 

    It goes without saying that I am not doing this on a live switch!.  

     

    show chassis routing-engine  will show you the last reboot reason, including swizzle reboot.

    also, if you have a 2300-c running 19.2, you may end up with a zombie switch ... see PR14422376 that was updated sunday  and have a look at 

    Re: EX2300-48T Stop working after random time after upgrade to 19.1R1.6

     

      Michel


  • 7.  RE: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

    Posted 10-29-2019 09:29

    Good Day,

     

    According to public PR1442376 https://prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR1442376 , fix will be available in 18.4R3 and 19.2R2.

     

    Thanks!



  • 8.  RE: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

    Posted 10-29-2019 09:44

    bonjour Deimos, 

    can't wait for them to be available and try.

    Checking hourly for that !!

    I was alos told by one of our Juniper rep that 18.2R3-S2 should fix this and other issues and be available early november. 

    Michel



  • 9.  RE: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

    Posted 10-29-2019 12:52

    awright, so ...

    15/236  switches are vomiting getty statements  

    I applied the set system ports auxiliary port-type rj45 disable command to all of them

    I lost connection to the mini-usb console port on all the switches I manually checked. Go figure !!!!!!

    I still have connection to rj45 console ports. 

    So far, on all the switches I checked, vomiting topped. 

    I'll check tomorrow if this had any effect on the swizzle reboot issue, or if a switch is going to start vomiting. 

    Michel



  • 10.  RE: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

     
    Posted 10-29-2019 20:02

    Did you read the configuration change I suggested?



  • 11.  RE: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

    Posted 10-30-2019 05:04

    hello smicker, 

    the priority now is finding a way to stop the vomiting of getty request and the set system port auxport-type rj45 disable seems to do the trick, at least for the last 12 hours on the machine that were sick. 

    Losing the miniusb console is a small price to pay. I would just like though to understand the link between disabling a rj45 and losing the miniusb.

    I'll be checking the switches today. I'll try the minusb command. I expect the vomiting to reappear, but only test will tell. Also, I am wondering why I have to issue a delete port command before. And I still don't understand what is this" auxiliary" access . 

     

    Since yesterday, 2/236 went zombie (PR1442376) , which is something I am geting used to by now 😞

    michel



  • 12.  RE: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

    Posted 10-31-2019 05:48

    bonjour smicker,

     

    just received this answer from Juniper on my service request ...

    The auxiliary port is the miniUSB console connection -  on configuration based you can be able to manipulate console & auxiliary port.  As you has showed us in previous email when you disable the auxiliary port the miniUSB shouldn’t response to any output, it might deliver a COM port, but no outputs will be display.  

    so I understand that any command sent to the auxiliary will affect the miniusb port. It's just confusing that I can use port-type rj45 and influence the mini-usb port. 

    once you know it ... 🙂



  • 13.  RE: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

    Posted 11-04-2019 07:09

    OK, so ...

    6 days now that my 236 EX2300-C have been running 18.3R2-S2.1 with the miniusb console port disable. during that time , I had :

    1.  no display of getty requests unless I turn the miniusb port up againfor a couple of minutes to check.
    2.  no swizzle reboot 

    6 days without swizzle reboot on 236 switches: I may be on to something ...

     

    next test will be taking place now: in the coming hour, I will reactivate the miniusbport on all switches and wait for a swizzle reboot that I believe would affect first one of the 15 switches that still are spilling getty request. 

     

    Michel

     



  • 14.  RE: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

    Posted 11-05-2019 06:56

    as of nov 5, 10:00,  I have 236 switches running with a beta image from Juniper that may solve PR1442376, and I have disabled the miniusb console port on all of them. So it is possible that in the coming days, I have no zombie switches neither swizzle reboot. Basically, I expect the "alarms" on my outlook folder that receive PRTG ping sensor warnings to be empty 

    How about a daily post to show how things are going ???

    Michel



  • 15.  RE: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

    Posted 11-07-2019 04:59

    my 236 switches  on which I disabled miniusb port have been running 2.5 days with no swizzle reboot. 

    I had one yesterday from one of our 8 prod switches that have not been modified. 

    I believe I will correct this as of today and see what happen. Juniper is working on this issue on a Service Request.

    Michel



  • 16.  RE: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

    Posted 11-11-2019 05:55
        Start time                     2019-11-04 14:04:20 EST
        Uptime                         6 days, 17 hours, 39 minutes, 55 seconds
        Last reboot reason             Router rebooted after a normal shutdown.

    last monday, I received a pre-version 18.2R3-S2.7 that I installed on all my test switches and I also disabled the miniusb console port (set system ports aux port-type rj45 disable) . The switches have now been rtunning for 6.5 days with no zombies (PR1442376) or swizzle reboot . 

    swizzle is being adressed in a Service Request by Juniper. 

    Michel



  • 17.  RE: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

    Posted 11-20-2019 04:52

    Quick update on this one...

    this thread and another one were based on myself unable to deploy EX2300 switches due to 2 problems: loss of communication with the switches (PR1442376)  and random swizzle reboot (not sure if there is a PR for this, but I have 2 Service request so far with Juniper)

    PR1442376: 

    so 236 EX2300 switches running pre-release of 18.2R3S2.7 for 15 days now and no zombie switch. PR1442376 seems to be under control. Can't wait for the official release. 

    SWIZZLE REBOOT

    as for the getty request that seems to induce swizzle reboot, I was told by Juniper to check for defective cables connected to the miniusb port. Problem is that no cables are connected, so I decided to just turn it off (set system aux port-type rj45 disable turn off the miniusb console but the rj45 console still works. Go figure ...) .

    The trick of shutting dow the miniusb console ports seems to work.

    Out of the 236 switches, I have 34 that issue getty requests on ttyu1 and on which I left the miniusb console port open to compare.  all the other 200 switches had their miniusb port disabled and none of them swizzled reboot. but in the  last 2 weeks. I am up to 13 of the 34 switches that went swizzle reboot during that time.

    (how do I determine if a switch issue getty request ? message start messages for 60 secs and watch for 

    Oct 25 13:01:19  cslt-bearn-01-BYPASS init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs
    Oct 25 13:01:49  cslt-bearn-01-BYPASS getty[76714]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:01:50  cslt-bearn-01-BYPASS getty[76895]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:01:50  cslt-bearn-01-BYPASS getty[76896]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:01:50  cslt-bearn-01-BYPASS getty[76903]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:01:51  cslt-bearn-01-BYPASS getty[76904]: tcsetattr /dev/ttyu1: Invalid argument
    Oct 25 13:01:51  cslt-bearn-01-BYPASS init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

    so I will now turn off the miniusb on all my switches and I expect not to see a swizzle reboot anymore.

    If that works, well, I seems to have a way to go to handle these 2 problems. 

    Juniper is working on the swizzle reboot thing. In the meantime, if the trick prevent a switch to randomly reboot, well, I'll take it !!!

    Michel

     



  • 18.  RE: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

    Posted 12-16-2019 08:15

    well, a band aid is a bandaid: it,s not a cure.

    I have 240  switches running 18.2R3S2.9 (the recommended EX23000 image) with also my trick of mini usb console port disable that dramatically reduced then number of swizzle reboot for 2 months. 

    last friday, a switch swizzled reboot. 😞 

    1 swizzle reboot in 2 months on 240 switches is not a lot, but there is a problem.  Unfortunately, no core dump are generated at the time. 

    So I am going to re-enable the miniusb port to 

    • see if there is a resurgence in the swizzle reboot
    • confirm that the disabling make a difference
    • identify switches that emit getty request. I had identified 33 in november with the previous image that were consistently issuing getty request. That identification, which was concistent at the time,  is no longer valid. 

    I'll keep this post updated with any useful development. 

    Michel



  • 19.  RE: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

    Posted 12-17-2019 06:23

    the re-enabling of the miniusb and "monitor start messages"  allowed me to check 2 things: 

    • 32/240 switches emit getty request.
    • 2 of them went swizzle reboot on me in the last 24 hours since I re-enabled the miniusb console port. what a coincidence .... 🙂

    there is no core dump associated with a swizzle reboot. I plan to disable the miniusb by tomorrow afternoon and leave it like this and see what happens in the holiday. 

     

    I am still heartborken at the switch that swizzled reboot last friday even with the console port disable. I wonder if it's possible to disable this port at the kernel level ?????  it seems directly related to the swizzle reboot problem and I don't  !"/$%? need it ....

     

    Michel



  • 20.  RE: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

    Posted 12-18-2019 05:32

    working on a new swizzle reboot theory since yesterday. ...

    Denis and I came up with the solution of disabling the miniusb console port after JTAC told us the getty requests were caused by a defective cable on the miniusb port. Since we don't use the miniusb port, we thought of disabling it. It seemed to work magic for 2 months, but last friday I had a reboot of a switch with the miniusb port disabled. So it was back to square one. 

    so I have been trying somwething else since yesterday

    • minisub console port is activated on all my 240 tests switches. 
    • monitor start messages telles me if a switch emits unanswered getty request. I identified 32 of these. 
    • I rebooted these 32 switches until none emit getty request. 30 reboot worked the first time, 1 took 2 reboots and the last one took 3.
    • The 240 switches have been running for alomost a day now with the miniusb console port on and no swizzle reboot .

    I keep my fngers crossed, but how about something that does not get completed in the reboot process translate into unanswered getty request until the watchdog decides to reboot the switch ? that's my hypothesis now, I'll keep you posted on the results, but so far ...

        Start time                     2019-12-17 15:18:31 EST
        Uptime                         17 hours, 11 minutes, 17 seconds
        Last reboot reason             Router rebooted after a normal shutdown.

    this switch (belcourt-01) was rebooted 3 times before getting rid of the getty messages. It has not rebooted in 17 hours, neither has the 239 others . 

    I'll stop the test has soon as one of them swizzle and keep you posted. 

    Michel

     



  • 21.  RE: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

    Posted 12-19-2019 07:46

    well, we are into 44 hours since I last rebooted a switch until the getty request disappeared. My oldest switches have been running for 17 days straight. 

    I checked everyone of them this morning: none are issuing the unanswered getty request that predict an eventual swizzle reboot. 

    that tells me (I may be wrong) that the getty request condition error happens at the time of the booting process and is not something that develops in a switch out of the blue. So that is good news. 

    Also, needless to say, no swizzle reboot for 44 hours. 

    I'll check and update again tomorrow afternoon before the holidays and lett the whle setu simmer for 2 weeks until I come back in January. I don't expect any swizzle reboot.

    Michel

     



  • 22.  RE: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

    Posted 12-20-2019 11:19

    how about a last update before the holidays ?

    my 240 switches are up and running in my test environnment, waiting to be deployed in the field in early 2020 if everything goes well. 

    the year's end brought closure to the infamous PR1442376 zombie issue. The swizzle reboot remains, but a temporary solution is in test.

    I dont believe anymore that disabling the miniusb console port prevent swizzler reboot. I had at least one that rebooted with that bandaid and that's all it takes to infirm a theory. So now I have 18.2R3S2  installed on all test switches, the miniusb console port is activated, but I made sure that none of them issue getty messages. In some cases I had to reboot 3 times to achieve that non-messages state. so I have switches that rebooted anywhere from 18 days to 3 days and I am letting everything cook during the holidays. I predict that none of them will swizzle reboot. I also predict that none of them will start issuing getty messages after having booted correctly. Let's see about this in january. 

    JTAC is working on it, and there is a PR on it. 

    see you in 2020

    Michel



  • 23.  RE: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

    Posted 01-03-2020 07:24

    back from the holidays and checking my switches: 

    first, the good news: 

        Start time                     2019-12-02 09:10:04 EST
        Uptime                         32 days, 1 hour, 7 minutes, 21 seconds
        Last reboot reason             Router rebooted after a normal shutdown.

    that is good. .

    the bad news is that one of the 240 switches went into a swizzle reboot. 

        Start time                     2019-12-31 23:43:21 EST
        Uptime                         2 days, 10 hours, 36 minutes, 39 seconds
        Last reboot reason             0x20000:Swizzle reboot
    

    I quickly checked the log messages. Nothing to be seen, not even getty requests. There was no core dumps. 

    I'll be sending the log files to JTAC. The only thing different between that switch and the other 240ish in the test setup is it's IP adress !. 

    Welcome to 2020. Hopefully the year where I'll deploy my switches. 

     



  • 24.  RE: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

    Posted 07-28-2020 13:09

    Hi Michel,

    Were you able to resolve this issue, and if so, could you share the solution?

    Best regards,

    Dante

     



  • 25.  Re: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

    Posted 30 days ago

    Just found this thread. Has anyone gotten word what the issue is yet from a Jtac case ?

    i have another 2300-c-12p  right now running 20.2R1-S2.1 and not logging the getty erros.

     

    Model: ex2300-c-12p
    Junos: 20.2R1-S2.1
    Junos: 20.1R1-S3.3

    getty[7313]: %AUTH-3: /dev/ttyu1: Inappropriate ioctl for device
    getty[7317]: %AUTH-3: login_tty /dev/ttyu1: Inappropriate ioctl for device
    %AUTH-1: getty repeating too quickly on port /dev/ttyu1, sleeping 30 sec



  • 26.  Re: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

    Posted 29 days ago

    Another reason for this  could just be a bad /var/etc/ttys config with  duplicate line ..

    This is just a quick fix, since if you reboot the ttys config file is from the mounted  image file.

    run start shell user root
    cd /var/etc
    vi ttys


    ttyu0 "/usr/libexec/getty std" vt100 on secure
    ttyu1 "/usr/libexec/getty std" unknown on secure
    ttyu2 "/usr/libexec/getty 3wire" vt100 onifconsole secure
    ttyu3 "/usr/libexec/getty 3wire" vt100 onifconsole secure
    ttyu4 "/usr/libexec/getty 3wire" vt100 onifconsole secure
    ttyu5 "/usr/libexec/getty 3wire" vt100 onifconsole secure
    ttyu1 "/usr/libexec/getty std" unknown on secure

    Delete the duplicate of ttyu1 at the bottom
    write quite and now restart the getty process

    kill -HUP 1


    JUST making note.. On my other 2300-c-12p running 19. my ttys looks like this and only two lines.

    ttyu0 "/usr/libexec/getty 3wire" vt100 on secure
    ttyu1 "/usr/libexec/getty 3wire" unknown on secure

     

    Versions ive seen this on

    20.1R1-S3.3
    20.2R1-S2.1

     



  • 27.  RE: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

    Posted 10-30-2019 11:23

    If you want both the rj-45 and usb console ports to be active at the same time the following works, at least on my 2300-C running 19.2R1.

     

    delete system ports
    set system ports auxiliary port-type mini-usb

    so I have been fiddling quite a bit on this. First of all, I was wondering what can "port auxiliary" commands do on a switch that do not have auxiliary ports. here is a couple of thing I found...

    • rj45 console port is always on, even after delete system ports. Good design on Juniper.
    • The command will disable the miniusb port, though.
    • you would expect set system ports console port-type mini-usb to reactivate it. It does not.
    • you may expect set system ports console port-type rj45 to reactivate it. It does not.
    • you would then try set system ports auxiliary port-type mini-usb. It does work !!!
    • but by curiosity, you would disable it again by delete system ports and check mini-usb is down. it is. 
    • you would the try set system port auxiliary port-type rj45 and tell yourself no, it cannot possibly activate de mini-usb ports. But it does !!!!
    • all this time, I have a ping going on on the console port updating every seconds.... 

    at that point, I put the switch back to set system ports auxiliary port-type rj45 disable because by sheer luck, I found it to make the vomiting of getty statement attempting to connect to the ttuy port stops. so that is a good thing. I still lose mini-usb console port connection, which does not bother me. But I would really like someone to explain to me why disabling auxiliary port-type 45   ends up deactivte the console mini-usb. 

    feel free to try and duplicate and keep me posted. I am still waiting for the new image that solve PR1442376

    Michel