Tag Info

New answers tagged

3

A Solution: The problem is that this serial port is non-PlugNPlay, and a system do not know which device was plugged in. Anyway, after reading a HowTo I get the working idea. An *nix-OS already have in /dev/ a files like ttySn where a n ending is a number. Most of this files is dumb i.e. doesn't correspond to an existing devices. But some of those is going ...


2

Screen is a bit heavy handed. A second way is to use the old school method of nohup. nohup script command 2>&1 > /dev/tty1 & The nohup command captures all hangup signals and ignores them, so the the command left after will not receive and there for not stop on closing your terminal.


2

Spawn your script within a screen session. Redirect output to TTY as you proposed. Detach from the screen session and close the terminal. No SIGHUP will be sent so the script should continue to run.


4

Adding a little bit of historical perspective, the idea of sleeping after a bad password is not just found in PAM-based systems. It's very old. For eaxmple in the 4.4BSD login source you'll find this tasty fragment: /* we allow 10 tries, but after 3 we start backing off */ if (++cnt > 3) { if (cnt >= 10) { badlogin(username); ...


2

As others have answered, PAM is most likely the cause for this. The actual verification of the password only takes a very short time, the rest is a delay designed to prevent brute force attacks. On Debian, I have the following lines in /etc/pam.d/login: # Enforce a minimal delay in case of failure (in microseconds). # (Replaces the `FAIL_DELAY' setting from ...


2

See this answer on StackOverflow that quotes the The Linux-PAM Module Writers' Guide: As directed by this file, one of more of the modules may fail causing the pam_...() call to return an error. It is desirable for there to also be a pause before the application continues. The principal reason for such a delay is security: a delay acts to discourage brute ...


0

I don't use Archlinux myself, so I don't know exactly, but this sounds like a mechanism against brute-force password guessing.


0

I tried your line, I get the following in /var/log/secure (fedora19): getty[12336]: bad speed: 34800 try this: agetty -s 38400 -t 600 tty8 linux


2

As root, edit /etc/default/grub and to GRUB_CMDLINE_LINUX add: --default-console=none Then run update-grub and try a reboot. I do not have a ubuntu system here to test this on, but I am pretty sure it should suppress output from upstart (the init daemon that runs your scripts), but not the kernel's initial boot messages. To do that, also add quiet ...


1

The console=ttyO2 allows you to see the kernel and system messages on the corresponding serial port. It does not affect the boot process otherwise - the system will boot even without a console. Remember to edit /etc/inittab - change ttyS2 to ttyO2 there to get a login prompt on the serial console once the system boots. Your new kernel is probably missing ...


1

You have two different keymaps. One used by your graphical environment (X) and one used by you console. The first one is configured by xmodmap and setxkbmap. The second one is configured by loadkeys. You can dump the first one with xmodmap and the second one with dumpkeys. Have a look at the man pages of those commands to find the correct options and ...


1

To suggest an alternative, have you tried minicom or screen. The thing you are wanting is to change the line disciplne, it sounds like you are in raw mode (each character sent to remote) instead of buffered (or cooked) mode (cr triggers buffer to be sent). there is also a half way house semi-cooked mode (cbreak). All these values can be set using the stty ...



Top 50 recent answers are included