AppArmor vs Minefield

Post Syndicated from RealEnder original http://alex.stanev.org/blog/?p=260

От доста време използвам trunk версията на Firefox, aka Minefield. За Ubuntu има подходящо хранилище, където екипа в Canonical опреснява редовно новите версии.
За всекидневната си работа използвам лаптоп, работния профил живее на TrueCrypt криптиран дял. Така имам два профила – другия живее в home директорията.
Когато преди няколко дни криптирания профил отказа да се зареди със съобщението, че вече се използва, го отдадох на регресия в trunk-а на Firefox. Странното беше, че този в home директорията работеше и премахването на .parentlock в TrueCrypt дяла не помогна.
Днес реших да огледам по-внимателно ситуацията и се оказа, че проблема съвсем не е в trunk build-а, а по-скоро в packaging-a – изключението в AppArmor, което е необходимо на този етап, не е обновено.
Ако имате подобен проблем, можете да направите следното:
Редактирате като root /etc/apparmor.d/usr.bin.firefox-4.0 , където заменяте firefox-4.0b7pre с firefox4.0b8pre (s/firefox-4.0b7pre/firefox4.0b8pre) на всички редове. Алтернативно вероятно ще откриете файла /etc/apparmor.d/usr.bin.firefox-4.0.apparmor , който е коректен и го заменяте с горния. След това проверете и symlink-а в /etc/apparmor.d/disable/usr.bin.firefox-4.0 дали сочи на правилното място(към основния файл, който заменихте)
За да приложите промените ще се наложи да презаредите AppArmor правилата:
sudo /etc/init.d/apparmor reload

Canonical, Ltd. Finally On Record: Seeking Open Core

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/10/17/shuttleworth-admits-it.html

I’ve
written before
about my deep skepticism regarding the true motives
of Canonical, Ltd.’s advocacy and demand of for-profit corporate
copyright assignment without promises to adhere
to copyleft. I’ve
often asked Canonical employees,
including Jono
Bacon
, Amanda
Brock
, Jane
Silber
, Mark
Shuttleworth
himself, and —
in the
comments of this very blog post

Matt Asay to
explain (a) why exactly
they demand copyright
assignment on their projects
, rather than merely having contributors
agree to the GNU
GPL
formally (like
projects such as Linux do), and (b) why, having received a contributor’s
copyright assignment, Canonical, Ltd. refuses to promise
to keep the software copylefted and never proprietarize it
(FSF, for example, has always done the latter in assignments). When I
ask these questions of Canonical, Ltd. employees, they invariably
artfully change the subject.

I’ve actually been asking these questions for at least a year and a
half, but I really began to get worried earlier this year
when Mark
Shuttleworth falsely claimed
that Canonical, Ltd.’s copyright
assignment was no different than the FSF’s copyright assignment.
That event made it clear to me that there was a job of salesmanship
going on: Canonical, Ltd. was trying to sell something to community that
the community doesn’t want nor need, and trying to reuse the good name
of other people and organizations to do it.

Since that interview in February, Canonical, Ltd. has launched a
manipulatively named product called
“Project
Harmony”
. They market this product as a “summit”
of sorts — purported to have no determined agenda other than
to discuss the issue of contributor agreements and copyright
assignment, and come to a community consensus on this. Their
goal, however, was merely to get community members to lend their good
names to the process. Indeed, Canonical, Ltd. has oft attempted to use
the involvement of good people to make it seem as if Canonical, Ltd.’s
agenda is endorsed by many. In
fact, FSF
recently distanced itself from the process
because of Canonical,
Ltd.’s actions in this
regard. Simon
Phipps had similarly distanced himself before that
.

Nevertheless, it seems Canonical, Ltd. now believes that they’ve
succeed in their sales job, because they’ve now confessed their true
motive. In
an IRC
Q&A session
last
Thursday0, Shuttleworth
finally admits that his goal is to increase the amount
of “Open
Core”
activity. Specifically, Shuttleworth says at 15:21 (and
following):

[C]ompare Qt and Gtk, Qt has a contribution agreement, Gtk doesn’t, for a
while, back in the bubble, Sun, Red Hat, Ximian and many other companies
threw money at Gtk and it grew and improved very quickly but, then they
lost interest, and it has stagnated. Qt was owned by Trolltech it was open
source (GPL) but because of the contribution agreement they had many
options including proprietary licensing, which is just fine with me
alongside the GPL and later, because they owned Qt completely, they were
an attractive acquisition for Nokia, All in all, the Qt ecosystem has
benefitted and the Gtk ecosystem hasn’t.

It takes some careful analysis to parse what’s going on here. First of
all, Shuttleworth is glossing over a lot of complicated Qt history. Qt
started with a non-FaiF
license (QPL),
which later
became a GPL-incompatible Free Software license
. After a few years
of this
oddball, license-proliferation-style
software freedom license, Trolltech stumbled upon the “Open
Core” model (likely inspired by MySQL AB), and switched to GPL.
When Nokia
bought Trolltech
, Nokia itself discovered that full-on “Open Core”
was bad for the code base, and
(as I
heralded at the
time
) relicensed
the codebase to LGPL
(the same license used by Gtk). A few
months after that, Nokia
abandoned
copyright assignment completely for Qt
as well! (I.e., Shuttleworth
is just wrong on this point entirely.) In fact, Shuttleworth, rather
than supporting his pro-Open-Core argument, actually gave the prime
example of Nokia/TrollTech’s lesson learned: “don’t do an
Open-Core-style contributor agreement, you’ll regret it”.
(RMS
also
recently published
a good essay on this subject
).

Furthermore, Shuttleworth also ignores completely plenty of historical angst in
communities that rely on Qt, which often had difficulty getting bugfixes
upstream and other such challenges when dealing with a for-profit
controlled “Open Core” library. (These were, in fact, among the
reasons Nokia
gave in May 2009 for the change in policy
). Indeed, if the proprietary
relicensing business is what made Trolltech such a lucrative acquisition
for Nokia, why did they abandon the business model entirely within four
months of the acquisition?

Although, Shuttleworth’s “lucrative acquisition” point has
some validity. Namely, “Open Core” makes wealthy,
profit-driven types (e.g.,
VCs) drool. Meanwhile,
people like
me,
Simon
Phipps
, NASA’s
Chris
Kemp
, John
Mark Walker
, Tarus
Balog
and many others are either very skeptical about “Open Core”, or
dead-set against it. The reason it’s meeting with so much opposition is
because “Open Core” is a VC-friendly way to control all the
copyright “assets” while pretending to actually have the
goal of building an Open Source community. The real goal of “Open
Core”, of course, is a bait-and-switch move. (Details on that are
beyond the scope of this post and well covered in the links I’ve
given.)

As to Shuttleworth’s argument of Gtk stagnation, after
my trip
this past summer to GUADEC
, I’m quite convinced that the GNOME
community is extremely healthy. Indeed,
as Dave
Neary’s GNOME Census shows
, the GNOME codebases are well-contributed
to by various corporate entities and (more importantly) volunteers.
For-profit corporate folks like Shuttleworth and his executives tend not
to like communities where a non-profit (in this case,
the GNOME Foundation)
shepherds a project and keeps the multiple for-profit interests at bay.
In fact, he dislikes this so much that when GNOME was
recently documenting
its long standing copyright policies
, he sent Silber to the GNOME
Advisory Board (the first and only time Canonical, Ltd. sent such a high
profile person to the Advisory Board) to argue against
the long-standing GNOME community preference for no
copyright assignment on its
projects1.
Silber’s primary argument was that it was unreasonable for individual
contributors to even ask to keep their own copyrights, since
Canonical, Ltd. puts in the bulk of the work on their projects that
require copyright assignment. Her argument was, in other words, an
anti-software-freedom equality argument: a for-profit company is more
valuable to the community than the individual contributor. Fortunately,
GNOME Foundation didn’t fall for this, continued its work with Intel to
get the Clutter codebase free of copyright assignment (and that work has
since succeeded). It’s also particularly ironic that, a few months
later, Neary showed that the very company making that argument
contributes 22% less to the GNOME codebase than the volunteers
Silber once argued don’t contribute enough to warrant keeping their
copyrights.

So, why have Shuttleworth and his staff been on a year-long campaign to
convince everyone to embrace “Open Core” and give up all
their rights that copyleft provides? Well, in the same IRC log (at
15:15) I quoted above, Shuttleworth admits that he has some work
left to do to make Canonical, Ltd. profitable. And therein lies the
connection: Shuttleworth admits Canonical, Ltd.’s profitability is a
major goal (which is probably obvious). Then, in his next answer, he
explains at great length how lucrative and important “Open
Core” is. We should accept “Open Core”, Shuttleworth
argues, merely because it’s so important that Canonical, Ltd. be
profitable.

Shuttleworth’s argument reminds me of a story
that Michael Moore (who
famously made the
documentary Roger and Me
, and has since made other
documentaries) told at a book-signing in the mid-1990s. Moore said (I’m
paraphrasing from memory here, BTW):

Inevitably, I end up on planes next to some corporate executive. They
look at me a few times, and then say: Hey, I know you, you’re Roger
Moore [audience laughs]. What I want to know, is what the hell have you
got against profit? What’s wrong with profit, anyway? The
answer I give is simple: There’s nothing wrong with profit at all. The
question I’m raising is: What lengths are acceptable to achieve profit?
We all agree that we can’t exploit child labor and other such things, even
if that helps profitability. Yet, once upon a time, these sorts of
horrible policies were acceptable for corporations. So, my point is that
we still need more changes to balance the push for profit with what’s
right for workers.

I quote this at length to make it abundantly clear: I’m not opposed to
Canonical, Ltd. making a profit by supporting software freedom. I’m
glad that Shuttleworth has contributed a non-trivial part of his
personal wealth to start a company that employs many excellent
FLOSS
developers (and even sometimes lets those developers work on upstream
projects). But the question really is: Are the values of software
freedom worth giving up merely to make Canonical, Ltd. profitable?
Should we just accept
that proprietary
network services like UbuntuOne
, integrated on nearly every menu of
the desktop, as reasonable merely because it might help Canonical,
Ltd. make a few bucks? Do we think we should abandon copyleft’s
assurances of fair treatment to all, and hand over full
proprietarization powers on GPL’d software to for-profit companies,
merely so they can employ a few FLOSS developers to work primarily on
non-upstream projects?

I don’t think so. I’m often critical of Red Hat, but one thing they do
get right in this regard is a healthy encouragement of their developers
to start, contribute to, and maintain upstream projects that live in the
community rather than inside Red Hat. Red Hat currently allows its
engineers to keep their own copyrights and license them under whatever
license the upstream project uses, binding them to the terms of the
copyleft licenses (when the upstream project is copylefted). For
projects generated inside Red Hat,
after experimenting
with the sorts of CLAs that I’m complaining about
,
they learned
from the mistake and corrected it
(although
unfortunately, Red
Hat hasn’t universally corrected the problem
). For the most part,
Red Hat encourages outside contributors to give under their own
copyright under the outbound license Red Hat chose for its projects
(some of which are also copylefted). Red Hat’s newer policies have some
flaws (details of which are beyond the scope of this post), but it’s
orders of magnitude better than the copyright assignment intimidation
tactics that other companies, like Canonical, Ltd., now employ.

So, don’t let a friendly name like “Harmony” fool you.
Our community has some key infrastructure, such as the copyleft itself,
that
actually keeps us harmonious.
Contributor
agreements aren’t created equal
, and therefore we should oppose the
idea that contributor and assignment agreements should be set to the
lowest common denominator to enable a for-profit corporate land-grab
that Shuttleworth and other “Open Core” proponents seek.
I also strongly advise the organizations and individuals who are
assisting Canonical, Ltd. in this goal to stop immediately,
particularly now that Shuttleworth has announced his “Open
Core” plans.

Update (2010-10-18): In comments, many people have,
quite correctly, argued that I have not proved that Canonical,
Ltd. has plans to go “Open Core” with their
copyright-assigned copyleft products. Such comments are correct; I
intended this article to be an opinion piece, not a logical proof. I
further agree that without absolute proof, the title of
this blog post is an exaggeration. (I didn’t change it, as that seemed
disingenuous after the fact).

Anyway, to be clear, the only thing the chain of events described
above prove is that Canonical, Ltd. wants “Open
Core” as a possibility for the future. That part is
trivially true: if they didn’t want to reserve the possibility, they’d
simply make a promise-back to keep the software as Free Software in
their assignment. The only reason not to make an
FSF-style promise-back is that you want to reserve the
possibility of proprietary relicensing.

Meanwhile, even though I cannot construct a logical proof of it, I
still believe the only possible explanation for this 1+ year marketing
campaign described above is that Canonical, Ltd. is moving toward
“Open Core” for those projects on which they are the sole
copyright holder. I have asked others to offer alternative
explanations of why Canonical, Ltd. is carrying out this campaign: I
agree that there could exist another logical explanation other than the
one I’ve presented. If someone can come up with one, then I would be
happy to link to it here.

Finally, if Canonical, Ltd. comes out with a statement that they’ll
switch to using FSF’s promise-back in their assignments, I will be very
happy to admit I was wrong. The outcome I want is for individual
developers to be treated right by corporations in control of particular
codebases; I would much rather that happen than be correct in my
opinions.

0I
originally credited OMG Ubuntu
as publishing
Shutleworth’s comments as an interview
. Their reformatting
of his comments temporarily confused me, and I thought they’d
done an interview. Thanks
to @gotunandan who
pointed this out.

1Ironically, the
debate had nothing to do with a Canonical, Ltd. codebase, since their
contributions amount to so little (1%) of the GNOME codebase anyway.
The debate was about the Clutter/Intel situation, which has since been
resolved.

Responses Not In the Identica Thread:

Alex
Hudson’s blog post

Discussion on
Hacker News

LWN comments
Matt
Aslett’s response

and my
response to him
Ingolf
Schaefer’s blog post
, which only allows comments with a Google
Account, so I comment below instead (to be clear, I’m not criticizing
Ingolf’s choice of Google-account-to-comment, especially since I make
everyone who wants to comment here sign up for identi.ca ;):
Ingolf, you noted that you’d rather I not try to read between the lines
to deduce that proprietary relicensing and/or “Open Core” is
where Canonical, Ltd.’s marketing is leading. I disagree; I think it’s
useful to consider what seems a likely end-outcome here. My primary
goal is to draw attention to it now in hopes of preventing it from
happening. My best possible outcome is that I get proved wrong, and
Canonical makes a promise-back in their assignment and/or CLA.

Meanwhile, I don’t think they can go “Open Core”
and/or proprietary relicensing for all of Ubuntu, as you are saying.
They aren’t sole copyright holder in most of Ubuntu. The places where
they can pursue these options is in Launchpad, pbuilder, upstart, and
the other projects that require CLA and/or assignment.

I don’t know for sure that they’ll do this, as I say above. I can
deduce no other explanation. As I keep saying, if someone else has
another possible explanation for Canonical, Ltd.’s behavior that I list
above, I’m happy to link to it here. I can’t see any other reason;
they’d surely by now just made an FSF-style promise-back in their CLA if
they didn’t want to hold proprietarization as a possibility.

FOSS.in CFP Deadline Approaching!

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/foss-in-2010.html

I just submitted my paper[1] for FOSS.in 2010 in
Bangalore/India. Don’t forget to submit yours! The CFP closes on 10th of
October. That’s this Sunday! Hurry up, before it is too late!

FOSS.in is one of the most amazing Free Software conferences this world has
to offer (hey, and I think I can say that because I have presented at quite a few). A dedicated
audience, flawless organization, magic hospitality, and all this in incredible
India! Both the technical programme and everything around it are impressive. Which
other conference can offer you a concert of one of
India’s greatest acts
as part of the schedule? Which other international
conference host city can be such a positive attack on your senses as Bangalore (see
that endless sea of flowers below)? And where else do they serve pure silver as part of the conference catering?

Bangalore Market

Read the CFP! Or, go straight to submitting a paper.

Footnotes

[1] About systemd.

FOSS.in CFP Deadline Approaching!

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/foss-in-2010.html

I just submitted my paper[1] for FOSS.in 2010 in
Bangalore/India. Don’t forget to submit yours! The CFP closes on 10th of
October. That’s this Sunday! Hurry up, before it is too late!

FOSS.in is one of the most amazing Free Software conferences this world has
to offer (hey, and I think I can say that because I have presented at quite a few). A dedicated
audience, flawless organization, magic hospitality, and all this in incredible
India! Both the technical programme and everything around it are impressive. Which
other conference can offer you a concert of one of
India’s greatest acts
as part of the schedule? Which other international
conference host city can be such a positive attack on your senses as Bangalore (see
that endless sea of flowers below)? And where else do they serve pure silver as part of the conference catering?

Bangalore Market

Read the CFP! Or, go straight to submitting a paper.

Footnotes

[1] About systemd.

Conservancy’s First Blog Post

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/10/04/first-conservancy-post.html

[ Crossposted
from Conservancy’s
blog
. ]

As can be seen in
today’s
announcement
, today is my first day as full-time Executive Director
at the Software Freedom Conservancy. For four years, I have worked
part-time on nights, weekends, and lunch times to keep Conservancy
running and to implement and administer
the services
that Conservancy provides to
its member
projects
. It’s actual quite a relief to now have full-time
attention available to carry out this important work.

From the start, one of my goals with Conservancy has been to run the
non-profit organization as transparently as possible. At times, I’ve
found that when time is limited, keeping the public informed about all
your work is often the first item to fall too far down on the action
item list. Now that Conservancy is my primary, daily focus, I hope to
increase its transparency as much as possible.

Specifically, I plan to keep
a regular blog about activities
of the Conservancy
. I’ve found that a public blog is a particular
convenient way to report to the public in a non-onerous way about the
activities of an organization. Indeed, we usually ask those developers
whose work is funded through Conservancy to keep a blog about their
activities, so that the project’s community and the public at large can
get regular updates about the work. I should hold myself to no less a
standard!

I encourage everyone to subscribe to the
full Conservancy site
RSS feed
, where you’ll receive both news items and blog posts from
the Conservancy. There are also separate feeds available
for just news
and just blog posts.
Also, if you’re a subscriber to
my personal blog, I will
cross-post these blog posts there, although my posts on Conservancy’s
blog will certainly be a proper subset of my entire personal blog.

systemd for Administrators, Part III

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/systemd-for-admins-3.html

Here’s the third installment of my ongoing
series about
systemd
for administrators
.

How Do I Convert A SysV Init Script Into A systemd Service File?

Traditionally, Unix and Linux services (daemons) are started
via SysV init scripts. These are Bourne Shell scripts, usually
residing in a directory such as /etc/rc.d/init.d/ which when
called with one of a few standardized arguments (verbs) such as
start, stop or restart controls,
i.e. starts, stops or restarts the service in question. For starts
this usually involves invoking the daemon binary, which then forks a
background process (more precisely daemonizes). Shell scripts
tend to be slow, needlessly hard to read, very verbose and
fragile. Although they are immensly flexible (after all, they are just
code) some things are very hard to do properly with shell scripts,
such as ordering parallized execution, correctly supervising processes
or just configuring execution contexts in all detail. systemd provides
compatibility with these shell scripts, but due to the shortcomings
pointed out it is recommended to install native systemd service files
for all daemons installed. Also, in contrast to SysV init scripts
which have to be adjusted to the distribution systemd service files
are compatible with any kind of distribution running systemd (which
become more and more these days…). What follows is a terse guide how
to take a SysV init script and translate it into a native systemd
service file. Ideally, upstream projects should ship and install
systemd service files in their tarballs. If you have successfully
converted a SysV script according to the guidelines it might hence be
a good idea to submit the file as patch to upstream. How to prepare a
patch like that will be discussed in a later installment, suffice to
say at this point that the daemon(7)
manual page shipping with systemd contains a lot of useful information
regarding this.

So, let’s jump right in. As an example we’ll convert the init
script of the ABRT daemon into a systemd service file. ABRT is a
standard component of every Fedora install, and is an acronym for
Automatic Bug Reporting Tool, which pretty much describes what it
does, i.e. it is a service for collecting crash dumps. Its SysV script I have uploaded
here.

The first step when converting such a script is to read it
(surprise surprise!) and distill the useful information from the
usually pretty long script. In almost all cases the script consists of
mostly boilerplate code that is identical or at least very similar in
all init scripts, and usually copied and pasted from one to the
other. So, let’s extract the interesting information from the script
linked above:

A description string for the service is “Daemon to detect
crashing apps”. As it turns out, the header comments include a
redundant number of description strings, some of them describing less
the actual service but the init script to start it. systemd services
include a description too, and it should describe the service and not
the service file.

The LSB header[1] contains dependency
information. systemd due to its design around socket-based activation
usually needs no (or very little) manually configured
dependencies. (For details regarding socket activation see the original
announcement blog post.
) In this case the dependency on
$syslog (which encodes that abrtd requires a syslog daemon),
is the only valuable information. While the header lists another
dependency ($local_fs) this one is redundant with systemd as
normal system services are always started with all local file systems
available.

The LSB header suggests that this service should be started in
runlevels 3 (multi-user) and 5 (graphical).

The daemon binary is /usr/sbin/abrtd

And that’s already it. The entire remaining content of this
115-line shell script is simply boilerplate or otherwise redundant
code: code that deals with synchronizing and serializing startup
(i.e. the code regarding lock files) or that outputs status messages
(i.e. the code calling echo), or simply parsing of the verbs (i.e. the
big case block).

From the information extracted above we can now write our systemd service file:

[Unit]
Description=Daemon to detect crashing apps
After=syslog.target

[Service]
ExecStart=/usr/sbin/abrtd
Type=forking

[Install]
WantedBy=multi-user.target

A little explanation of the contents of this file: The
[Unit] section contains generic information about the
service. systemd not only manages system services, but also devices,
mount points, timer, and other components of the system. The generic
term for all these objects in systemd is a unit, and the
[Unit] section encodes information about it that might be
applicable not only to services but also in to the other unit types
systemd maintains. In this case we set the following unit settings: we
set the description string and configure that the daemon shall be
started after Syslog[2], similar to what is encoded in the
LSB header of the original init script. For this Syslog dependency we
create a dependency of type After= on a systemd unit
syslog.target. The latter is a special target unit in systemd
and is the standardized name to pull in a syslog implementation. For
more information about these standardized names see the systemd.special(7). Note
that a dependency of type After= only encodes the suggested
ordering, but does not actually cause syslog to be started when abrtd
is — and this is exactly what we want, since abrtd actually works
fine even without syslog being around. However, if both are started
(and usually they are) then the order in which they are is controlled
with this dependency.

The next section is [Service] which encodes information
about the service itself. It contains all those settings that apply
only to services, and not the other kinds of units systemd maintains
(mount points, devices, timers, …). Two settings are used here:
ExecStart= takes the path to the binary to execute when the
service shall be started up. And with Type= we configure how
the service notifies the init system that it finished starting up. Since
traditional Unix daemons do this by returning to the parent process
after having forked off and initialized the background daemon we set
the type to forking here. That tells systemd to wait until
the start-up binary returns and then consider the processes still
running afterwards the daemon processes.

The final section is [Install]. It encodes information
about how the suggested installation should look like, i.e. under
which circumstances and by which triggers the service shall be
started. In this case we simply say that this service shall be started
when the multi-user.target unit is activated. This is a
special unit (see above) that basically takes the role of the classic
SysV Runlevel 3[3]. The setting WantedBy= has
little effect on the daemon during runtime. It is only read by the
systemctl enable command, which is the recommended way to
enable a service in systemd. This command will simply ensure that our
little service gets automatically activated as soon as
multi-user.target is requested, which it is on all normal
boots[4].

And that’s it. Now we already have a minimal working systemd
service file. To test it we copy it to
/etc/systemd/system/abrtd.service and invoke systemctl
daemon-reload. This will make systemd take notice of it, and now
we can start the service with it: systemctl start
abrtd.service. We can verify the status via systemctl status
abrtd.service. And we can stop it again via systemctl stop
abrtd.service. Finally, we can enable it, so that it is activated
by default on future boots with systemctl enable
abrtd.service.

The service file above, while sufficient and basically a 1:1
translation (feature- and otherwise) of the SysV init script still has room for
improvement. Here it is a little bit updated:

[Unit]
Description=ABRT Automated Bug Reporting Tool
After=syslog.target

[Service]
Type=dbus
BusName=com.redhat.abrt
ExecStart=/usr/sbin/abrtd -d -s

[Install]
WantedBy=multi-user.target

So, what did we change? Two things: we improved the description
string a bit. More importantly however, we changed the type of the
service to dbus and configured the D-Bus bus name of the
service. Why did we do this? As mentioned classic SysV services
daemonize after startup, which usually involves double forking
and detaching from any terminal. While this is useful and necessary
when daemons are invoked via a script, this is unnecessary (and slow)
as well as counterproductive when a proper process babysitter such as
systemd is used. The reason for that is that the forked off daemon
process usually has little relation to the original process started by
systemd (after all the daemonizing scheme’s whole idea is to remove
this relation), and hence it is difficult for systemd to figure out
after the fork is finished which process belonging to the service is
actually the main process and which processes might just be
auxiliary. But that information is crucial to implement advanced
babysitting, i.e. supervising the process, automatic respawning on
abnormal termination, collectig crash and exit code information and
suchlike. In order to make it easier for systemd to figure out the
main process of the daemon we changed the service type to
dbus. The semantics of this service type are appropriate for
all services that take a name on the D-Bus system bus as last step of
their initialization[5]. ABRT is one of those. With this setting systemd
will spawn the ABRT process, which will no longer fork (this is
configured via the -d -s switches to the daemon), and systemd
will consider the service fully started up as soon as
com.redhat.abrt appears on the bus. This way the process
spawned by systemd is the main process of the daemon, systemd has a
reliable way to figure out when the daemon is fully started up and
systemd can easily supervise it.

And that’s all there is to it. We have a simple systemd service
file now that encodes in 10 lines more information than the original
SysV init script encoded in 115. And even now there’s a lot of room
left for further improvement utilizing more features systemd
offers. For example, we could set Restart=restart-always to
tell systemd to automatically restart this service when it dies. Or,
we could use OOMScoreAdjust=-500 to ask the kernel to please
leave this process around when the OOM killer wreaks havoc. Or, we
could use CPUSchedulingPolicy=idle to ensure that abrtd
processes crash dumps in background only, always allowing the kernel
to give preference to whatever else might be running and needing CPU
time.

For more information about the configuration options mentioned
here, see the respective man pages systemd.unit(5),
systemd.service(5),
systemd.exec(5). Or,
browse all of
systemd’s man pages
.

Of course, not all SysV scripts are as easy to convert as this
one. But gladly, as it turns out the vast majority actually are.

That’s it for today, come back soon for the next installment in our series.

Footnotes

[1] The LSB header of init scripts is a convention of
including meta data about the service in comment blocks at the top of
SysV init scripts and is
defined by the Linux Standard Base
. This was intended to
standardize init scripts between distributions. While most
distributions have adopted this scheme, the handling of the headers
varies greatly between the distributions, and in fact still makes it
necessary to adjust init scripts for every distribution. As such the LSB spec
never kept the promise it made.

[2] Strictly speaking, this dependency does not even have to
be encoded here, as it is redundant in a system where the Syslog
daemon is socket activatable. Modern syslog systems (for example
rsyslog v5) have been patched upstream to be socket-activatable. If
such a init system is used configuration of the
After=syslog.target dependency is redundant and
implicit. However, to maintain compatibility with syslog services that
have not been updated we include this dependency here.

[3] At least how it used to be defined on Fedora.

[4] Note that in systemd the graphical bootup
(graphical.target, taking the role of SysV runlevel 5) is an
implicit superset of the console-only bootup
(multi-user.target, i.e. like runlevel 3). That means hooking
a service into the latter will also hook it into the
former.

[5] Actually the majority of services of the default Fedora
install now take a name on the bus after startup.

systemd for Administrators, Part III

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/systemd-for-admins-3.html

Here’s the third installment of my ongoing
series about
systemd
for administrators
.

How Do I Convert A SysV Init Script Into A systemd Service File?

Traditionally, Unix and Linux services (daemons) are started
via SysV init scripts. These are Bourne Shell scripts, usually
residing in a directory such as /etc/rc.d/init.d/ which when
called with one of a few standardized arguments (verbs) such as
start, stop or restart controls,
i.e. starts, stops or restarts the service in question. For starts
this usually involves invoking the daemon binary, which then forks a
background process (more precisely daemonizes). Shell scripts
tend to be slow, needlessly hard to read, very verbose and
fragile. Although they are immensly flexible (after all, they are just
code) some things are very hard to do properly with shell scripts,
such as ordering parallized execution, correctly supervising processes
or just configuring execution contexts in all detail. systemd provides
compatibility with these shell scripts, but due to the shortcomings
pointed out it is recommended to install native systemd service files
for all daemons installed. Also, in contrast to SysV init scripts
which have to be adjusted to the distribution systemd service files
are compatible with any kind of distribution running systemd (which
become more and more these days…). What follows is a terse guide how
to take a SysV init script and translate it into a native systemd
service file. Ideally, upstream projects should ship and install
systemd service files in their tarballs. If you have successfully
converted a SysV script according to the guidelines it might hence be
a good idea to submit the file as patch to upstream. How to prepare a
patch like that will be discussed in a later installment, suffice to
say at this point that the daemon(7)
manual page shipping with systemd contains a lot of useful information
regarding this.

So, let’s jump right in. As an example we’ll convert the init
script of the ABRT daemon into a systemd service file. ABRT is a
standard component of every Fedora install, and is an acronym for
Automatic Bug Reporting Tool, which pretty much describes what it
does, i.e. it is a service for collecting crash dumps. Its SysV script I have uploaded
here.

The first step when converting such a script is to read it
(surprise surprise!) and distill the useful information from the
usually pretty long script. In almost all cases the script consists of
mostly boilerplate code that is identical or at least very similar in
all init scripts, and usually copied and pasted from one to the
other. So, let’s extract the interesting information from the script
linked above:

  • A description string for the service is “Daemon to detect
    crashing apps
    “. As it turns out, the header comments include a
    redundant number of description strings, some of them describing less
    the actual service but the init script to start it. systemd services
    include a description too, and it should describe the service and not
    the service file.
  • The LSB header[1] contains dependency
    information. systemd due to its design around socket-based activation
    usually needs no (or very little) manually configured
    dependencies. (For details regarding socket activation see the original
    announcement blog post.
    ) In this case the dependency on
    $syslog (which encodes that abrtd requires a syslog daemon),
    is the only valuable information. While the header lists another
    dependency ($local_fs) this one is redundant with systemd as
    normal system services are always started with all local file systems
    available.
  • The LSB header suggests that this service should be started in
    runlevels 3 (multi-user) and 5 (graphical).
  • The daemon binary is /usr/sbin/abrtd

And that’s already it. The entire remaining content of this
115-line shell script is simply boilerplate or otherwise redundant
code: code that deals with synchronizing and serializing startup
(i.e. the code regarding lock files) or that outputs status messages
(i.e. the code calling echo), or simply parsing of the verbs (i.e. the
big case block).

From the information extracted above we can now write our systemd service file:

[Unit]
Description=Daemon to detect crashing apps
After=syslog.target

[Service]
ExecStart=/usr/sbin/abrtd
Type=forking

[Install]
WantedBy=multi-user.target

A little explanation of the contents of this file: The
[Unit] section contains generic information about the
service. systemd not only manages system services, but also devices,
mount points, timer, and other components of the system. The generic
term for all these objects in systemd is a unit, and the
[Unit] section encodes information about it that might be
applicable not only to services but also in to the other unit types
systemd maintains. In this case we set the following unit settings: we
set the description string and configure that the daemon shall be
started after Syslog[2], similar to what is encoded in the
LSB header of the original init script. For this Syslog dependency we
create a dependency of type After= on a systemd unit
syslog.target. The latter is a special target unit in systemd
and is the standardized name to pull in a syslog implementation. For
more information about these standardized names see the systemd.special(7). Note
that a dependency of type After= only encodes the suggested
ordering, but does not actually cause syslog to be started when abrtd
is — and this is exactly what we want, since abrtd actually works
fine even without syslog being around. However, if both are started
(and usually they are) then the order in which they are is controlled
with this dependency.

The next section is [Service] which encodes information
about the service itself. It contains all those settings that apply
only to services, and not the other kinds of units systemd maintains
(mount points, devices, timers, …). Two settings are used here:
ExecStart= takes the path to the binary to execute when the
service shall be started up. And with Type= we configure how
the service notifies the init system that it finished starting up. Since
traditional Unix daemons do this by returning to the parent process
after having forked off and initialized the background daemon we set
the type to forking here. That tells systemd to wait until
the start-up binary returns and then consider the processes still
running afterwards the daemon processes.

The final section is [Install]. It encodes information
about how the suggested installation should look like, i.e. under
which circumstances and by which triggers the service shall be
started. In this case we simply say that this service shall be started
when the multi-user.target unit is activated. This is a
special unit (see above) that basically takes the role of the classic
SysV Runlevel 3[3]. The setting WantedBy= has
little effect on the daemon during runtime. It is only read by the
systemctl enable command, which is the recommended way to
enable a service in systemd. This command will simply ensure that our
little service gets automatically activated as soon as
multi-user.target is requested, which it is on all normal
boots[4].

And that’s it. Now we already have a minimal working systemd
service file. To test it we copy it to
/etc/systemd/system/abrtd.service and invoke systemctl
daemon-reload
. This will make systemd take notice of it, and now
we can start the service with it: systemctl start
abrtd.service
. We can verify the status via systemctl status
abrtd.service
. And we can stop it again via systemctl stop
abrtd.service
. Finally, we can enable it, so that it is activated
by default on future boots with systemctl enable
abrtd.service
.

The service file above, while sufficient and basically a 1:1
translation (feature- and otherwise) of the SysV init script still has room for
improvement. Here it is a little bit updated:

[Unit]
Description=ABRT Automated Bug Reporting Tool
After=syslog.target

[Service]
Type=dbus
BusName=com.redhat.abrt
ExecStart=/usr/sbin/abrtd -d -s

[Install]
WantedBy=multi-user.target

So, what did we change? Two things: we improved the description
string a bit. More importantly however, we changed the type of the
service to dbus and configured the D-Bus bus name of the
service. Why did we do this? As mentioned classic SysV services
daemonize after startup, which usually involves double forking
and detaching from any terminal. While this is useful and necessary
when daemons are invoked via a script, this is unnecessary (and slow)
as well as counterproductive when a proper process babysitter such as
systemd is used. The reason for that is that the forked off daemon
process usually has little relation to the original process started by
systemd (after all the daemonizing scheme’s whole idea is to remove
this relation), and hence it is difficult for systemd to figure out
after the fork is finished which process belonging to the service is
actually the main process and which processes might just be
auxiliary. But that information is crucial to implement advanced
babysitting, i.e. supervising the process, automatic respawning on
abnormal termination, collectig crash and exit code information and
suchlike. In order to make it easier for systemd to figure out the
main process of the daemon we changed the service type to
dbus. The semantics of this service type are appropriate for
all services that take a name on the D-Bus system bus as last step of
their initialization[5]. ABRT is one of those. With this setting systemd
will spawn the ABRT process, which will no longer fork (this is
configured via the -d -s switches to the daemon), and systemd
will consider the service fully started up as soon as
com.redhat.abrt appears on the bus. This way the process
spawned by systemd is the main process of the daemon, systemd has a
reliable way to figure out when the daemon is fully started up and
systemd can easily supervise it.

And that’s all there is to it. We have a simple systemd service
file now that encodes in 10 lines more information than the original
SysV init script encoded in 115. And even now there’s a lot of room
left for further improvement utilizing more features systemd
offers. For example, we could set Restart=restart-always to
tell systemd to automatically restart this service when it dies. Or,
we could use OOMScoreAdjust=-500 to ask the kernel to please
leave this process around when the OOM killer wreaks havoc. Or, we
could use CPUSchedulingPolicy=idle to ensure that abrtd
processes crash dumps in background only, always allowing the kernel
to give preference to whatever else might be running and needing CPU
time.

For more information about the configuration options mentioned
here, see the respective man pages systemd.unit(5),
systemd.service(5),
systemd.exec(5). Or,
browse all of
systemd’s man pages
.

Of course, not all SysV scripts are as easy to convert as this
one. But gladly, as it turns out the vast majority actually are.

That’s it for today, come back soon for the next installment in our series.

Footnotes

[1] The LSB header of init scripts is a convention of
including meta data about the service in comment blocks at the top of
SysV init scripts and is
defined by the Linux Standard Base
. This was intended to
standardize init scripts between distributions. While most
distributions have adopted this scheme, the handling of the headers
varies greatly between the distributions, and in fact still makes it
necessary to adjust init scripts for every distribution. As such the LSB spec
never kept the promise it made.

[2] Strictly speaking, this dependency does not even have to
be encoded here, as it is redundant in a system where the Syslog
daemon is socket activatable. Modern syslog systems (for example
rsyslog v5) have been patched upstream to be socket-activatable. If
such a init system is used configuration of the
After=syslog.target dependency is redundant and
implicit. However, to maintain compatibility with syslog services that
have not been updated we include this dependency here.

[3] At least how it used to be defined on Fedora.

[4] Note that in systemd the graphical bootup
(graphical.target, taking the role of SysV runlevel 5) is an
implicit superset of the console-only bootup
(multi-user.target, i.e. like runlevel 3). That means hooking
a service into the latter will also hook it into the
former.

[5] Actually the majority of services of the default Fedora
install now take a name on the bus after startup.

Leaving Last.fm

Post Syndicated from Laurie Denness original https://laur.ie/blog/2010/09/leaving-last-fm/

I’ve spent 3.43 years at Last.fm, which seems almost like a lifetime. For a long time, I couldn’t ever imagine leaving; every morning I would wake up excited to go and face new challenges and do fascinating new things. In the last 6-12 months so much has changed, as Last.fm gradually slips out of being a startup to being a company that, for better or for worse, has to make some money. I will certainly think twice before working for a company that has anything to do with the music industry… it’s a pain of a situation.

I’ve babysat the wonderful creation that is Last.fm through launches (both expected and unexpected), crashes (always unexpected), overheatings (and break-ins, and power failures… All the kind of thing that should never happen to a datacentre) and plenty of blood, sweat and tears.

It’s been an amazing experience, working with some of the most amazing people I have ever met (some of which have come and gone), but it’s time for me to help another startup through getting up at 4am to fix databases and exciting scaling questions.

And that will be Etsy; another website that has an awesome product that I love, plenty of traffic and graphs that point upwards and a bunch of guys who are passionate and have an awesome method of working. I’m really excited about getting involved and learning things again, as well as enabling a different group of passionate users go about their day to day business. I’ll still be in London, but popping to NY on occasion.

Let’s hope the next 3.43 years will be just as exciting.

Facebook Status and Burglaries

Post Syndicated from David original http://feedproxy.google.com/~r/DevilsAdvocateSecurity/~3/Df7UEQzf9yc/facebook-status-and-burglaries.html

WMUR in New Hampshire reports what is one of the first large-scale burglary cases based on Facebook status messages that I’m aware of. For those of us who need to communicate about Facebook and social network security concerns to varied populations, this is a great example to cite. According to the article, “Investigators said the suspects used social networking sites such as Facebook to identify victims who posted online that they would not be home at a certain time.”The article mentions $100,000-200,000 of stolen property that was recovered, and that the case was solved due to an officer who noticed that fireworks of the same brand reported stolen in a burglary were being shot off and investigated on orders to check out any fireworks they heard being fired.

_uacct = “UA-1423386-1”;
urchinTracker();

Facebook Status and Burglaries

Post Syndicated from David original http://feedproxy.google.com/~r/DevilsAdvocateSecurity/~3/Df7UEQzf9yc/facebook-status-and-burglaries.html

WMUR in New Hampshire reports what is one of the first large-scale burglary cases based on Facebook status messages that I’m aware of. For those of us who need to communicate about Facebook and social network security concerns to varied populations, this is a great example to cite. According to the article, “Investigators said the suspects used social networking sites such as Facebook to identify victims who posted online that they would not be home at a certain time.”The article mentions $100,000-200,000 of stolen property that was recovered, and that the case was solved due to an officer who noticed that fireworks of the same brand reported stolen in a burglary were being shot off and investigated on orders to check out any fireworks they heard being fired.

_uacct = “UA-1423386-1”;
urchinTracker();

A Different Angle on Identity Theft: When Identity Thieves Use Your Identity

Post Syndicated from David original http://feedproxy.google.com/~r/DevilsAdvocateSecurity/~3/v9K21jFvgs4/different-angle-on-identity-theft-when.html

The story of Dr. Gemma Meadows, as reported by MSNBC is an intriguing one. Like many victims of identity theft, she was contacted by her bank and informed of fraudulent activity. What happened next though, is a bit off the normal path for identity theft victims.Various packages with a wide range of values started to show up, and have continued to show up. Now, Dr. Meadows spends time tracking and returning packages, as well as fielding calls from various vendors from whom the items are ordered.Why? According to the article, and what she has been able to determine, the identity thieves are using her information to test validation scripts on e-commerce websites. Her valid address, phone, and other details are being used to make transactions appear valid.Interestingly, the scripts seem to work in some cases, flagging the transactions as possible fraudlent. The article mentions that some sites note that the item is to be shipped thousands of kilometers away from the order location, and that others call to verify that she is the one placing the order. Many others, however, don’t do as well, and the stream of packages continues.The article is well worth a read. We’re used to seeing lives disrupted by identity theft and the credit and financial issues that can go with it. Receiving packages when criminals use your identity to support their crimes in a different way is an entirely different event, and appears to be one that law enforcement and our database driven society isn’t geared to handle.

_uacct = “UA-1423386-1”;
urchinTracker();

A Different Angle on Identity Theft: When Identity Thieves Use Your Identity

Post Syndicated from David original http://feedproxy.google.com/~r/DevilsAdvocateSecurity/~3/v9K21jFvgs4/different-angle-on-identity-theft-when.html

The story of Dr. Gemma Meadows, as reported by MSNBC is an intriguing one. Like many victims of identity theft, she was contacted by her bank and informed of fraudulent activity. What happened next though, is a bit off the normal path for identity theft victims.Various packages with a wide range of values started to show up, and have continued to show up. Now, Dr. Meadows spends time tracking and returning packages, as well as fielding calls from various vendors from whom the items are ordered.Why? According to the article, and what she has been able to determine, the identity thieves are using her information to test validation scripts on e-commerce websites. Her valid address, phone, and other details are being used to make transactions appear valid.Interestingly, the scripts seem to work in some cases, flagging the transactions as possible fraudlent. The article mentions that some sites note that the item is to be shipped thousands of kilometers away from the order location, and that others call to verify that she is the one placing the order. Many others, however, don’t do as well, and the stream of packages continues.The article is well worth a read. We’re used to seeing lives disrupted by identity theft and the credit and financial issues that can go with it. Receiving packages when criminals use your identity to support their crimes in a different way is an entirely different event, and appears to be one that law enforcement and our database driven society isn’t geared to handle.

_uacct = “UA-1423386-1”;
urchinTracker();

Two Thank-Yous

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/09/11/two-thank-yous.html

I’m well known for being critical when necessary about what happens in
the software freedom community, but occasionally, there’s nothing to do
but thank someone, particularly when they’ve done something I asked
for. 🙂

First, I’d like to
thank Matthew Garrett
for engaging in some
GPL enforcement
(as
covered on lwn.net
). He’s taking an interesting tack of filing a
complaint with US Customs. I’ve thought about this method in the past,
but never really felt I wanted to go that route (mainly because I’m more
familiar with the traditional GPL enforcement processes). However, it’s
really important that we try lots of different strategies for GPL
enforcement; the path to success is often many methods in parallel. It
looks like
Matthew already
got the attention of the violator
. In the end, every GPL
enforcement strategy is primarily to get the violator’s attention so
they take the issue seriously and come into compliance with the
license.

I’ve written
before about how GPL enforcement can be a lonely place
, and when I
see someone get serious about doing some — as Matthew has in the
last year or so — it makes GPL enforcement a lot less lonely. I
still think I can count on my hands all the people active regularly in
GPL enforcement efforts, but I am glad to see that’s changing. The
license
stands
for a principle
, and we should defend it, despite the great length
the corporate powers in the software freedom world go to in trying to
stop GPL enforcement.

Secondly, I need to thank my
colleague Chris
DiBona
. Two years
ago, I
gave him quite a hard time
that Google prohibited hosting
of AGPLv3‘d
projects on its FLOSS Project
Hosting site
. The interesting part of our debate was that Chris
argued
that license
proliferation
was the reason to prohibit AGPLv3. I argued at the
time that Google simply opposed AGPLv3 because many parts of Google’s
business model rely on the fact that the GPL behaves in practice
somewhat like permissive licenses when deployed in a web services
environment.

Honestly, I never had definitive proof at Google’s “real
reasons” for holding the policy it did for two years, but it
doesn’t matter now, because
yesterday Chris
announced that Google Code Hosting now accepts AGPLv3’d
projects
0. I really
appreciate Chris’ friendly words on AGPLv3, noting that he didn’t
like turning away projects under licenses that serve a truly new
function, like the AGPL.

Google will now accept projects under any license that is
on OSI’s approved
list
. I think this is a reasonable outcome. I firmly believe that
acceptable license lists must be the purview of not-for-profit
organizations, not for-profit ones. Personally, I tend to avoid and
distrust any license that fails to appear on both OSI’s
list and
the FSF
Free Software License List
. While I obviously favor the FSF list
myself
(having
helped originate it
), I generally want to see a license on both
lists before I’m ready to say for sure there are no worries about
it.

There are two other entities that maintain license lists,
namely the Debian
Project
and
Red Hat’s Fedora
Project
. I wouldn’t say that I find Debian’s list definitive,
mainly because, despite Debian’s generally democratic slant, the
ftp-masters hold a bit too
much power in interpreting
the DFSG.

As for Fedora, that’s ultimately a project controlled by a for-profit
corporation (Red Hat), and therefore I have some trepidation about
trusting their list, just as I had concerns that Google attempted to set
licensing policy by defining an acceptable license list. As it stands
at the moment, I trust Fedora’s list because I know
that Spot
and Fontana
currently have the ultimate say on what does or does not go onto
Fedora’s list. Nevertheless, Red Hat is ultimately in control of
Fedora, so I think its license list can’t be relied on indefinitely
(e.g., in case Spot and/or Fontana ever leave Red Hat at some
point.)

Anyway, I think the best outcome for the community is for
the logical
conjunction
of the OSI’s list and the FSF’s list to be considered
the accepted list of licenses. While I often disagree with the OSI, I
think it’s in the best interest of the community to require that two
distinct non-profits with different missions both
approve a license before it’s considered acceptable. (I suppose I’d
have a different view if OSI had
not accepted
the AGPLv3
, though. 😉

0I must point out
that Chris has an error
in his
blog post
: namely, FSF’s Code
hosting site, Savannah
accepts not
just GPL‘d
projects, but any project that is listed as
“GPL-Compatible” on FSF’s Free Software License List
.

systemd for Administrators, Part II

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/systemd-for-admins-2.html

Here’s the second installment of my ongoing series about systemd for administrators.

Which Service Owns Which Processes?

On most Linux systems the number of processes that are running by
default is substantial. Knowing which process does what and where it
belongs to becomes increasingly difficult. Some services even maintain
a couple of worker processes which clutter the “ps” output with
many additional processes that are often not easy to recognize. This is
further complicated if daemons spawn arbitrary 3rd-party processes, as
Apache does with CGI processes, or cron does with user jobs.

A slight remedy for this is often the process inheritance tree, as
shown by “ps xaf”. However this is usually not reliable, as processes
whose parents die get reparented to PID 1, and hence all information
about inheritance gets lost. If a process “double forks” it hence loses
its relationships to the processes that started it. (This actually is
supposed to be a feature and is relied on for the traditional Unix
daemonizing logic.) Furthermore processes can freely change their names
with PR_SETNAME or by patching argv[0], thus making
it harder to recognize them. In fact they can play hide-and-seek with
the administrator pretty nicely this way.

In systemd we place every process that is spawned in a control
group named after its service. Control groups (or cgroups)
at their most basic are simply groups of processes that can be
arranged in a hierarchy and labelled individually. When processes
spawn other processes these children are automatically made members of
the parents cgroup. Leaving a cgroup is not possible for unprivileged
processes. Thus, cgroups can be used as an effective way to label
processes after the service they belong to and be sure that the
service cannot escape from the label, regardless how often it forks or
renames itself. Furthermore this can be used to safely kill a service
and all processes it created, again with no chance of escaping.

In today’s installment I want to introduce you to two commands you
may use to relate systemd services and processes. The first one, is
the well known ps command which has been updated to show
cgroup information along the other process details. And this is how it
looks:

$ ps xawf -eo pid,user,cgroup,args
PID USER CGROUP COMMAND
2 root – [kthreadd]
3 root – _ [ksoftirqd/0]
[…]
4281 root – _ [flush-8:0]
1 root name=systemd:/systemd-1 /sbin/init
455 root name=systemd:/systemd-1/sysinit.service /sbin/udevd -d
28188 root name=systemd:/systemd-1/sysinit.service _ /sbin/udevd -d
28191 root name=systemd:/systemd-1/sysinit.service _ /sbin/udevd -d
1096 dbus name=systemd:/systemd-1/dbus.service /bin/dbus-daemon –system –address=systemd: –nofork –systemd-activation
1131 root name=systemd:/systemd-1/auditd.service auditd
1133 root name=systemd:/systemd-1/auditd.service _ /sbin/audispd
1135 root name=systemd:/systemd-1/auditd.service _ /usr/sbin/sedispatch
1171 root name=systemd:/systemd-1/NetworkManager.service /usr/sbin/NetworkManager –no-daemon
4028 root name=systemd:/systemd-1/NetworkManager.service _ /sbin/dhclient -d -4 -sf /usr/libexec/nm-dhcp-client.action -pf /var/run/dhclient-wlan0.pid -lf /var/lib/dhclient/dhclient-7d32a784-ede9-4cf6-9ee3-60edc0bce5ff-wlan0.lease –
1175 avahi name=systemd:/systemd-1/avahi-daemon.service avahi-daemon: running [epsilon.local]
1194 avahi name=systemd:/systemd-1/avahi-daemon.service _ avahi-daemon: chroot helper
1193 root name=systemd:/systemd-1/rsyslog.service /sbin/rsyslogd -c 4
1195 root name=systemd:/systemd-1/cups.service cupsd -C /etc/cups/cupsd.conf
1207 root name=systemd:/systemd-1/mdmonitor.service mdadm –monitor –scan -f –pid-file=/var/run/mdadm/mdadm.pid
1210 root name=systemd:/systemd-1/irqbalance.service irqbalance
1216 root name=systemd:/systemd-1/dbus.service /usr/sbin/modem-manager
1219 root name=systemd:/systemd-1/dbus.service /usr/libexec/polkit-1/polkitd
1242 root name=systemd:/systemd-1/dbus.service /usr/sbin/wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -B -u -f /var/log/wpa_supplicant.log -P /var/run/wpa_supplicant.pid
1249 68 name=systemd:/systemd-1/haldaemon.service hald
1250 root name=systemd:/systemd-1/haldaemon.service _ hald-runner
1273 root name=systemd:/systemd-1/haldaemon.service _ hald-addon-input: Listening on /dev/input/event3 /dev/input/event9 /dev/input/event1 /dev/input/event7 /dev/input/event2 /dev/input/event0 /dev/input/event8
1275 root name=systemd:/systemd-1/haldaemon.service _ /usr/libexec/hald-addon-rfkill-killswitch
1284 root name=systemd:/systemd-1/haldaemon.service _ /usr/libexec/hald-addon-leds
1285 root name=systemd:/systemd-1/haldaemon.service _ /usr/libexec/hald-addon-generic-backlight
1287 68 name=systemd:/systemd-1/haldaemon.service _ /usr/libexec/hald-addon-acpi
1317 root name=systemd:/systemd-1/abrtd.service /usr/sbin/abrtd -d -s
1332 root name=systemd:/systemd-1/[email protected]/tty2 /sbin/mingetty tty2
1339 root name=systemd:/systemd-1/[email protected]/tty3 /sbin/mingetty tty3
1342 root name=systemd:/systemd-1/[email protected]/tty5 /sbin/mingetty tty5
1343 root name=systemd:/systemd-1/[email protected]/tty4 /sbin/mingetty tty4
1344 root name=systemd:/systemd-1/crond.service crond
1346 root name=systemd:/systemd-1/[email protected]/tty6 /sbin/mingetty tty6
1362 root name=systemd:/systemd-1/sshd.service /usr/sbin/sshd
1376 root name=systemd:/systemd-1/prefdm.service /usr/sbin/gdm-binary -nodaemon
1391 root name=systemd:/systemd-1/prefdm.service _ /usr/libexec/gdm-simple-slave –display-id /org/gnome/DisplayManager/Display1 –force-active-vt
1394 root name=systemd:/systemd-1/prefdm.service _ /usr/bin/Xorg :0 -nr -verbose -auth /var/run/gdm/auth-for-gdm-f2KUOh/database -nolisten tcp vt1
1495 root name=systemd:/user/lennart/1 _ pam: gdm-password
1521 lennart name=systemd:/user/lennart/1 _ gnome-session
1621 lennart name=systemd:/user/lennart/1 _ metacity
1635 lennart name=systemd:/user/lennart/1 _ gnome-panel
1638 lennart name=systemd:/user/lennart/1 _ nautilus
1640 lennart name=systemd:/user/lennart/1 _ /usr/libexec/polkit-gnome-authentication-agent-1
1641 lennart name=systemd:/user/lennart/1 _ /usr/bin/seapplet
1644 lennart name=systemd:/user/lennart/1 _ gnome-volume-control-applet
1646 lennart name=systemd:/user/lennart/1 _ /usr/sbin/restorecond -u
1652 lennart name=systemd:/user/lennart/1 _ /usr/bin/devilspie
1662 lennart name=systemd:/user/lennart/1 _ nm-applet –sm-disable
1664 lennart name=systemd:/user/lennart/1 _ gnome-power-manager
1665 lennart name=systemd:/user/lennart/1 _ /usr/libexec/gdu-notification-daemon
1670 lennart name=systemd:/user/lennart/1 _ /usr/libexec/evolution/2.32/evolution-alarm-notify
1672 lennart name=systemd:/user/lennart/1 _ /usr/bin/python /usr/share/system-config-printer/applet.py
1674 lennart name=systemd:/user/lennart/1 _ /usr/lib64/deja-dup/deja-dup-monitor
1675 lennart name=systemd:/user/lennart/1 _ abrt-applet
1677 lennart name=systemd:/user/lennart/1 _ bluetooth-applet
1678 lennart name=systemd:/user/lennart/1 _ gpk-update-icon
1408 root name=systemd:/systemd-1/console-kit-daemon.service /usr/sbin/console-kit-daemon –no-daemon
1419 gdm name=systemd:/systemd-1/prefdm.service /usr/bin/dbus-launch –exit-with-session
1453 root name=systemd:/systemd-1/dbus.service /usr/libexec/upowerd
1473 rtkit name=systemd:/systemd-1/rtkit-daemon.service /usr/libexec/rtkit-daemon
1496 root name=systemd:/systemd-1/accounts-daemon.service /usr/libexec/accounts-daemon
1499 root name=systemd:/systemd-1/systemd-logger.service /lib/systemd/systemd-logger
1511 lennart name=systemd:/systemd-1/prefdm.service /usr/bin/gnome-keyring-daemon –daemonize –login
1534 lennart name=systemd:/user/lennart/1 dbus-launch –sh-syntax –exit-with-session
1535 lennart name=systemd:/user/lennart/1 /bin/dbus-daemon –fork –print-pid 5 –print-address 7 –session
1603 lennart name=systemd:/user/lennart/1 /usr/libexec/gconfd-2
1612 lennart name=systemd:/user/lennart/1 /usr/libexec/gnome-settings-daemon
1615 lennart name=systemd:/user/lennart/1 /usr/libexec/gvfsd
1626 lennart name=systemd:/user/lennart/1 /usr/libexec//gvfs-fuse-daemon /home/lennart/.gvfs
1634 lennart name=systemd:/user/lennart/1 /usr/bin/pulseaudio –start –log-target=syslog
1649 lennart name=systemd:/user/lennart/1 _ /usr/libexec/pulse/gconf-helper
1645 lennart name=systemd:/user/lennart/1 /usr/libexec/bonobo-activation-server –ac-activate –ior-output-fd=24
1668 lennart name=systemd:/user/lennart/1 /usr/libexec/im-settings-daemon
1701 lennart name=systemd:/user/lennart/1 /usr/libexec/gvfs-gdu-volume-monitor
1707 lennart name=systemd:/user/lennart/1 /usr/bin/gnote –panel-applet –oaf-activate-iid=OAFIID:GnoteApplet_Factory –oaf-ior-fd=22
1725 lennart name=systemd:/user/lennart/1 /usr/libexec/clock-applet
1727 lennart name=systemd:/user/lennart/1 /usr/libexec/wnck-applet
1729 lennart name=systemd:/user/lennart/1 /usr/libexec/notification-area-applet
1733 root name=systemd:/systemd-1/dbus.service /usr/libexec/udisks-daemon
1747 root name=systemd:/systemd-1/dbus.service _ udisks-daemon: polling /dev/sr0
1759 lennart name=systemd:/user/lennart/1 gnome-screensaver
1780 lennart name=systemd:/user/lennart/1 /usr/libexec/gvfsd-trash –spawner :1.9 /org/gtk/gvfs/exec_spaw/0
1864 lennart name=systemd:/user/lennart/1 /usr/libexec/gvfs-afc-volume-monitor
1874 lennart name=systemd:/user/lennart/1 /usr/libexec/gconf-im-settings-daemon
1903 lennart name=systemd:/user/lennart/1 /usr/libexec/gvfsd-burn –spawner :1.9 /org/gtk/gvfs/exec_spaw/1
1909 lennart name=systemd:/user/lennart/1 gnome-terminal
1913 lennart name=systemd:/user/lennart/1 _ gnome-pty-helper
1914 lennart name=systemd:/user/lennart/1 _ bash
29231 lennart name=systemd:/user/lennart/1 | _ ssh tango
2221 lennart name=systemd:/user/lennart/1 _ bash
4193 lennart name=systemd:/user/lennart/1 | _ ssh tango
2461 lennart name=systemd:/user/lennart/1 _ bash
29219 lennart name=systemd:/user/lennart/1 | _ emacs systemd-for-admins-1.txt
15113 lennart name=systemd:/user/lennart/1 _ bash
27251 lennart name=systemd:/user/lennart/1 _ empathy
29504 lennart name=systemd:/user/lennart/1 _ ps xawf -eo pid,user,cgroup,args
1968 lennart name=systemd:/user/lennart/1 ssh-agent
1994 lennart name=systemd:/user/lennart/1 gpg-agent –daemon –write-env-file
18679 lennart name=systemd:/user/lennart/1 /bin/sh /usr/lib64/firefox-3.6/run-mozilla.sh /usr/lib64/firefox-3.6/firefox
18741 lennart name=systemd:/user/lennart/1 _ /usr/lib64/firefox-3.6/firefox
28900 lennart name=systemd:/user/lennart/1 _ /usr/lib64/nspluginwrapper/npviewer.bin –plugin /usr/lib64/mozilla/plugins/libflashplayer.so –connection /org/wrapper/NSPlugins/libflashplayer.so/18741-6
4016 root name=systemd:/systemd-1/sysinit.service /usr/sbin/bluetoothd –udev
4094 smmsp name=systemd:/systemd-1/sendmail.service sendmail: Queue [email protected]:00:00 for /var/spool/clientmqueue
4096 root name=systemd:/systemd-1/sendmail.service sendmail: accepting connections
4112 ntp name=systemd:/systemd-1/ntpd.service /usr/sbin/ntpd -n -u ntp:ntp -g
27262 lennart name=systemd:/user/lennart/1 /usr/libexec/mission-control-5
27265 lennart name=systemd:/user/lennart/1 /usr/libexec/telepathy-haze
27268 lennart name=systemd:/user/lennart/1 /usr/libexec/telepathy-logger
27270 lennart name=systemd:/user/lennart/1 /usr/libexec/dconf-service
27280 lennart name=systemd:/user/lennart/1 /usr/libexec/notification-daemon
27284 lennart name=systemd:/user/lennart/1 /usr/libexec/telepathy-gabble
27285 lennart name=systemd:/user/lennart/1 /usr/libexec/telepathy-salut
27297 lennart name=systemd:/user/lennart/1 /usr/libexec/geoclue-yahoo

(Note that this output is shortened, I have removed most of the
kernel threads here, since they are not relevant in the context of
this blog story)

In the third column you see the cgroup systemd assigned to each
process. You’ll find that the udev processes are in the
name=systemd:/systemd-1/sysinit.service cgroup, which is
where systemd places all processes started by the
sysinit.service service, which covers early boot.

My personal recommendation is to set the shell alias psc
to the ps command line shown above:

alias psc=’ps xawf -eo pid,user,cgroup,args’

With this service information of processes is just four keypresses
away!

A different way to present the same information is the
systemd-cgls tool we ship with systemd. It shows the cgroup
hierarchy in a pretty tree. Its output looks like this:

$ systemd-cgls
+ 2 [kthreadd]
[…]
+ 4281 [flush-8:0]
+ user
| lennart
| 1
| + 1495 pam: gdm-password
| + 1521 gnome-session
| + 1534 dbus-launch –sh-syntax –exit-with-session
| + 1535 /bin/dbus-daemon –fork –print-pid 5 –print-address 7 –session
| + 1603 /usr/libexec/gconfd-2
| + 1612 /usr/libexec/gnome-settings-daemon
| + 1615 /ushr/libexec/gvfsd
| + 1621 metacity
| + 1626 /usr/libexec//gvfs-fuse-daemon /home/lennart/.gvfs
| + 1634 /usr/bin/pulseaudio –start –log-target=syslog
| + 1635 gnome-panel
| + 1638 nautilus
| + 1640 /usr/libexec/polkit-gnome-authentication-agent-1
| + 1641 /usr/bin/seapplet
| + 1644 gnome-volume-control-applet
| + 1645 /usr/libexec/bonobo-activation-server –ac-activate –ior-output-fd=24
| + 1646 /usr/sbin/restorecond -u
| + 1649 /usr/libexec/pulse/gconf-helper
| + 1652 /usr/bin/devilspie
| + 1662 nm-applet –sm-disable
| + 1664 gnome-power-manager
| + 1665 /usr/libexec/gdu-notification-daemon
| + 1668 /usr/libexec/im-settings-daemon
| + 1670 /usr/libexec/evolution/2.32/evolution-alarm-notify
| + 1672 /usr/bin/python /usr/share/system-config-printer/applet.py
| + 1674 /usr/lib64/deja-dup/deja-dup-monitor
| + 1675 abrt-applet
| + 1677 bluetooth-applet
| + 1678 gpk-update-icon
| + 1701 /usr/libexec/gvfs-gdu-volume-monitor
| + 1707 /usr/bin/gnote –panel-applet –oaf-activate-iid=OAFIID:GnoteApplet_Factory –oaf-ior-fd=22
| + 1725 /usr/libexec/clock-applet
| + 1727 /usr/libexec/wnck-applet
| + 1729 /usr/libexec/notification-area-applet
| + 1759 gnome-screensaver
| + 1780 /usr/libexec/gvfsd-trash –spawner :1.9 /org/gtk/gvfs/exec_spaw/0
| + 1864 /usr/libexec/gvfs-afc-volume-monitor
| + 1874 /usr/libexec/gconf-im-settings-daemon
| + 1882 /usr/libexec/gvfs-gphoto2-volume-monitor
| + 1903 /usr/libexec/gvfsd-burn –spawner :1.9 /org/gtk/gvfs/exec_spaw/1
| + 1909 gnome-terminal
| + 1913 gnome-pty-helper
| + 1914 bash
| + 1968 ssh-agent
| + 1994 gpg-agent –daemon –write-env-file
| + 2221 bash
| + 2461 bash
| + 4193 ssh tango
| + 15113 bash
| + 18679 /bin/sh /usr/lib64/firefox-3.6/run-mozilla.sh /usr/lib64/firefox-3.6/firefox
| + 18741 /usr/lib64/firefox-3.6/firefox
| + 27251 empathy
| + 27262 /usr/libexec/mission-control-5
| + 27265 /usr/libexec/telepathy-haze
| + 27268 /usr/libexec/telepathy-logger
| + 27270 /usr/libexec/dconf-service
| + 27280 /usr/libexec/notification-daemon
| + 27284 /usr/libexec/telepathy-gabble
| + 27285 /usr/libexec/telepathy-salut
| + 27297 /usr/libexec/geoclue-yahoo
| + 28900 /usr/lib64/nspluginwrapper/npviewer.bin –plugin /usr/lib64/mozilla/plugins/libflashplayer.so –connection /org/wrapper/NSPlugins/libflashplayer.so/18741-6
| + 29219 emacs systemd-for-admins-1.txt
| + 29231 ssh tango
| 29519 systemd-cgls
systemd-1
+ 1 /sbin/init
+ ntpd.service
| 4112 /usr/sbin/ntpd -n -u ntp:ntp -g
+ systemd-logger.service
| 1499 /lib/systemd/systemd-logger
+ accounts-daemon.service
| 1496 /usr/libexec/accounts-daemon
+ rtkit-daemon.service
| 1473 /usr/libexec/rtkit-daemon
+ console-kit-daemon.service
| 1408 /usr/sbin/console-kit-daemon –no-daemon
+ prefdm.service
| + 1376 /usr/sbin/gdm-binary -nodaemon
| + 1391 /usr/libexec/gdm-simple-slave –display-id /org/gnome/DisplayManager/Display1 –force-active-vt
| + 1394 /usr/bin/Xorg :0 -nr -verbose -auth /var/run/gdm/auth-for-gdm-f2KUOh/database -nolisten tcp vt1
| + 1419 /usr/bin/dbus-launch –exit-with-session
| 1511 /usr/bin/gnome-keyring-daemon –daemonize –login
+ [email protected]
| + tty6
| | 1346 /sbin/mingetty tty6
| + tty4
| | 1343 /sbin/mingetty tty4
| + tty5
| | 1342 /sbin/mingetty tty5
| + tty3
| | 1339 /sbin/mingetty tty3
| tty2
| 1332 /sbin/mingetty tty2
+ abrtd.service
| 1317 /usr/sbin/abrtd -d -s
+ crond.service
| 1344 crond
+ sshd.service
| 1362 /usr/sbin/sshd
+ sendmail.service
| + 4094 sendmail: Queue [email protected]:00:00 for /var/spool/clientmqueue
| 4096 sendmail: accepting connections
+ haldaemon.service
| + 1249 hald
| + 1250 hald-runner
| + 1273 hald-addon-input: Listening on /dev/input/event3 /dev/input/event9 /dev/input/event1 /dev/input/event7 /dev/input/event2 /dev/input/event0 /dev/input/event8
| + 1275 /usr/libexec/hald-addon-rfkill-killswitch
| + 1284 /usr/libexec/hald-addon-leds
| + 1285 /usr/libexec/hald-addon-generic-backlight
| 1287 /usr/libexec/hald-addon-acpi
+ irqbalance.service
| 1210 irqbalance
+ avahi-daemon.service
| + 1175 avahi-daemon: running [epsilon.local]
+ NetworkManager.service
| + 1171 /usr/sbin/NetworkManager –no-daemon
| 4028 /sbin/dhclient -d -4 -sf /usr/libexec/nm-dhcp-client.action -pf /var/run/dhclient-wlan0.pid -lf /var/lib/dhclient/dhclient-7d32a784-ede9-4cf6-9ee3-60edc0bce5ff-wlan0.lease -cf /var/run/nm-dhclient-wlan0.conf wlan0
+ rsyslog.service
| 1193 /sbin/rsyslogd -c 4
+ mdmonitor.service
| 1207 mdadm –monitor –scan -f –pid-file=/var/run/mdadm/mdadm.pid
+ cups.service
| 1195 cupsd -C /etc/cups/cupsd.conf
+ auditd.service
| + 1131 auditd
| + 1133 /sbin/audispd
| 1135 /usr/sbin/sedispatch
+ dbus.service
| + 1096 /bin/dbus-daemon –system –address=systemd: –nofork –systemd-activation
| + 1216 /usr/sbin/modem-manager
| + 1219 /usr/libexec/polkit-1/polkitd
| + 1242 /usr/sbin/wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -B -u -f /var/log/wpa_supplicant.log -P /var/run/wpa_supplicant.pid
| + 1453 /usr/libexec/upowerd
| + 1733 /usr/libexec/udisks-daemon
| + 1747 udisks-daemon: polling /dev/sr0
| 29509 /usr/libexec/packagekitd
+ dev-mqueue.mount
+ dev-hugepages.mount
sysinit.service
+ 455 /sbin/udevd -d
+ 4016 /usr/sbin/bluetoothd –udev
+ 28188 /sbin/udevd -d
28191 /sbin/udevd -d

(This too is shortened, the same way)

As you can see, this command shows the processes by their cgroup
and hence service, as systemd labels the cgroups after the
services. For example, you can easily see that the auditing service
auditd.service spawns three individual processes,
auditd, audisp and sedispatch.

If you look closely you will notice that a number of processes have
been assigned to the cgroup /user/1. At this point let’s
simply leave it at that systemd not only maintains services in cgroups,
but user session processes as well. In a later installment we’ll discuss in
more detail what this about.

So much for now, come back soon for the next installment!

systemd for Administrators, Part II

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/systemd-for-admins-2.html

Here’s the second installment of my ongoing series about systemd for administrators.

Which Service Owns Which Processes?

On most Linux systems the number of processes that are running by
default is substantial. Knowing which process does what and where it
belongs to becomes increasingly difficult. Some services even maintain
a couple of worker processes which clutter the “ps” output with
many additional processes that are often not easy to recognize. This is
further complicated if daemons spawn arbitrary 3rd-party processes, as
Apache does with CGI processes, or cron does with user jobs.

A slight remedy for this is often the process inheritance tree, as
shown by “ps xaf“. However this is usually not reliable, as processes
whose parents die get reparented to PID 1, and hence all information
about inheritance gets lost. If a process “double forks” it hence loses
its relationships to the processes that started it. (This actually is
supposed to be a feature and is relied on for the traditional Unix
daemonizing logic.) Furthermore processes can freely change their names
with PR_SETNAME or by patching argv[0], thus making
it harder to recognize them. In fact they can play hide-and-seek with
the administrator pretty nicely this way.

In systemd we place every process that is spawned in a control
group
named after its service. Control groups (or cgroups)
at their most basic are simply groups of processes that can be
arranged in a hierarchy and labelled individually. When processes
spawn other processes these children are automatically made members of
the parents cgroup. Leaving a cgroup is not possible for unprivileged
processes. Thus, cgroups can be used as an effective way to label
processes after the service they belong to and be sure that the
service cannot escape from the label, regardless how often it forks or
renames itself. Furthermore this can be used to safely kill a service
and all processes it created, again with no chance of escaping.

In today’s installment I want to introduce you to two commands you
may use to relate systemd services and processes. The first one, is
the well known ps command which has been updated to show
cgroup information along the other process details. And this is how it
looks:

$ ps xawf -eo pid,user,cgroup,args
  PID USER     CGROUP                              COMMAND
    2 root     -                                   [kthreadd]
    3 root     -                                    \_ [ksoftirqd/0]
[...]
 4281 root     -                                    \_ [flush-8:0]
    1 root     name=systemd:/systemd-1             /sbin/init
  455 root     name=systemd:/systemd-1/sysinit.service /sbin/udevd -d
28188 root     name=systemd:/systemd-1/sysinit.service  \_ /sbin/udevd -d
28191 root     name=systemd:/systemd-1/sysinit.service  \_ /sbin/udevd -d
 1096 dbus     name=systemd:/systemd-1/dbus.service /bin/dbus-daemon --system --address=systemd: --nofork --systemd-activation
 1131 root     name=systemd:/systemd-1/auditd.service auditd
 1133 root     name=systemd:/systemd-1/auditd.service  \_ /sbin/audispd
 1135 root     name=systemd:/systemd-1/auditd.service      \_ /usr/sbin/sedispatch
 1171 root     name=systemd:/systemd-1/NetworkManager.service /usr/sbin/NetworkManager --no-daemon
 4028 root     name=systemd:/systemd-1/NetworkManager.service  \_ /sbin/dhclient -d -4 -sf /usr/libexec/nm-dhcp-client.action -pf /var/run/dhclient-wlan0.pid -lf /var/lib/dhclient/dhclient-7d32a784-ede9-4cf6-9ee3-60edc0bce5ff-wlan0.lease -
 1175 avahi    name=systemd:/systemd-1/avahi-daemon.service avahi-daemon: running [epsilon.local]
 1194 avahi    name=systemd:/systemd-1/avahi-daemon.service  \_ avahi-daemon: chroot helper
 1193 root     name=systemd:/systemd-1/rsyslog.service /sbin/rsyslogd -c 4
 1195 root     name=systemd:/systemd-1/cups.service cupsd -C /etc/cups/cupsd.conf
 1207 root     name=systemd:/systemd-1/mdmonitor.service mdadm --monitor --scan -f --pid-file=/var/run/mdadm/mdadm.pid
 1210 root     name=systemd:/systemd-1/irqbalance.service irqbalance
 1216 root     name=systemd:/systemd-1/dbus.service /usr/sbin/modem-manager
 1219 root     name=systemd:/systemd-1/dbus.service /usr/libexec/polkit-1/polkitd
 1242 root     name=systemd:/systemd-1/dbus.service /usr/sbin/wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -B -u -f /var/log/wpa_supplicant.log -P /var/run/wpa_supplicant.pid
 1249 68       name=systemd:/systemd-1/haldaemon.service hald
 1250 root     name=systemd:/systemd-1/haldaemon.service  \_ hald-runner
 1273 root     name=systemd:/systemd-1/haldaemon.service      \_ hald-addon-input: Listening on /dev/input/event3 /dev/input/event9 /dev/input/event1 /dev/input/event7 /dev/input/event2 /dev/input/event0 /dev/input/event8
 1275 root     name=systemd:/systemd-1/haldaemon.service      \_ /usr/libexec/hald-addon-rfkill-killswitch
 1284 root     name=systemd:/systemd-1/haldaemon.service      \_ /usr/libexec/hald-addon-leds
 1285 root     name=systemd:/systemd-1/haldaemon.service      \_ /usr/libexec/hald-addon-generic-backlight
 1287 68       name=systemd:/systemd-1/haldaemon.service      \_ /usr/libexec/hald-addon-acpi
 1317 root     name=systemd:/systemd-1/abrtd.service /usr/sbin/abrtd -d -s
 1332 root     name=systemd:/systemd-1/[email protected]/tty2 /sbin/mingetty tty2
 1339 root     name=systemd:/systemd-1/[email protected]/tty3 /sbin/mingetty tty3
 1342 root     name=systemd:/systemd-1/[email protected]/tty5 /sbin/mingetty tty5
 1343 root     name=systemd:/systemd-1/[email protected]/tty4 /sbin/mingetty tty4
 1344 root     name=systemd:/systemd-1/crond.service crond
 1346 root     name=systemd:/systemd-1/[email protected]/tty6 /sbin/mingetty tty6
 1362 root     name=systemd:/systemd-1/sshd.service /usr/sbin/sshd
 1376 root     name=systemd:/systemd-1/prefdm.service /usr/sbin/gdm-binary -nodaemon
 1391 root     name=systemd:/systemd-1/prefdm.service  \_ /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1 --force-active-vt
 1394 root     name=systemd:/systemd-1/prefdm.service      \_ /usr/bin/Xorg :0 -nr -verbose -auth /var/run/gdm/auth-for-gdm-f2KUOh/database -nolisten tcp vt1
 1495 root     name=systemd:/user/lennart/1             \_ pam: gdm-password
 1521 lennart  name=systemd:/user/lennart/1                 \_ gnome-session
 1621 lennart  name=systemd:/user/lennart/1                     \_ metacity
 1635 lennart  name=systemd:/user/lennart/1                     \_ gnome-panel
 1638 lennart  name=systemd:/user/lennart/1                     \_ nautilus
 1640 lennart  name=systemd:/user/lennart/1                     \_ /usr/libexec/polkit-gnome-authentication-agent-1
 1641 lennart  name=systemd:/user/lennart/1                     \_ /usr/bin/seapplet
 1644 lennart  name=systemd:/user/lennart/1                     \_ gnome-volume-control-applet
 1646 lennart  name=systemd:/user/lennart/1                     \_ /usr/sbin/restorecond -u
 1652 lennart  name=systemd:/user/lennart/1                     \_ /usr/bin/devilspie
 1662 lennart  name=systemd:/user/lennart/1                     \_ nm-applet --sm-disable
 1664 lennart  name=systemd:/user/lennart/1                     \_ gnome-power-manager
 1665 lennart  name=systemd:/user/lennart/1                     \_ /usr/libexec/gdu-notification-daemon
 1670 lennart  name=systemd:/user/lennart/1                     \_ /usr/libexec/evolution/2.32/evolution-alarm-notify
 1672 lennart  name=systemd:/user/lennart/1                     \_ /usr/bin/python /usr/share/system-config-printer/applet.py
 1674 lennart  name=systemd:/user/lennart/1                     \_ /usr/lib64/deja-dup/deja-dup-monitor
 1675 lennart  name=systemd:/user/lennart/1                     \_ abrt-applet
 1677 lennart  name=systemd:/user/lennart/1                     \_ bluetooth-applet
 1678 lennart  name=systemd:/user/lennart/1                     \_ gpk-update-icon
 1408 root     name=systemd:/systemd-1/console-kit-daemon.service /usr/sbin/console-kit-daemon --no-daemon
 1419 gdm      name=systemd:/systemd-1/prefdm.service /usr/bin/dbus-launch --exit-with-session
 1453 root     name=systemd:/systemd-1/dbus.service /usr/libexec/upowerd
 1473 rtkit    name=systemd:/systemd-1/rtkit-daemon.service /usr/libexec/rtkit-daemon
 1496 root     name=systemd:/systemd-1/accounts-daemon.service /usr/libexec/accounts-daemon
 1499 root     name=systemd:/systemd-1/systemd-logger.service /lib/systemd/systemd-logger
 1511 lennart  name=systemd:/systemd-1/prefdm.service /usr/bin/gnome-keyring-daemon --daemonize --login
 1534 lennart  name=systemd:/user/lennart/1        dbus-launch --sh-syntax --exit-with-session
 1535 lennart  name=systemd:/user/lennart/1        /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
 1603 lennart  name=systemd:/user/lennart/1        /usr/libexec/gconfd-2
 1612 lennart  name=systemd:/user/lennart/1        /usr/libexec/gnome-settings-daemon
 1615 lennart  name=systemd:/user/lennart/1        /usr/libexec/gvfsd
 1626 lennart  name=systemd:/user/lennart/1        /usr/libexec//gvfs-fuse-daemon /home/lennart/.gvfs
 1634 lennart  name=systemd:/user/lennart/1        /usr/bin/pulseaudio --start --log-target=syslog
 1649 lennart  name=systemd:/user/lennart/1         \_ /usr/libexec/pulse/gconf-helper
 1645 lennart  name=systemd:/user/lennart/1        /usr/libexec/bonobo-activation-server --ac-activate --ior-output-fd=24
 1668 lennart  name=systemd:/user/lennart/1        /usr/libexec/im-settings-daemon
 1701 lennart  name=systemd:/user/lennart/1        /usr/libexec/gvfs-gdu-volume-monitor
 1707 lennart  name=systemd:/user/lennart/1        /usr/bin/gnote --panel-applet --oaf-activate-iid=OAFIID:GnoteApplet_Factory --oaf-ior-fd=22
 1725 lennart  name=systemd:/user/lennart/1        /usr/libexec/clock-applet
 1727 lennart  name=systemd:/user/lennart/1        /usr/libexec/wnck-applet
 1729 lennart  name=systemd:/user/lennart/1        /usr/libexec/notification-area-applet
 1733 root     name=systemd:/systemd-1/dbus.service /usr/libexec/udisks-daemon
 1747 root     name=systemd:/systemd-1/dbus.service  \_ udisks-daemon: polling /dev/sr0
 1759 lennart  name=systemd:/user/lennart/1        gnome-screensaver
 1780 lennart  name=systemd:/user/lennart/1        /usr/libexec/gvfsd-trash --spawner :1.9 /org/gtk/gvfs/exec_spaw/0
 1864 lennart  name=systemd:/user/lennart/1        /usr/libexec/gvfs-afc-volume-monitor
 1874 lennart  name=systemd:/user/lennart/1        /usr/libexec/gconf-im-settings-daemon
 1903 lennart  name=systemd:/user/lennart/1        /usr/libexec/gvfsd-burn --spawner :1.9 /org/gtk/gvfs/exec_spaw/1
 1909 lennart  name=systemd:/user/lennart/1        gnome-terminal
 1913 lennart  name=systemd:/user/lennart/1         \_ gnome-pty-helper
 1914 lennart  name=systemd:/user/lennart/1         \_ bash
29231 lennart  name=systemd:/user/lennart/1         |   \_ ssh tango
 2221 lennart  name=systemd:/user/lennart/1         \_ bash
 4193 lennart  name=systemd:/user/lennart/1         |   \_ ssh tango
 2461 lennart  name=systemd:/user/lennart/1         \_ bash
29219 lennart  name=systemd:/user/lennart/1         |   \_ emacs systemd-for-admins-1.txt
15113 lennart  name=systemd:/user/lennart/1         \_ bash
27251 lennart  name=systemd:/user/lennart/1             \_ empathy
29504 lennart  name=systemd:/user/lennart/1             \_ ps xawf -eo pid,user,cgroup,args
 1968 lennart  name=systemd:/user/lennart/1        ssh-agent
 1994 lennart  name=systemd:/user/lennart/1        gpg-agent --daemon --write-env-file
18679 lennart  name=systemd:/user/lennart/1        /bin/sh /usr/lib64/firefox-3.6/run-mozilla.sh /usr/lib64/firefox-3.6/firefox
18741 lennart  name=systemd:/user/lennart/1         \_ /usr/lib64/firefox-3.6/firefox
28900 lennart  name=systemd:/user/lennart/1             \_ /usr/lib64/nspluginwrapper/npviewer.bin --plugin /usr/lib64/mozilla/plugins/libflashplayer.so --connection /org/wrapper/NSPlugins/libflashplayer.so/18741-6
 4016 root     name=systemd:/systemd-1/sysinit.service /usr/sbin/bluetoothd --udev
 4094 smmsp    name=systemd:/systemd-1/sendmail.service sendmail: Queue [email protected]:00:00 for /var/spool/clientmqueue
 4096 root     name=systemd:/systemd-1/sendmail.service sendmail: accepting connections
 4112 ntp      name=systemd:/systemd-1/ntpd.service /usr/sbin/ntpd -n -u ntp:ntp -g
27262 lennart  name=systemd:/user/lennart/1        /usr/libexec/mission-control-5
27265 lennart  name=systemd:/user/lennart/1        /usr/libexec/telepathy-haze
27268 lennart  name=systemd:/user/lennart/1        /usr/libexec/telepathy-logger
27270 lennart  name=systemd:/user/lennart/1        /usr/libexec/dconf-service
27280 lennart  name=systemd:/user/lennart/1        /usr/libexec/notification-daemon
27284 lennart  name=systemd:/user/lennart/1        /usr/libexec/telepathy-gabble
27285 lennart  name=systemd:/user/lennart/1        /usr/libexec/telepathy-salut
27297 lennart  name=systemd:/user/lennart/1        /usr/libexec/geoclue-yahoo

(Note that this output is shortened, I have removed most of the
kernel threads here, since they are not relevant in the context of
this blog story)

In the third column you see the cgroup systemd assigned to each
process. You’ll find that the udev processes are in the
name=systemd:/systemd-1/sysinit.service cgroup, which is
where systemd places all processes started by the
sysinit.service service, which covers early boot.

My personal recommendation is to set the shell alias psc
to the ps command line shown above:

alias psc='ps xawf -eo pid,user,cgroup,args'

With this service information of processes is just four keypresses
away!

A different way to present the same information is the
systemd-cgls tool we ship with systemd. It shows the cgroup
hierarchy in a pretty tree. Its output looks like this:

$ systemd-cgls
+    2 [kthreadd]
[...]
+ 4281 [flush-8:0]
+ user
| \ lennart
|   \ 1
|     +  1495 pam: gdm-password
|     +  1521 gnome-session
|     +  1534 dbus-launch --sh-syntax --exit-with-session
|     +  1535 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
|     +  1603 /usr/libexec/gconfd-2
|     +  1612 /usr/libexec/gnome-settings-daemon
|     +  1615 /ushr/libexec/gvfsd
|     +  1621 metacity
|     +  1626 /usr/libexec//gvfs-fuse-daemon /home/lennart/.gvfs
|     +  1634 /usr/bin/pulseaudio --start --log-target=syslog
|     +  1635 gnome-panel
|     +  1638 nautilus
|     +  1640 /usr/libexec/polkit-gnome-authentication-agent-1
|     +  1641 /usr/bin/seapplet
|     +  1644 gnome-volume-control-applet
|     +  1645 /usr/libexec/bonobo-activation-server --ac-activate --ior-output-fd=24
|     +  1646 /usr/sbin/restorecond -u
|     +  1649 /usr/libexec/pulse/gconf-helper
|     +  1652 /usr/bin/devilspie
|     +  1662 nm-applet --sm-disable
|     +  1664 gnome-power-manager
|     +  1665 /usr/libexec/gdu-notification-daemon
|     +  1668 /usr/libexec/im-settings-daemon
|     +  1670 /usr/libexec/evolution/2.32/evolution-alarm-notify
|     +  1672 /usr/bin/python /usr/share/system-config-printer/applet.py
|     +  1674 /usr/lib64/deja-dup/deja-dup-monitor
|     +  1675 abrt-applet
|     +  1677 bluetooth-applet
|     +  1678 gpk-update-icon
|     +  1701 /usr/libexec/gvfs-gdu-volume-monitor
|     +  1707 /usr/bin/gnote --panel-applet --oaf-activate-iid=OAFIID:GnoteApplet_Factory --oaf-ior-fd=22
|     +  1725 /usr/libexec/clock-applet
|     +  1727 /usr/libexec/wnck-applet
|     +  1729 /usr/libexec/notification-area-applet
|     +  1759 gnome-screensaver
|     +  1780 /usr/libexec/gvfsd-trash --spawner :1.9 /org/gtk/gvfs/exec_spaw/0
|     +  1864 /usr/libexec/gvfs-afc-volume-monitor
|     +  1874 /usr/libexec/gconf-im-settings-daemon
|     +  1882 /usr/libexec/gvfs-gphoto2-volume-monitor
|     +  1903 /usr/libexec/gvfsd-burn --spawner :1.9 /org/gtk/gvfs/exec_spaw/1
|     +  1909 gnome-terminal
|     +  1913 gnome-pty-helper
|     +  1914 bash
|     +  1968 ssh-agent
|     +  1994 gpg-agent --daemon --write-env-file
|     +  2221 bash
|     +  2461 bash
|     +  4193 ssh tango
|     + 15113 bash
|     + 18679 /bin/sh /usr/lib64/firefox-3.6/run-mozilla.sh /usr/lib64/firefox-3.6/firefox
|     + 18741 /usr/lib64/firefox-3.6/firefox
|     + 27251 empathy
|     + 27262 /usr/libexec/mission-control-5
|     + 27265 /usr/libexec/telepathy-haze
|     + 27268 /usr/libexec/telepathy-logger
|     + 27270 /usr/libexec/dconf-service
|     + 27280 /usr/libexec/notification-daemon
|     + 27284 /usr/libexec/telepathy-gabble
|     + 27285 /usr/libexec/telepathy-salut
|     + 27297 /usr/libexec/geoclue-yahoo
|     + 28900 /usr/lib64/nspluginwrapper/npviewer.bin --plugin /usr/lib64/mozilla/plugins/libflashplayer.so --connection /org/wrapper/NSPlugins/libflashplayer.so/18741-6
|     + 29219 emacs systemd-for-admins-1.txt
|     + 29231 ssh tango
|     \ 29519 systemd-cgls
\ systemd-1
  + 1 /sbin/init
  + ntpd.service
  | \ 4112 /usr/sbin/ntpd -n -u ntp:ntp -g
  + systemd-logger.service
  | \ 1499 /lib/systemd/systemd-logger
  + accounts-daemon.service
  | \ 1496 /usr/libexec/accounts-daemon
  + rtkit-daemon.service
  | \ 1473 /usr/libexec/rtkit-daemon
  + console-kit-daemon.service
  | \ 1408 /usr/sbin/console-kit-daemon --no-daemon
  + prefdm.service
  | + 1376 /usr/sbin/gdm-binary -nodaemon
  | + 1391 /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1 --force-active-vt
  | + 1394 /usr/bin/Xorg :0 -nr -verbose -auth /var/run/gdm/auth-for-gdm-f2KUOh/database -nolisten tcp vt1
  | + 1419 /usr/bin/dbus-launch --exit-with-session
  | \ 1511 /usr/bin/gnome-keyring-daemon --daemonize --login
  + [email protected]
  | + tty6
  | | \ 1346 /sbin/mingetty tty6
  | + tty4
  | | \ 1343 /sbin/mingetty tty4
  | + tty5
  | | \ 1342 /sbin/mingetty tty5
  | + tty3
  | | \ 1339 /sbin/mingetty tty3
  | \ tty2
  |   \ 1332 /sbin/mingetty tty2
  + abrtd.service
  | \ 1317 /usr/sbin/abrtd -d -s
  + crond.service
  | \ 1344 crond
  + sshd.service
  | \ 1362 /usr/sbin/sshd
  + sendmail.service
  | + 4094 sendmail: Queue [email protected]:00:00 for /var/spool/clientmqueue
  | \ 4096 sendmail: accepting connections
  + haldaemon.service
  | + 1249 hald
  | + 1250 hald-runner
  | + 1273 hald-addon-input: Listening on /dev/input/event3 /dev/input/event9 /dev/input/event1 /dev/input/event7 /dev/input/event2 /dev/input/event0 /dev/input/event8
  | + 1275 /usr/libexec/hald-addon-rfkill-killswitch
  | + 1284 /usr/libexec/hald-addon-leds
  | + 1285 /usr/libexec/hald-addon-generic-backlight
  | \ 1287 /usr/libexec/hald-addon-acpi
  + irqbalance.service
  | \ 1210 irqbalance
  + avahi-daemon.service
  | + 1175 avahi-daemon: running [epsilon.local]
  + NetworkManager.service
  | + 1171 /usr/sbin/NetworkManager --no-daemon
  | \ 4028 /sbin/dhclient -d -4 -sf /usr/libexec/nm-dhcp-client.action -pf /var/run/dhclient-wlan0.pid -lf /var/lib/dhclient/dhclient-7d32a784-ede9-4cf6-9ee3-60edc0bce5ff-wlan0.lease -cf /var/run/nm-dhclient-wlan0.conf wlan0
  + rsyslog.service
  | \ 1193 /sbin/rsyslogd -c 4
  + mdmonitor.service
  | \ 1207 mdadm --monitor --scan -f --pid-file=/var/run/mdadm/mdadm.pid
  + cups.service
  | \ 1195 cupsd -C /etc/cups/cupsd.conf
  + auditd.service
  | + 1131 auditd
  | + 1133 /sbin/audispd
  | \ 1135 /usr/sbin/sedispatch
  + dbus.service
  | +  1096 /bin/dbus-daemon --system --address=systemd: --nofork --systemd-activation
  | +  1216 /usr/sbin/modem-manager
  | +  1219 /usr/libexec/polkit-1/polkitd
  | +  1242 /usr/sbin/wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -B -u -f /var/log/wpa_supplicant.log -P /var/run/wpa_supplicant.pid
  | +  1453 /usr/libexec/upowerd
  | +  1733 /usr/libexec/udisks-daemon
  | +  1747 udisks-daemon: polling /dev/sr0
  | \ 29509 /usr/libexec/packagekitd
  + dev-mqueue.mount
  + dev-hugepages.mount
  \ sysinit.service
    +   455 /sbin/udevd -d
    +  4016 /usr/sbin/bluetoothd --udev
    + 28188 /sbin/udevd -d
    \ 28191 /sbin/udevd -d

(This too is shortened, the same way)

As you can see, this command shows the processes by their cgroup
and hence service, as systemd labels the cgroups after the
services. For example, you can easily see that the auditing service
auditd.service spawns three individual processes,
auditd, audisp and sedispatch.

If you look closely you will notice that a number of processes have
been assigned to the cgroup /user/1. At this point let’s
simply leave it at that systemd not only maintains services in cgroups,
but user session processes as well. In a later installment we’ll discuss in
more detail what this about.

So much for now, come back soon for the next installment!

The Saga of Sun RPC

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/08/27/sun-rpc.html

I first became aware of the Sun RPC license in mid-2001, but my email
archives from the time indicate the issue predated my involvement with
it; it’d been an issue of consideration since 1994. I later had my
first large email thread “free-for-all” on the issue in
April 2002, which was the first of too many that I’d have before it was
all done. In December 2002,
the Debian
bug was filed
, and then it became a very public debate. Late last
week, it
was finally resolved
. It now ranks as the longest standing Free
Software licensing problem of my career. A cast of dozens deserve credit
for getting it resolved.

Tom “spot” Callaway does
a good job summarizing
the recent occurrences on this issue
(and by recent, I mean since
2005 — it’s been going long enough that five years ago is
“recent”), and its final resolution. So, I won’t cover that
recent history, but I encourage people to read Spot’s summary. Simon
Phipps, who worked on this issue during his time as the Chief Open
Source Officer of
Sun, also
wrote about his work on the issue
. For my part, I’ll try to cover
the “middle” part of the story from 2001-2005.

So, the funny thing about this license is everyone knew it was Sun’s
intention to make it Free Software. The code is so old, it dates back
to a time when the drafting of Free Software licenses weren’t well
understood (old-schoolers will, for example, remember the annoying
advertising clause in early BSD licenses). Thus, by our modern
standards, the Sun RPC license does appear on its face as trivially
non-Free, but in its historical context, the intent was actually clear,
in my opinion.

Nevertheless, by 2002, we knew how to look at licenses objectively and
critically, and it was clear to many people that the license had
problems. Competing legal theories existed, but the concerns of Debian
were enough to get everyone moving toward a solution.

For my part, I checked in regularly during 2002-2004 with Danese Cooper
(who was, effectively, Simon Phipps’ predecessor at Sun), until I was
practically begging her to pay attention to the issue. While I could
frequently get verbal assurances from Danese and other Sun officials
that it was their clear intention that glibc be permitted to include the
code under the LGPL, I could never get something in writing. I had a
hundred other things to worry about, and eventually, I stopped worrying
about it. I remember thinking at the time: well, I’ve notes on all
these calls and discussions I’ve had with Sun people about the license.
Worst case scenario: I’ll have to testify to this when Sun sues some
Free Software project, and there will be a good estoppel
defense.

Meanwhile, around early 2004, my friend and colleague at
FSF, David “Novalis”
Turner
took up the cause in earnest. I think he spent a year or two
as I did: desperately trying to get others to pay attention and solve
the problem. Eventually, he left FSF for other work, and others took up
the cause, including Brett Smith (who took over Novalis’ FSF job), and,
by that time, Spot was also paying attention to this. Both Brett and
Spot worked hard
to get
Simon Phipps attention on it, which finally happened
. But around
then began that long waiting period while Oracle was preparing to buy
Sun. It stopped almost anything anyone wanted to get done with Sun, so
everyone just waited (again). It was around that time that I decided I
was pretty sure I never wanted to hear the phrase: “Sun RPC
license” again in my life.

Meanwhile, Richard Fontana had gone to work for Red Hat, and his
self-proclaimed pathological obsession with Free Software (which can
only be rivaled by my own) led him to
begin discussing
the Sun RPC issue again
. He and Spot were also doing their best
negotiating with Oracle to get it fixed. They took us the last miles of
this marathon, and now the job is done.

I admit that I feel of some shame that, in recent years, I’ve had such
fatigue about this issue — a simple one that should’ve been
solved a decade and a half ago — that, since 2008, I’ve done
nothing but kibitz about the issue when people complained. I also
didn’t believe that a company as disturbing and anti-Free-Software as
Oracle could ever be convinced to change a license to be
more FaiF. Spot and
Fontana proved me wrong, and I’m glad.

Thanks to everyone in this great cast of characters that made this
ultimately beneficial production of licensing theater possible. I’ve
been honored that I shared the stage in the first few acts, and sorry
that I hid backstage for the last few. It was right to keep working on
it until the job was done. As Fontana
said: Estoppel may be
relevant but never enough; software freedom principle[s] should matter
as much as legal risk.

[the] standard for FaiF can’t
simply be ‘good defense to copyright infringement
likely’
. Thanks to everyone; I’m so glad I no longer have
to wait in fear of a subpoena from Oracle in a lawsuit claiming
infringement of their Sun RPC copyrights.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close