I Want To Replace A Lot Of Heads
I install a VPN client and suddenly, while installing, all connections are reset. Consequently, all remote applications close and all unsaved data is lost. And as if that doesn't suffice, the installer requests a windows reboot. Seriously, if the programmer writing this crap would have had been standing by me, I'd have had his head replaced. After rebooting I discover that if I activate the damn VPN connection, ALL traffic is routed through it. HEY! AT LEAST I WANT TO ACCESS COMPUTERS ON MY LAN, YOU STUPID GIT! What a bunch of idiots, conceiving this piece of shit. Yeah, I'm outrageously pissed of, thanks to Cisco. Sure, I can customize settings so I can access my LAN, but it's astoundingly hard. Where the heck did their logic go? Only traffic to the LAN on the other end of the VPN connection should be routed through the VPN connection by default! Or at least there should be some easy questions about this issue when setting up a VPN, if security is such an issue.My boss has some weird problems, too. The virus checker on his computer demands a reboot after every automatic update of virus definitions. Imagine: you come in the office, turn on the computer, after the login the virus checker loads up and does its automatic tasks, and then a request for reboot pops up. OK, reboot, and login again, and then you may start working.
And don't think Debian (a GNU/Linux distro) is without issues, too. After a wasted day of debugging I found out that debconf scripts don't set close-on-exec flag, so any programs forked into background (daemons) inherit all open file descriptors. And debconf is such a stupid piece of shit: for anything that is to be executed it creates a pipe, then it forks itself and the child sets up the pipe descriptors in a weird way before execing the thing. The weird way is this: the input pipe becomes descriptor 0 (stdin, that's ok) and the output pipe becomes descriptor 3 (say, what?), while descriptors 1 and 2 remain connected to whatever the parent was connected. Oh, wait, there's more. The parent debconf process remains in a read/write loop while any pipe descriptor remains open. It doesn't detect the zombie child. How could it be there is still something open even after the child dies, you ask? Because the child exec'd a startup script, which runs a daemon, that forks into background, and has no way of knowing, what descriptors are open, beyond standard 0, 1, and 2! Of course, if someone set up close-on-exec process flag before running the daemon, it would all be okay. And the solution? My daemon has to try to close all possible descriptors when run. Debconf scripts return correctly now. Idiots. I was about to report a bug when I read that it's surely an issue with the daemon and I should use db_stop in my setup scripts for misbehaving daemons. Really, if I'd have been given the chance, I'd have had replaced a lot of heads this week already. Oh, and there is even more. What I described up until now happens if an (initial) package configuration takes place. If you want to reconfigure the package, then the daemon misteriously gets another couple of pipes on descriptors 10 and 12. Oh well, I gave up and just wrote that loop that tries to close every possible descriptor. Because I have this addiction to portability and didn't want to use the /proc/<pid>/fd list.
posted by AlesS @ 2/08/2006 09:03:00 PM
2 comments
