Re: apply /etc/ttys changes on system
In the last episode (Jun 19), takCoder said: Is there any way to apply /etc/ttys changes on system, except for *restarting system* and *running kill -HUP 1* command ? Due some reasons, i need to change tc value of some of my ttys, periodically. I'm looking for a safer way than *kill -HUP 1* command. So, as this command is not a good one to be used often, any ideas are really appreciated. I couldn't find any other one so far.. Why is kill -HUP 1 unsafe? It's documented in init's manpage: Line status (on, off, secure, getty, or window information) may be changed in the ttys(5) file without a reboot by sending the signal SIGHUP to init with the command ``kill -HUP 1''. On receipt of this signal, init re-reads the ttys(5) file. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: apply /etc/ttys changes on system
From: owner-freebsd-questi...@freebsd.org [owner-freebsd-questi...@freebsd.org] on behalf of Dan Nelson [dnel...@allantgroup.com] Sent: Wednesday, June 19, 2013 7:54 AM To: takCoder Cc: freebsd-questions@freebsd.org Subject: Re: apply /etc/ttys changes on system In the last episode (Jun 19), takCoder said: Is there any way to apply /etc/ttys changes on system, except for *restarting system* and *running kill -HUP 1* command ? Due some reasons, i need to change tc value of some of my ttys, periodically. I'm looking for a safer way than *kill -HUP 1* command. So, as this command is not a good one to be used often, any ideas are really appreciated. I couldn't find any other one so far.. Why is kill -HUP 1 unsafe? It's documented in init's manpage: Line status (on, off, secure, getty, or window information) may be changed in the ttys(5) file without a reboot by sending the signal SIGHUP to init with the command ``kill -HUP 1''. On receipt of this signal, init re-reads the ttys(5) file. Or init q -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: apply /etc/ttys changes on system
Thank you all for your replys. :) Why is kill -HUP 1 unsafe? It's documented in init's manpage: Line status (on, off, secure, getty, or window information) may be changed in the ttys(5) file without a reboot by sending the signal SIGHUP to init with the command ``kill -HUP 1''. On receipt of this signal, init re-reads the ttys(5) file. You are right, it is in the man page. I just wanted to preserve my machine from facing possible side-effects this command may cause, which i may not be aware of, if possible.. If one tty's tc has been changed and i run *kill -HUP 1* command, any current session on that tty will be forcibly closed; but not for those with same tty configs as before. At least, i may loose things, according to the loss of open sessions(though not having faced any problems during tests till now). i know i am responsible for the time of running this command, but do all child PIDs exit normally? I have heard of unwanted reactions on other OS es because of this command, but not for FreeBSD (at least till now).. Or init q As i heard, this command is just the same as kill -HUP 1. Does init q have any difference with the other one, in any aspects?? FWIW, I've used kill -HUP 1 on FreeBSD for reloading /etc/ttys since roughly 1997. No repercussions. Ever. Not once. It wasn't until sometime in the early 2000s that I found init(8) mentioning you could do init q instead, so since then I've done that. That's the experience! good to hear about that.. Anyhow, i think i will try init q from now on. At least seems more handy :) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
