- Roundtable - muug.ca

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

Network Issue
by Robert Keizer 12 Dec '13

12 Dec '13

Hey everyone, As it turns out I didn't have to go very far in terms of testing the network issue I described at the meeting last night. * Connect laptop to port in question. * No link light. * Grab new cable that is premade. Replace. * No link light. * Wiggle cable. Entire port on switch moves up and down with cable. * Link light. Rob

2 1

Reminder: MUUG Meeting Tonight, 7:30pm -- Round-table, Mingling and Munchies
by Gilbert E. Detillieux 10 Dec '13

10 Dec '13

Howdy folks! A reminder that the MUUG meeting is tonight, December 10, with the following topic: Round-table, Mingling and Munchies As the year draws to a close, we've decided to continue our not-quite-yet-tradition of turning the December meeting into more of a social event. We'll have the usual round-table session, which can run longer than average since there's no pressure to fit the presentation in, followed by time for mingling and eating and drinking instead of the usual short coffee break. This will be a "pot-luck" event, like we've done in the past. Some food and drink will be provided by MUUG, but members are encouraged to bring food to sample. Feel free to bring your own drink, too, if you want something particular just remember, please, that we don't have a liquor license! Winnipeg Harvest Food Drive Also as in previous years, we're combining this with a food drive for Winnipeg Harvest. We'd like members to bring some non-perishable food item for donation to the food bank. They have information about what they're looking for on their website. Winnipeg Harvest has apparently been running a shortfall all year, and needs your donations! http://winnipegharvest.org/donate-food/ So, please come, one and all, with a snack item to share with the group, and a non-perishable food item for Winnipeg Harvest. Hope to see you there!... ***************************************************************** 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. ***************************************************************** -- 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

Google certificates suborned
by Adam Thompson 10 Dec '13

10 Dec '13

Well, that's just lovely: http://googleonlinesecurity.blogspot.ca/2013/12/further-improving-digital-c… -- -Adam Thompson athompso(a)athompso.net

2 1