Systemd oneshot, ExecStop and RemainAfterExit
I wanted to create a systemd service file that just ran 3 small commands today in a sequence on ExecStart and another set of reverse commands on ExecStop. My initial idea was to use bash syntax with ; between the commands (I keep forgetting that Systemd is not bash…), and the service file was set to being a oneshot file, which meant the ; was actually interpreted correctly, but all the ExecStop commands where also run directly when running systemctl start service.
So I read up a little on Systemd and ExecStart, this is what the http://www.freedesktop.org/software/systemd/man/systemd.service.html#ExecStart= page has to say:
When Type is not oneshot, only one command may and must be given. When Type=oneshot is used, zero or more commands may be specified. This can be specified by providing multiple command lines in the same directive, or alternatively, this directive may be specified more than once with the same effect.
So… that means the ; syntax will only work with oneshot apparently. Also, oneshot means that ExecStop runs directly after ExecStart. Further reading the documentation seems to indicate that RemainAfterExit=yes will make the service stay around according to systemd, so it will only try to execute the first time you run systemctl start, but not the second one. I don’t think this fixes that it runs ExecStop on start however, but I’m not sure.
ABS plastic with plastic modelling accessories
Filed under: 3D printing, Development, Hardware, Plastic modelling
I’ve been building plastic models on and off since I was a kid, and very much so as of late, meaning that I have a lot of modelling accessories available at home.
I accidentally broke off one of the screw holes for the BabyNES Raspberry PI case (http://www.thingiverse.com/thing:449877) almost instantly due to the bad print quality. Reading around I didn’t find any obvious glues to use except acetone. In fact, I found a whole heap of warnings that the fat plastic would probably be hard to glue etc. Hence, I decided to test Revell Contacta Professional glue (http://www.amazon.co.uk/Revell-39604-Contacta-Professional-Glue/dp/B000KJPUL0) and it worked like a charm from what it looks like!
Since this worked so well, I tried some Italeri putty for plastic models (http://www.model-making.eu/products/Italeri-putty-for-plastic-models-28-ml.html) to cover up the sides which shows a lot of layers and some defects. Except the putty smelling really bad, it tacked on really hard and dried enough in just a few minutes to be sanded down.
Since the above went so well, I went ahead and did some more tests by printing a set of battered barrels (http://www.thingiverse.com/thing:535261) which turned out fairly crappy due to the print quality (mind you, much better than the first BabyNES case). Either way, perfect chance to test what could be done using those modelling tools/supplies. Here’s some before through after shots:
I think a lot of the plastic modeller materials could be used with ABS and possibly PLA plastics as well, especially where you want to make a structure, and then want to improve the details. There are much better printers out there with much better calibration of course, but these materials combined shows some great promise IMHO.
3D printing
Filed under: 3D printing, Development, Hardware, Personal
I started working at a new company a while back if I failed to mention it called Pelagicore, doing automotive in vehicle infotainment systems the right way with open source, working in the community etc. They have a 3D printer (Makerbot thing-o-matic) that’s been standing around for a while really grabbing my attention and I’ve wanted to find the time to use it since I started there. I finally took the time and am happy as a clam.
I made my first 3D print at work two days ago, first of three pieces for a BabyNES Raspberry Pi 2 case (http://www.thingiverse.com/thing:449877), a small hatch. When I went on and tried building the two larger pieces I ran into troubles. Running out of time that day, I got around to try and fix it today. Disassembled the extruder stepper motor and realized a screw had dislocated from the vibrations. Re-screw it and assemble everything again, and this time, it worked! Got top and bottom parts done before leaving for home today and am fairly happy. They will do.
The print quality is pretty shoddy, a lot of settings needs to be tuned I guess, and the print speed was probably too high for the unit. Judging by the software installed, I should probably install newer software and redo the calibrations using those instead. Still, awesome to work with this 🙂
Project build speed importance
Filed under: Configuration Management, Development, Linux
I began writing this several years ago but never published it for various reasons. I think some of the thoughts are still really interesting, I joined a company named Pelagicore some months ago and we do some rather large builds at this company, similar in build times in the project I refer to in this text, but with some major differences. This build is based on yocto and it actually works really well once you get through the first build (currently a scratch dev image build is up to 4 hours in time, but after that it’s able to rebuild only changed software and recipes as necessary. The scratch build is heavy admittedly, but we are working on some ways to improve that as well, such as sstate caches, icecc distributed build systems, and so forth. I think with modifications we could get those 4 hours down to under an hour, which would be really sweet. Anyways, I thought I’d post this text as is, even though it’s not finished, just because and since I re-read it right now 😉 .
Original text
Again, I’m struck by the importance of a proper build process in projects. No matter how small or big the project is, the build must be kept fast and working from get go to the end — which means its end of life cycle. I am currently working in a large project with a huge code base where the build system is, in my opinion, next to completely collapsed. Build time is in excess of 1-4 hours, and the automated test-suites take from 3 hours to 7 hours to complete, depending on how thorough a test-suite you choose. A gigantic heap of time is spent just…. waiting… waiting…. waiting. Just to make a simple one line edit and then compile to see if it compiles can take up to 4 hours. I’ve previously been a bit spoiled with good and simple build systems, only occasionally running into really crappy build systems — for some reason, a lot of scientific open source software seem to be stuck in this category.
This time, I think I hit pay-dirt on “how not to do it”. Instead of focusing on the bad parts, I will try to focus on the things to do and to keep in mind. Nobody seems to like a grumpy person anyways, which I really am sometimes.
1. Keep the build system simple and manageable. Try to maintain the build system in a logical fashion and in a single language/system (scons/python, Makefiles, etc).
2. Expandable (new directories, files, etc)
3. Scalable (multiple CPU’s, machines, threads, etc)
4. Try to use as few frontends as possible (a single top makefile for example, with targets depending on what you want to do), and keep people informed of changes. Wiki with history via RSS is _perfect_ for this. This doesn’t mean you can create a script to build something, then 2 months down the road delete it because it is no longer needed, it causes a lot of stress for developers who just barely had a chance to find the script.
5. The programmers are (most likely) your customers.
DIY OSD update
Filed under: Development, FPV, Hardware, Robots, Video
Late update, but video is working as expected, GPS is working to some extent, but because of local weather I havent really tested it outdoors… I’m considering changing video transmitter and power system however. I’m currently running on 1S 160mAh batteries with a stepup regulator to 5v to a 10mw transmitter, which gives a really lousy battery time for the video system, also I’ve got too many batteries flying around at the moment I think.. Limiting to a bit fewer might be a good idea. Currently, there’s a battery for the video link/osd, one built into the camera, one for motor/rc receiver/servos, and one in the rc transmitter, 4 batteries in total of various sizes etc… a pain to charge them all. Hooking up the videolink and OSD to ESC/BEC is a trivial change and would remove a lot of cruft (stepup module etc), but will also add the EMC from motor/ESC to handle for the videolink etc as it’s a completely separate system today.
I’ve also upgraded so I’m using a mobius actioncam. Everything all in all means the system will draw more power and weigh more as well. Removing some batteries and running from the mains system would be really nice.
qmake project custom install and files being installed as non-executable
I had some issues with creating a custom install target from a qmake pro file for a project today and everything took me quite some time to get working I’m embarassed to say. This was done to create make install_ptest target for a yocto build, but the files kept turning up non-executable in the rpm’s and install directory. In the end, I got it working by adding the executable keyword to the CONFIG of the target, in addition to the no_check_exist.
PTEST_FILES += \
$$ROOT_SOURCE_DIR/tests/service_tests/test_runner.py \
$$ROOT_BUILD_DIR/tests/service_tests/tst_service_tests
ptest.depends += $(first) sub-tests tests
ptest.path = /usr/lib/AnyApp1/ptest
ptest.files = $$PTEST_FILES
ptest.CONFIG = no_check_exist executable
INSTALLS += ptest
QMAKE_EXTRA_TARGET += ptest
I hope this helps you if you run into the same problem as I had some issues finding information about that specific flag or the problem.
Build ppa package
Filed under: Debian, Development, Linux, Ubuntu
To build a package for ppa distribution, you need some tools. To “cross compile” for releases, for example i386 and amd64 packages on the same machine, takes some more work with schroot, dchroot etc. I’ll start with explaining how to create a “local” package for your own host, I’ll add another entry on how to do an i386 package from amd64. Everything is done on ubuntu 14.04 amd64 machine in this case, and I’m rebuilding dbus.
In short you need:
- apt-get install build-essentials dpkg-buildroot schroot gpg
- gpg –gen-key
- apt-get build-dep dbus
- mkdir dbus-amd64 && cd dbus-amd64
- apt-get source dbus
- export DEB_SIGN_KEYID=
- cd dbus-directory
- make changes.
- dch -i
- dpkg-source –commit
- dpkg-buildroot -i -I
If you plan on publishing your deb packages to launchpad or some such, you need to create an account and add a ppa. This is simple and done via the http://www.launchpad.net webpage. The webpage also gives you good upload information. Note that they require signed files, so signing must work for you first.
8. Create account on launchpad.
9. Export the gpg generated key to hkp://keyserver.ubuntu.com:11371 (easiest to do via Passwords and Keys tool
10. Import the key to launchpad using the key fingerprint.
11. Create a new PPA from the launchpad dashboard
12. dput ppa: dbus_1.6.18-0ubuntu4.4_source.changes
The package will be built by launchpad on its own, this may take some time..
DIY OSD
I’ve built a DIY OSD based on Dennis Frie hardware and software released on rcgroups forum. I’m fairly happy with the results, the osd actually work. I do have some issues, but nothing serious. I have GPS, voltage sensors working as they should so far and am planning to add a current sensor and possibly rssi as well.
Top side not much to talk about. It’s an arduino pro mini 5v unit.
The GPS in the picture is not the one I’m using so far, but I will move over to it in a few days I hope, if I find the time. Main problem is that the GPS requires 3.3v,I’m running everything on 5v at the moment. I’m currently using a ublox neo7m from banggood. The picture shows how I hope to mount the GPS approximately though, depending on how I plan to mount OSD in comparison to the video link and the camera… GPS and video link should be mounted as far away from each other as possible, but OSD needs to be close to the video cable.
The bottom side. Most of the components have been sandwiched between the PCB’s. Some of the routing is a bit stupid but I’ll see if I can fix it so I can fit the current sensor somewhere on the bottom as well.
Remote DBus continued (using your own program)
Filed under: Communications, Development, Linux
Continuing the previous thought on running DBus remotely using d-feet to check how it looks etc, this time, I wanted to call the DBus from my own program. Just write the DBus code as you would to query the DBus interface locally.
#!/usr/bin/env python import dbus import dbus.service from dbus.mainloop.glib import DBusGMainLoop BUS_NAME="org.freedesktop.DBus" OPATH="/" bus = dbus.SessionBus() obj = bus.get_object(BUS_NAME, OPATH) iface = dbus.Interface(obj, BUS_NAME) lala = iface.GetId() print lala
Then the magic comes in running the application.
DBUS_SESSION_BUS_ADDRESS="tcp:host=192.168.X.Y,port=Z" ./dbus-hello.py
DBus remote connection
Filed under: Communications, Development, General, Linux
In a project I’m working on at the moment we wanted to remotely monitor a DBus session bus. The system in question has several buses available using different users and systemd. d-feet can connect and monitor remotely via TCP. The following code will allow you to connect to a remote DBus on a target development board for example.
First copy the original session.conf to separate configuration files for each user.
cp /etc/dbus-1/session.conf /etc/dbus-1/session.conf.<username> cp /etc/dbus-1/session.conf /etc/dbus-1/session.conf.<username2>
Then for each of the newly created configuration file, add the following configuration but with different port numbers and correct username director in /run/user. The ip address should be the IP of the connecting host, not the server. Edit session.conf.<username> and add:
<listen>tcp:host=<ip>,bind=*,port=<port>,family=ipv4</listen> <listen>unix:path=/run/user/<username>/dbus/user_bus_socket</listen> <listen>unix:tmpdir=/tmp</listen> <auth>ANONYMOUS</auth> <allow_anonymous/>
The systemd script is rewritten to use a specific conf file for the specific user trying to start the DBus.
Edit /lib/systemd/system/dbus-session@.service and rewrite the ExecStart line as follows.
ExecStart=/usr/bin/dbus-daemon --config-file /etc/dbus-1/session.conf.%i --nofork
This allows you to connect using d-feet or other dbus applications (potentially, you should be able to connect for example other services over the network to the new DBus….).
Choose “connect to other bus” and use as bus address:
tcp:host=<targetIp>,port=<port>
Done. Hopefully.