# systemd vs launchd



## beatgammit (Feb 17, 2014)

I'm looking for a comparison between the architectures of systemd and launchd. I've heard both criticized as being anti-unix, but the only real criticism of launchd I've read is the merging of crond into init.

For example, the major feature systemd brought (in my opinion) is socket activation paired with dependency management, which both decreases boot time and simplifies process management. This provides init with more information, and many of the features naturally follow. It looks like launchd offers a similar feature set (registering daemons as opposed to immediately starting them), but I haven't used launchd, so I don't know what exactly it brings to the table. I _have_ used upstart, so comparisons there would also be helpful.

I've read the launchd wiki page, which states what it replaces, but I still don't understand _how_ it works. Specifically, I have these questions:


Does launchd require (or at least _strongly encourage_) changes to daemons like systemd?
Does launchd have enough information about processes to analyze boot times (i.e. does it replace bootchart)?
Is there a concept of runlevels (like systemd's targets)? If so, how do they work?

It looks like there's significant interest in launchd in the FreeBSD community, so I'd like to understand it before I form any long-term opinions/potentially help out.


----------



## ChalkBored (Feb 18, 2014)

I wouldn't say there's significant interest in launchd, the efforts to port it to FreeBSD seem to be someone's side project. The original porting effort seemed to stagnate around 2005, and only recently has someone else picked up the torch.

If you're interested in it, you'll probably find more information about it from people who know about OS X. There should be someone who's had to migrate stuff to it.


----------



## kpedersen (Feb 19, 2014)

beatgammit said:
			
		

> It looks like there's significant interest in launchd in the FreeBSD community, so I'd like to understand it before I form any long-term opinions/potentially help out.



Understanding the existing rc system FreeBSD has in place (and likely will remain for our lifespans) will be a lot more useful to yourself and others if you want to help out in the future.

It may not be immediately trendy but I can guarentee that it will outlive both systemd and Apple's launchd. Heck, it has already outlived Upstart and that was brand new and shiny 

If there is a particular feature you like from another OSes startup system, perhaps you could look at intergrating it with FreeBSD's?


----------



## sossego (Feb 20, 2014)

Are you building go on FreeBSD?


----------



## obsigna (Mar 3, 2014)

beatgammit said:
			
		

> ... Specifically, I have these questions:
> 
> 
> Does launchd require (or at least _strongly encourage_) changes to daemons like systemd?
> ...




A Daemon started by launchd must not daemonize itself, i.e. doing a foreground/background switch on its own. For example, Apache httpd should be started by launchd with the option -D FOREGROUND. Otherwise, launchd would loose its track on the daemon and if the keep-alive flag is set, it would simply start it again.
 
The philosophy behind launchd is, that the daemon should know best what it needs, and if the requirements are still not met during the boot process, it should simply exit gracefully as quickly as possible (no core dump, no romances in the error log, no e-mail to the root user, no phone-call to the president). launchd would simply try to start it again on the next occasion. It is worth to note that launchd is not blocked by a daemon which is still deciding whether it should continue to run or should exit, launchd happily continues to fork(2) other processes, and re-launches those that failed.
 
AFAIK, the notion of runlevels is provided by the OS. System V runlevel designation in RC scripts is sort of accepted by FreeBSD, but otherwise ignored. So, if it ever comes to a port of launchd to FreeBSD, I guess launchd would ignore runlevels either.
 
On Mac OS X, launchd got the concept of user-daemons and it calls this agents. Agents are configured in the home directory and run with the credentials of the respective user. This does not exactly match the concept of runlevels, but it can be used to automatically start certain agents on the login of for example a special user maintenance.

For me the main unique selling point of launchd compared to the RC system is the included configurable process watchdog. For example, if httpd would crash for any reason, launchd would simply start it again within a few milliseconds. I wrote already RC startup scripts for some of my daemons, and I wrote launchd configuration files for others, the latter of which is way more straightforward.

Anyway, I would not suggest to port launchd as is to FreeBSD. Having configuration files instead of RC-scripts would already be nice, but I would prefer simple key/value tables instead of XML files. A configurable process watchdog included into the startup system should already bring 95 % of the functionality of launchd.


----------



## beatgammit (Mar 4, 2014)

obsigna said:
			
		

> ...
> The philosophy behind launchd is, that the daemon should know best what it need, and if the requirements are still not met during the boot process, it should simply exit gracefully as quickly as possible (no core dump, no romances in the error log, no e-mail to the root user, no phone-call to the president). launchd would simply try to start it again on the next occasion. It is worth to note that launchd is not blocked by a daemon which is still deciding whether it should continue to run or should exit, launchd happily continues to fork(2) other processes, and re-launches those that failed.



Interesting. I think that's a bit more unix-like than systemd because daemons don't have to make any assumptions about which init is starting them.

I still like socket-activation, but I think this is an acceptable solution as well, and better than the status quo.
 


			
				obsigna said:
			
		

> Anyway, I would not suggest to port launchd as is to FreeBSD. Having configuration files instead of RC-scripts would already be nice, but I would prefer simple key/value tables instead of XML files. A configurable process watchdog included into the startup system should already bring 95 % of the functionality of launchd.



So, something like sysutils/monit?


----------



## obsigna (Mar 4, 2014)

beatgammit said:
			
		

> ...
> I still like socket-activation, but I think this is an acceptable solution as well, and better than the status quo.



IMHO, this should be handled within a daemon itself, not by the watchdog.
 


			
				beatgammit said:
			
		

> obsigna said:
> 
> 
> 
> ...



No, monit is a polling watchdog. I had a quick look in the documents of it, and there was an example where it polls every 2 minutes if sendmail is active.

launchd creates process forks for each of its daemons, and therefore, once a daemon dies, launchd knows this immediately, in less than perhaps a millisecond. So, if the daemon behaves well on exit, there is minimal processing involved on re-spawning it once again. Since all this happens in a compiled binary, forking, exiting, and re-forking is much faster than anything, that can be done with shell scripts.

For an examples on how this might work, look on these 3 posts:
        http://forums.freebsd.org/viewtopic.php ... 38#p120709
        http://forums.freebsd.org/viewtopic.php ... 38#p122038
        http://forums.freebsd.org/viewtopic.php ... 38#p122050

I posted a more elaborated example of a non-configurable watchdog (tunnel guard) on my blog:
        http://blog.obsigna.net/?p=229#the_watchdog

So, a launchd equivalent would ideally be a daemon by itself, lauching its daemons using fork(2) and  waiting for them using wait(2). Some of the above may be taken as a basic prototype of this. All the configuration stuff needs to be added of course.


----------



## beatgammit (Mar 4, 2014)

obsigna said:
			
		

> launchd creates process forks for each of its daemons, and therefore, once a daemon dies, launchd knows this immediately



Ok, so launchd is like systemd and upstart in this regard.

If daemons don't daemonize themselves, does launchd define another way for the service to notify init that it's ready? It seems systemd provides several options for signaling this. Does launchd do something similar? If so, I expect that means that boot profiling will be possible, which is a big win for embedded systems (which I'm particularly interested in).

Also, what do you think is most likely of the following:


Update existing init with ideas taken from launchd, upstart and systemd
Use launchd, but with some changes
Use openrc, but with some changes

I imagine FreeBSD is unlikely to make any drastic changes to init in the near future, and most of this is just speculation, but the recent drama in the Linux community over systemd got me interested in where the FreeBSD community stands.


----------



## obsigna (Mar 4, 2014)

beatgammit said:
			
		

> ...
> If daemons don't daemonize themselves, does launchd define another way for the service to notify init that it's ready?



On Mac OS X, launchd is init, i.e. the process that gets PID 1. Foreground daemons may write .pid-files to /var/run. FG-daemons, may create sockets, and register IPC-ports, they can do anything that BG-daemons are able to do, and more. Only, FG-daemons must not move themselves into the background because launchd is supposed to do this.

Processes may query launchctl for the status of running jobs. For example  `launchctl list` would give a complete list of jobs registered with launchd, and `launchctl list [i]label[/i]` would show the status of the job having the given label.



			
				beatgammit said:
			
		

> It seems systemd provides several options for signaling this. Does launchd do something similar?



It doesn't seem to me that launchd is actively signaling anything, I may be wrong, though.



			
				beatgammit said:
			
		

> If so, I expect that means that boot profiling will be possible, which is a big win for embedded systems (which I'm particularly interested in).



I don't think that signaling is necessary for boot profiling, because launchd could simply do this by itself, it is in command. It is the first one that knows once one of its subordinated daemons exits prematurely and upon the next boot it may want to start that daemon later in the boot sequence. 



			
				beatgammit said:
			
		

> Also, what do you think is most likely of the following:
> 
> 
> Update existing init with ideas taken from launchd, upstart and systemd
> ...



I don't know, what people are pretending to do or even whether they are pretending anything. I know what I would do. I would keep init completely functional and I only would force it to launch immediately a second stage init daemon (let's call it sstid having PID 2).

This sstid inherits a watchdog, would crawl the configuration directories of daemons and agents in designated system and users locations, and would launch what it finds in there. It would analyze the boot process for failures and would re-order the sequence for the next boot. Perhaps, I would implement xinetd capabilities, so sstid would create inet/inet6 sockets on behalf of daemons/agents that don't need to be started immediately, but may be started on occasion.

With that in place, a system admin could opt for using the traditional rc system, or he could leave the /etc/rc.conf completely empty and place for everything that is needed sstid config files into the designated locations, or he/she could use a wild mixture of both systems.



			
				beatgammit said:
			
		

> I imagine FreeBSD is unlikely to make any drastic changes to init in the near future, and most of this is just speculation, but the recent drama in the Linux community over systemd got me interested in where the FreeBSD community stands.



Agreed:


			
				Erich Kästner said:
			
		

> Es gibt nichts Gutes außer man tut es.


----------



## SirDice (Mar 4, 2014)

obsigna said:
			
		

> I don't know, what people are pretending to do or even whether they are pretending anything. I know what I would do. I would keep init completely functional and I only would force it to launch immediately a second stage init daemon (let's call it sstid having PID 2).
> 
> This sstid inherits a watchdog, would crawl the configuration directories of daemons and agents in designated system and users locations, and would launch what it finds in there. It would analyze the boot process for failures and would re-order the sequence for the next boot. Perhaps, I would implement xinetd capabilities, so sstid would create inet/inet6 sockets on behalf of daemons/agents that don't need to be started immediately, but may be started on occasion.
> 
> With that in place, a system admin could opt for using the traditional rc system, or he could leave the /etc/rc.conf completely empty and place for everything that is needed sstid config files into the designated locations, or he/she could use a wild mixture of both systems.


This sounds a lot like what Daemon Tools (not to be confused with a virtual CD device of the same name) does. At least partly. Daemon tools is actually quite old already and runs on a multitude of UNIX systems. Perhaps it could be extended to include the other features?

http://cr.yp.to/daemontools.html
sysutils/daemontools


----------



## obsigna (Mar 4, 2014)

SirDice said:
			
		

> This sounds a lot like what Daemon Tools (not to be confused with a virtual CD device of the same name) does. At least partly. Daemon tools is actually quite old already and runs on a multitude of UNIX systems. Perhaps it could be extended to include the other features?
> 
> http://cr.yp.to/daemontools.html
> sysutils/daemontools



At least for prototyping the concept this may be a good start. However, I think after this some optimization and development is necessary. For example, svscan expects shell scripts in the configuration directories. If we are looking for performance than it would be better to pass the actual command line directly to the launchd equivalent, so it could launch its subordinates directly and not by the way of another shell. I would also restrict the number of possible configuration locations, perhaps:

Daemons and per-user agents provided by the base system
/etc/daemons.d
/etc/agents.d

Daemons and per-user agents provided by other system installations
/usr/local/etc/daemons.d
/usr/local/etc/agents.d

User agents installed by users
/home/user1/etc/agents.d
/home/user2/etc/agents.d
/home/user3/etc/agents.d
...

The set of configuration options could be very similar to that what Apple provides for launchd (s. launchd.plist(5)). As already mentioned in a previous post, I would prefer simple key/value tables over XML files, though.


----------



## Senjaz (May 2, 2015)

I came here by looking for a comparison of launchd and systemd. This is an old thread but I can hopefully add some more information on launchd (I mainly use OS X). launchd also has the ability to launch daemons on demand either when a new volume is mounted, or when a socket is bound to. The later replaces the need for explicit interdependency maps. daemons are expected to handle their own checks via IPC, when they do so launchd will launch the required daemons. This means everything can be lazily launched. It's quite elegant and well documented.


----------



## drhowarddrfine (May 2, 2015)

And not the way Unix works. Linux is Linux, not Unix-like anymore.


----------



## BSDBernd (May 3, 2015)

Since Hubbards talk I am very interested in init systems and process control daemons. Intuitively, for me, they can not be intelligent and modern and advanced enough . If the Unix philosphy is that you do a particular thing and that as good as possible, then this should also hold for process control daemons. Imagine you have a very very smart process control deamon , not as smart J. A. R. V. I. S. of course , but quite smart..... 
Important note: I do not know much about init systems, so my dream could be something that an expert would not want to have.


----------



## vermaden (May 18, 2015)

http://blog.wuntee.sexy/osx/kernel/debugging/2015/05/11/debugging-launchd/


----------



## Joseph Bruni (Apr 21, 2016)

I have written daemons that run under launchd and the only real difference is not calling fork(2) and setsid(2). launchd will also allow you to continue to use stdout for logging and will route that output to asl.

On other unix systems, you needed to move your working directory to /, close your std streams, and all logging had to go to syslog(3) since all your std streams were closed. Anyone familiar with APUE knows the drill.

My biggest and probably only complaint about launchd is the use of XML files for configuration. Some of the keys are pretty ambiguous. I think someone could have spent a bit more time with a thesaurus defining better keywords in the config files.


----------



## Joseph Bruni (Apr 21, 2016)

I don't see systemd moving to BSD any time soon. GPL and BSD license models don't really go well together.


----------



## zirias@ (Apr 21, 2016)

Joseph Bruni said:


> I have written daemons that run under launchd and the only real difference is not calling fork() and setsid(). launchd will also allow you to continue to use stdout for logging and will route that output to asl.
> 
> On other unix systems, you needed to move your working directory to /, close your std streams, and all logging had to go to syslog() since all your std streams were closed.


Sounds all nice, but the problem is: THIS is how it always worked, so >90% of Unix daemons are written this way. If you pull in a dependency on a non-standard "service manager" in your daemon, this service manager should at least run on top of a standard init system. It wouldn't be a problem. In fact, inetd and friends do a similar (minimal) thing for network services. Implementing the main features of launchd and systemd in a service manager that is started by init would allow you to have your managed services as well as classical daemons side by side easily and it wouldn't force anything upon users who do not intend to run a "managed service". But the attempt to just replace init not only violates the "one job, one tool" paradigm. It also forces users to use it even if they don't need it.

If, in a far future, a standard for a new Unix service manager evolved, so no "classic" daemon of any relevance is left, THEN it would be the time to completely replace init without violating Unix design principles.


----------



## obsigna (Apr 21, 2016)

Zirias said:


> Joseph Bruni said:
> 
> 
> > I have written daemons that run under launchd and the only real difference is not calling fork() and setsid(). ...
> ...



I guess, you misunderstood what Joseph Bruni was saying. The actual point is, that launchd requires the "daemon" not to daemonize, i.e. it should stay in the foreground running mode. This is because launchd does fork() and setsid() on behalf of the daemon, like inetd does, and if you develop a daemon for inetd, then as well you must not call fork()/setsid(). Many well known daemons have their special flags for this:

-D for sshd
-DFOREGROUND for httpd (Apache)
without -D for ftpd
...
And specifying the respective flags, said daemons would behave nice under launchd without any code changes.


----------



## zirias@ (Apr 21, 2016)

This was _exactly_ what I understood and my argument is that this is not how a daemon is constructed. It's still fine as long as the manager for this doesn't _replace_ init but is launched from it.


----------



## obsigna (Apr 21, 2016)

Zirias said:


> This was _exactly_ what I understood and my argument is that this is not how a daemon is constructed. It's still fine as long as the manager for this doesn't _replace_ init but is launched from it.



Well, yeah, read my post from 2 years ago:


obsigna said:


> I don't know, what people are pretending to do or even whether they are pretending anything. I know what I would do. I would keep init completely functional and I only would force it to launch immediately a second stage init daemon (let's call it sstid having PID 2).


----------



## zirias@ (Apr 22, 2016)

obsigna said:


> Well, yeah, read my post from 2 years ago:


There's nothing in this post on the subject of putting this "service manager" in PID 1. This has serious implications. Referring to Joseph Bruni's post again, one thing that comes to mind immediately is logging. If all you have is stdout, you can't easily give syslogd the information (facility and level) it needs to do it's job. Maybe that was the reason for systemd to pull logging into scope. As well as lots of other things. What you typically do in a daemon supporting to run without detaching is to have some abstraction for logging. This abstraction layer can also write to stdout, in this case putting meta info like the log level into the text in some form.


----------



## Joseph Bruni (Apr 22, 2016)

Zirias said:


> Sounds all nice, but the problem is: THIS is how it always worked, so >90% of Unix daemons are written this way. If you pull in a dependency on a non-standard "service manager" in your daemon, ...



There is no dependency on launchd pulled in. Most daemons that I have seen (and written) have a "debug" or "foreground" mode that is enabled using a command line switch. Many of those daemons can also be launched from inetd using the same method. If you have one that doesn't, launchd can accommodate that too using keys in the configuration. launchd will react faster if the daemon does not disconnect from its parent because, as the parent, it simply blocks on a call to waitpid(2).


----------



## obsigna (Apr 22, 2016)

Zirias said:


> There's nothing in this post on the subject of putting this "service manager" in PID 1. ...


I thought, that my post made it very clear, that I am not fond of an init replacement at PID 1 either, anyway, forget it.


----------



## zirias@ (Apr 22, 2016)

obsigna said:


> I thought, that my post made it very clear, that I am not fond of an init replacement at PID 1 either, anyway, forget it.


By the time I replied, there wasn't a quote! I was reading another post


----------



## debguy (Sep 1, 2016)

in debian they called red hat systemd part of linux wars

i'm glad to see Apple has taken enough interest to improve and not just "take code and use it"

however for BOTH OF THEM: there was no reason to disable System V and bsd'ish rc (often both used and supported on some systems).  systemd and launchd could be processes (spawned/forked) by init

people today have ZERO respect for not clobbering namespaces (using a new name, and a long descriptive one) and not breaking what already works - causing versional depends havoc and migration nightmares

i think both are fine but the idea that "everyone must rewrite when apple or RH changes their mind" (ie, any admin with a key to hack others) is what is wrong with today's IT.  they do whatever they please and get paid while others suffer.  simply put - clobbering should not be allowed any more .  it's not just that it's hardware incompatibility too (ie, dropping VGA or IDE support while failing to provide drivers, they are becoming to hack in silicon while coders suffer their omnipotence).

on the other hand there's no reason why apple or RH startup should not use their custom launcher - it's just that it should not assume to "take over", is all.  it should drop in, and do it's thing

the problem is lack of respect for others, lack of planning, and very much: abuse of authority


----------



## SporkVillain (Sep 2, 2016)

As OSX is almost always used as a client system... why are people configuring launchd? I've never run into the need for using it on my MBP.


----------



## obsigna (Sep 2, 2016)

SporkVillain said:


> As OSX is almost always used as a client system... why are people configuring launchd? I've never run into the need for using it on my MBP.



One famous usage case is a Web-Development system. For example, I have running on my client system a test web server, and the httpd and database services are launched when starting the machine. The benefit of this is that you can quickly run many test scenarios with your new code without needing it to upload to somewhere, so development can happen completely offline.

In the case of Mac OS X, one would take the launchd.plist example script from the respective man file, adjust the executable name, path and its command line parameters, and drop the new launch_my_daemon.plist into /Library/LaunchDaemons.

However, installation of respective daemons is another mostly yet as simple story.


----------



## SporkVillain (Sep 2, 2016)

Yeah I'm not sure I'd want a webserver starting every time my machine booted. I'd rather do that inside vagrant or something that better replicated the actual situation on the server. I get what you mean now, though. I usually just associate the tight control of init with server situations.


----------



## obsigna (Sep 3, 2016)

SporkVillain said:


> Yeah I'm not sure I'd want a webserver starting every time my machine booted. I'd rather do that inside vagrant or something that better replicated the actual situation on the server. I get what you mean now, though. I usually just associate the tight control of init with server situations.


Perhaps, I am nitpicking. Your first comment was about "why are people configuring launchd?", and I assumed that with people you mean the User of the system, and I answered that one with a usage case that some people like and perhaps others dislike.

Now, your more general point of view "I usually just associate the tight control of init with server situations." does not match the client systems that I know, usually those run tons of daemons that don't make sense on a server. Here comes an example of Mac OS X 10.11:

```
# ls -1 /System/Library/LaunchDaemons
bootps.plist
com.apple.AirPlayXPCHelper.plist
com.apple.AppleFileServer.plist
com.apple.AssetCacheLocatorService.plist
com.apple.CommCenterRootHelper.plist
com.apple.CoreRAID.plist
com.apple.CrashReporterSupportHelper.plist
com.apple.DesktopServicesHelper.plist
com.apple.DumpGPURestart.plist
com.apple.DumpPanic.plist
com.apple.FileCoordination.plist
com.apple.FileSyncAgent.sshd.plist
com.apple.FontWorker.plist
com.apple.GSSCred.plist
com.apple.GameController.gamecontrollerd.plist
com.apple.IFCStart.plist
com.apple.IOAccelMemoryInfoCollector.plist
com.apple.IOBluetoothUSBDFU.plist
com.apple.InstallerDiagnostics.installerdiagd.plist
com.apple.InstallerDiagnostics.installerdiagwatcher.plist
com.apple.Kerberos.digest-service.plist
com.apple.Kerberos.kadmind.plist
com.apple.Kerberos.kcm.plist
com.apple.Kerberos.kdc.plist
com.apple.Kerberos.kpasswdd.plist
com.apple.KernelEventAgent.plist
com.apple.MRTd.plist
com.apple.ManagedClient.cloudconfigurationd.plist
com.apple.ManagedClient.enroll.plist
com.apple.ManagedClient.plist
com.apple.ManagedClient.startup.plist
com.apple.MobileFileIntegrity.plist
com.apple.NetBootClientStatus.plist
com.apple.NetworkDiagnostics.plist
com.apple.NetworkLinkConditioner.plist
com.apple.NetworkSharing.plist
com.apple.ODSAgent.plist
com.apple.PCIELaneConfigTool.plist
com.apple.PasswordService.plist
com.apple.RFBEventHelper.plist
com.apple.RemoteDesktop.PrivilegeProxy.plist
com.apple.ReportCrash.Root.plist
com.apple.ReportPanicService.plist
com.apple.SCHelper.plist
com.apple.SubmitDiagInfo.plist
com.apple.TMCacheDelete.plist
com.apple.TrustEvaluationAgent.system.plist
com.apple.UserEventAgent-System.plist
com.apple.UserNotificationCenter.plist
com.apple.WindowServer.plist
com.apple.WirelessRadioManagerd-osx.plist
com.apple.afpfs_afpLoad.plist
com.apple.afpfs_checkafp.plist
com.apple.airplaydiagnostics.server.mac.plist
com.apple.airport.wps.plist
com.apple.airportd.plist
com.apple.akd.plist
com.apple.alf.agent.plist
com.apple.appleseed.fbahelperd.plist
com.apple.applessdstatistics.plist
com.apple.apsd.plist
com.apple.aslmanager.plist
com.apple.atrun.plist
com.apple.audio.coreaudiod.plist
com.apple.audio.systemsoundserverd.plist
com.apple.auditd.plist
com.apple.autofsd.plist
com.apple.automountd.plist
com.apple.avbdeviced.plist
com.apple.awacsd.plist
com.apple.awdd.plist
com.apple.backupd-auto.plist
com.apple.backupd.plist
com.apple.blued.plist
com.apple.bluetoothReporter.plist
com.apple.bluetoothaudiod.plist
com.apple.bnepd.plist
com.apple.bsd.dirhelper.plist
com.apple.cache_delete.plist
com.apple.cfprefsd.xpc.daemon.plist
com.apple.cloudfamilyrestrictionsd-mac.plist
com.apple.cmio.AVCAssistant.plist
com.apple.cmio.AppleCameraAssistant.plist
com.apple.cmio.IIDCVideoAssistant.plist
com.apple.cmio.VDCAssistant.plist
com.apple.cmio.iOSScreenCaptureAssistant.plist
com.apple.colorsyncd.plist
com.apple.comsat.plist
com.apple.configd.plist
com.apple.configureLocalKDC.plist
com.apple.corecaptured.plist
com.apple.coreduetd.osx.plist
com.apple.coreservices.appleevents.plist
com.apple.coreservices.appleid.passwordcheck.plist
com.apple.coreservices.launchservicesd.plist
com.apple.coreservices.sharedfilelistd.plist
com.apple.coreservicesd.plist
com.apple.corestorage.corestoraged.plist
com.apple.corestorage.corestoragehelperd.plist
com.apple.coresymbolicationd.plist
com.apple.csrutil.report.plist
com.apple.ctkd.plist
com.apple.cvmsServ.plist
com.apple.diagnostic.uuidpathd.plist
com.apple.diagnosticd.plist
com.apple.diskarbitrationd.plist
com.apple.diskmanagementd.plist
com.apple.diskmanagementstartup.plist
com.apple.displaypolicyd.plist
com.apple.distnoted.xpc.daemon.plist
com.apple.dnsextd.plist
com.apple.dpaudiothru.plist
com.apple.dpd.plist
com.apple.dspluginhelperd.plist
com.apple.dvdplayback.setregion.plist
com.apple.dynamic_pager.plist
com.apple.eapolcfg_auth.plist
com.apple.efax.plist
com.apple.efilogin-helper.plist
com.apple.emlog.plist
com.apple.emond.aslmanager.plist
com.apple.emond.plist
com.apple.eppc.plist
com.apple.familycontrols.plist
com.apple.findmymac.plist
com.apple.findmymacmessenger.plist
com.apple.firmwaresyncd.plist
com.apple.fontd.plist
com.apple.fontmover.plist
com.apple.fseventsd.plist
com.apple.ftp-proxy.plist
com.apple.getty.plist
com.apple.gkreport.plist
com.apple.gssd.plist
com.apple.hdiejectd.plist
com.apple.hidd.plist
com.apple.hidfud.plist
com.apple.icloud.findmydeviced.plist
com.apple.iconservices.iconservicesagent.plist
com.apple.iconservices.iconservicesd.plist
com.apple.ifdreader.plist
com.apple.installandsetup.systemmigrationd.plist
com.apple.installd.plist
com.apple.kcproxy.plist
com.apple.kdumpd.plist
com.apple.kextd.plist
com.apple.kuncd.plist
com.apple.locate.plist
com.apple.locationd.plist
com.apple.lockd.plist
com.apple.logd.plist
com.apple.logind.plist
com.apple.loginwindow.LFVTracer.plist
com.apple.loginwindow.plist
com.apple.logkextloadsd.plist
com.apple.lsd.plist
com.apple.mDNSResponder.plist
com.apple.mDNSResponderHelper.plist
com.apple.mbsystemadministration.plist
com.apple.mbusertrampoline.plist
com.apple.mdmclient.daemon.plist
com.apple.mdmclient.daemon.runatboot.plist
com.apple.metadata.mds.index.plist
com.apple.metadata.mds.plist
com.apple.metadata.mds.scan.plist
com.apple.metadata.mds.spindump.plist
com.apple.msrpc.echosvc.plist
com.apple.msrpc.lsarpc.plist
com.apple.msrpc.mdssvc.plist
com.apple.msrpc.netlogon.plist
com.apple.msrpc.srvsvc.plist
com.apple.msrpc.wkssvc.plist
com.apple.mtmd.plist
com.apple.mtmfs.plist
com.apple.nehelper.plist
com.apple.nesessionmanager.plist
com.apple.netauth.sys.auth.plist
com.apple.netauth.sys.gui.plist
com.apple.netbiosd.plist
com.apple.networkd.plist
com.apple.networkd_privileged.plist
com.apple.newsyslog.plist
com.apple.nfsconf.plist
com.apple.nfsd.plist
com.apple.nis.ypbind.plist
com.apple.noticeboard.state.plist
com.apple.notifyd.plist
com.apple.nsurlsessiond.plist
com.apple.nsurlstoraged.plist
com.apple.ocspd.plist
com.apple.odproxyd.plist
com.apple.opendirectoryd.plist
com.apple.periodic-daily.plist
com.apple.periodic-monthly.plist
com.apple.periodic-weekly.plist
com.apple.pfctl.plist
com.apple.pfd.plist
com.apple.platform.ptmd.plist
com.apple.powerd.plist
com.apple.powerd.swd.plist
com.apple.preferences.timezone.admintool.plist
com.apple.preferences.timezone.auto.plist
com.apple.printtool.daemon.plist
com.apple.racoon.plist
com.apple.remotepairtool.plist
com.apple.revisiond.plist
com.apple.rootless.init.plist
com.apple.rpcbind.plist
com.apple.rpmuxd.plist
com.apple.sandboxd.plist
com.apple.screensharing.plist
com.apple.scsid.plist
com.apple.secinitd.plist
com.apple.security.FDERecoveryAgent.plist
com.apple.security.agent.login.plist
com.apple.security.authhost.plist
com.apple.security.syspolicy.plist
com.apple.securityd.plist
com.apple.securityd_service.plist
com.apple.sessionlogoutd.plist
com.apple.smb.preferences.plist
com.apple.smbd.plist
com.apple.softwareupdate_download_service.plist
com.apple.softwareupdate_firstrun_tasks.plist
com.apple.softwareupdated.plist
com.apple.speech.speechsynthesisd.plist
com.apple.spindump.plist
com.apple.startupdiskhelper.plist
com.apple.statd.notify.plist
com.apple.storagekitd.plist
com.apple.storeaccountd.daemon.plist
com.apple.storeagent.daemon.plist
com.apple.storeassetd.daemon.plist
com.apple.storedownloadd.daemon.plist
com.apple.storeinstalld.plist
com.apple.storereceiptinstaller.plist
com.apple.suhelperd.plist
com.apple.symptomsd.plist
com.apple.sysdiagnose.plist
com.apple.syslogd.plist
com.apple.sysmond.plist
com.apple.system_installd.plist
com.apple.systemkeychain.plist
com.apple.systempreferences.installer.plist
com.apple.systemstats.analysis.plist
com.apple.systemstats.daily.plist
com.apple.systemstatsd.plist
com.apple.taskgated-helper.plist
com.apple.taskgated.plist
com.apple.tccd.system.plist
com.apple.thermald.plist
com.apple.trustd.plist
com.apple.ucupdate.plist
com.apple.uninstalld.plist
com.apple.unmountassistant.sysagent.plist
com.apple.updateEFIDesktopPicture.plist
com.apple.usbd.plist
com.apple.usbmuxd.plist
com.apple.uucp.plist
com.apple.var-db-dslocal-backup.plist
com.apple.vsdbutil.plist
com.apple.warmd.plist
com.apple.watchdogd.plist
com.apple.wdhelper.plist
com.apple.wifid.plist
com.apple.wirelessproxd.plist
com.apple.wwand.plist
com.apple.xpc.smd.plist
com.apple.xpc.uscwoap.plist
com.apple.xsan.plist
com.apple.xsandaily.plist
com.apple.xscertadmin.plist
com.apple.xscertd-helper.plist
com.apple.xscertd.plist
com.vix.cron.plist
exec.plist
finger.plist
ftp.plist
login.plist
ntalk.plist
org.apache.httpd.plist
org.cups.cups-lpd.plist
org.cups.cupsd.plist
org.net-snmp.snmpd.plist
org.ntp.ntpd.plist
org.openldap.slapd.plist
org.postfix.master.plist
org.postfix.newaliases.plist
shell.plist
ssh.plist
telnet.plist
tftp.plist
```


----------



## BSD-Kitsune (Sep 12, 2016)

Systemd and Launchd suffer from the same fundamental issue:

PID 1 contains both the init and the process supervisor. This is bad. Because, race conditions in the process supervision code can compromise the root process of the entire OS. 

Ideally, what we need is PID 1 only used for startup and shut down. It should be made out of entirely hardened code. The process supervisor should be a separate process, and get fed data from existing tools and protocols, such as STREAMS. 

One architecture design I had for a supervisor was this:

PID 2 being the process supervisor - it monitors init from a log that init would keep at /var/log/init - this is so that it can keep track of all processes/daemons. PID 2 would be the parent process of all daemons that would normally go in /etc/rc.d and start them up by attaching them to a console device - this console would act similar to if you started the program from a terminal - if the console dies, the process exits gracefully. This would be instead of linux cgroups. In order to facilitate IPC, I would leverage the System V streams protocol and make a streams stack.

The stack would be supervisor <-> console supervisor <-> console <-> daemon and to communicate between processes , it would be console supervisor <-> console(s) which would simply communicate over standard STREAMS protocol. As a backup, if configured to not use the console supervisor, you could create a cgroups API or leverage a log that logs everytime a process forks, but I prefer the setup proposed because it's been used in IRIX before, and IRIX is extremely stable, and it offers the sophistication of the Linux stack from a KISS perspective.


----------



## Alexandru Moise (Sep 17, 2016)

Joseph Bruni said:


> I don't see systemd moving to BSD any time soon. GPL and BSD license models don't really go well together.


FreeBSD is the most linuxified BSD out there as it is, the line must be drawn HERE, no further!


----------



## debguy (Nov 8, 2016)

the elephant in the room may have been missed.

launchd is tightly integrated to control about everything on apple.  and maybe so is systemd on redhat.

However!  systemd along with kernel and libc "compiled options" allow systemd to put a PC into remote debugging mode before light (and i mean before VGA too) (total remote control even if booting local image).  I'm unsure if anyone has had a problem of this happening without their knowledge, but if there's bugs, there's a way.

launchd controls so many things it's bugs would be just as bad impact, but i'm unsure if launchd controls "remote fresh re-install" feature of apple products or not (ie, feature that boots remotely and installs a fresh OS to "renew product").  allot of system services the "come and go" whilie you use software are using launchd - any app that's worth using does.  it has a hand in sandboxing too.

systemd is a huge package with many bins and libs, you'd have to study it a long time to really "know what it does or might do" (that you wouldn't want).  it seems more focused on system startup and shutdown, but i imagine RedHat also uses it runtime - but likely not to level of integration of app sandboxing.

launchd ... _Apple has some liability_ as to whether it's being used *"to serving you, or a dis-service to you"*

i think if BSD linux et al took up some liability it would be good.   "if you can't say who edited source/script why in the apps, if users are not allowed to choose which management package should run their OS (ie meaning sysinit versus systemd)", then you of course have a serious problem that someone (or many) will eventually get maintainer access, abuse it, and not be liable - and be laughing to some bank when their goal xxxxxx is achieved, as no one had a choice or knew that they ran code against their own interest.

liability is a good thing.  proffesors of Berkeley University of California U.S.A. (knowing full well there are now probably 100 Berkeley elsewhere!), they had some liability in using public funds and expressing to the public they were not intended for harm.  i feel even the most remote liability has been forgotten even attacked as "legacy"

liability is good

good news is linux (mostly) builds bare (without trash forced in by "maintainers") and BSD is fully source

still, liability shouldn't be dis-claimed, it's just not health when "maintainers" can do things like "disable madatory access control - that was/is perfect no bugs" and replace it with "modular access - that continually has shown bugs".  they should be liable when things go wrong when they didn't give others a real choice


----------



## BSD-Kitsune (Nov 8, 2016)

The primary issue with Launchd, is summed up here : http://blog.darknedgy.net/technology/2015/08/26/0/

Basically OS X is architecturally very distant from FreeBSD and its goals are different. We cannot seek to merge them in a way that benefits FreeBSD enough to otherwise just stick with rc - or adopt the myriad other inits available.


----------

