The Debian init system general resolution returns
The Debian init system general resolution returns
Posted Oct 21, 2014 18:03 UTC (Tue) by nix (subscriber, #2304)In reply to: The Debian init system general resolution returns by mchapman
Parent article: The Debian init system general resolution returns
Posted Oct 21, 2014 18:47 UTC (Tue)
by mgb (guest, #3226)
[Link] (46 responses)
All but one of our systems - that includes desktops, laptops, servers, and VPSs - have one or more inittab entries in addition to those supplied by the distro.
There is no point in creating an initscript in those cases where inittab already does exactly what is needed.
This reminds me of Poettering's surprise when sound drivers in the real world were not as he had imagined either.
Posted Oct 21, 2014 19:28 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link] (5 responses)
I'm not discounting the idea that people have a customized inittab. But I am seriously skeptical that there is a functional situation in the wild where inittab semantics is more capable of expressing the desired action than what systemd unit semantics are able to provide.
If you simply don't want to learn a new system. Fine. I can respect that. I'll let you continue to use like and prefer inittab, just as long as you let me like an prefer 8-track cassettes. But please don't continue to express an expectation that factory installed default options will continue to support your preference. I've given up on getting an 8-track cassette player installed years ago.
-jef
Posted Oct 21, 2014 19:45 UTC (Tue)
by mgb (guest, #3226)
[Link] (4 responses)
You are at liberty to replicate an inittab function with a Turing machine if you wish.
F/LOSS and Debian are about choice. They are not about RH using EEE to force us to use the wrong tool for the job.
Posted Oct 21, 2014 20:32 UTC (Tue)
by louie (guest, #3285)
[Link] (1 responses)
Posted Nov 18, 2014 17:26 UTC (Tue)
by blujay (guest, #39961)
[Link]
Posted Oct 21, 2014 22:24 UTC (Tue)
by rodgerd (guest, #58896)
[Link] (1 responses)
Posted Oct 22, 2014 12:27 UTC (Wed)
by micka (subscriber, #38720)
[Link]
_But they do the work themselves_!
Posted Oct 21, 2014 19:39 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (39 responses)
More power to you. So keep using sysvinit.
In the unlikely event that you'd ever want to move to systemd, it's a pretty trivial exercise to come up with a systemd unit file corresponding to an inittab entry. If your /etc/inittab has a line like
From a maintenance POV, this setup has the additional benefit that you don't have to fix your configuration by hand like you need to when your distribution installs a new version of the /etc/inittab file.
Posted Oct 21, 2014 20:03 UTC (Tue)
by mgb (guest, #3226)
[Link] (38 responses)
sysvinit has provided respawn rate-limiting for as long as I can remember.
> additional benefit that you don't have to fix your configuration by hand like you need to when your distribution installs a new version
inittabs are updated by the configuration management system.
//
There may well be situations where systemd is the right tool for the job. The problem is RH using EEE to preclude us from using the right tool for the job when that tool is not systemd.
Posted Oct 21, 2014 21:26 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (37 responses)
Sort of. Sysvinit's rate limiting is hard-coded and not configurable – it's great if its fixed parameters suit your application but it sucks if they don't. Systemd gives you a lot more control.
In general, systemd lets you do many more things out of the box that would be a hassle to configure with sysvinit.
With sysvinit, there is a completely arbitrary and superfluous distinction between services started from inittab and services started by init scripts. This is one of sysvinit's various design flaws. Systemd, on the other hand, treats all services the same regardless of how they're started. This makes life easier for admins and people who are learning or teaching how the system works.
You still need to reconcile your tweaks with whatever changes to the base configuration file the distribution makes from one version to the next. With systemd this is a complete non-issue since the distribution's base configuration files and one's own local changes are cleanly separated by design. (/etc/inittab is a reasonably simple file but the issue is worse with init scripts.)
Posted Oct 21, 2014 21:30 UTC (Tue)
by mgb (guest, #3226)
[Link] (36 responses)
You are not welcome to force other people to use systemd where it is the wrong tool for the job.
Posted Oct 21, 2014 21:34 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link] (19 responses)
And by that logic, when an application or framework developer thinks the systemd APIs are the right tool for the job, they have the freedom to choose to support those APIs without being forced to support other less optimal APIs.
-jef
Posted Oct 21, 2014 21:48 UTC (Tue)
by mgb (guest, #3226)
[Link] (18 responses)
And Debian has the freedom not to include software which violates Debian's policies.
Posted Oct 21, 2014 22:06 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link] (17 responses)
And in point of fact.. up until very recently sysvinit was the _only_ forced init in debian due to its essential nature:
http://www.vitavonni.de/blog/201410/2014102101-avoiding-s...
So even without the GR in place to coerce or mandate, maintainers have already been working to make it easier for everyone involved in Debian to have more "choice" and to agree to disagree as to watch choices are best.
Makes me wonder... Why was it okay to mandate sysvinit as essential prior releases? if this is really about choice...why weren't the choice proponents making the case back then that sysvinit as essential was taking choice away? Where were the proponents champion the choice to run a system on runit or minit without having sysvinit installed at all on the system?
The GR solves nothing, addresses nothing. Even if it passes, sysvinit compatibility in the future when uselessd becomes available as a packaged alternative to systemd.
-jef
Posted Oct 21, 2014 22:31 UTC (Tue)
by mgb (guest, #3226)
[Link] (16 responses)
Debian's "Essential: yes" package attribute does not mean what you think it does.
Thanks to modular design, Debian Wheezy supports numerous tools in this space including daemontools, filerc, openrc, runit, systemd, sysvinit, and upstart.
The problem comes now that RH deliberately breaks existing software so that it no longer works without systemd.
Posted Oct 21, 2014 23:06 UTC (Tue)
by anselm (subscriber, #2796)
[Link]
For the record, “Essential: yes” means that the package can't be removed with the package management tools (without a special command line option to dpkg, anyway).
Please name a package in Debian that has been “deliberately broken so that it no longer works without systemd.“
Posted Oct 21, 2014 23:25 UTC (Tue)
by pizza (subscriber, #46)
[Link] (14 responses)
Whether or not you have any valid points...this is *not* one of them.
FYI, Your "existing software" will continue to work as well now as it did the moment you first installed it. If you *chose* to install a newer version of said software, then guess what? It isn't "existing software" any longer; it is "new software", usually developed by independent third parties, which may have new features, along with new prerequisites to support those features.
You've even conceded this point elsewhere in this thread, so I can only wonder why you keep bringing it up. Your insistence on harping on something demonstrably false only hurts your credibility and any legitimate arguments you may have. I respectfully suggest you drop it.
Posted Oct 22, 2014 1:16 UTC (Wed)
by mgb (guest, #3226)
[Link] (13 responses)
Debian is deciding whether to include in Jessie software which has been deliberately crippled to only work with systemd.
RH cannot force Debian to distribute broken software.
Posted Oct 22, 2014 1:19 UTC (Wed)
by raven667 (subscriber, #5198)
[Link] (9 responses)
Posted Oct 22, 2014 4:44 UTC (Wed)
by dlang (guest, #313)
[Link] (8 responses)
Posted Oct 22, 2014 5:28 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link] (7 responses)
But I'd be a little more nuanced than that. Its the dependence on the logind API specifically. There are other systemd provided APIs like hostnamed and friends which have not be controversial as they were easily re-implementable as small tools outside the systemd codebase. But there was a real question as to whether or not the existing -shim was going to gain support logind in time to matter for jessie.
Now with -shim supporting logind API that original concern has been taken care of. So credit where credit is due. The work to bring logind API support to -shim should be applauded as it definitely is going to benefit Debian users who desire to update systems to jessie and transition to systemd more slowly.
Moving forward I expect the next pain point is going to be the GNOME concept of app containers which will be using systemd APIs. But I don't have a good feel for the shape of that battleground yet. cgmanager does exist now so its not as dire. Maybe there might have to be an API translation layer to connect systemd API to cgmanager API, but not nearly as scary as the logind situation before -shim gained gained support for logind using cgmanager in the background.
Then in the longer term, kdbus is going to be a big problem... because nobody outside of systemd dev is looking to implement a userspace side to support kdbus. I fully expect GNOME to start making use of kdbus as soon as it goes mainline. And unlike for what happend for -shim, I'm not sure Debian can rely on Canonical/Ubuntu to help lead an alternative to systemd's implementation. If Ubuntu fully transitions over to systemd before kdbus is merged in the kernel mainline (and that seems likely) then there's no obvious candidate to do the work to provide the alternative implementation.
-jef
Posted Oct 22, 2014 5:37 UTC (Wed)
by dlang (guest, #313)
[Link] (2 responses)
Therefor fearing that such software may be created in the future is not someone being a fearmonger or being deceitful, instead it's someone expecting that what was done before will be done again.
If Gnome no longer requires systemd, that's a good thing. It's also what the response should have been in the first place rather than taking the attitude that doing anything other than forcing everyone to switch to systemd was putting an unreasonable burden on Gnome.
Posted Oct 22, 2014 5:59 UTC (Wed)
by mchapman (subscriber, #66589)
[Link]
To be fair, it never really *required* systemd. It can make use of a particular D-Bus interface that systemd provides, but it doesn't care one iota whether that interface happens to be provided by some other project instead. So it's probably wrong to think of Gnome as having undergone change -- what has happened is that the environment "around" GNOME has changed: there is now more than one implementation of this interface. And that most certainly is a good thing!
Posted Oct 22, 2014 6:27 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link]
GNOME is still technically depending on exactly the same thing it did 6 months ago. systemd-logind is still the only implementation of logind's API. -shim just now implements the systemd APIs that systemd-logind is using.
So again its more nuanced. If GNOME upstream or GNOME debian maintainers had waited for a second implementation to exist before depending on an API, would a second implementation ever been made? Or is it because GNOME upstream pushed ahead and the distro maintainers integrated the new upstream code, that created the need for the alternative implementation that caused it to be created? The need being the mother of invention and all that.
I think the historic Debian transition to use hal is instructive: https://lists.debian.org/debian-user/2009/09/msg00915.html
then the application incompatibilities transitioning from hal to udev in wheezy:
Call me a greybeard..but it sure seems like kids these days seem to have a poor grasp on how Debian has handled major userspace plumbing historicly.
The transition to hal and then to udev both introduced incompatibilities and there was never a requirement that multiple implementations be expected to work seamlessly as alternatives of each other. What mattered was a plan to get from old default to new default.
And so it should be with the transition for new default init. Regardless of changes in the API.
-shim is an important piece to aid the transition to the new default init. But to hold the idea of init diversity as something sacrosanct after years and years of previous Debian project experience transitioning plumbing in a more focused linear manner is.. smirkable.
No matter how this all shakes out sysinit is going to join HAL and devfs in the software retirement home. It's just a matter of time.
-jef
Posted Oct 22, 2014 8:29 UTC (Wed)
by johannbg (guest, #65743)
[Link] (3 responses)
I would take that "support" with a very and I mean very much grain of salt.
systemd-shim package is a futile attempt since the goal that it has to aim for, keeps moving around. There are no stability promises on a core functionality logind uses and as a result of that has left systemd-shim broken for months before and will do so again each and everytime it's (afaik sole ) maintainer Steve Langasek has to play catchup with upstream changes.
Now as it's name indicated requires you to still have systemd installed so the Debian community has the choice of using a) An component which is busy chasing rainbows and developed/maintained by single individual or b) Use systemd with logind and all the other bells and whistle systemd provides which is backup by Tollef Fog Heen, Michael Biebl, Marco d'Itri, Michael Stapelberg, Sjoerd Simon and the entire upstream systemd community.
Now let's return to the core of the matter, the work required by the Debian, ( as well as Gentoo,Slackware and whomever intents to support multiple and or use alternative init system than systemd whatever they may be called uselessd,openrc,sysvinit etc in the long run ) community has to come up with ( and the systembsd maintainer bumped into as well and significantly slowed down the development or grounded his development to halt entirely ).
In *addition* having to carry downstream compatibility patches for all upstream components that have decided to integrate/use what systemd provides them with *beside* logind and the added load on the service support community ( help,qa,releng etc ) and it's maintainers that will bring, they will need to write and thus provide a daemon that provides the external, supported, and guaranteed stable "login" API, an daemon that maps the "login" API to the non-portable operating-system-specific underpinnings which is an hefty chunk of development work.
You cant workaround this problem in apt through some dependency/resolving magic and you wont achieve this with something like systemd-shim or have it magically appear by whining about it on mailing lists, in forum, and various comment sections or by continually coming up with GR's and the likes, you actually need to get your hands dirty and start doing that hefty coding period.
Ian and his followers are doing pretty good job disrupting the Debian community from doing what needs to be done to make Jessie the most awesome release ever ( integrate it to the best of it's ability to systemd. I've been midst in this integration work myself and I know how much it pains users have things half integrated, half migrated and thus half working ) and ensuring Jessie will become the worst release ever by having no init working reliably since him and his followers are not coming up with components and the code necessary to do so.
I just sincerely hope for the sake of Debian that the DD will vote for Luca Falavigna proposal ( Choice 3 ) which will put this power into the hands of the maintainers themselves since I know quite few of them know the reality for what it is but have chosen to keep themselves outside any ( systemd ) discussion and mud sliding.
Posted Oct 22, 2014 15:40 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link] (2 responses)
point of information. I think ryan lortie is primary committer upstream.
both U and D bzr packaging systems suck in the upstream releases from ryan and seem to be point to http://people.gnome.org/~desrt/ as the source
Ryan seems to be using github primarily, but not github's release tagging mechanism, so the tarballs in http://people.gnome.org/~desrt/ are probably the canonical upstream release source.
Steve is acting primarily in the role of distribution packaging maintainer I think. And Martin Pitt is committing at both the distro and upstream levels.
Anyways... Ryan had a lovely blog post back in Feb, which I believe concurs with your assessment of the difficulty of using -shim to mimic the full systemd API. I think he draws different conclusions than you do from that. Considering what Ryan posted in Feb, I'm actually surprised that they got -shim updated to support logind. His post implied to me that it wasn't going to be attempted.
Seems -shim grew all the necessary cgroups stuff since september looking at ryan's github for -shim.
-jef
Posted Oct 22, 2014 17:45 UTC (Wed)
by johannbg (guest, #65743)
[Link] (1 responses)
Which happens to be one area him and or him and Martin will be constantly playing catchup with systemd.
I would not be surprised if they will only continue to maintain it until unity/ubuntu catches up with systemd and at that point they loose interest.
In anycase bottom line still remains the same if people want to ( continue to ) use alternate init system(s), be it single or plural instead of systemd in the name of choice or disgust towards systemd, individual members of the systemd community or the systemd community in whole, those individuals *will* have to code up/beef up those existing init system ( or write one from scratch ) to be somewhat on par with systemd. Once they have achieved that then they will have to convince wide variety of upstreams that currently use systemd to support that and or integrate it with their alternative.
Posted Oct 22, 2014 18:27 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link]
What I don't really have my head around is what the plan is for updating systemd in either U or D and how conservative the systemd packaging updating is going to be. Both could basically peg systemd to a specific upstream version and skip some upstream releases in an effort to lower the risk of creating an API delta that -shim will have to keep up with.
I expect work on -shim compatibility to be bursty...and only happen for upstream versions of systemd that land in Ubuntu pre-release packaging, even if systemd versions roll into Debian unstable/experimental on a more regular fashion thanks to the effort of the systemd debian maintenance team. So I expect to see a delta to build up in the Debian unstable/experimental repo just to the differences in available attention and interest in tracking upstream systemd.
I'm willing to see this admitted low expectation on -shim work to be surpassed and I'll take any well deserved lumps for discounting the commitment of the people working on -shim if they are able to keep the delta between -shim and systemd API coverage low without another 4+ month lapse in -shim activity.
-jef
Posted Oct 22, 2014 1:29 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link] (2 responses)
Proponents of the GR have stipulated in the ongoing discussion on -vote that there is no current issue in jessie currently which the outcome of this GR would impact.
Also they have explicitly stipulated that any RC bugs which are created due to the mandates of this GR for a yet to be found issue that -shim doesn't adequately handle, such RC bugs would be treated by the release team as jessie-ignore.
Do I need to provide citations to the ongoing discussion for these facts?
In very fundamental ways this GR is explicitly _not_ about fixing any perceived brokenness in jessie release. As there is no perceived brokenness in the jessie release.
Which is why the timing of this is a bit of a head scratcher. This could have waited for post jessie freeze.
-jef
Posted Oct 22, 2014 1:53 UTC (Wed)
by mgb (guest, #3226)
[Link] (1 responses)
Furthermore he said that ignoring such bugs is but one possible course of action. He did not say that the release team would ignore such bugs. Other possible courses of action include fixing the bugs and omitting Gnome from Jessie.
Posted Oct 22, 2014 4:38 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link]
The proposed GR text was amended by Ian after discussion concerning the impact on jesse. The amended GR text that exists right now stipulates that the expectation the release team with ignore RC bugs generated if the proposed GR passes for the express purpose of avoiding blockers on jessie release.
Citations:
Posted Oct 21, 2014 21:48 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (15 responses)
At the risk of sounding like a broken record, nobody is “forcing“ anyone to use systemd. Sysvinit isn't going away as long as there are people willing to put in the work to keep it around.
Posted Oct 21, 2014 21:56 UTC (Tue)
by mgb (guest, #3226)
[Link] (14 responses)
Posted Oct 21, 2014 22:03 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (13 responses)
Exactly which Debian packages in jessie force you to run systemd as PID 1?
(Other than systemd-sysv, that is.)
Posted Oct 23, 2014 3:37 UTC (Thu)
by xz (guest, #86176)
[Link] (12 responses)
network-manager
Here is another more complete graph generated by debtree for packages with hard dependecy on systemd: http://i.imgur.com/5MchQde.png
Posted Oct 23, 2014 6:56 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (11 responses)
For example: https://packages.debian.org/jessie/lighttpd has a dependency on systemd or lsb-base. Systemd is not mandated at all.
Posted Oct 24, 2014 1:05 UTC (Fri)
by xz (guest, #86176)
[Link] (10 responses)
The list I provided can be manually verified and they require systemd (via libpam-systemd or not). The fact that user applications far downstream start having hard dependency on systemd shows the dependency land grabbing scheme in the work.
Thanks for the catch on lighttpd though. That was because debtree doesn't have a good way to deal with alternative dependencies (`apt-cache -i rdepends systemd` doesn't show lighttpd as an alternative reverse dependency). I had to manually weed out many irrelevant packages, like -dbg, -plugins, -mod packages, and I skipped many of gnome packages for the sake of showing the effect on non-gnome users. It is certain there could be some errors. Large part of the result is valid.
Here, I patched debtree to ignore all alternative dependencies. The updated graph is largely unchanged: http://i.imgur.com/SxufNQ2.png . Error reports are welcome.
Posted Oct 24, 2014 1:20 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (9 responses)
Anyway, it still doesn't hard-depend on systemd. Libpam-systemd can work just fine with systemd-shim: https://packages.debian.org/jessie/libpam-systemd
Posted Oct 24, 2014 2:00 UTC (Fri)
by mchapman (subscriber, #66589)
[Link]
Moreover, libpam-systemd can work "perfectly well" -- as a no-op -- on systems that don't have any logind implementation at all. Looking at its code, it simply appears to check whether /run/systemd/seats/ exists, exiting successfully if it doesn't. Curiously, on Debian this check is patched out...
Posted Oct 24, 2014 2:32 UTC (Fri)
by xz (guest, #86176)
[Link] (7 responses)
Tell me, how do you install libpam-systemd without systemd? I'm sure you have reason for libpam-systemd to be technically optional, but why does it have a hard dependency on systemd? Is it a bug?
libpam-systemd itself is NOT optional if you happen to be one of the users of the packages I listed above. I listed hard reverse dependencies above to demonstrate which users will have to use systemd because of (reverse) dependencies. If everything depends on libpam-systemd but you're not using anything, I guess you can still have the truism of libpam-systemd being optional.
Posted Oct 24, 2014 2:39 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
libpam-systemd ( https://packages.debian.org/jessie/libpam-systemd ) has the following dependency:
>dep: systemd-sysv
So yes, systemd is optional and not required in Jessie.
Posted Oct 24, 2014 2:41 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (5 responses)
That's incorrect, libpam-systemd simply needs some files packaged in the systemd package. It doesn't require it running.
To actually activate systemd on Debian one needs to install the systemd-sysvinit package (or manually specify it in the kernel command line).
Posted Oct 24, 2014 3:38 UTC (Fri)
by xz (guest, #86176)
[Link] (4 responses)
Is the package designed for being installed without being used? No.
As Chapman pointed out, libpam-systemd is explicit patched in Debian to start logind on demand. Therefore libpam-systemd depends on and actively uses an integral component of systemd. If it is really as simple as using some files from the systemd package, why not put those files into libpam-systemd?
Or are you changing the definition of systemd? logind is not systemd! I know systemd the word can mean a lot of things.
P.S. who on earth think it is a good idea to start daemons from deep inside a library "on demand"?
Posted Oct 24, 2014 3:59 UTC (Fri)
by dlang (guest, #313)
[Link] (1 responses)
The first requires coding to fix, the second just requires packaging changes.
Since the systemd advocates have less than zero interest is supporting anyone not using systemd, it's not at all surprising that the packaging of the software drags in extra stuff
After all, it's the advocates who become package maintainers, they are interested in making that package work, not in supporting other packages working without their favourite software. It takes extremely mature maintainers to support that level of compatibility. This isn't the dig against systemd maintainers that it may sound like, _very_ few packages have maintainers or project leads that think about how people who don't use their whole package should be supported, either by breaking out components that are useful to others, or in terms of how users will be able to migrate cleanly away from the software.
Posted Oct 24, 2014 9:44 UTC (Fri)
by anselm (subscriber, #2796)
[Link]
Packaging software pretty much always involves tradeoffs.
It would probably be possible to divide the “systemd” package on Debian into a number of packages that split out library support, etc. However, given that systemd is the designated default init system for Debian, we can reasonably expect that in the future a majority of Debian systems will run systemd. This means that for most users, splitting systemd into a number of packages that will all be installed doesn't really add value – it mostly makes extra work for the package maintainers and increases the probability of bugs.
For those who don't run systemd as PID 1 but still need the package installed for the libraries, a few extra files likely won't make that much of a difference, and if at some point a reasonable case for separating out some functionality emerges (say, when kdbus becomes popular) then the package can still be split.
Posted Oct 24, 2014 4:37 UTC (Fri)
by mchapman (subscriber, #66589)
[Link]
The Debian systemd package maintainers, clearly.
As I pointed out, the upstream systemd code does not do this. If you use the upstream pam-systemd on a non-systemd system, it's a no-op.
Posted Oct 24, 2014 4:44 UTC (Fri)
by mchapman (subscriber, #66589)
[Link]
Well, I think Cyberax is wrong there. It isn't as simple as "using some files".
pam-systemd uses the logind D-Bus interface, org.freedesktop.login1. Anything that implements that interface correctly should work with it, which is why Debian's libpam-systemd can work with systemd-shim.
The error here is in removing the "test if logind even appears to be installed" check. While that's probably the right idea, in that I suspect systemd-shim doesn't create the directory it looks for, it means that D-Bus activation now takes effect: it's made pam-systemd *require* a logind D-Bus interface, instead of failing gracefully if logind isn't present.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
All but one of our systems - that includes desktops, laptops, servers, and VPSs - have one or more inittab entries in addition to those supplied by the distro.
fb:2345:respawn:/usr/local/bin/foobar -baz
simply add a file /etc/systemd/system/foobar.service containing
[Unit]
Description=Foobar service (from inittab)
[Service]
ExecStart=/usr/local/bin/foobar -baz
Restart=always
[Install]
WantedBy=multi-user.target
At first glance this seems more wordy but it does allow all sorts of useful features that sysvinit doesn't offer (like, for example, rate limiting for respawns). In addition, the service can be started and stopped manually like all other systemd services where with sysvinit you would need to edit the /etc/inittab file, and it shows up in the usual service status listings.
The Debian init system general resolution returns
The Debian init system general resolution returns
sysvinit has provided respawn rate-limiting for as long as I can remember.
inittabs are updated by the configuration management system.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
Debian's "Essential: yes" package attribute does not mean what you think it does.
The problem comes now that RH deliberately breaks existing software so that it no longer works without systemd.
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
https://wiki.debian.org/Suspend
The Debian init system general resolution returns
The Debian init system general resolution returns
ref: http://blogs.gnome.org/desrt/2014/02/19/on-portability/
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
Please don't mislead people. Ian said he was not aware of any RC bugs - not that there are none, or that there will be none.
The Debian init system general resolution returns
"This GR seeks to preserve the freedom of our users now to select an
init system of their choice, and the project's freedom to select a
different init system in the future. It will avoid Debian becoming
accidentally locked in to a particular init system (for example,
because so much unrelated software has ended up depending on a
particular init system that the burden of effort required to change
init system becomes too great). A number of init systems exist, and
it is clear that there is not yet broad consensus as to what the
best init system might look like."
The Debian init system general resolution returns
https://lists.debian.org/debian-vote/2014/10/msg00124.html
https://lists.debian.org/debian-vote/2014/10/msg00197.html
https://www.debian.org/vote/2014/vote_003
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
libvirt-*
hplip - HP Linux Printing and Imaging System
fprintd - D-Bus daemon for fingerprint reader access
colord - system service to manage device colour profiles
bluefish - advanced Gtk+ text editor for web and software development
steadyflow - Simple download manager for GNOME
sparkleshare - distributed collaboration and sharing tool
nemo - File manager and graphical shell for Cinnamon
nautilus - file manager and graphical shell for GNOME
caja - file manager for the MATE desktop
brasero - CD/DVD burning application for GNOME
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
> system and service manager - SysV links
>or systemd-shim (>= 8-2)
> shim for systemd
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
