| View previous topic :: View next topic |
| Author |
Message |
rich0
Developer
Joined: 15 Sep 2002
Posts: 161
|
 Posted: Tue Mar 06, 2018 1:24 pm Post subject: Re: Effects of blocking systemd via INSTALL_MASK |
 |
|
| steveL wrote: | | Then come back and re-read your previous posts, and see what you think of yourself. |
You do realize that somebody can know just as much as you know, and actually disagree with you, right? |
|
| Back to top |
|
 |
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Mar 11, 2018 3:13 am Post subject: |
|
|
It's got nothing to do with "disagreement."
Your question is "full of fail" as the kids say nowadays, in at least 3 ways I could list (if I had time, and inclination to go throught the subsequent explanations), all of which sum up to a question that would make any ##bash long-term regular user both recoil and wince; then start to explain before greycat gave you a rundown of just how broken your thinking is in much less polite terms.
The thing is, you need to learn these things for yourself, and it's clear to me (as it would be to any such #bash or ##posix regular) that you have not grasped them yet. Sorry to be the bearer of bad news.
TIAS; ask that question in #bash and watch as at least 2 or 3 people start explaining to you just how broken your pre-conceptions are, in the friendliest manner possible, before greycat gets a chance to drub you down (if he's online; if you haven't read him yet, then you haven't lurked long enough, or regularly enough.)
Note that none of this is about you as a person, so please take the time to ego-detach from your own words. They're only words.
Nothing to live or die by.
And FTR: there are many people who know more than I do, and many subjects I know very little about, so don't pretend to expertise or even knowledge of.
Nor am I pretending to vast knowledge of UNIX (and years of experience since I first used..); I am referring you to the collective that does, to my personal experience, have precisely that knowledge, and both the willingness and aptitude to teach it to others: the collection of professional sysadmins who provide the backbone of #bash experience across Unixen.
Take it or leave it, it really makes sod-all difference to me and my work.
Just don't expect me to sit by and watch stuff that would make a #bash regular splutter into their cereal with laughter, pass for "greybeard wisdom."
It is nothing of the sort; it is in fact a rhetorical putdown, and the sad part is how wilfully stupid it sounds. Your argument is logically equivalent to:
"We must use Windows, because the USB spec says nothing about MPEG-4."
Since you know so much, that should be enough of a clue to show you the holes.
HF now. Life's too short for anything else. ;) |
|
| Back to top |
|
|
rich0
Developer
Joined: 15 Sep 2002
Posts: 161
|
| Posted: Sun Mar 11, 2018 11:26 am Post subject: |
|
|
| steveL wrote: | | Your question is "full of fail" as the kids say nowadays, in at least 3 ways I could list (if I had time, and inclination to go throught the subsequent explanations) |
You actually managed to write 400 words that boiled down to, "you're wrong, and I can't be bothered to explain why I feel that way."
Please note that I'm not concerned with you as a person, so please take the time to ego-detach from your own words. They're only words. Nothing to live or die by.
The thing is, you need to learn these things for yourself, and it's clear to me that you have not grasped them yet. Sorry to be the bearer of bad news.
Since you know so much, that should be enough of a clue to show you the holes.
HF now. Life's too short for anything else.  |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Mar 11, 2018 5:41 pm Post subject: |
|
|
| rich0 wrote: | | You actually managed to write 400 words that boiled down to, "you're wrong, and I can't be bothered to explain why I feel that way." |
You say that like it's news.
I thought I was quite upfront: No I cannot be bothered to correct your borken thinking. It would take far too long, and would involve far too much of this kind of puerile back and forth.
I very much doubt I could get through to you, and the argument would simply be preserved in aspic forever, before you finally gave in and y'know did some basic research. Even that, I doubt: far more likely you'd just take the information, stash it away for a later argument, and still not grok what's been said.
Still, at least I have a better idea now of where you are in the life-cycle of a Gentoo developer.
Chances are you're going to burn out in the next year or two (could be 6 months, could be longer).
Before that happens, you'll start being dubious about the people you currently listen to without critique.
That's healthy: the #gentoo-dev cargo-cult, where posturing is more important than end-results, and toilet-humour is somehow an acceptable substitute for wit, are full of crap anyhow.
You really do need to get out of your confirmation-bias bubble; but you need to let go of all that unhelpful attitude first.
As for verbiage, cast your mind back a few years, to the days when you regularly sent long, hearfelt missives to the mailing-list.
Longwinded and tedious as those were, and mind-numbing in the way they took a page and a half for you to lay out your exploration of ground everyone else already had covered, only to end up in a turgid conclusion of the bleedingly obvious that never shed any light on the specific implementation aspects that were under discussion, they were much preferable to your current approach.
You appear to be in thrall to some real nubskulls, to the extent that you are susceptible to parroting weasel-worded toxic propaganda, designed for the cargo-cult generation to engender precisely the kind of divisive argument you put on display.
You clearly have never paid your dues in #bash, never mind understanding what ##posix has to teach.
So while I'd love to help out, and even had a couple of books that you need to read now, surprisingly your puerile response means that I have even less inclination.
Still no matter: after all, you know just as much as I do, if not more ("cos that's wots rly imprtnt.")
And FTR, deleting quote tags and mirroring my statements back to me: the only possible rationalisation you could have for that is that you wanted to show me how they felt. Thing is, even as I realised you were doing that, the words came across as friendly, and I didn't feel any ill-will toward you.
You should try it sometime. It's a helluva lot more fun than smug superiority.
Especially when that's based on bone-headed ignorance, and some turd that floated downstream from the guys poisoning the water for all of us (so they can sell us bottled "water" instead.)
Since I likely won't be around by the time you work through all this, let me put it in terms you will understand, no doubt from prior experience:
*plonk* |
|
| Back to top |
|
|
rich0
Developer
Joined: 15 Sep 2002
Posts: 161
|
| Posted: Sun Mar 11, 2018 6:27 pm Post subject: |
|
|
| steveL wrote: | | Since I likely won't be around by the time you work through all this... |
I can't imagine that I'd be so lucky... |
|
| Back to top |
|
|
jd2066
Apprentice
Joined: 04 Jun 2006
Posts: 155
|
| Posted: Mon Mar 12, 2018 1:10 am Post subject: |
|
|
Wow, I didn't know this topic was still active.
To find that a topic I created on January 3rd is still active on March 11 is a bit of a surprise as I didn't think there was really anything left to say about the topic of tmpfiles.d.
After catching up on the recent replies, it appears that is still true.
It mostly appears to be @steveL arguing with @rich0 on the topic of tmpfiles.d being a good idea or not a good idea.
I'm not a *NIX expert that knows everything there is to know about the topic but @rich0 appears to be making more sense to me about tmpfiles.d being a useful service in systemd and openrc.
There really don't seem to be anything technically wrong with tmpfiles.d, while it is part of systemd that doesn't mean it's not a good thing to have in general.
I think some of the ideas that came from the systemd developers are actually pretty good and useful even outside of systemd such as the /run introduction and tmpfiles.d.
It's sucks that many of the systemd developers did things that were just unnecessary and make things harder to manage and use overall.
Otherwise, systemd at first glace seems like the better init system then openrc as it enables all kinds of nifty automatic configuration and service dependency management that no other init system including openrc is able to do. |
|
| Back to top |
|
|
CasperVector
Apprentice
Joined: 03 Apr 2012
Posts: 156
|
| Posted: Mon Mar 12, 2018 8:44 am Post subject: |
|
|
| jd2066 wrote: | | I think some of the ideas that came from the systemd developers are actually pretty good and useful even outside of systemd such as the /run introduction and tmpfiles.d. |
There might be some good ideas, but quite a few of us do not think the /var/run-to-/run migration and tmpfiles.d are. Did you read this and this?
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C |
|
| Back to top |
|
|
jd2066
Apprentice
Joined: 04 Jun 2006
Posts: 155
|
| Posted: Mon Mar 12, 2018 12:49 pm Post subject: |
|
|
| CasperVector wrote: | | jd2066 wrote: | | I think some of the ideas that came from the systemd developers are actually pretty good and useful even outside of systemd such as the /run introduction and tmpfiles.d. |
There might be some good ideas, but quite a few of us do not think the /var/run-to-/run migration and tmpfiles.d are. Did you read this and this? |
Yes I did read those posts.
I also read the replies to those posts which mentioned some of the positive things about tmpfiles.d.
None of the listed negatives in the topic seem to be a big deal at all.
It seems like tmpfiles.d just centralizes the configuration of temporary directories/files removing the need for the programs themselves, init scripts, etc to create and set proper permissions on the needed temporary directories/files.
Why put code in each init script for a daemon that needs certain temporary directories/files to eixst before it starts when tmpfiles.d can handle that?
I've been using Gentoo Linux sence at least 2004/2005 and during most of that time a /run directory and tmpfiles.d did not exist but that doesn't nessesarily mean the changes weren't useful and even nessesary for some things.
I agree that things like modules-load.d don't really serve a purpose and can make things harder to configure due to having an existing pretty good module configuration file at /etc/conf.d/modules which works just fine but the existing system for tmpfiles is not as good.
If all applications defined their temporary directories/files a sub directories of /run and /var instead of creating things on-the-fly in /tmp then /tmp would likely not be needed anymore.
I don't know if that is one of their goals with tmpfiles.d or not but it would certainly be possible as the main purpose of a world writable directory like /tmp is to allow applications to create their own temporairy directories/files so if those were already created in other places then /tmp wouldn't really be needed at all. |
|
| Back to top |
|
|
rich0
Developer
Joined: 15 Sep 2002
Posts: 161
|
| Posted: Mon Mar 12, 2018 1:04 pm Post subject: |
|
|
| jd2066 wrote: | | I don't know if that is one of their goals with tmpfiles.d or not but it would certainly be possible as the main purpose of a world writable directory like /tmp is to allow applications to create their own temporairy directories/files so if those were already created in other places then /tmp wouldn't really be needed at all. |
At least in systemd this is typically done by giving services private /tmp directories in their own mount namespaces. Sure, there are other ways to go about this but those require application changes, or possibly changes that could have unintended consequences. Private /tmp directories at least improve security/isolation without any need for application changes.
A lot of the drivers behind stuff like tmpfiles.d are associated with stateless containers/systems. The idea is to minimize any kind of persistent state, or greatly consolidate where it is stored. |
|
| Back to top |
|
|
CasperVector
Apprentice
Joined: 03 Apr 2012
Posts: 156
|
| Posted: Mon Mar 12, 2018 2:07 pm Post subject: |
|
|
| jd2066 wrote: | Yes I did read those posts.
I also read the replies to those posts which mentioned some of the positive things about tmpfiles.d.
None of the listed negatives in the topic seem to be a big deal at all. |
Fine. And I would like to note that, at least in my opinion, the positive things are even less of a big deal than the negative things.
| jd2066 wrote: | It seems like tmpfiles.d just centralizes the configuration of temporary directories/files removing the need for the programs themselves, init scripts, etc to create and set proper permissions on the needed temporary directories/files.
Why put code in each init script for a daemon that needs certain temporary directories/files to eixst before it starts when tmpfiles.d can handle that? |
Because the centralised way requires much more code than the decentralised way does, and is much less flexible, as already shown (and nobody seemed to oppose).
Actually, I found the usage of install(1) much easier to understand than that of tmpfiles.d, which is unsurprising given the background of Unix philosophy.
| jd2066 wrote: | If all applications defined their temporary directories/files a sub directories of /run and /var instead of creating things on-the-fly in /tmp then /tmp would likely not be needed anymore.
I don't know if that is one of their goals with tmpfiles.d or not but it would certainly be possible as the main purpose of a world writable directory like /tmp is to allow applications to create their own temporairy directories/files so if those were already created in other places then /tmp wouldn't really be needed at all. |
Which seems independent of whether tmpfiles.d is used or not.
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C
Last edited by CasperVector on Mon Mar 12, 2018 2:26 pm; edited 1 time in total |
|
| Back to top |
|
|
CasperVector
Apprentice
Joined: 03 Apr 2012
Posts: 156
|
| Posted: Mon Mar 12, 2018 2:21 pm Post subject: |
|
|
| jd2066 wrote: | | Otherwise, systemd at first glace seems like the better init system then openrc as it enables all kinds of nifty automatic configuration and service dependency management that no other init system including openrc is able to do. |
(Did not notice this in the first place.) May I ask for some examples? Actually, I have still not found a single thing systemd does that daemontools-like init/rc systems cannot do better. In most cases, just remember that chainloading is your friend.
As for managing temporary files and directories, I find a `./run' script that runs install(1) before the final exec() and (optionally) a `./finish' script that does clean-up work to be much more elegant; if isolation (based on namespace, chroot, etc.) is needed, just do the related work after the install(1) invocation (perhaps using tools like this). Moreover, all these code (if they really need to be complex) can be abstracted into shared functions, macros, etc. that are stored elsewhere, so the `./run' / `./finish' scripts will still be extremely clean (perhaps even cleaner than systemd unit files). And the cost of implementation and maintenance would be vastly lower than that in the systemd case.
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C
Last edited by CasperVector on Mon Mar 12, 2018 5:39 pm; edited 1 time in total |
|
| Back to top |
|
|
rich0
Developer
Joined: 15 Sep 2002
Posts: 161
|
| Posted: Mon Mar 12, 2018 3:06 pm Post subject: |
|
|
| CasperVector wrote: | | Moreover, all these code (if they really need to be complex) can be abstracted into shared functions, macros, etc. that are stored elsewhere, so the `./run' / `./finish' scripts will still be extremely clean (perhaps even cleaner than systemd unit files). And the cost of implementation and maintenance would be vastly lower than that in the systemd case. |
Are you referring to the cost of implementing a service using your already-highly-customized openrc solution, or the cost of building it in the first place?
If I want to do all that stuff in your "run/finish" scripts with systemd it is usually just a one-liner in a config file, assuming upstream didn't already provide that line.
Ultimately openrc uses bash which is turing complete, so of course you can do anything in an init.d script that systemd does, and since systemd units can call bash scripts the reverse is also true. If you limit yourself to declarative configuration I'd argue that you can do a lot more with systemd.
But, sure, you can basically build your own custom service manager that does things just the way you want them done. Since openrc is scripted I could see how doing that in openrc is potentially easier. |
|
| Back to top |
|
|
CasperVector
Apprentice
Joined: 03 Apr 2012
Posts: 156
|
| Posted: Mon Mar 12, 2018 3:32 pm Post subject: |
|
|
| rich0 wrote: | | Are you referring to the cost of implementing a service using your already-highly-customized openrc solution, or the cost of building it in the first place? |
Neither. I consider the total complexity of the system, where any part might fail. Given this background, and the careful design and implementation of daemontools-like init/rc systems, they (in combination with all tools to come that are mostly combinations of well-tested Unix utilities) are certainly much more cost-effective. And actually, I quite agree that openrc is a mediocre project, which is still vastly better than the disaster called systemd
| rich0 wrote: | | If I want to do all that stuff in your "run/finish" scripts with systemd it is usually just a one-liner in a config file, assuming upstream didn't already provide that line. |
Nice advantange, not unlike the advantages of many alternative init/rc systems when systemd did not yet have a cacophony of all those bells and whistles 
And for most use cases, these bells and whistles can already be implemented elegantly using one-liners in the `./run' / `./finish' scripts.
| rich0 wrote: | | Ultimately openrc uses bash which is turing complete, so of course you can do anything in an init.d script that systemd does, and since systemd units can call bash scripts the reverse is also true. If you limit yourself to declarative configuration I'd argue that you can do a lot more with systemd. |
And scripting (when done right, and preferably using more rigorously designed languages like rc(1)) is provably the simpler, securer and more flexible way.
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C |
|
| Back to top |
|
|
rich0
Developer
Joined: 15 Sep 2002
Posts: 161
|
| Posted: Mon Mar 12, 2018 4:16 pm Post subject: |
|
|
| CasperVector wrote: | | And scripting (when done right, and preferably using more rigorously designed languages like rc(1)) is provably the simpler, securer and more flexible way. |
Sure, I'll grant flexibility, but that comes at a cost. Otherwise I'll take declarative syntax over procedural syntax any day. It certainly is simpler.
Now, certainly systemd itself is more complex than openrc, but it is also more capable, and generally has a lot more investment in maintenance.
If you really prefer openrc by all means use it. It isn't like it is going to magically stop working. There are certainly a number of others who share your opinions, and perhaps even a majority of Gentoo developers are among them. I personally suspect that in the long term it will look more and more like an anachronism, but nobody knows the future with certainty. |
|
| Back to top |
|
|
CasperVector
Apprentice
Joined: 03 Apr 2012
Posts: 156
|
| Posted: Mon Mar 12, 2018 4:31 pm Post subject: |
|
|
| rich0 wrote: | | Sure, I'll grant flexibility, but that comes at a cost. Otherwise I'll take declarative syntax over procedural syntax any day. It certainly is simpler. |
Agreed, so I usually stick to a certain subset of rc(1) when writing `./run' / `./finish' scripts, so that they would be similar to these which I find as declarative as systemd unit files.
| rich0 wrote: | Now, certainly systemd itself is more complex than openrc, but it is also more capable, and generally has a lot more investment in maintenance.
If you really prefer openrc by all means use it. It isn't like it is going to magically stop working. |
Yes, the capabilities in systemd that came at some huge costs which can be completely avoided by factoring out the functionalities, as discussed. Anyway, you are free to waste your time on whatever you like.
And of course I use s6/s6-rc; actually, I have already migrated completely to s6/s6-rc on all my machines. Nevertheless, please by all means continue to pretend that I preferred openrc.
| rich0 wrote: | | There are certainly a number of others who share your opinions, and perhaps even a majority of Gentoo developers are among them. I personally suspect that in the long term it will look more and more like an anachronism, but nobody knows the future with certainty. |
Well, good luck then with your notion of "anachronism".
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C
Last edited by CasperVector on Sun Mar 18, 2018 8:29 am; edited 3 times in total |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Mon Mar 12, 2018 5:11 pm Post subject: |
|
|
| rich0 wrote: | | I personally suspect that in the long term it will look more and more like an anachronism, but nobody knows the future with certainty. |
IMHO, it is systemd that will look like an anachronism when RedHat abandons it for another shiny toy as they have with so many projects. In the mean time, the old unix tools continue to evolve rather be replaced with something totally new. But that's just my opinion. |
|
| Back to top |
|
|
rich0
Developer
Joined: 15 Sep 2002
Posts: 161
|
| Posted: Mon Mar 12, 2018 5:37 pm Post subject: |
|
|
| Tony0945 wrote: | | rich0 wrote: | | I personally suspect that in the long term it will look more and more like an anachronism, but nobody knows the future with certainty. |
IMHO, it is systemd that will look like an anachronism when RedHat abandons it for another shiny toy as they have with so many projects. In the mean time, the old unix tools continue to evolve rather be replaced with something totally new. But that's just my opinion. |
You say that as if bash-based service managers haven't also replaced over time. OpenRC is itself a completely new service manager that replaced baselayout-1.
I'm sure systemd itself will not last forever. However, I suspect whatever replaces it will look a lot more like systemd than what came before.
I will share some of your frustration with the tendency of projects to just reinvent the wheel for its own sake. People often don't like being caretakers of things others have built. |
|
| Back to top |
|
|
jd2066
Apprentice
Joined: 04 Jun 2006
Posts: 155
|
| Posted: Tue Mar 13, 2018 1:01 am Post subject: |
|
|
| CasperVector wrote: | | jd2066 wrote: | It seems like tmpfiles.d just centralizes the configuration of temporary directories/files removing the need for the programs themselves, init scripts, etc to create and set proper permissions on the needed temporary directories/files.
Why put code in each init script for a daemon that needs certain temporary directories/files to eixst before it starts when tmpfiles.d can handle that? |
Because the centralised way requires much more code than the decentralised way does, and is much less flexible, as already shown (and nobody seemed to oppose).
Actually, I found the usage of install(1) much easier to understand than that of tmpfiles.d, which is unsurprising given the background of Unix philosophy. |
Why does the amount of code involved matter in regards to using daemon init scripts to create temporary directories/files vs using tmpfiles.d to the same thing?
| CasperVector wrote: | | jd2066 wrote: | If all applications defined their temporary directories/files a sub directories of /run and /var instead of creating things on-the-fly in /tmp then /tmp would likely not be needed anymore.
I don't know if that is one of their goals with tmpfiles.d or not but it would certainly be possible as the main purpose of a world writable directory like /tmp is to allow applications to create their own temporairy directories/files so if those were already created in other places then /tmp wouldn't really be needed at all. |
Which seems independent of whether tmpfiles.d is used or not. |
You are correct that removing /tmp would be independant on use of tmpfiles.d.
I was refering to the idea of a world wriable temporary directory and /tmp was the first that came to mind.
Things like /run are not world writable and the daemons themselves can't create anything in there if they don't run as root so a tool like tmpfiles.d is needed to create directories with the required permissions for the target daemon to use.
Without tmpfiles.d then you need to handle that with an init script which is more de-centralized and not as easy to manage.
| CasperVector wrote: | | jd2066 wrote: | | Otherwise, systemd at first glace seems like the better init system then openrc as it enables all kinds of nifty automatic configuration and service dependency management that no other init system including openrc is able to do. |
(Did not notice this in the first place.) May I ask for some examples? Actually, I have still not found a single thing systemd does that daemontools-like init/rc systems cannot do better. In most cases, just remember that chainloading is your friend. |
Here are a few advantages of systemd over openrc:
* systemd can track what daemons are running and restart them if they crash.
* systemd unit files in theory are simpler to deal with then init scripts. In Practive the systemd unit files can be more complicated in some cases.
There are more but I don't have time to list them all right now as I have other things to do but I can amed this list later. |
|
| Back to top |
|
|
CasperVector
Apprentice
Joined: 03 Apr 2012
Posts: 156
|
| Posted: Tue Mar 13, 2018 1:39 am Post subject: |
|
|
| jd2066 wrote: | | Why does the amount of code involved matter in regards to using daemon init scripts to create temporary directories/files vs using tmpfiles.d to the same thing? |
Because the cost of maintenance is proportional to the total complexity of the implementation, and especially to the amount of code that is not yet well-tested. I believe many of us have seen the myriad ways systemd can fail unintuitively and impressively; in comparison, there have been very few ways s6/s6-rc are known to fail, as all users on their mailing lists can tell. Yet s6/s6-rc (in combination with Unix utilities) are even more powerful than systemd, because they are designed with simplicity and flexibility (or iow, minimising the total complexity of the system) in mind.
| jd2066 wrote: | Things like /run are not world writable and the daemons themselves can't create anything in there if they don't run as root so a tool like tmpfiles.d is needed to create directories with the required permissions for the target daemon to use.
Without tmpfiles.d then you need to handle that with an init script which is more de-centralized and not as easy to manage. |
Decentralised? Yes. Harder to manage? No. And as shown, this way is actually also much more flexible, exactly due to its decentralised nature.
| jd2066 wrote: | Here are a few advantages of systemd over openrc:
* systemd can track what daemons are running and restart them if they crash.
* systemd unit files in theory are simpler to deal with then init scripts. In Practive the systemd unit files can be more complicated in some cases.
There are more but I don't have time to list them all right now as I have other things to do but I can amed this list later. |
openrc is not a daemontools-like init/rc system; s6/s6-rc, s6/anopa and nosh are, and all of them work by supervising processes (what you call "tracking daemon states").
As for the myth on the "simplicity" of systemd unit files, you did not really seem to have read this and this.
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C |
|
| Back to top |
|
|
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom
|
| Posted: Wed Mar 14, 2018 2:52 am Post subject: |
|
|
| CasperVector wrote: | | As for the myth on the "simplicity" of systemd unit files, you did not really seem to have read this and this. |
I can vouch for that. I spent days trying to get systemd on my family's PC to launch a backup script at shutdown and wait for the script to run to completion before halting and powering down the PC. There are umpteen posts on the Web asking how to run a script at shutdown and/or reboot in distributions that use systemd. The unit files that most of them end up using appear to work, but only because the job is short enough that it completes before systemd reaches the end of the shutdown and/or reboot process. Take a look at the Arch Linux Forums thread controlling systemd shutdown order started by a user trying to find a way to get systemd to launch a script at shutdown (or reboot) and wait until the script completes before stopping user processes. She never got a proper answer, only that 'it is possible'.
It is possible to make systemd wait for a long-running script to run to completion at shutdown -- I got a working unit file and Bash script combination in the end -- but it isn't as simple as it would seem to write a unit file to stop systemd doing so many things in parallel, and not that straightforward to discriminate between reboot and shutdown in systemd, either. On the other hand, with OpenRC you can put a Bash script in /etc/local.d/ that includes a check on the runlevel and it will be launched and will run to completion [1]. (In case anyone is wondering, you can't drop this sort of script in /lib/systemd/system-shutdown/ in a systemd distribution, because scripts in that directory are launched late in the shutdown process, after file systems have been mounted read-only.)
[1] Running a shell script at shutdown only (not at reboot) – a comparison between OpenRC and systemd
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.
Fitzcarraldo's blog |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Apr 23, 2018 7:12 pm Post subject: |
|
|
| rich0 wrote: | | Ultimately openrc uses bash which is turing complete, so of course you can do anything in an init.d script that systemd does, and since systemd units can call bash scripts the reverse is also true. If you limit yourself to declarative configuration I'd argue that you can do a lot more with systemd. |
And more bs masquerading as expertise.
openrc does not use bash, ffs.
But then you know all this, right, so this is just crap-talking. Still at least it shows the perils of limited IRC and confirmation bubbles.
As for limiting oneself, openrc already had a much better declarative format, way before systemdbust was a glint in Poeterrring's evil-eye.
It just can be extended easily, whereas systemdbust ends up shelling out anyway, with much less grace. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
