1
00:00:00,000 --> 00:00:05,000
[stapelberg]: Hi! So first of all, the type of this lecture

2
00:00:05,000 --> 00:00:07,000
is that it's going to be a workshop, just to make the expectations

3
00:00:07,000 --> 00:00:09,000
clear, I have a few slides prepared that

4
00:00:09,000 --> 00:00:11,000
should give you a general introduction

5
00:00:11,000 --> 00:00:13,000
and they will take

6
00:00:13,000 --> 00:00:15,000
probably about half of the time we have allocated

7
00:00:15,000 --> 00:00:17,000
for this slot, and afterwards

8
00:00:17,000 --> 00:00:19,000
we can answer your questions

9
00:00:19,000 --> 00:00:21,000
or have some hands-down hacking

10
00:00:21,000 --> 00:00:23,000
on actual packages.

11
00:00:23,000 --> 00:00:25,000
My name is Michael Stapelberg

12
00:00:25,000 --> 00:00:27,000
Just a quick show of hands so that I know my audience --

13
00:00:27,000 --> 00:00:29,000
who of you maintains a Debian package

14
00:00:29,000 --> 00:00:31,000
in Debian or derivatives?

15
00:00:31,000 --> 00:00:33,000
OK, that's almost everybody

16
00:00:33,000 --> 00:00:35,000
Perfect.

17
00:00:35,000 --> 00:00:37,000
How many of you actually added

18
00:00:37,000 --> 00:00:39,000
systemd support to their packages already?

19
00:00:39,000 --> 00:00:41,000
OK, a couple.

20
00:00:41,000 --> 00:00:44,410
Who of you are looking into doing that?

21
00:00:44,750 --> 00:00:47,810
OK, perfect! You are exactly the right audience.

22
00:00:48,450 --> 00:00:51,210
Great.  So the topics I want to cover with my slides are:

23
00:00:51,210 --> 00:00:51,270
First of all, how systemd works for package maintainers
Great.  So the topics I want to cover with my slides are:

24
00:00:51,270 --> 00:00:54,840
First of all, how systemd works for package maintainers

25
00:00:54,840 --> 00:00:54,940
That means I'm not going to cover all of it
First of all, how systemd works for package maintainers

26
00:00:54,940 --> 00:00:57,530
That means I'm not going to cover all of it

27
00:00:57,530 --> 00:01:01,900
And also it's not so much of a user standpoint

28
00:01:01,900 --> 00:01:05,730
but just what you need to know to get you started on testing your stuff in systemd.

29
00:01:05,730 --> 00:01:09,630
We will then have a look at an example service file

30
00:01:09,630 --> 00:01:13,060
where we'll make clear what all the different directives are supposed to mean

31
00:01:13,060 --> 00:01:16,090
We will look at the tmpfiles mechanism

32
00:01:16,090 --> 00:01:18,090
and at dh-systemd, a debhelper plugin

33
00:01:18,090 --> 00:01:22,110
We will consider a few more advanced examples, and then finally we will

34
00:01:22,110 --> 00:01:24,490
answer your questions, hopefully.

35
00:01:24,490 --> 00:01:28,870
So, non-topics for this presentation are:

36
00:01:28,870 --> 00:01:31,560
systemd sucks, let's just use something else instead

37
00:01:31,560 --> 00:01:37,470
When will debian ever finally switch the default, and essentially anything that ever came up on debian-devel. I'm not going to talk about that.

38
00:01:37,470 --> 00:01:41,510
This is just about how to make it work if you have already accepted that this is something that you want to do.

39
00:01:41,510 --> 00:01:43,930
So, how does systemd work?

40
00:01:43,930 --> 00:01:49,040
Essentially, where we previously had initscripts, we now have service files.

41
00:01:49,040 --> 00:01:52,340
Service files are just a special kind of unit files

42
00:01:52,340 --> 00:01:57,510
so the more generic term is unit files and that which corresponds to an initscript is a service file.

43
00:01:57,510 --> 00:02:04,100
So previously, you would have /etc/init.d/apache2 as an initscript

44
00:02:04,100 --> 00:02:09,590
and the corresponding file would be /lib/systemd/system/apache2.service

45
00:02:09,590 --> 00:02:13,280
Now what's important here to notice

46
00:02:13,280 --> 00:02:17,220
Is that the base name (apart from the .service suffix)

47
00:02:17,220 --> 00:02:19,880
needs to be the same, because what will happen is that

48
00:02:19,880 --> 00:02:22,770
systemd, when booting on a machine

49
00:02:22,770 --> 00:02:26,340
will look at all the services in /etc/init.d

50
00:02:26,340 --> 00:02:28,340
and use them if they are available

51
00:02:28,340 --> 00:02:32,160
but if there is also a service file, that will take precedence.

52
00:02:32,160 --> 00:02:35,630
So in order to make sure that systemd uses your service file and not

53
00:02:35,630 --> 00:02:39,650
your service file plus the old initscript, make sure that the name is correct.

54
00:02:39,650 --> 00:02:42,890
Before you ask, yes there are also mechanisms to make sure that

55
00:02:42,890 --> 00:02:47,060
when you have a name transition, because you've adopted the upstream name for a service file

56
00:02:47,060 --> 00:02:50,280
or something like that, then you can have a compatibility symlink.

57
00:02:50,280 --> 00:02:52,040
We can cover that later.

58
00:02:52,040 --> 00:02:55,670
And essentially, systemctl does what service did.

59
00:02:55,670 --> 00:02:58,690
So if you had service apache2 start

60
00:02:58,690 --> 00:03:01,630
Then you would use systemctl start apache2.service

61
00:03:01,630 --> 00:03:07,320
In recent versions, you can even skip the .service suffix so it would just be systemctl start apache2

62
00:03:08,430 --> 00:03:13,140
The systemctl tool is mostly for the actual users, or for you when testing.

63
00:03:13,140 --> 00:03:19,160
and just like you would usually use /etc/init.d/apache2 start as an actual user

64
00:03:19,160 --> 00:03:22,920
but "service" inside your maintenance script, we have something for that.

65
00:03:24,300 --> 00:03:29,110
Now, what we had in SystemV init were runlevels

66
00:03:29,110 --> 00:03:32,740
and they were poorly defined and different from distribution to distribution

67
00:03:32,740 --> 00:03:36,270
And what systemd does to replace them is that it has something called a target.

68
00:03:36,270 --> 00:03:41,150
A target is precisely the same as a runlevel

69
00:03:41,150 --> 00:03:43,150
it just has a much nicer name

70
00:03:43,150 --> 00:03:47,540
and the names are standardized between all the different distributions.

71
00:03:47,540 --> 00:03:53,080
The most important targets for you are basic.target, multi-user.target and graphical.target

72
00:03:53,080 --> 00:03:56,880
Each of them is more specific than the other

73
00:03:56,880 --> 00:03:59,710
in that it starts more services for a particular use case

74
00:03:59,710 --> 00:04:02,530
So basic.target is what everybody of you will run

75
00:04:02,670 --> 00:04:06,600
and then multi-user.target extends basic.target with more stuff

76
00:04:06,840 --> 00:04:11,710
and graphical.target brings in all the graphical components like a display manager

77
00:04:11,710 --> 00:04:16,450
and stuff that you would normally not use on servers where multi-user.target is what you would want to use.

78
00:04:16,450 --> 00:04:21,290
You can look that up if you care later on in the manpage systemd.special.

79
00:04:22,300 --> 00:04:26,300
Just as previously, with SystemV init

80
00:04:26,300 --> 00:04:28,470
we had symlinks to enable a service

81
00:04:28,470 --> 00:04:31,340
and these symlinks were created by update-rc.d

82
00:04:31,340 --> 00:04:33,740
we still have symlinks to enable a service

83
00:04:33,740 --> 00:04:36,490
now they're just created by systemctl enable

84
00:04:37,120 --> 00:04:41,530
Again, systemctl is what you would use as a user, or while testing, etc.

85
00:04:41,530 --> 00:04:44,530
And we have a maintainer script equivalent of that.

86
00:04:46,090 --> 00:04:49,550
Are there any questions so far?  This is really the basic stuff.

87
00:04:58,090 --> 00:05:02,260
[question]: What is the reason there are different commands for the user and the maintainer scripts?

88
00:05:02,260 --> 00:05:08,190
[stapelberg]: I think will go into this later, but I can just briefly explain it

89
00:05:08,190 --> 00:05:08,230
The maintainer scripts also need to work on machines where systemd is not actually installed.
[stapelberg]: I think will go into this later, but I can just briefly explain it

90
00:05:08,230 --> 00:05:11,780
The maintainer scripts also need to work on machines where systemd is not actually installed.

91
00:05:12,470 --> 00:05:14,140
So that's why we can't use systemctl.

92
00:05:14,540 --> 00:05:17,740
Alright, let's look at an example service file.

93
00:05:17,740 --> 00:05:19,770
I just picked vnstat.service

94
00:05:19,780 --> 00:05:26,700
which is a tiny daemon that will just store (and plot later on) your network traffic.

95
00:05:27,760 --> 00:05:33,310
What you can see here is a very clear, human-readable configuration file

96
00:05:33,310 --> 00:05:35,540
And this is the service file. it's called vnstat.service.

97
00:05:35,780 --> 00:05:39,600
It starts with a [Unit] section, and you can see

98
00:05:39,600 --> 00:05:44,150
just like inifiles, which probably everybody of you is comfortable with

99
00:05:44,150 --> 00:05:48,270
or .desktop files, which have the same format, so this is actually a .desktop file.

100
00:05:48,930 --> 00:05:53,250
There are sections which are enclosed in square brackets, and then there's key/value pairs

101
00:05:53,250 --> 00:05:55,800
separated by an equals sign, so that's really simple.

102
00:05:55,800 --> 00:05:59,200
The first section is entirely just for humans.

103
00:05:59,200 --> 00:06:05,380
So the description will tell me what kind of service this is, if I'm looking at my system and wondering what is this that's starting up here.

104
00:06:05,900 --> 00:06:10,400
The second section is the [Service] section, and this is actually where

105
00:06:11,800 --> 00:06:13,380
all the relevant stuff is.

106
00:06:13,380 --> 00:06:17,720
What we specify here in the second line is ExecStart, which is

107
00:06:17,720 --> 00:06:21,570
the command that systemd will run when trying to start that service.

108
00:06:21,570 --> 00:06:25,770
In this case, it's really simple, you just start the vnstatd binary.

109
00:06:25,770 --> 00:06:30,850
What you need to notice here though is that systemd does not invoke a shell to start it up,

110
00:06:31,170 --> 00:06:34,830
so you need to specify the full path, and you don't have your usual

111
00:06:34,830 --> 00:06:38,270
shell stuff in your command line, so just keep that in mind.

112
00:06:38,290 --> 00:06:43,870
We also have the ExecReload line, and there could also be an ExecStop line.

113
00:06:43,870 --> 00:06:47,500
In the absence of an ExecStop line, systemd will just kill the service

114
00:06:47,500 --> 00:06:52,690
And it will do what many many people implemented in initscripts by hand

115
00:06:52,690 --> 00:06:55,980
which is to gently try to kill it, and if that doesn't work within a certain timespan

116
00:06:55,980 --> 00:06:59,000
then it will try to kill it harder, until it finally succeeds.

117
00:06:59,570 --> 00:07:03,240
The ExecReload line is pretty standard

118
00:07:03,240 --> 00:07:08,860
the thing is that not all of the services provide a way of reloading in the first place

119
00:07:08,860 --> 00:07:13,960
so we need to have such a line to tell systemd what to do on a reload command

120
00:07:14,140 --> 00:07:19,030
Some other service (you could probably think of the bind nameserver)

121
00:07:19,030 --> 00:07:22,900
have a different way of reloading (so you could call "rndc reload" in that case)

122
00:07:22,900 --> 00:07:27,780
but this one is really simple, it just sends SIGHUP to the service, and then it will reload.

123
00:07:27,780 --> 00:07:31,830
the $MAINPID is not actually a shell variable or anything

124
00:07:31,830 --> 00:07:36,950
it's just a special thing that you can use in unit files and service files in particular.

125
00:07:37,380 --> 00:07:41,140
And then we also have the User= line which will specify

126
00:07:41,140 --> 00:07:45,150
under which user this program will be started.  That's pretty straightforward.

127
00:07:45,990 --> 00:07:48,430
The last section is also interesting

128
00:07:48,430 --> 00:07:51,480
it's called the [Install] section, and it has a line called

129
00:07:51,480 --> 00:07:53,900
WantedBy=multi-user.target

130
00:07:53,900 --> 00:07:56,690
And that essentially says that when this service file

131
00:07:56,690 --> 00:07:59,070
is enabled on the machine

132
00:07:59,070 --> 00:08:02,680
it will be pulled in by multi-user.target, so this specifies

133
00:08:02,680 --> 00:08:05,560
which runlevel it runs in, so to say.

134
00:08:05,620 --> 00:08:10,030
Are there any questions so far?

135
00:08:11,460 --> 00:08:13,140
yes -- microphone?

136
00:08:15,350 --> 00:08:18,660
[question]: can there be more than one WantedBy= line?

137
00:08:18,680 --> 00:08:21,150
[stapelberg]: Yes, there can be multiple WantedBy= lines.

138
00:08:22,510 --> 00:08:23,760
More questions -- over there?

139
00:08:27,780 --> 00:08:30,460
[question]: So just to make sure that I understand correctly

140
00:08:30,460 --> 00:08:34,510
If systemd tries to restart or reload a service

141
00:08:34,510 --> 00:08:37,800
it first executes this reload phrase, and then it execs

142
00:08:37,800 --> 00:08:39,370
the start phrase again?

143
00:08:39,370 --> 00:08:42,960
[stapelberg]: No, there's two different cases here.  One is the reload case

144
00:08:42,960 --> 00:08:45,400
and the other one is the restart case.

145
00:08:45,400 --> 00:08:49,230
In the reload case, it just executes what's specified here

146
00:08:49,230 --> 00:08:53,130
If the service file supports reloading; if it doesn't, then you can't reload it.

147
00:08:53,130 --> 00:08:55,240
If you do a restart, it will

148
00:08:55,240 --> 00:08:59,100
first execute stop if present, or kill it if not present, and then start it again.

149
00:08:59,100 --> 00:08:59,240
[question]: Fine.  OK, thank you.
first execute stop if present, or kill it if not present, and then start it again.

150
00:08:59,240 --> 00:09:00,790
[stapelberg]: one more question here?
[question]: Fine.  OK, thank you.

151
00:09:00,790 --> 00:09:01,990
[stapelberg]: one more question here?

152
00:09:05,430 --> 00:09:10,360
[question]: Is there an equivalent to debian's force-reload,

153
00:09:10,360 --> 00:09:16,780
where you care so much about wanting it to reload that you're OK with it falling back to stop and start if necessary?

154
00:09:16,780 --> 00:09:22,100
which debian's sysvinit system does support in the usual skeleton file.

155
00:09:22,230 --> 00:09:27,200
[stapelberg]: I think there is a try-reload action, but I would have to confirm that.  We can do that later.

156
00:09:28,820 --> 00:09:31,890
[question]: Is there also something to stop a service?

157
00:09:31,890 --> 00:09:36,330
[stapelberg]: Yes, I already mentioned that you can specify ExecStop=, and if you don't, it will just kill it.

158
00:09:36,330 --> 00:09:39,310
[question]: Sorry, I didn't hear that.

159
00:09:39,310 --> 00:09:41,310
[stapelberg]: one more question here?

160
00:09:42,320 --> 00:09:46,550
[question, quoting from a man page]: "tries to reload if possible and falls back to restart"

161
00:09:46,550 --> 00:09:51,030
[stapelberg]: He just said there's a "reload-or-restart" command in systemctl that does precisely what you asked for.

162
00:09:51,030 --> 00:09:57,880
[question]: Are there other things than start, reload, stop, and ... can you define other things?

163
00:09:57,880 --> 00:10:01,490
[stapelberg]: Can you clarify what you mean by that?

164
00:10:01,670 --> 00:10:10,570
[question]: For example, status, or I was thinking more about something specific to a certain daemon?

165
00:10:10,830 --> 00:10:14,680
For instance, fetchmail can have an "awaken" option

166
00:10:14,680 --> 00:10:19,290
it does a sleep of 5 minutes or something, and you can say "check right now"

167
00:10:20,670 --> 00:10:22,750
[stapelberg]: What exactly is the question?  I still don't get it.

168
00:10:22,750 --> 00:10:26,170
[question]: Can you have some exec line in there --

169
00:10:26,170 --> 00:10:30,960
[stapelberg]: -- Oh, can we have a custom action, like in initscripts, is that what you mean?  No, we can't.

170
00:10:30,960 --> 00:10:35,250
There are different ways of coping with that:

171
00:10:35,250 --> 00:10:39,490
Most often there's an alternative to what you want to do

172
00:10:39,490 --> 00:10:46,920
But I think it's really clean and nice that they standardized on a few verbs, and all of these work with all of the services

173
00:10:47,030 --> 00:10:48,480
(except for the reload one, obviously)

174
00:10:48,480 --> 00:10:50,900
but you can't have really custom weird stuff.

175
00:10:50,900 --> 00:10:56,800
You could ship that in an additional shell script.  That's what I would usually use as a first suggestion

176
00:10:56,800 --> 00:11:01,430
if there's no specific, no better way of solving the problem.  But we can discuss that later on.

177
00:11:01,430 --> 00:11:03,430
for specific services that you might have in mind.

178
00:11:04,290 --> 00:11:07,120
Any more general questions up until here?

179
00:11:10,170 --> 00:11:18,470
[question]: Maybe you answered and I missed it, but about the possibility of querying the status of the service?

180
00:11:18,470 --> 00:11:23,470
[stapelberg]: Yes, obviously.  As I said, I will show that in the second part.

181
00:11:23,470 --> 00:11:26,950
Now, tmpfiles:

182
00:11:26,950 --> 00:11:30,670
The tmpfiles mechanism is really useful not only within systemd

183
00:11:30,670 --> 00:11:35,530
but also oftentimes when people read about it they think "hey, this could be useful standalone."

184
00:11:35,530 --> 00:11:43,850
What it does, is it provides a mechanism to configure creating temporary directories, like runtime directories.

185
00:11:43,850 --> 00:11:49,600
As a really simple example, I have here the lighttpd configuration file

186
00:11:49,600 --> 00:11:53,910
where we will essentially say "create a directory called /run/lighttpd"

187
00:11:53,910 --> 00:11:58,950
with this mode, this user, this group, and no more arguments.

188
00:11:58,950 --> 00:12:05,740
There are some arguments you could specify there, for cleaning it up every ten days or some delay like that

189
00:12:05,740 --> 00:12:11,270
that's all supported.  This mechanism is much more powerful than this very simple example.

190
00:12:11,270 --> 00:12:16,330
it can also support not only directories, but also files, pipes, symlinks, etc.

191
00:12:16,330 --> 00:12:22,320
I don't want to go into all of the details, but this is the preferred mechanism to create a /run/something

192
00:12:22,320 --> 00:12:28,610
and it's much much cleaner than having all these varying mkdir commands

193
00:12:28,610 --> 00:12:33,590
that sometimes specify a user and a group and sometimes they don't and then they don't have a mode, etc. etc.

194
00:12:33,590 --> 00:12:37,820
So this is what we want to use.  Question?

195
00:12:40,550 --> 00:12:46,540
[question]: There's no implicit conflict with other things, so I have to take care to do a proper namespace organization?

196
00:12:46,540 --> 00:12:51,250
and, for example, call my temporary directory like my service and not

197
00:12:51,250 --> 00:12:54,580
choose an arbitrary name which would perhaps clash with another service?

198
00:12:54,580 --> 00:12:59,050
[stapelberg]: Sure. I mean obviously you need to watch out for filesystem clashes in debian packages.

199
00:12:59,050 --> 00:13:00,870
That's just as it always has been.

200
00:13:00,870 --> 00:13:03,010
[question]: So it's the mechanism, you have to provide the policy.

201
00:13:03,010 --> 00:13:05,010
[stapelberg]: Yes, obviously.

202
00:13:05,010 --> 00:13:08,630
Alright -- service file location:

203
00:13:08,630 --> 00:13:14,860
oftentimes, the upstream provider ships a service file, and that's the way it's meant to be.

204
00:13:14,860 --> 00:13:22,190
because the upstream should know best how to install the service on a particular machine

205
00:13:22,190 --> 00:13:25,650
Now, that doesn't always happen

206
00:13:25,650 --> 00:13:29,050
but if it happens please use the upstream service file

207
00:13:29,280 --> 00:13:32,580
and if the upstream file is really broken, please work with upstream to fix it

208
00:13:32,580 --> 00:13:35,400
If it's broken in some minor detail, you might ask upstream

209
00:13:35,400 --> 00:13:38,730
if it's acceptable to change it in the way that it would be better

210
00:13:38,730 --> 00:13:44,040
I don't have any specific details; one example that would come to mind is that some

211
00:13:44,040 --> 00:13:49,560
upstream service files are actually pretty old -- like they were written in 2009 or something

212
00:13:49,560 --> 00:13:54,370
and by now they're, for example, referring to syslog.target as a dependency

213
00:13:54,370 --> 00:13:57,730
whereas syslog is autostarted nowadays by socket activation.

214
00:13:57,730 --> 00:14:00,860
So that could be removed, and then the service file would be simpler

215
00:14:00,860 --> 00:14:04,890
and more idiomatic, and that would be a typical change that you could push upstream

216
00:14:04,920 --> 00:14:09,260
I don't say that I expect any of you to know what the idiomatic service files

217
00:14:09,260 --> 00:14:13,570
are, and contribute that upstream; I'm just saying that it would be the right thing to do.

218
00:14:13,570 --> 00:14:14,340
Question?

219
00:14:14,410 --> 00:14:20,630
[question]: So you say just write the debian/packagename.service and .tmpfiles

220
00:14:20,630 --> 00:14:28,500
but most debhelpers also accept just debian/service and, just the type of the file

221
00:14:28,500 --> 00:14:34,650
without the package prefix if there's only one binary package -- is that supported?

222
00:14:34,650 --> 00:14:39,420
[stapelberg]: To be honest, I didn't test it, but i'm using the exact same debhelper plugin code

223
00:14:39,420 --> 00:14:42,450
that all the others are using, so I would expect it to be supported.

224
00:14:42,450 --> 00:14:45,410
What we also support, even though I didn't actually program it

225
00:14:45,440 --> 00:14:45,580
is "package.(and then some actual package name)" if it's only for a specific package in a set of all packages

226
00:14:45,580 --> 00:14:50,650
[ed: he means sourcepackgename.binarypackagename.service]
is "package.(and then some actual package name)" if it's only for a specific package in a set of all packages

227
00:14:50,650 --> 00:14:51,480
which is a typical debhelper feature in that sense.
[ed: he means sourcepackgename.binarypackagename.service]

228
00:14:51,480 --> 00:14:53,180
which is a typical debhelper feature in that sense.

229
00:14:53,180 --> 00:14:53,920
[question]: Thanks!

230
00:14:53,920 --> 00:14:54,590
[stapelberg]: Sure.
[question]: Thanks!

231
00:14:54,590 --> 00:14:55,230
[stapelberg]: Sure.

232
00:14:55,230 --> 00:15:00,670
Now, to actually cover that point, if upstream actually doesn't ship a service file and/or a tmpfile

233
00:15:00,670 --> 00:15:06,190
then you can just place them in debian/$yourpackagename.service and debian/$yourpackagename.tmpfile and it will be installed.

234
00:15:06,190 --> 00:15:10,290
It will be installed by dh_installinit, which might confuse you

235
00:15:10,290 --> 00:15:13,380
because dh_installinit is for initscripts and not for servicefiles

236
00:15:13,380 --> 00:15:17,120
and in fact, we by now have dh_systemd, so that's weird!

237
00:15:17,120 --> 00:15:17,250
The only reason why that is is because of historic reasons.
and in fact, we by now have dh_systemd, so that's weird!

238
00:15:17,250 --> 00:15:20,280
The only reason why that is is because of historic reasons.

239
00:15:20,280 --> 00:15:22,560
We first started implementing it in dh_installinit,

240
00:15:22,560 --> 00:15:22,630
but then it turned out that it would make the helper very complex and weird
We first started implementing it in dh_installinit,

241
00:15:22,630 --> 00:15:25,460
but then it turned out that it would make the helper very complex and weird

242
00:15:25,460 --> 00:15:25,560
and handling upstart and sysv and systemd all at the same time is really not a good idea
but then it turned out that it would make dhelper very complex and weird

243
00:15:25,560 --> 00:15:29,830
and handling upstart and sysv and systemd all at the same time is really not a good idea

244
00:15:29,830 --> 00:15:34,370
So we decided to leave it there for the time being, but eventually to migrate it

245
00:15:34,370 --> 00:15:39,510
If you use just the dh command it will all just work, you don't have to care

246
00:15:39,510 --> 00:15:44,960
In all the other cases, currently policy dictates that you still need to ship an initscript

247
00:15:45,060 --> 00:15:52,020
so that's all fine, and as soon as policy gets changed, I promise that we will be in a state where you don't have to care about this either.

248
00:15:52,020 --> 00:15:57,000
I already mentioned to please send service files upstream, but I'll just stress it again.

249
00:15:57,030 --> 00:16:01,230
Not only if you have an upstream service file and modify it and fix it, please send it upstream

250
00:16:01,230 --> 00:16:05,400
but also, if you create a service file, please send it upstream so that upstream can distribute it.

251
00:16:05,400 --> 00:16:09,670
Some upstream software might not agree; some are actually very thankful.

252
00:16:09,670 --> 00:16:11,490
Question over there

253
00:16:11,520 --> 00:16:16,970
[question]: Assuming upstream ships a valid service file, what's the best practice:

254
00:16:16,970 --> 00:16:21,910
Is it to call dh_installinit specifying the path in the upstream directory,

255
00:16:21,910 --> 00:16:22,320
or copying it into the debian directory before dh_installinit is invoked?
Is it to call dh_installinit specifying the path in the upstream directory,

256
00:16:22,320 --> 00:16:27,430
or copying it into the debian directory before dh_installinit is invoked?

257
00:16:27,430 --> 00:16:34,560
[stapelberg]: In case upstream installs it, just let upstream install it. I'm not sure I get the question.

258
00:16:34,860 --> 00:16:40,510
[question]: The question is: in case upstream does not install it; they ship it, but they do not install it?

259
00:16:40,510 --> 00:16:47,060
[stapelberg]: OK, in case they don't install it, and then what is the second part of your question?  just put it in debian/ as I explained.

260
00:16:48,110 --> 00:16:53,450
[question]: So you can put it manually in debian/ before dh_installinit is invoked.

261
00:16:53,450 --> 00:16:54,110
Or you can invoke dh_installinit with the path from the upstream directory

262
00:16:54,110 --> 00:16:55,090
[stapelberg]: Oh, right, yes.
Or you can invoke dh_installinit with the path from the upstream directory

263
00:16:55,090 --> 00:16:59,000
Or you can invoke dh_installinit with the path from the upstream directory

264
00:16:59,000 --> 00:17:03,290
So if upstream doesn't install it, but ship it

265
00:17:03,290 --> 00:17:03,470
[question]: Yes.
So if upstream doesn't install it, but ship it

266
00:17:03,470 --> 00:17:03,750
[stapelberg]: Yeah, you could either manually copy it before, or just use what you suggest.
[question]: Yes.

267
00:17:03,750 --> 00:17:09,830
[stapelberg]: Yeah, you could either manually copy it before, or just use what you suggest.

268
00:17:09,830 --> 00:17:11,830
Any more questions?

269
00:17:13,160 --> 00:17:14,700
Great, let's move on.

270
00:17:15,340 --> 00:17:23,180
Getting your service enabled: I already mentioned that just as with update-rc.d you need to enable services

271
00:17:23,180 --> 00:17:29,160
and the easiest way, if you already have a service file shipped by upstream

272
00:17:29,330 --> 00:17:32,630
or if you put your own service file into debian/package.service

273
00:17:32,630 --> 00:17:35,650
is you add a build dependency on dh-systemd

274
00:17:35,650 --> 00:17:38,980
and then you use the dh command, which you hopefully already use

275
00:17:38,980 --> 00:17:42,510
and add the --with=systemd flag

276
00:17:42,510 --> 00:17:45,670
and then all automatically happens and it will just work.

277
00:17:45,670 --> 00:17:50,780
The maintainer scripts that are generated

278
00:17:50,780 --> 00:17:54,410
as part of that package build will contain the appropriate code

279
00:17:54,410 --> 00:18:00,900
they will call a binary called deb-systemd-helper instead of systemctl as I mentioned earlier

280
00:18:00,900 --> 00:18:07,360
which avoids having a dependency on systemd on all the packages which is probably politically not a good move.

281
00:18:08,940 --> 00:18:17,010
If you are not using dh, you can also add the dh_systemd_enable and dh_systemd_start calls directly

282
00:18:17,010 --> 00:18:22,050
in the wiki we have instructions, and the link is provided on these slides.

283
00:18:22,050 --> 00:18:26,260
To test your package -- oh, a question here?

284
00:18:26,260 --> 00:18:30,970
[question]: So you mentioned the deb-systemd-helper maintainer scripts

285
00:18:30,970 --> 00:18:37,220
I know the scope of systemd is broader than sysvinit, but

286
00:18:37,220 --> 00:18:41,490
in the sysvinit world, policy recommends

287
00:18:41,590 --> 00:18:49,590
whether or not you are using sysvinit, including other things like sysvrc or openrc or a few of the other minor ones

288
00:18:49,590 --> 00:18:53,090
(and I think also upstart) they recommend

289
00:18:53,160 --> 00:18:59,650
using invoke-rc.d and update-rc.d in debian maintainer scripts as a way of

290
00:18:59,650 --> 00:19:03,650
both abstracting from the specific system and for

291
00:19:03,650 --> 00:19:09,130
handling the case where you're debootstrapping and the daemons are not running because of policy-rc.d

292
00:19:09,130 --> 00:19:12,960
so the question is: why this instead of those

293
00:19:12,960 --> 00:19:19,390
and if policy-rc.d is configured to not start or stop, will this respect that?

294
00:19:19,390 --> 00:19:26,310
[stapelberg]: We have another of these helpers called deb-systemd-invoke which is for the invoke-rc.d part

295
00:19:26,310 --> 00:19:30,820
and it will try to respect policy.  Unfortunately, policy is really hard

296
00:19:30,850 --> 00:19:35,020
It's a really horrible standard -- it's underdocumented and I had a really hard time figuring out how it works

297
00:19:35,020 --> 00:19:37,540
so it will support the use cases I could identify

298
00:19:37,540 --> 00:19:40,910
and if you have use cases that are broken please talk to me and we can try to fix it

299
00:19:40,910 --> 00:19:52,470
Also, to answer the first part of your question, update-rc.d is really hard to have a good solution in there

300
00:19:52,470 --> 00:19:59,030
we tried implementing it in there, but it turned out to not work that well, and upstream is not that responsive to our concerns.

301
00:19:59,030 --> 00:20:06,960
so we actually chose to implement a separate helper that we have under tight control and can release independently of sysvrc

302
00:20:06,960 --> 00:20:12,280
which turned out to be a much better solution because we already refactored it once and iterated on it

303
00:20:12,280 --> 00:20:15,740
quite a few times, and by now it's actually in a pretty good state.

304
00:20:15,740 --> 00:20:18,130
So that's why.

305
00:20:18,500 --> 00:20:23,470
Alright! So, to test your package, which is actually the most interesting part

306
00:20:23,540 --> 00:20:30,230
you will just install systemd, and then you can boot with the init=/bin/systemd kernel parameter

307
00:20:30,230 --> 00:20:35,480
Installing systemd does not involve breaking sysvinit or anything

308
00:20:35,480 --> 00:20:38,670
there's no conflicts in that package, you can still have both of them.

309
00:20:38,670 --> 00:20:41,160
If you just install systemd, nothing will happen.

310
00:20:41,160 --> 00:20:45,160
If you boot with init=/bin/systemd, you will actually use systemd

311
00:20:45,160 --> 00:20:48,390
so that distinction is important.  You can always switch back and forth.

312
00:20:48,390 --> 00:20:50,910
So testing it is really simple. you just reboot.

313
00:20:50,910 --> 00:20:54,040
You could reboot in a vm if you don't like to reboot your main machine.

314
00:20:54,170 --> 00:20:58,650
Then what you would typically do is you check that your service starts properly on boot

315
00:20:58,650 --> 00:21:04,460
You would probably check the reload action, check stop, start, restart, and that's about it, I would say.

316
00:21:04,500 --> 00:21:10,850
because there's really not that much more to it, except if your service makes use of really advanced features and all that stuff.

317
00:21:10,920 --> 00:21:20,770
In general, I would say that your users will report bug reports if your service does not work with systemd right now

318
00:21:20,770 --> 00:21:25,750
There are plenty of users of systemd and debian that care enough to submit bug reports.

319
00:21:25,750 --> 00:21:30,150
So it's not expected of you to test it all the time

320
00:21:30,150 --> 00:21:35,430
and convert all your systems and run it all the time; a brief test will be enough.

321
00:21:36,980 --> 00:21:40,580
Now to an advanced example:

322
00:21:40,580 --> 00:21:46,460
There's actually a few more features that were maybe already mentioned if you listened to the previous talk by Lennart

323
00:21:46,460 --> 00:21:51,340
We have a nice service called debian codesearch which I happen to maintain

324
00:21:51,340 --> 00:21:54,160
And the service file is actually much more complicated.

325
00:21:54,160 --> 00:21:56,920
It not only specifies a user and a group

326
00:21:56,920 --> 00:21:59,940
It also has some arguments in here, and you can see that

327
00:21:59,940 --> 00:22:04,350
the service file format supports line wrapping, so if your command line is pretty long

328
00:22:04,420 --> 00:22:07,210
then it might make sense to wrap it and have it really nice.

329
00:22:07,210 --> 00:22:12,690
Also, we have standard output redirected to /dev/null because it's really noisy

330
00:22:12,690 --> 00:22:17,660
and mostly used for debugging.  so when I feel like debugging, I can just change that to get standard output

331
00:22:17,660 --> 00:22:20,350
but in the default case I just want standard error

332
00:22:20,350 --> 00:22:26,410
Now also, my service does not actually care to log to syslog, so I say that standard error should go to the journal

333
00:22:26,410 --> 00:22:29,030
which will then end up in the syslog.

334
00:22:29,330 --> 00:22:37,400
Also, I cannot obviously exclude that there are bugs, but I also cannot sit in front of a computer 24/7 and restart my server if it crashes

335
00:22:37,400 --> 00:22:43,590
So what I want is that whenever it fails (that is, it exits with an exit code that is not 0)

336
00:22:43,590 --> 00:22:45,510
I want it to just wait a second and then restart it.

337
00:22:46,720 --> 00:22:52,300
So far I think in production I only restarted my servers once

338
00:22:52,330 --> 00:22:57,210
and then promptly fixed the bug so most of the time it's perfect, but you know: better safe than sorry!

339
00:22:57,210 --> 00:23:02,320
The other parts of the unit file are probably clear by now

340
00:23:02,320 --> 00:23:06,350
and what you will see in practice is that most of the service files really look

341
00:23:06,350 --> 00:23:09,820
kind of the same.  It's pretty simple, they're pretty short

342
00:23:09,820 --> 00:23:12,340
they all use the same features.

343
00:23:12,340 --> 00:23:16,070
One more interesting feature that you should be aware of

344
00:23:16,070 --> 00:23:22,490
Who of you -- show of hands -- maintains a package that ships a dbus service?

345
00:23:22,490 --> 00:23:25,450
one or two?  OK

346
00:23:25,450 --> 00:23:28,550
For the others, this is more of an academic interest

347
00:23:28,550 --> 00:23:32,510
but systemd can actually care about dbus-activated services

348
00:23:32,510 --> 00:23:37,760
so whereas dbus usually would start on its own in older versions

349
00:23:37,760 --> 00:23:40,380
nowadays it's better to use systemd for it

350
00:23:40,380 --> 00:23:45,490
because then it all ends up in the same hierarchy and it all gets tracked and you get all the benefits and stuff

351
00:23:45,530 --> 00:23:50,100
so what you do is you add Type=dbus and you specify the BusName

352
00:23:50,100 --> 00:23:54,170
and you don't have an [Install] section -- it's not missing on the slide, it's just not there.

353
00:23:54,170 --> 00:23:59,110
and then systemd will activate that service whenever that bus name is actually accessed.

354
00:24:03,280 --> 00:24:08,320
This is a more advanced example of the dh_systemd debhelper plugin

355
00:24:08,320 --> 00:24:14,040
what we do here is we install a service that should not actually be installed by default.

356
00:24:14,140 --> 00:24:21,440
and the way we do this is we override the dh_systemd_enable target and specify the --no-enable flag

357
00:24:21,440 --> 00:24:25,340
This should not be a surprise to any of you who has been using debhelper in the past

358
00:24:25,340 --> 00:24:29,840
I just wanted to mention it and make sure that you understand what the options are here.

359
00:24:29,840 --> 00:24:33,140
-- I will answer that in a second --

360
00:24:33,140 --> 00:24:37,850
The second example here is for the second part of the dh_systemd debhelper plugin

361
00:24:37,850 --> 00:24:39,850
It's dh_systemd_start

362
00:24:39,850 --> 00:24:45,350
and what I specify here is the --restart-after-upgrade flag which will make sure that the package does not get stopped

363
00:24:45,350 --> 00:24:49,010
then replaced then started, but will just get replaced and then restarted afterward

364
00:24:49,010 --> 00:24:52,610
which is kind of cleaner, but the package needs to support it.  Question?

365
00:24:52,610 --> 00:25:00,210
[question]: Why do you call the dh_systemd_enable with an option of --no-enable

366
00:25:00,210 --> 00:25:03,370
instead of just leaving the target empty?

367
00:25:03,370 --> 00:25:07,710
[stapelberg]: That's an excellent question, and the comment above tries to somewhat explain it

368
00:25:07,710 --> 00:25:10,260
The thing is that when you purge the package

369
00:25:10,260 --> 00:25:15,570
if the user decided to enable it even though you ship it disabled by default

370
00:25:15,570 --> 00:25:17,860
then you need to clean up the symlinks

371
00:25:17,860 --> 00:25:21,460
So that's what dh_systemd_enable also generates maintainer scripts for

372
00:25:21,530 --> 00:25:24,250
So that still needs to run, so we can't just skip it.

373
00:25:24,250 --> 00:25:26,600
In the first version we tried, but it didn't work out.

374
00:25:26,600 --> 00:25:28,600
More questions?

375
00:25:31,850 --> 00:25:33,190
In the back?

376
00:25:35,310 --> 00:25:40,420
[question]: You mentioned services triggered by dbus actions

377
00:25:40,420 --> 00:25:40,790
[stapelberg]: Yes

378
00:25:40,790 --> 00:25:44,090
[question]: Is there a way to disable them even if the service is installed?

379
00:25:44,090 --> 00:25:47,420
[stapelberg]: Yes, you can mask any service.  I can show you that later.

380
00:25:47,420 --> 00:25:51,120
One more question?

381
00:25:51,590 --> 00:25:56,400
[question]: So you say --restart-after-upgrade; how does restart -- I guess this is more general, but it's prompted by this

382
00:25:56,400 --> 00:25:59,830
how does restart work if the service is not running?

383
00:26:01,910 --> 00:26:04,470
[stapelberg]: That's a good question. I would have to really look it up.

384
00:26:04,470 --> 00:26:09,270
I think there is a try-restart action

385
00:26:09,270 --> 00:26:13,010
that would restart if it's running

386
00:26:13,010 --> 00:26:15,010
but not start it if it's not running

387
00:26:15,010 --> 00:26:19,530
[question]: For example, in this case you set up the service to

388
00:26:19,530 --> 00:26:23,430
remain disabled upon install in this example

389
00:26:23,430 --> 00:26:26,490
so if you install the package it is not enabled

390
00:26:26,490 --> 00:26:26,520
Then the user takes no action
so if you install the package it is not enabled

391
00:26:26,520 --> 00:26:28,520
Then the user takes no action

392
00:26:28,520 --> 00:26:30,930
and then they upgrade their system

393
00:26:30,930 --> 00:26:34,060
and a new version of the package is installed, it tries to restart?

394
00:26:34,060 --> 00:26:40,240
[stapelberg]: The thing is, as I was saying, there is a restart action in systemctl and there is a try-restart

395
00:26:40,240 --> 00:26:44,610
The difference is try-restart will only restart it if it's running, which probably answers your question

396
00:26:44,610 --> 00:26:46,830
The caveat is that

397
00:26:46,830 --> 00:26:50,730
currently, if you maintain a package that ships

398
00:26:50,730 --> 00:26:58,270
a system V initscript and a systemd service file, it will still use invoke-rc.d for the actual starting/restarting etc.

399
00:26:58,270 --> 00:27:03,680
And the invoke-rc.d actually has code to divert that to systemd

400
00:27:03,810 --> 00:27:07,750
but the problem is it's not flexible enough to use try-restart and the fancy stuff

401
00:27:07,750 --> 00:27:11,280
so this might need some actual hand-tweaking or just ignoring it for now.

402
00:27:12,320 --> 00:27:18,810
Alright!  So before we enter the questions and hands-on part of this workshop

403
00:27:18,810 --> 00:27:24,090
I just want to make sure that you're all aware that we will provide help

404
00:27:24,090 --> 00:27:28,090
There is a wiki page which is linked here called https://wiki.debian.org/Systemd/Packaging

405
00:27:28,090 --> 00:27:32,600
which contains most of the information hopefully, or at least pointers

406
00:27:32,600 --> 00:27:38,210
We have an irc channel on irc.debian.org called #debian-systemd

407
00:27:38,210 --> 00:27:40,300
where you can just stop by at any time

408
00:27:40,300 --> 00:27:44,400
Most of the time there's somebody around who actually knows how to write service files and stuff

409
00:27:44,400 --> 00:27:49,640
There is a mailing list that we are all active and we really do mean it

410
00:27:49,640 --> 00:27:53,540
Please ask! Also, during debconf, if there is at any time any questions

411
00:27:53,540 --> 00:27:56,130
from any of you or from your friends

412
00:27:56,130 --> 00:27:59,560
please ask.  we're here for answering these sorts of questions.

413
00:27:59,560 --> 00:28:03,940
Now just one more quick note: finding documentation

414
00:28:03,940 --> 00:28:06,560
There are manpages -- a lot of manpages

415
00:28:06,560 --> 00:28:10,860
They are roughly categorized by the sections I previously showed in service files

416
00:28:10,860 --> 00:28:14,860
So there's a systemd.service, there's a systemd.exec, etc.

417
00:28:14,860 --> 00:28:21,990
There's also an overview on the freedesktop.org web site (http://www.freedesktop.org/wiki/Software/systemd/) where it points to all the documentation

418
00:28:21,990 --> 00:28:27,000
The particularly interesting parts of that are the systemd for administrators blog series

419
00:28:27,000 --> 00:28:32,950
where Lennart talks about a lot of features that are interesting and how to actually make use of them in your service files

420
00:28:32,950 --> 00:28:36,990
And then there's a link for package repositories for the various distributions

421
00:28:36,990 --> 00:28:41,530
where you can just look if there already is a service file for that particular package that you maintain

422
00:28:41,530 --> 00:28:43,610
even though it doesn't ship one upstream

423
00:28:43,610 --> 00:28:48,860
So the best thing in that case would also be to adopt the service file and then also make upstream accept that.

424
00:28:48,960 --> 00:28:58,640
Alright! That's the talk part so far.  Now I'm ready to answer any questions or look at any packages

425
00:29:00,760 --> 00:29:03,590
[question]: What are the plans for backports?

426
00:29:03,590 --> 00:29:10,080
I mean if you want to make backports to wheezy, can we use  the dh_systemd helper?

427
00:29:10,080 --> 00:29:14,210
[stapelberg]: Yes, the dh_systemd helper is available in wheezy backports

428
00:29:14,210 --> 00:29:22,480
Be aware that the systemd version in wheezy is version 44, and we're currently trying to get version 204, which is much more recent

429
00:29:22,480 --> 00:29:26,650
into debian -- it had a version jump because of udev.

430
00:29:26,650 --> 00:29:30,550
So it's not that much more recent, it's just more recent.

431
00:29:30,550 --> 00:29:36,340
So there might be issues and it's up to you if you decide to commit to maintaining support

432
00:29:36,340 --> 00:29:41,510
for that old systemd version with your service files in wheezy, just so you know.

433
00:29:42,460 --> 00:29:49,180
If there is no immediate question, I would just go on to show you a little bit of stuff and we can answer questions as we go

434
00:29:49,180 --> 00:30:00,710
[question]: I have to prepend that at the moment I'm not maintaining any package that has to start daemons at poweron

435
00:30:00,710 --> 00:30:04,140
So I know nearly nothing about it.

436
00:30:04,140 --> 00:30:09,960
But I am a bit confused.  Since I understand there are a lot of these kind of systems

437
00:30:09,960 --> 00:30:14,000
systemd, sysvinit, and so on

438
00:30:14,000 --> 00:30:20,720
As a package maintainer, what do I have to do

439
00:30:20,720 --> 00:30:24,590
if I want to support all of them, I have to provide

440
00:30:24,590 --> 00:30:29,970
the script or description file that they need for each of them

441
00:30:29,970 --> 00:30:30,910
[stapelberg]: -- to answer this, the policy mandates --
the script or description file that they need for each of them

442
00:30:30,910 --> 00:30:32,420
[stapelberg]: -- to answer this, the policy mandates --

443
00:30:32,420 --> 00:30:32,990
[question]: For example, just to complete the question, in particular if we consider just sysvinit, it is one that we have
[stapelberg]: -- to answer this, the policy mandates --

444
00:30:32,990 --> 00:30:39,180
[question]: For example, just to complete the question, in particular if we consider just sysvinit, it is one that we have

445
00:30:39,180 --> 00:30:43,080
by default, and systemd, which we are discussing now

446
00:30:43,080 --> 00:30:48,060
If I want to provide a systemd information file

447
00:30:48,060 --> 00:30:56,400
Do I also have to provide a sysvinit scripts

448
00:30:56,400 --> 00:31:02,150
or is there some compatibility layer that enables me to write one thing

449
00:31:02,150 --> 00:31:09,110
and (at least in common cases) expect some magic to make it work for other systems

450
00:31:09,110 --> 00:31:13,750
[stapelberg]: OK, I would be happy to answer that after the talk because that's not really the focus of this talk.

451
00:31:13,750 --> 00:31:18,090
So now, let me just show you a few handy things that might be useful

452
00:31:18,090 --> 00:31:22,120
I have a terminal here that you hopefully can read in the back

453
00:31:22,120 --> 00:31:26,560
Is that OK? Great!  So let's just have a look at

454
00:31:26,560 --> 00:31:33,320
thinkfan.service and what I was using here is the systemctl command and you can see multiple interesting things

455
00:31:33,320 --> 00:31:36,410
First of all, it is active and running, so that's good.

456
00:31:36,410 --> 00:31:40,010
It shows that I started it 6 days ago, when I last rebooted my laptop

457
00:31:40,010 --> 00:31:45,830
It also shows the main pid, which is 2588, and that's the binary that corresponds to it.

458
00:31:45,930 --> 00:31:49,930
For more complex services, there are more binaries in the cgroup hierarchy

459
00:31:49,930 --> 00:31:53,730
What is particularly interesting for you is

460
00:31:53,730 --> 00:31:58,370
first of all, where the service file actually lives; so make sure you ship it to the correct path.

461
00:31:58,370 --> 00:32:03,710
There's also a lintian warning for that, so if you use lintian you should catch that

462
00:32:03,710 --> 00:32:07,310
It should go to /lib/systemd/system, as I mentioned

463
00:32:07,310 --> 00:32:12,730
It also should be enabled unless, of course, you decided to not enable it by default

464
00:32:14,510 --> 00:32:20,260
Now, I can just show you systemctl stop, it will be that

465
00:32:20,260 --> 00:32:25,710
[question]: the video projector does not show all of the terminal

466
00:32:25,710 --> 00:32:30,920
[stapelberg]: That is a good point.  The first two columns are not shown, so let's make it like this

467
00:32:30,920 --> 00:32:32,770
Should be much better!

468
00:32:32,770 --> 00:32:37,100
Not perfect.  Better?

469
00:32:37,100 --> 00:32:43,900
[question, unintelligible]

470
00:32:43,900 --> 00:32:45,910
[stapelberg]: Yeah, whatever.  That's good enough.

471
00:32:45,910 --> 00:32:53,610
thinkfan.service -- now it's still enabled.  It's still loaded but it's inactive because I stopped it

472
00:32:53,610 --> 00:32:58,490
I can start it again

473
00:32:58,490 --> 00:32:59,900
check that it's started

474
00:32:59,900 --> 00:33:03,370
You can also see that it used this ExecStart line

475
00:33:03,370 --> 00:33:07,270
I can also actually show you the service file.  There's really no magic in here.

476
00:33:07,270 --> 00:33:14,460
There is an ExecReload directive here, so we can test if the reload actually works

477
00:33:14,460 --> 00:33:17,490
Which I need to do as root

478
00:33:17,490 --> 00:33:21,660
And then in the status output we will see that it tried to reload the service

479
00:33:21,660 --> 00:33:25,560
code=exited, status = 0/SUCCESS, so that worked.

480
00:33:25,560 --> 00:33:30,530
So those are a few simple things you can check to see if your service actually works

481
00:33:30,530 --> 00:33:36,520
10 minutes, yes.  Are there any questions now?  Microphone?

482
00:33:39,010 --> 00:33:48,120
[question]: The example has Type=forking.  What are the other values which are valid?

483
00:33:49,030 --> 00:33:54,140
[stapelberg]: So that was obviously a suggestion to open the man page and show you that actually it is documented

484
00:33:55,590 --> 00:33:59,320
The manpage in question here is systemd.service, as I tried to explain earlier

485
00:33:59,320 --> 00:34:01,910
There's multiple Types -- there is simple

486
00:34:01,910 --> 00:34:04,900
There's forking, oneshot, dbus, notify or idle

487
00:34:04,900 --> 00:34:08,160
The most interesting ones are simple, forking, oneshot, and dbus

488
00:34:08,160 --> 00:34:11,320
dbus I already explained -- that's if you have an actual dbus service

489
00:34:11,320 --> 00:34:16,200
There's oneshot, which is for stuff like doing one thing and then nothing

490
00:34:16,200 --> 00:34:20,170
like, it's not a permanently running service, it's just a simple command like a shell script

491
00:34:20,170 --> 00:34:24,810
and then it will stay active, as in "started" afterwards

492
00:34:25,040 --> 00:34:28,570
There is forking and there is simple.  The difference between simple and forking

493
00:34:28,570 --> 00:34:35,670
is that simple will -- the daemon you're starting, if it's a Type=simple one

494
00:34:35,670 --> 00:34:40,740
should just continue running in the foreground, whereas a forking one will fork itself into background.

495
00:34:40,840 --> 00:34:44,380
The preferred model is using simple because, you know, it's simple.

496
00:34:44,380 --> 00:34:48,780
forking has the implicit assumption, and I think this is important to know, that

497
00:34:48,780 --> 00:34:53,620
as long as the daemon is still running in the foreground, it's not ready

498
00:34:53,620 --> 00:34:58,830
The unit file will be considered started precisely at the moment where the daemon forks.

499
00:34:58,830 --> 00:35:03,780
That is not necessarily what your upstream software implements, but that's how it's

500
00:35:03,780 --> 00:35:05,780
[question, unintelligible]

501
00:35:05,780 --> 00:35:10,570
[stapelberg]: The question was: when it forks, or when the main process exits?

502
00:35:10,570 --> 00:35:14,770
Obviously, I think when the main process exits.

503
00:35:16,120 --> 00:35:17,390
[question]: It would be really strange in the other case

504
00:35:17,390 --> 00:35:23,140
[stapelberg]: That's how it usually works, right?  You double-fork and then you exit the main process.

505
00:35:23,140 --> 00:35:25,230
More questions?

506
00:35:28,190 --> 00:35:31,520
Masking processes -- perfect, let's do that!

507
00:35:31,520 --> 00:35:35,350
So I have thinkfan and I now decide

508
00:35:35,350 --> 00:35:39,490
That it's really a shame that my fan is not spinning up as much as I would like

509
00:35:39,490 --> 00:35:44,130
So what I will just do is I will mask thinkfan.service and it will helpfully

510
00:35:44,130 --> 00:35:50,380
print out what it actually did, which is it just created a symlink in /etc/systemd/system/thinkfan.service

511
00:35:50,620 --> 00:35:51,790
pointing to /dev/null

512
00:35:53,240 --> 00:35:57,580
Essentially, it will try to load that service file but fail, because it can't read /dev/null.

513
00:35:57,580 --> 00:36:00,700
So if I now check status

514
00:36:00,700 --> 00:36:03,860
on thinkfan.service, it will tell me that it's masked

515
00:36:03,860 --> 00:36:08,370
but it's also still running.  So if I now do systemctl stop

516
00:36:08,370 --> 00:36:13,280
and then status, it's now dead, and it will not be started on my next boot.

517
00:36:13,280 --> 00:36:21,110
This is different from enable and disable because it also works for dbus services  and it's really like the last resort

518
00:36:21,110 --> 00:36:25,350
If you really really don't want this thing to be started, mask it.  Question?

519
00:36:27,270 --> 00:36:34,500
[question]: In this case, you cannot start it by hand, you have another method implemented in systemd

520
00:36:34,500 --> 00:36:46,670
[question]: If I want it to not start at boot, but I want to be able to run it by hand

521
00:36:46,670 --> 00:36:53,190
[stapelberg]: Yes, then you obviously disable it because disable just means don't start it at boot, but you can still start and stop and restart and all that stuff

522
00:36:53,190 --> 00:36:56,620
masked is really "don't start this at all"

523
00:36:56,620 --> 00:37:02,940
So now, because I don't like loud fans, let me just unmask that

524
00:37:04,050 --> 00:37:09,700
So it told me that it deleted that symlink, and I can start it again and it will just work.

525
00:37:10,710 --> 00:37:14,110
More questions please?  Over there.

526
00:37:15,750 --> 00:37:23,290
[question]: When it's active, it says "active (running)" or it says "inactive (dead)"

527
00:37:23,290 --> 00:37:29,680
Is there any particular meaning that there is a part "active" and a part in parenthesis?

528
00:37:29,680 --> 00:37:34,280
[stapelberg]: It could be "active (exited)" and that would be the case for the oneshot services

529
00:37:34,280 --> 00:37:40,230
that just fork one command, then exited, but the unit is still considered active because the command succeeded.

530
00:37:41,110 --> 00:37:42,860
More questions over here?

531
00:37:45,950 --> 00:37:52,570
[question]: Is there any support for -- what happens when a daemon dies, is it restarted, like a few times, or ?

532
00:37:52,570 --> 00:37:56,310
[stapelberg]: I actually had this on my slides earlier

533
00:37:57,350 --> 00:38:02,860
Yes: more features, here we go.  You can specify RestartSec=1 and Restart=on-failure

534
00:38:02,860 --> 00:38:06,730
There's more options in that direction to restart stuff when it dies

535
00:38:07,440 --> 00:38:10,160
More questions please?  Here.

536
00:38:10,830 --> 00:38:14,360
[question]: It's about the packaging

537
00:38:14,500 --> 00:38:20,520
Is it possible to use dpkg triggers -- instead we just put a file in /lib/systemd

538
00:38:20,550 --> 00:38:22,770
And then the dpkg trigger happens

539
00:38:22,770 --> 00:38:27,980
It means it will work with other packaging systems like cdbs without modification

540
00:38:27,980 --> 00:38:28,450
[stapelberg]: we actually have sent a patch to cdbs and it supports dh_systemd by now.
It means it will work with other packaging systems like cdbs without modification

541
00:38:28,450 --> 00:38:33,500
[stapelberg]: we actually have sent a patch to cdbs and it supports dh_systemd by now.

542
00:38:33,500 --> 00:38:37,090
[question]: OK, but why are you not using trigger support?

543
00:38:37,090 --> 00:38:38,170
[stapelberg]: Not using what, sorry?

544
00:38:38,170 --> 00:38:44,420
[question]: Instead of inserting a debhelper snippet in postinst

545
00:38:44,420 --> 00:38:46,640
you could have registered a trigger

546
00:38:47,820 --> 00:38:47,890
[stapelberg]: It's more complicated than that because

547
00:38:47,890 --> 00:38:49,500
[question]: It will be executed when it detects a file appearing in some allocation
[stapelberg]: It's more complicated than that because

548
00:38:49,500 --> 00:38:54,410
[question]: It will be executed when it detects a file appearing in some allocation

549
00:38:54,410 --> 00:38:57,070
[stapelberg]: Yeah, but we don't want to enable all the services by default

550
00:38:57,070 --> 00:39:00,130
And then we would need to maintain a whitelist or a blacklist of services

551
00:39:00,130 --> 00:39:02,210
and stuff, and it really needs to be more flexible than that

552
00:39:02,210 --> 00:39:04,210
OK, more questions?

553
00:39:06,410 --> 00:39:07,260
Another one?

554
00:39:08,230 --> 00:39:12,740
[question]: This time it's for services that need several instances

555
00:39:12,870 --> 00:39:14,740
Like stunnel

556
00:39:15,190 --> 00:39:16,500
[stapelberg]: Oh, multiple instances, yes

557
00:39:16,500 --> 00:39:22,620
[question]: Yes, multiple instances; usually they come with several configuration files

558
00:39:22,760 --> 00:39:26,320
And we want one instance per configuration file

559
00:39:26,320 --> 00:39:29,620
And be able to control them separately

560
00:39:29,620 --> 00:39:30,460
[stapelberg]: Yes, so there are actually --

561
00:39:30,460 --> 00:39:32,170
[question]: It's a bummer[?] to do that with sysV
[stapelberg]: Yes, so there are actually --

562
00:39:32,170 --> 00:39:34,050
[question]: It's a bummer[?] to do that with sysV

563
00:39:34,050 --> 00:39:34,170
[stapelberg]: There are good examples here of how that works.  There's ifup and there's getty
[question]: It's a bummer[?] to do that with sysV

564
00:39:34,170 --> 00:39:37,280
[stapelberg]: There are good examples here of how that works.  There's ifup and there's getty

565
00:39:37,280 --> 00:39:38,800
Let me just show you getty

566
00:39:38,830 --> 00:39:42,560
which has getty@tty1.service

567
00:39:42,660 --> 00:39:44,560
and what's interesting is you can see that

568
00:39:44,560 --> 00:39:47,170
the service file path actually does not include that

569
00:39:47,170 --> 00:39:49,190
so if you have a look at the service file

570
00:39:49,190 --> 00:39:51,880
You can see that it's much more complicated than I would like it to be

571
00:39:51,880 --> 00:39:56,580
But the interesting part for us is that there's %I

572
00:39:56,580 --> 00:39:59,680
which will be replaced with whatever you specify after the @

573
00:39:59,680 --> 00:40:05,590
So you can make your service file contain the @

574
00:40:05,830 --> 00:40:09,930
in the filename and then use %I and then start a specific instance of that

575
00:40:11,680 --> 00:40:15,580
[question]: And the user is expected to create all the @ files?

576
00:40:15,580 --> 00:40:17,530
[stapelberg]: Yes

577
00:40:18,170 --> 00:40:20,020
OK! More questions?

578
00:40:24,360 --> 00:40:25,100
Here.

579
00:40:26,980 --> 00:40:29,640
[question]: How about this socket-based activation?

580
00:40:29,640 --> 00:40:31,920
[stapelberg]: Socket activation -- that is a good question!

581
00:40:31,920 --> 00:40:37,640
Let me just have a look if I have any socket activation files lying around here

582
00:40:37,640 --> 00:40:42,350
I have approx.socket, which seems kind of appropriate for this conference.

583
00:40:43,460 --> 00:40:45,880
Socket activation essentially works like this, where you have

584
00:40:45,880 --> 00:40:49,070
[Socket] instead of [Service] in your service file

585
00:40:49,950 --> 00:40:51,160
In your socket file, sorry

586
00:40:52,130 --> 00:40:55,120
You specify a TCP port

587
00:40:55,120 --> 00:40:57,850
or a unix socket or whatever it should listen on

588
00:40:57,850 --> 00:41:00,240
And then there is Accept=yes

589
00:41:00,240 --> 00:41:02,760
where the default is Accept=no

590
00:41:02,760 --> 00:41:07,160
The difference is that Accept=yes mimics the inetd-style behavior

591
00:41:07,160 --> 00:41:10,590
of just starting one process per connection, which is kind of wasteful

592
00:41:10,590 --> 00:41:14,090
and the actual real good socket activation is

593
00:41:14,090 --> 00:41:17,790
not having that, but patching the service to

594
00:41:17,790 --> 00:41:21,350
when being started, inherit the file descriptor

595
00:41:21,350 --> 00:41:25,960
of the socket and then just integrate it in its event loop and handle that.

596
00:41:25,960 --> 00:41:28,380
And many services are already patched for that.

597
00:41:28,650 --> 00:41:32,750
Some of them are patched, but not in debian, and some of them you would need to patch.

598
00:41:32,750 --> 00:41:35,310
But this is really a thing of like an hour or two.

599
00:41:35,310 --> 00:41:37,260
I did it for bacula once, for example.

600
00:41:38,400 --> 00:41:39,680
OK.  Question over here?

601
00:41:42,200 --> 00:41:46,300
[question]: So the socket file just includes information about where to listen

602
00:41:46,300 --> 00:41:51,350
And if to accept or not, or to start.  Is that just in the service file then?

603
00:41:51,350 --> 00:41:55,620
[stapelberg]: Yes, the socket file has to match, by name, the service file

604
00:41:55,620 --> 00:42:00,860
And because I used Accept=yes, it needs to be approx@.service, not approx.service

605
00:42:00,860 --> 00:42:06,910
And then this will in turn just take the standard input from the socket, like inetd does, and start it up.

606
00:42:07,990 --> 00:42:08,860
One more question?

607
00:42:08,860 --> 00:42:12,230
[question]: Why do I have to add the @?

608
00:42:12,230 --> 00:42:20,800
[stapelberg]: Because if you use inetd-style stuff, then for every incoming new connection it will start a separate process.

609
00:42:20,800 --> 00:42:20,870
so all these processes show up in your cgroup hierarchy.
[stapelberg]: Because if you use inetd-style stuff, then for every incoming new connection it will start a separate process.

610
00:42:20,870 --> 00:42:23,190
so all these processes show up in your cgroup hierarchy.

611
00:42:23,460 --> 00:42:25,840
So that's why the instance is used in this case.

612
00:42:25,840 --> 00:42:33,210
Does that also relate to ExecStart=- instead of directly the path?

613
00:42:33,380 --> 00:42:36,940
No, in fact, I already looked at this and wondered why it is there

614
00:42:36,940 --> 00:42:41,780
I think it should not be there, because the - means that failures should be ignored.

615
00:42:41,780 --> 00:42:45,780
I'm not entirely sure why it makes sense to have it here

616
00:42:45,780 --> 00:42:49,480
My suspicion would be that if there's a connection and then it goes away

617
00:42:49,480 --> 00:42:53,450
then it shouldn't -- I would need to look that up.  Sorry, no answer.

618
00:42:53,450 --> 00:42:56,910
More questions?  Last question, we have one minute left.

619
00:42:56,910 --> 00:42:58,830
Last question over there.

620
00:43:04,650 --> 00:43:10,100
[question]: Thank you.  Where are dependencies defined in this thing?

621
00:43:10,100 --> 00:43:15,240
[stapelberg]: Oh yes, that's a good question.  Ideally, dependencies are not defined anywhere because they are implicit by socket activation.

622
00:43:15,240 --> 00:43:19,340
In case that's not the case, for example, if my

623
00:43:19,340 --> 00:43:24,490
-- I think I should probably have it here, let me just have a look real quick --

624
00:43:26,500 --> 00:43:33,430
dcs-web.service, it's actually more complicated.  No it doesn't have it.

625
00:43:33,430 --> 00:43:40,090
So there is, in the [Unit] section, where we also specified the Description, there can be a Before= and After=

626
00:43:40,090 --> 00:43:44,930
So in my case, I would start codesearch after postgresql came up

627
00:43:44,930 --> 00:43:47,920
and I would just specify After=postgresql.service

628
00:43:47,920 --> 00:43:51,660
You can specify multiple services there, you can specify the directive multiple times

629
00:43:51,660 --> 00:43:55,520
But usually it should not be required to specify dependencies, which is nice.

630
00:43:55,660 --> 00:43:57,520
OK, thank you.

631
00:43:57,610 --> 00:44:01,100
OK, time is over.  I would like to say, thank you very much for your attention.

632
00:44:01,100 --> 00:44:03,630
If you have any questions, please let me know and we can fix it.

633
00:44:03,630 --> 00:44:05,120
[talkmeister]: Thank you, Michael.

634
00:44:05,120 --> 00:44:05,860
[clapping]
[talkmeister]: Thank you, Michael.

635
00:44:05,860 --> 00:44:10,430
[clapping]