- Roundtable - muug.ca

MUUG Meeting, Jan 14, 7:30pm -- Wireshark
by gedetil＠cs.umanitoba.ca 07 Jan '14

07 Jan '14

The Manitoba UNIX User Group (MUUG) will be holding its next monthly meeting on Tuesday, January 14. The meeting topic for this month is as follows: Wireshark Katherine Scrupa will be presenting Wireshark as the main topic. "Wireshark is the world's foremost network protocol analyzer. It lets you see what's happening on your network at a microscopic level. It is the de facto (and often de jure) standard across many industries and educational institutions." Kevin McGregor will be presenting an RTFM from the depths of CLI Magic; @climagic on Twitter. The group holds its general meetings at 7:30pm on the second Tuesday of every month from September to June. (There are no meetings in July and August.) Meetings are open to the general public; you don't have to be a MUUG member to attend. ***************************************************************** Please note our *NEW* meeting location for this month: Room 1L08, Lockhart Hall, University of Winnipeg, entrance on Ellice Ave. between Spence St. and Balmoral St. Parking is available on the surrounding streets and in the lots on nearby streets. Look for signage once you're at the building, or ask a security guard. ***************************************************************** For more information about MUUG, and its monthly meetings, check out their Web server: http://www.muug.mb.ca/ Help us promote this month's meeting, by putting this poster up on your workplace bulletin board or other suitable public message board: http://www.muug.mb.ca/meetings/MUUGmeeting.pdf -- Gilbert E. Detillieux E-mail: <gedetil(a)muug.mb.ca> Manitoba UNIX User Group Web: http://www.muug.mb.ca/ PO Box 130 St-Boniface Phone: (204)474-8161 Winnipeg MB CANADA R2H 3B4 Fax: (204)474-7609

1 0

Korn shell script debugging
by Kevin McGregor 03 Jan '14

03 Jan '14

I've got a Korn shell script which I'm trying to debug with the aid of the "-x" switch, and it works for a while (i.e. as the script executes) until a function is called, then the shell stops displaying the commands as it executes. When the function returns, the commands are displayed again. How do I get it to display commands for the entire script? Kevin

2 1

dhclient-exit-hooks
by Trevor Cordes 03 Jan '14

03 Jan '14

Yet another obscure problem. /etc/dhcp/dhclient-exit-hooks is supposed to run (if it exists) after dhclient has accepted a new DHCP IP from your ISP and done all its stuff. One would assume that would include setting the IP on your actual interface. I have a problem where a script that /etc/dhcp/dhclient-exit-hooks talks to (async through a named pipe, so after that it won't block) then does some stuff based on what /sbin/ip says the ip address is. I am expecting this to be the *new* ip address. But what it seems to be doing is still using the old ip, meaning (if I'm following my extremely complex scripts properly) /sbin/ip is still returning the old ip at that point. Does anyone have experience with dhclient, or its hooks? Is this even possible? Even weirder is my scripts wait an additional 10s before checking /sbin/ip so even if there was a short delay, it shouldn't still give me the old ip. The /sbin/ip command I use it: /sbin/ip -o -4 addr list <interface> then I parse out the address. Is there anything in the linux networking layer that would cause an IP bind to "not show up" for >10s? Secondly, debug testing this will be very difficult because our Shaw IP's change so infrequently. I suppose I could "trick it" by switching NICs and/or changing my NIC's MAC. I've never done that before, is that easy and safe?

2 3

Tablet dev software
by Robert Keizer 21 Dec '13

21 Dec '13

Greeting, I recently received a new Samsung tablet as a gift. Does anyone have experience with using a tablet as a primary development system? I'm leaning towards purchasing a HDMI cable and running a bluetooth keyboard/mouse. Rob.

2 1

SOLVED: PPPoE/pppd dying
by Trevor Cordes 21 Dec '13

21 Dec '13

Some may recall my strange pppoe hanging-up up watchdog-script restart problem from a few months back (original email included at bottom) to which no one replied ;-) After a few serendipitous epiphanies I stumbled upon the possibility of kernel "session id" as the culprit. I could get around that by starting pppoe stuff with setsid (either in perl or right at the command line). That got me my own session (removing me from the same session as the watchdog script). But that didn't solve it. But that led me to process groups, but that was also not it. Then I stumbled across in the fs /proc/*/cgroup and noticed that the ppp ps's were (still) tied to my watchdog script, via the systemd unit name (call it my-watchdog), so, where pppd is 13480: #cat /proc/13480/cgroup 10:perf_event:/ 9:blkio:/ 8:net_cls:/ 7:freezer:/ 6:devices:/ 5:memory:/ 4:cpuacct,cpu:/system/my-watchdog.service 3:cpuset:/ 2:name=systemd:/system/my-watchdog.service So that was the tie between the watchdog and the ppp* programs! Time to learn cgroups... argh. To make a long story short, this is all systemd's fault! Surprise! It makes sense now, as this bug only appeared for me around the time Fedora switched to systemd. Before that I was using inittab and then upstart to control these things and those tools don't use cgroups (well, upstart might?). Systemd, as a "feature", puts each *.service into its own eponymous cgroup. Then all child ps's of those would inherit the same cgroup settings. Then when the parent *.service gets restarted or killed, either the kernel or systemd (haven't deduced which; ideas?) propagates the kill signal to all members of the cgroup. Thus answering the question. The solution I settled on (for now) out of the about 20 ways it seemed one could fix it is to put the following in my my-watchdog.service file in the [Service] section: ControlGroup=cpuacct:/ name=systemd:/ Which then causes the relevant /proc/*/cgroup files to look like (relevant lines only): 4:cpuacct,cpu:/ 2:name=systemd:/ Thus tying them to the "root" cgroup and eliminating the propagation of kill signals. (Which hints that it is systemd propagating, not the kernel unless the kernel explicitly excludes the root cgroup.) I also achieved the same thing by writing directly to the /sys/fs/cgroup/ files, but that only achieves temporary independence and would have to be done each time ppp* is started. echo <pid> >> /sys/fs/cgroup/cpu,cpuacct/tasks echo <pid> >> /sys/fs/cgroup/systemd/tasks That's actually a viable solution, and perhaps better, as it allows me to keep my-watchdog in its own cgroup as systemd wants to do whilst separating out just the ppp* stuff. BUT, systemd's online docs indicate systemd will in the future block manual fs configuration like this. Also, the systemd docs and current Fedora 19 implementation seem to be a bit at odds and many of the options they discuss do not work when tried (invalid lvalue, etc). I also think that my solution here may not work in the future as they lock down cgroups more. I think perhaps the "real" solution to all of this is to somehow make ppp* a unit in systemd and have my-watchdog use systemd to control it. That way we achieve cgroup independence without doing anything weird. But, pppoe (client) doesn't really fit the systemd *.service mold as such and no one I can see has implemented it that way yet. This may be required in the future, however. The moral of the story is, if you use systemd and your service files/programs launch a process as a "side effect", that process will die when your service gets restarted/killed. If you are starting anything daemon-like that you want to survive, you'll need to implement workarounds as described in this email. On 20130324 17:53:30, Trevor Cordes wrote: > I have a script that starts/restarts PPPoE/pppd (MTS aDSL) as required on > a box. It used to work A-OK. After updates w ehil back (probably from > Fedora 14 -> 16 I think) a weird thing started happening: > > When my script is stopped (to be restarted after an update for instance), > it instantly kills pppd and so my pppoe connection. > > pppd[1572]: Terminating on signal 15 > pppd[1572]: Connect time 7.5 minutes. > pppd[1572]: Sent 136980 bytes, received 76924 bytes. > pppd[1572]: Connection terminated. > pppoe[1573]: read (asyncReadFromPPP): Session 14782: Input/output error > pppoe[1573]: Sent PADT > pppd[1572]: Exit. > > sig 15 is SIGTERM. > > I can see before this happens that the processes involved are at the root > owned by init (ps 1): > > root 4393 1 0 17:30 ? 00:00:00 /bin/bash /sbin/pppoe-connect /etc/sysconfig/network-scripts/ifcfg-ppp0 > root 4417 4393 0 17:30 ? 00:00:00 /usr/sbin/pppd pty /usr/sbin/pppoe -p /var/run/pppoe-adsl.pid.pppoe -I eth0 -T 60 -U -m 1412 ipparam ppp0 linkname ppp0 noipdefault noauth default-asyncmap defaultroute hide-p$ > nobody 4418 4417 0 17:30 ? 00:00:00 /usr/sbin/pppoe -p /var/run/pppoe-adsl.pid.pppoe -I eth0 -T 60 -U -m 1412 > > One would think that if it's been "daemonized" to be owned by init then > killing the calling script would not affect it. But it is. > > What my script actually call is ifup and then Fedora's network magic in > turn calls pppoe/pppd. ifup itself exits right after doing this (which is > probably why its children become children of init). > > I tried adding a nohup before the ifup, but it doesn't help. I guess that > makes sense since it's SIGTERM, not SIGHUP. > > I'm out of ideas to make sure this stuff stays up after restarting my > script, and don't know what could have changed in Fedora to make this > happen. > > Thanks!

1 0

Recommendations for wireless mini-keyboard/trackpad?
by Gilbert E. Detillieux 20 Dec '13

20 Dec '13

I'm thinking of getting a wireless mini-keyboard with integrated trackpad, with a USB receiver, to use as a remote control for an XBMC set-top box. I've tried using a Logitech K400r, which works great, but I thought something more compact might be more convenient (since I won't be doing a lot of touch-typing on it). There seems to be a wide range of prices for these things, from around $15 at the low end to over $100. I'm always interested in saving money, but I want something that will work well, of course. Has anyone tried these? Any recommendations for brands and models that are worth considering? Any that should be avoided? Thanks! -- Gilbert E. Detillieux E-mail: <gedetil(a)muug.mb.ca> Manitoba UNIX User Group Web: http://www.muug.mb.ca/ PO Box 130 St-Boniface Phone: (204)474-8161 Winnipeg MB CANADA R2H 3B4 Fax: (204)474-7609

2 1

out of inodes
by Trevor Cordes 13 Dec '13

13 Dec '13

As a follow-up to the opera-ate-my-inodes problem discussed at the meeting, I checked a few things out and realized that this surely is a problem not limited to bad (or lazy) admin choices, for the following reasons: 1. People with separate /home partitions aren't spared: what if an app or malicious user writes to /var/tmp, which on 99% of systems is going to be on the same partition as /. So a separate /home won't spare you from / running out of inodes: all it takes is one sticky-bit dir in the whole tree where a non-root can write to have one non-root user/app starve the system of inodes. 2. The thought that you should create your fs's with massively more inodes than your usage pattern could ever use won't help either, as the user/app could create 0 byte files that eat an inode but never a fs block. You'd run out of inodes before you hit the reserved-root-du limit no matter how many inodes you created at fs creation time. (Not to mention the non-insignificant loss of usable disk space that occurs if you allocate many orders of magnitude more inodes than you will ever need.) 3. Quotas might be able to help, but I'm not talking about public systems here, I'm talking about my own personal home desktop. Surely no one is running quotas against themselves on their personal home system? And surely that can't be offered as a "sane" solution the average Joe is supposed to implement. OK, here's the weirdest part: I just checked and my / is ext4! I thought Adam mentioned ext4 dynamically creates inode out of thin air (and I thought that too) like XFS? So why did I run out of inodes on a non-full (df) ext4 fs? If this "bug" indeed affects ext4 then for sure I am filing a bug report. If it only affected "legacy" fs's like ext3 then I probably would just let it pass (and switch to ext4 if I hadn't already). Thanks for everyone's input!

3 3

The voicemail messages we've been getting
by Daryl F 13 Dec '13

13 Dec '13

Attached are WAV and AMR formats. I create both forms. The first for my Windows user (wife) the other for my BlackBerry. Same data, different encoding. I'm suprised to see my MUA considers the Adaptive Multirate Recording's MIME type as TEXT/PLAIN. A little tweaking needed there. Happy Holidays to all. -Daryl

3 4

Amazon's new delivery system!
by Brian Doob 12 Dec '13

12 Dec '13

After our discussion of “Amazon Prime Air”, I think it’s worth sharing this video. This came online only a few days after Amazon’s drone announcement…. http://www.youtube.com/watch?v=jHrngvEok9M

1 0

too much time on his hands...
by Adam Thompson 12 Dec '13

12 Dec '13

http://rasteri.blogspot.ca/2011/03/chain-of-fools-upgrading-through-every.h… I must stand corrected, as although I knew this was theoretically possible, I didn't believe it could actually be done successfully. -Adam

3 2