 Hey, so first of all the type of this lecture said it's going to be a workshop just to make the expectations clear I have a few slides prepared that should give you a general introduction and They will take probably about half of the time we have allocated for the slot and afterwards We can answer your questions or have some hands-down hacking on actual packages My name is Michael Staeperberg just a quick show of hands so that I know my audience Who of you maintains a Debian package in Debian or derivatives? Okay, that's almost everybody perfect. How many of actually added system d support to their packages already Okay, a couple who of you are looking into doing that? Okay, perfect. You're exactly the right audience Great, so the topics I want to cover with my slides are first of all how system d works for package maintainers That means I'm not gonna cover all of it and also it's not So much of a user standpoint, but just what you need to know to get you started on testing your stuff in system D we will then have a look at an example service file where I will make clear what all the different Directives are supposed to mean we will look at the temp files mechanism and at DH system D a depth helper plug-in We will consider a few more advanced examples, and then finally we will Answer your questions. Hopefully So Non-topics for this presentation are system D sucks Let's just use something else instead when will Debian finally switch to default and essentially anything that ever came up on Debian? Devil I'm not gonna talk about that right. This is just about how to make it work if you already accepted that that's something you want to do So how does system D work? Essentially where we previously had in its scripts. We now have service files Service files are just a special kind of unit files So the more generic term is unit files and that what corresponds to an init script is a service file, right? So previously you would have Slash etc init dot d slash Apache 2 as an init script and the corresponding file would be slash lip slash system D slash System slash Apache 2 dot service Now what's important here to notice is that the base name so to say apart from the dot service suffix Needs to be the same because what will happen is that system D when booting on us on a machine will look at all these services in slash etc slash init dot D and use them if they're available But if there is also a service file that will take precedence So in order to make sure that system D uses your service file and not your service file plus the old init script Make sure that the name is correct Before you ask yes There's also mechanisms to make sure that when you have a name transition because you've adopted the upstream name for a service file Or something like that then you can have a compatibility sum link. We can cover that later and Essentially system CTL does what service did So if you had service Apache to start then you would use system CTL start Apache 2 dot service in recent versions You can even skip the dot service prefix. So it would just be system CTL start Apache 2 The system CTL tool is mostly for the actual users or for you when testing And just like you would usually use it to see in it the Apache to start as an actual user But service inside your maintenance scripts. We have something for that now What we had in system 5 in it were run levels and they were poorly defined and different from distribution to distribution And what system D does to replace them is it has something called a target now a target is Precisely the same as a run level It just has a much nicer name and the names are standardized Between all the different distributions the most important targets for you are basic target multi-user target and graphical target Each of them is you know more specific than the other in that it starts more services for a particular use case So basic target is what everybody of you will run and then multi-user target extends basic target with more stuff And graphical target brings in all the graphical components like a display manager and stuff that you would normally not use on service Where multi-user target is what you would want to use you can look that up if you care later on in the month page system D dot special now just as Previously with system 5 in it We had some links to enable a service and these sim links were created by update dash RC dot D We still have some links to enable a service now They're just created by system CTL enable Again system CTL is what you would use as a user or while testing etc. And we have a maintainer script equivalent of that All right, are there any questions so far? This is really the basic stuff. Okay question What's the reason that there are different commands for the user and the maintenance scripts the the reason I think I will go into this later But I can just briefly explain it the maintenance scripts also need to work on machines where system D is not actually installed So that's why we can't use system CTL All right. Now, let's look at an example service file. I just picked VN stat dot service Which is a tiny demon that will just Store and plot later on your network traffic What you can see here is a very clear Human readable configuration file, and this is the service file. It's called VN stat dot service It starts with a unit section and you can see just like any files, which probably everybody of you is comfortable with or dot desktop files which have the same format So this is actually a dot desktop file There are sections which are enclosed in square brackets, and then there's key value pairs separated by an equal sign So that's really simple The first section is entirely just for humans 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 starting up here? The second section is the service section, and this is actually where you know all The relevant stuff is what we specify here in the second line is xx start Which is the command that system D will run when trying to start that service, right? So in this case, it's really simple. You just start the VN stat D binary What you need to notice here though is that system D does not invoke a shell to start that up So you need to specify the full path and you don't have your usual shell stuff in your command line, right? So just keep that in mind We also have the exec reload line and there could also be an exec stop line in the absence of an exec stop line System D will just kill the service, right? And it will do what many many people implemented in its scripts by hand We'll just gently try to kill it and if that doesn't work within a certain time span Then it will try to kill it harder until it finally succeeds Now the exec reload line is pretty standard The thing is that not all of the services provide a way of reloading in the first place So we need to have such a line to tell system D what to do on a reload command some other Services you could probably think of the bind name server have a different way of reloading So you could call RNDC reload in that case, but this one is just really simple It just sends a sick up to the service and then it will reload, right? The dollar main PID is not actually a shell variable or anything It's just a special thing that you can use in unit files and service files in in particular and then we also have the user line which will specify Under which user this program will be started. That's pretty straightforward Now the last section is also interesting It's called the installed section and it has a line called wanted by equals multi-user target And that essentially says that when the service file is enabled on the machine It will be pulled in by multi-user target. So just specifies which run level it runs in so to say Okay, are there any questions so far? Yes microphone Can there be a more than one wanted by line? Yes, there can be multiple wanted by lines More questions over there. Yes So just to make sure that I understand correctly if system D tries to we start a reload a service It first executes this reload phrase and then the exec start phrase again No, okay So there's two different cases here one is the reload case and the other one is the restart case, right? In the reload case It's just executes what specified here if the service file supports reloading if it doesn't then you can't reload it If you do a restart it will first execute stop if present or kill it if not present and then start it again, right? Okay, thank you one more question here Okay, is there a equivalent to Debian Fourth reload where you care so much about wanting to reload that you're okay with it falling back to stop and start if necessary Which Debian CSV in its system does support in the usual skeleton file I think there is a try reload action, but I would have to confirm that we can do that later Yes, is there also something to stop the service? Well, yeah, I already mentioned that you can specify exec stop and if you don't it will just kill it, right? Is that I didn't yeah, okay one more question here. Oh, yeah Yeah false back to restart. Yes, he just said there's a reload or restart command and system CTL that does precisely what he asked Are there other things and start reload stop and Can you define other things? Could you clarify what you mean by that? Status yes, I will actually show you some of the actions later on This is just thinking more about something specific to certain demon that for instance fetch mail Can have an awakened option? It has a sleep of five minutes or something and then you say trigger it now And what exactly is the question I still don't quite so can you have some exec line there? Oh, can you have a custom action like an init scripts? Is that what you mean? No, we can't There is different ways of coping with that so you could there's most often there's an alternative to what you want to do 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 Except for the reload one obviously But you can't have really custom weird stuff. You could ship that in an additional shell script That's what I would usually Use as the first suggestion if there's no specific no better way of solving the problem But we can discuss that later on for specific services. They might have in mind Okay, any more general questions up until here Yes Maybe you answered any and I missed it, but about the status the possibly to cure the status of the Of the service. Yes, there is yes, obviously as I said, I will show that all okay. Yes, sorry in the second part All right now temp files The temp files mechanism is really useful not only within system D But also oftentimes when people read about it, they think hey, this could be useful stand alone What it does is it creates it provides a mechanism to configure creating temporary directories like runtime directories So as a really simple example, I have here the lighty Configuration file where it will essentially say created directory called slash run slash lighty With this mode this user this group and no more arguments There are some arguments you could specify there for cleaning it up every say 10 days or some delay like that That's all supported This mechanism is much more powerful than this very simple example It can also support, you know, not only fire not on directories, but also files pipe similar etc I don't want to go into all of the details But this is the preferred mechanism to create a slash run slash something and it's much much cleaner than having You know all these varying MK dear commands that sometimes specify a user and a group and sometimes they don't and then they don't have a mode Etc etc etc So this is what we want to use question But there's no implicit conflict with all things. I have to take care that I do a proper namespace organization And for example call my temporary Directory like my service and not choose an arbitrary name which would perhaps clash with another service. Sure Yeah, I mean obviously you need to watch out for file system clashes and they've been packages That's just as it always has been yes, so it's the mechanism. You have to provide the policy. Yes, obviously all right Service file location oftentimes The upstream provider ships a service file and that's the way it's meant to be because the upstream should know best how to install the service on a particular machine right now That doesn't always happen But if it happens, please use the upstream service file and if the upstream service file is really broken Please work with upstream to fix it if it's broken in some minor detail You might ask upstream if it's acceptable, you know to change it in the way that it would be better I don't have any specific details One example that would come to mind is that some upstream service files are actually pretty old like they were written in 2009 or something and by now they're for example referring to a syslog.target as a dependency Whereas syslog is auto-started nowadays via socket activation So that could be removed and then the service file would be simpler and more idiomatic And that would be a typical change that you could push upstream now I don't say that I expect anybody of you to know what the idiomatic service files are And contribute that upstream which is saying it would be the right thing to do question. Yes You know just write that debbie n slash package name dot service and dot temp files But most the depth helpers also accept just service And I will just the type of the file without the package prefix if there's only One binary package build. Yes. Is that supported? To be honest, I didn't test it But I'm using the exact same depth per plug-in code that all the others are using so I would expect it to be supported What we also support even though I didn't actually program it is package dot and then some actual package name If it's only for a specific package in a set of all packages, which is a typical depth helper feature in that sense Thanks. Sure So now to actually cover that point if upstream doesn't ship a service file And or a temp file then you can just place them in debbie n slash your packages name dot service and dot temp file And it will be installed It will be installed by DH install in it which might confuse you because DH install in it is for in its scripts And not for service files and in fact we by now have the age system D So that's weird and the only reason why that is is because of historic reasons We first started implementing it in DH install in it But then it turned out that would make the helper a very complex and weird and handle upstart and sysv and system D all at the same time is really not a good idea So we decided to you know leave it there for the time being but eventually migrated If you use just the DH command it will all just work. You don't have to care In all the other cases currently policy dictates that you still need to ship it in it Script so that's all fine and as soon as the policy gets changed I promise that we will be in the state where you don't have to care about this either Okay, I already mentioned that please send service files upstream I will just stress it again Not only if you have an upstream service file and modify it and fix it Please send it upstream but also if you create a service file, please send it upstream so that upstream can distribute it Some upstream software might not agree. Some are actually very thankful question over there Assuming a sim ships a valid service file. What's the best practice is it to call? The eights installing it specifying the path in the a sim directory or copy it in the debut and directory Before the eights installing it is invoked in case upstream installs it just let upstream install it. I Don't I'm not sure I get the question I suppose the question is in case upstream does not install it. Oh, yeah, okay, but they don't install it Okay, in case they don't install it and then what was the second part of the question just put it in Debbie and slash as I explained So you can put it manually in Debbie and slash before the eights installing it is invoked Oh, right. Yes, you can invoke the eights installing it with the path in the upstream directory Okay, so if upstream doesn't install it but ship it. Yes. Oh, yeah, sure Yeah, you could either manually copy it before or just use what you suggested Okay, any more questions? Great, let's move on now getting your service enabled already mentioned that just as with update RCD you need to enable services and The easiest way if you already have a service file shipped by upstream Or if you put your own service file into Debbie and slash package dot service is you add a built dependency on DH system D and then you use the DH command which you hopefully already use And add the dash dash with equal system D flag and then all automatically happens and it will just work now The maintenance scripts that are generated as part of that package build will contain the appropriate code They will call a binary called depth system D helper instead of system CTL as I mentioned earlier Which avoids having a dependency on system D on all the packages, which is probably politically not a good move Now if you are not using DH you can also add the DH system D enable and DH system D start calls directly In the wiki we have instructions and the link is provided on these slides To test your package, oh there's a question here So you mentioned the Deb system D helper maintenance scripts the So I know if the scope of system D is broader than CISV in it, but in the CISV in it world policy recommends Whether or not you are using CISV in it including other things like CISV RC or open RC or a few of the other Minor ones and I think also upstart They recommend using invoke RC dot D and update RC dot D in Debian maintainer scripts. Yes as a way of both abstracting from the specific system and for Handling the case where you the bootstrapping and the demons are not running because of policy RC dot D so the question is why this instead of those and if policy RC dot D is Configured to not start or stop. We'll disrespect that. Yes, so We have another of these helpers called depth system the invoke which is for the invoke RC dot D part and it will try to respect policy Unfortunately policy is really hard. It's a really horrible standard. It's under documented and I had a really hard time figuring out How it works so it will support the use cases I could identify and if you have a use case that is broken Please talk to me and we can try to fix it Also to answer the second part of you the first part of a question actually update RC dot D. It's really hard to Have a good Solution in there we tried implementing it in there But it turned out to not work that well and upstream is not that Responsive to our concerns so we Actually chose to implement a separate helper that we had in tight control and can release independently of this VRC Which turned out to be a much much better solution because already we refactored it once and iterated on it Quite a few times and by now it's actually in a pretty good state So yeah, that's why All right To test your package, which is actually the most interesting part You will just install system D and then you can boot with the in it equal slash bin slash system D kernel parameter Now install system D does not involve breaking CSV in it or anything There's no conflicts in that package You can still have both of them if you just install system D nothing will happen If you boot with in it equals bin system D you will actually use system D right so that distinction is important You can always switch back and forth So testing it is really simple. You just reboot you could reboot in a VM if you don't like to reboot your main machine Then what you would typically do is you check your service starts properly on boot You would probably check the reload action check stop start restart and that's about it I would say Because there's really not that much more to it except if your service makes use of really advanced features and all that stuff in general I Would say that your users will report bug reports if your service does not work with system D right now So there's plenty of users of system D and Debian that carry enough to submit bug reports So it's not expected of you to test it You know all the time and convert all your systems and run it all the time and all that stuff a brief test will be enough Okay, so now to an advanced example There's actually a few more features that were maybe already mentioned if you listen to the previous talk by Leonard we have a nice service called Debian code search which I happen to maintain and The service file is actually much more complicated It's not only specifies a user and a group It also has some arguments in here and you can see that the service file format supports line wrapping So if your command line is pretty long, then it might make sense to wrap it and have it really nice Also, we have standard output redirected to DevNull because it's really noisy and mostly used for debugging So whenever I feel like debugging it, I can just change that to get standard output But in the default case, I just want standard error now also my service does not actually care to log to syslogs So I say that standard error should go to the journal which will then end up in the syslog 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 So what I want is that whenever it fails that is it exits with an exit code that is not zero I wanted to just wait a second and then restart it So far I think in production I only restarted my service once and then probably fix the bugs So most of the time it's bug free but you know better safe than sorry So the the other parts of the unit file are probably clear by now And what you will see in practice is that most of the service files really look kind of the same, right? It's pretty simple. They're pretty short. They all use these same features One more interesting feature that you should be aware of who a few show of hands ships a Maintains a package that ships a debuff service One two, okay So for the others is more of an academic interest But system. They actually can care about debuff activated services So whereas debuff would usually start them on its own in older versions Nowadays, it's better to use system D for it because then it all ends up in you know The same hierarchy and it all gets tracked and you get all the benefits and stuff So what you do is you add type equals debuff and you specify the bus name and you don't have an installed section It's not missing on the slide. It's just not there and then a system. D will activate that service whenever that buzz name is actually accessed alright Okay, so this is a more advanced example of the DH system D depth helper plugin what we do here is we install a service that should not actually be installed by default and The way we do this is we override the DH system D enable target and specify the dash dash no enable flag This should not be a surprise to anybody of you who has been using that pepper in the past I just wanted to mention it and make sure that you know, you understand what the options are here and I Will answer that in a second The second example here is for the second part of the DH system D depth helper plugin It's DH system D start and what I specify here is the dash dash restart after upgrade flag Which will make sure that the package does not get stopped then replace then started But we'll just get replaced and then restarted afterwards, which is you know kind of cleaner But the package needs to support it question. So why do you? Call the DH system D enable with a option of dash dash no enable instead of just Leaving the target empty. That's an excellent question and the comment above tries to somewhat explain it the thing is that when you purge the package if the User decided to enable it even though you ship it disabled by default then you need to clean up these sim links, right? So that's what the edge system D enable also generates main scripts for so that still needs to run So we can't just skip it in the first version. We tried but it didn't work Okay, more questions in the back Yes, you mentioned services triggered by deboss actions Yes, it's a way to disable them even if the service is installed. Yes, you can mask any service I can show you that later one more question So you say restart after upgrade. How does restart? I guess this is more general, but it's prompted by this How does restart work if the service is not running? That's a good question. I would have to really look it up. I think I Think there is a try restart action that would You know restart if it if it's running but not started if it's not running but example in this case the you set up the service to Remain disabled upon install this example. So if you install the package it is not enabled Yes, the user takes no action and then they upgrade their system Yes, and a new version of the package is installed. It tries to restart Yes, so the thing is as I was saying there is a restart action in system CTL And there's a try restart the difference is try restart will only restart it if it's running Which probably answers your question. Now the caveat is that Currently if you ship a if you maintain a package that ships a System five in a script and a system to service file. It will still use invoke rcd for the actual You know starting restarting etc And the invoke rcd actually has code to divert that to system d But the problem is it's not flexible enough to use try restart and all the fancy stuff So this might need some actual hand tweaking or just ignoring it for now All right So before we enter the questions and hands-on part of this workshop I just want to make sure that you're all aware that we will provide help There is a wiki page which is linked here called systemd slash packaging which contains Most of the information hopefully or at least pointers. We have an irc channel on irc.debin.org called Hashtabian dash system d where you can just stop by at any time and there's Most of the time somebody around to actually knows how to write service files and stuff There is a mailing list that we are all active and we really do mean it Please ask also during debcon if there's at any time any question From anybody of you or from your friends Please ask we're here for answering these sorts of questions Now just one more quick note finding documentation Um There are man pages a lot of man pages They are roughly categorized by the sections that I previously showed in service files So there's a system d.service. There's a system d.exec etc There's also an overview on the free desktop.org website where it points to all documentation The particularly interesting parts of that are the system d for administrators block series where lennard Kind of talks about a lot of features that are interesting and how to actually make use of them in your service files And then there's a link for package repositories of the various distributions Where you can just look if there already is a service file for that particular package that you maintain Even though it doesn't ship one upstream So the best thing in that case would be to adopt the service file and then also make upstream except that All right, um, that's the talk part so far. Um, now i'm ready to answer any questions or look at any packages Uh, what is the plans for the for back ports? I mean, uh, if you if you want to to use back ports to wheezy, can we use the hsystem helper or Yes, um, so the dh system the helper is available in wheezy back ports Um, be aware that the system d version in wheezy is version 44 And we're currently trying to get version 204, which is much more recent Um into debian Um, it had a version jump because of utip. Um, so it's not that much more recent. It's just more recent So there might be issues and it's up to you if you decide to Commit to maintaining support for that old system d version with your service files in wheezy. So just you know, just so you know Um, if there's no immediate questions, I would just go on to show you a little bit of stuff And then we can ask for questions as they go along Uh, I have to pretend that at the moment i'm not maintaining any package who has um in general has to start demons at Power on Um, and so I know nearly nothing about it. Yes, but I am a bit confused Since I understand there are a lot of these kind of systems to system d, cz v in it and and so on. Yes As a package maintainers, uh, what have I to do to uh, I have if I want to support all of them I have to provide Okay, the the script or or or description file that they need to reach each of them To answer this, um, the policy mandates for example, um, just to complete the question Okay, in particular if in particular we consider just cz v in it that it is one we have By default and system d which you are discussing now Yes, uh, I have if uh, if I want to provide system d information file Do I also have to um to to provide the? Um cz v in it Uh scripts or is that some compatibility layer that enables me to write one thing and at least in common cases expect Some magic to to make it working for other systems Okay, I would be happy to answer that after the talk because that's not really the focus of this talk Okay, okay So now let me just show you a few handy things that might be useful So, um, I have a terminal here that you hopefully can read in the back. Is that okay? Yeah, great Um, so let's just have a look at think fan dot service Um, and what I was using here is the system ctl command and you can see multiple interesting things First of all, it's active and running. Um, so that's good It shows that I started it six days ago when I last rebooted my laptop Also shows the main p id which is 2588 and that's the binary that corresponds to it for more complex services There are more binaries in the c group here key Um, what is particularly interesting for you is first of all where the service file actually lives So make sure that you shipped it to the correct path. There's also a linfian Warning for that. So if you use linfian, uh, you should catch that Um, it should go to lip system d system as I mentioned It also should be enabled unless of course you decided to not enable it by default um Now I can just show you system ctl stop it will be that That is a good point. Um, the first two columns are not shown. So let's make it like this Should be much better great, um Not perfect better Yeah, whatever. That's good enough. So, um think fan dot service. Um Now it's still enabled. It's still loaded, but it's inactive because I stopped it I can start it again. Wait, uh, I can Start it again Check that it started. Um, you can also see that it used this xx start line I can also actually show you the service file. There's really no magic in here There is an xx reload Directive here. So we can test if the reload actually works Which I need to do as root And then in the status output, we will see that it tried to reload the service Code exited status equals zero slash success. So that worked So those are a few simple things that you can check to see if your service actually works Ten minutes. Yes. Are there any questions now? Here microphone The example has typed Equals forking. Yes. What are the other values which are valid? So that was obviously a suggestion to open the man page and show you that actually is documented The man page in question here is system d.service as I tried to explain earlier. There's multiple types. Um, they're simple Um, there's forking one shot debas notify or idle The most interesting ones are simple forking one shot and debas debas I already explained That's if you have an actual deba service There's one shot which is uh for stuff like doing one thing and then nothing like it's not a permanently running service It's just one simple command like a shell script and then it will stay Um active as it started Afterwards there is forking and there is simple. So the difference between simple and forking is that simple will Um, the the the demon you're starting if it's a type equal simple one should just continue running in the foreground Whereas a forking one will fork itself into background The preferred model is using simple because you know it's simple Forking has the implicit assumption and I think this is important to know that As long as the demon is still running in foreground, it's not ready. The unit file will be considered started Precisely the moment where the demon forks That is not necessarily what your upstream software implements. But that's how it's The question was when it forks or when the main process exits Obviously, I think when the main process exits In the other case, yes, but I mean That's how it usually works, right? You double fork and then you exit the main process. Okay, um more questions Masking process is perfect. Um, let's do that. So I have um, I have think fan And I now decide that it's really a shame that my fan is not spinning up as much as I would like So what I will just do is I will mask think fan dot service and it will helpfully print out what it actually did Which is it just created a sim link in ATC system d et cetera pointing to dev null so Essentially, it will try to load that service file but fail because it you know can't read dev null. So if I now check status on think fan dot service it will tell me that it's masked But it's also still running. So if I now do system ctl stop and then status It's now dead and it will not be started on my next boot So this is different, you know from uh enable and disable because it also works for deba services And it's really like the last resort if you really really don't want this thing to be started mask it question But in this case you you cannot start it by hand you have another method implemented in our system d to I can't start it by hand But what if I want to prevent You need to start at boot. Yes, then you want to be able to Run it by hand Yes, then you obviously disable it right because disable just means don't start it at boot But you can still start and stop and restart all that stuff mask does really don't start this at all right So now because I don't like loud fans. Let me just unmask that All right, so now it told me that it deleted that sim link and I can just start it again and it will just work All right more questions, please over there When it's a active it says active and running or it says inactive and dead it's Is there any particular meaning that there is a part active and the part in parentheses and yes It could be active and exited and that would be the case for the one-shot services that just you know Forked one command that exited but the unit is still considered active because the command succeeded More questions over here Is there any support for what happens when a demon dies? Is it restarted like? Yeah, I actually I actually had this on my slides earlier Yes more features here we go you can specify restart sec equals one and restart on failure There's more options in that direction to restart stuff when it dies Okay, more questions, please here It's about the the packaging Isn't possible to use the bell per triggers instead We just put a file in deep system day and then the trigger happens It means it will work with other packaging system like cdbs without modifications We actually have uh sent a patch to cdbs and it supports the h system db now Okay, but no trigger why not using trigger support? Not using what sorry instead instead of using uh the bell per snippet inserting the bell per snippet in in post-hanced Yes, you could have a register trigger Uh, yeah, but it's it's more complicated than that because it will be executed when it detects Filed appearing in some location Yeah, but we don't want to enable all the services by default and then we would need to maintain A whitelist or a black list of services and stuff that really needs to be more flexible than that Okay, more questions another one Okay, this time it's for services that need several instances um like s tunnel Oh multiple instances. Yes multiple instances one with uh Usually as I come with several configuration files and we want one instance per configuration file And be able to control them separately. Yes, um, so there are actually Six five there are good examples here on how that works. There's if up and there's getty Let me just show you getty Which has getty at tty one dot service and what's interesting is you can see that the service file path actually does not include that So if you have a look at the service file, you can see that it's much more complicated than I would like it to be But um, what's the interesting part for us is that there's a percent capital i Which will be replaced by whatever you specify after the at so you can say You know, um, you can make your service file contain the at In the file name and then use percent i and then start a specific instance of that On the user is suspected to create all the at file. Yes, okay Okay, more questions here Well, how about this socket based activation socket activation? That is a good question Let me just have a look if I have any socket activation files lying around here Um, I have aprox.socket, which seems kind of appropriate for this conference um A socket activation essentially works like this you have socket instead of a service in your service file um in your socket file, sorry, um, you specify a tcp port or a unique socket or whatever it should listen on and then there is accept equals yes Or the default is accept equals no the difference is that accept equals yes mimics the Inet D style behavior of just you know starting one process per connection Which is kind of wasteful and the actual real good socket activation is not having that but um patching the service to When being started inherit the file descriptor off the socket and then just you know Integrated in its event loop and handle that and many services are already patched for that Some of them are patched but not in debian and some of them you would need to patch But this is really like a thing of an hour or two. I did it for bacula once for example Okay question over here So the socket file just includes information about where to listen and if to accept but not what to start Is that just in a service file then? Yes, um The socket file has to match by name the service file and because I used accept equals Yes, it needs to be aprox at dot service not aprox service and then this will in turn just say You know take the standard input from socket like inet d does and start it up Okay, one more question So why does it mean I have to add the add? Because if you use inet d style stuff then for every incoming new connection it will start a separate Process right so all these processes show up in your secret pirate key. So that's why the instance is used here And does it also relate to xx start equals Dash instead of directly the path. No, in fact, um, I already looked at this and wondered why it is there It I think it should not be there because the minus means that ignore Failure should be ignored. Um, I'm not entirely sure why it makes sense to have it here My suspicion would be that you know if there is a connection and it goes away Then this shouldn't there was something like I would need to look that up. So sorry no answer here More questions last question. We have one minute left Last question over there. Thank you. Thank you There are dependencies defined in the thing. Oh, yes, that's a good question So ideally dependencies are not defined anywhere because they're implicit by socket activation in case. That's not the case For example, uh, if my I think I should probably have it here. Let me just have a look real quick um, I Think dcs web dot service It's actually more complicated. No, it doesn't have it. So there's um in the unit section where we also specify the description There can be a before equals and after equals So in my case, I would start uh code search after postgresql came up And I would just specify after equals postgresql dot service Uh, you can specify multiple services there. You can specify the directive multiple times But usually it should not be required to specify dependencies, which is nice Okay, thank you Okay, time is over. So I would like to say thank you very much for your attention if you have any questions Please let me know and we can fix it Thank you Michael