On Tue, Jul 15, 2014 at 09:57:12AM +0200, Stef Walter wrote: > On 15.07.2014 09:47, Karel Zak wrote: > > Now when I think about it.. would be better to have this feature > > optional? I think it's overkill to have it enabled on all machines. > > Sure. > > > The another story is the signal usage (and possible race with login(1) as > > discussed at https://bugzilla.redhat.com/show_bug.cgi?id=1110763). > > > > What about for example: > > > > agetty --reload-trigger <file> > > As I said in the above bugzilla bug, I don't mind doing this ... but in > my opinion unix signals are meant exactly for this use case, and are > used by many (most?) other linx processes as a reload trigger. Yes, it's pretty common classic solution, but I think that in this case it is not too robust solution. > > and use inotify for the <file>. I guess this way also allows to avoid > > the ioctl() tty voodoo and you can use select() for the inotify and > > tty file descriptors. > > Unfortunately that's not how it works. When in canonical mode, the tty > file descriptor only becomes readable once a complete line has been > entered. I've verified that select() does not return until <enter> is > pressed. Ah.. good point, but with non-canonical mode it works as expected, right? So, we can use fd with VMIN=1 and inotify fd for the select(). Maybe the best would be to implement all within agetty, I mean add a special command agetty --reload [<tty>] to reload another already running agetty process(es). So rather than "killall agetty" you have to use "agetty --reload". Then all the implementation will be a private thing and only the "--reload" command line option will be a public API. Note that we does not control code of all login(1) implementations and we have --login-program <path> to start arbitrary random thing from agetty, so our solution have to be generic rather than rely on any login(1) change. Karel -- Karel Zak <kzak@xxxxxxxxxx> http://karelzak.blogspot.com -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
